To dBFS or not dBFS - New SDR# release #announcements


prog
 

This new release addresses a long standing annoyance in the FFT display when changing either the FFT bins (processing gain) or the Window function. Now the peak reading is consistent over the different settings and matches the dBFS definition perfectly.
Why is this important? 0 dBFS should now inform you if the ADC is at the edge of clipping so you can act on the problem (for example, change the gain distribution).
This is especially useful for our #MWDX friends who can optimize the gain to pull weak signals while avoiding the saturation of the ADC stage.

Download: https://airspy.com/download


jdow
 

Now you can add a visual gain with a thin 0dBFS line on the screen so the display can be user calibrated to "best estimate" of real dBm.

Simon ought to add that thin (blue?) line across his spectrum display, too.

HOWEVER, 10 signals at -10dBFS are still going to give you problems. The peak signal in this case is 100 times each individual signal. Gotta keep that in mind when "good enough" is not an option in the "quest for best."

{^_-}

On 20200927 09:05:09, prog wrote:
This new release addresses a long standing annoyance in the FFT display when changing either the FFT bins (processing gain) or the Window function. Now the peak reading is consistent over the different settings and matches the dBFS definition perfectly.
Why is this important? 0 dBFS should now inform you if the ADC is at the edge of clipping so you can act on the problem (for example, change the gain distribution).
This is especially useful for our #MWDX friends who can optimize the gain to pull weak signals while avoiding the saturation of the ADC stage.

Download: https://airspy.com/download


prog
 

On Sun, Sep 27, 2020 at 07:09 PM, jdow wrote:
Now you can add a visual gain with a thin 0dBFS line on the screen so the display can be user calibrated to "best estimate" of real dBm.

Simon ought to add that thin (blue?) line across his spectrum display, too.

HOWEVER, 10 signals at -10dBFS are still going to give you problems. The peak signal in this case is 100 times each individual signal. Gotta keep that in mind when "good enough" is not an option in the "quest for best."

{^_-}
Manual IQ scaling is easier.


chutton12000
 

Yeah, being an EE I am used to wearing srist straps to avoid sending CMOS to an earky death. But sometimes it dies anywat.
The good side is another Discovery sale for you.
If only you woukd make a version that recorded the entire MW band,

Chuck


From: airspy@groups.io <airspy@groups.io> on behalf of prog <info@...>
Sent: Sunday, September 27, 2020 9:05 AM
To: airspy@groups.io <airspy@groups.io>
Subject: [Special] [airspy] To dBFS or not dBFS - New SDR# release #announcements
 
This new release addresses a long standing annoyance in the FFT display when changing either the FFT bins (processing gain) or the Window function. Now the peak reading is consistent over the different settings and matches the dBFS definition perfectly.
Why is this important? 0 dBFS should now inform you if the ADC is at the edge of clipping so you can act on the problem (for example, change the gain distribution).
This is especially useful for our #MWDX friends who can optimize the gain to pull weak signals while avoiding the saturation of the ADC stage.

Download: https://airspy.com/download


Phil Karn
 

On 9/27/20 09:05, prog wrote:
This new release addresses a long standing annoyance in the FFT
display when changing either the FFT bins (processing gain) or the
Window function. Now the *peak reading* is consistent over the
different settings and matches the dBFS definition perfectly.

What *is* the definition of 0 dBFS? I've seen at least two conventions
that differ by 3 dB.

And how does a 0dBFS signal consisting of real samples compare with a 0
dBFS signal with complex samples and half the sample rate? At the
moment, I consider the power in a signal to be the sample rate times the
square of each component of the sample.

All the SDR front ends I've used before have complex outputs. Because
the Airspy supports both complex and real I'm having to confront this
for the first time. Real is its natural mode so that's the one I prefer
using, but I want the results to be consistent.

Phil


jdow
 



On 20200928 16:22:46, Phil Karn wrote:
On 9/27/20 09:05, prog wrote:
This new release addresses a long standing annoyance in the FFT
display when changing either the FFT bins (processing gain) or the
Window function. Now the *peak reading* is consistent over the
different settings and matches the dBFS definition perfectly.

What *is* the definition of 0 dBFS? I've seen at least two conventions
that differ by 3 dB.

And how does a 0dBFS signal consisting of real samples compare with a 0
dBFS signal with complex samples and half the sample rate? At the
moment, I consider the power in a signal to be the sample rate times the
square of each component of the sample.

All the SDR front ends I've used before have complex outputs. Because
the Airspy supports both complex and real I'm having to confront this
for the first time. Real is its natural mode so that's the one I prefer
using, but I want the results to be consistent.

Phil
FS is when the peak signal voltage for all signals summed worst case is 1.000000. It is when the A/D converter would wrap. Ain't no 3 dB difference possible here. If at any part of a cycle the voltage could exceed the A/D full scale value then you are in plus dBFS territory. At least that definition has a real physical meaning.

{^_^}


jdow
 

BTW, complex is taking alternate Real samples to I and Q respectively.
{o.o}

On 20200928 16:22:46, Phil Karn wrote:
On 9/27/20 09:05, prog wrote:
This new release addresses a long standing annoyance in the FFT
display when changing either the FFT bins (processing gain) or the
Window function. Now the *peak reading* is consistent over the
different settings and matches the dBFS definition perfectly.

What *is* the definition of 0 dBFS? I've seen at least two conventions
that differ by 3 dB.

And how does a 0dBFS signal consisting of real samples compare with a 0
dBFS signal with complex samples and half the sample rate? At the
moment, I consider the power in a signal to be the sample rate times the
square of each component of the sample.

All the SDR front ends I've used before have complex outputs. Because
the Airspy supports both complex and real I'm having to confront this
for the first time. Real is its natural mode so that's the one I prefer
using, but I want the results to be consistent.

Phil









Phil Karn
 

On 9/28/20 16:35, jdow wrote:
BTW, complex is taking alternate Real samples to I and Q respectively.

Only in a conceptual sense, i.e., 10 MHz complex is the same number of
bits/sec as 20 MHz real. I don't think you can just stuff real samples
into I and Q and have a complex signal, at least not at the same data
rate. (I'm omitting the trivial procedure of converting 20 MHz real-only
into 20 MHz complex where all the imaginary components are zero.) It
takes a spectral shift and a decimation operation, which libairspy does
for you if you ask for complex samples. This takes a significant amount
of CPU time that I can avoid since I do everything in the frequency
domain and my first operation is a forward FFT.

Phil


jdow
 

Seriously, it works. That is what happens in the rtlsdr code in the SDR I am building and readouts are exactly as expected.
{o.o}

On 20200928 16:52:06, Phil Karn wrote:
On 9/28/20 16:35, jdow wrote:
BTW, complex is taking alternate Real samples to I and Q respectively.

Only in a conceptual sense, i.e., 10 MHz complex is the same number of
bits/sec as 20 MHz real. I don't think you can just stuff real samples
into I and Q and have a complex signal, at least not at the same data
rate. (I'm omitting the trivial procedure of converting 20 MHz real-only
into 20 MHz complex where all the imaginary components are zero.) It
takes a spectral shift and a decimation operation, which libairspy does
for you if you ask for complex samples. This takes a significant amount
of CPU time that I can avoid since I do everything in the frequency
domain and my first operation is a forward FFT.

Phil











Phil Karn
 

On 9/28/20 16:33, jdow wrote:
 
FS is when the peak signal voltage for all signals summed worst case
is 1.000000. It is when the A/D converter would wrap. Ain't no 3 dB
difference possible here. If at any part of a cycle the voltage could
exceed the A/D full scale value then you are in plus dBFS territory.
At least that definition has a real physical meaning.
I agree this is the preferred definition, but it's not the only one.
Think peak vs RMS. The AES (Audio Engineering Society) standard says a
full-scale sine wave is 0 dBFS, which means a full-scale square wave
will be +3dBFS. But there's an ITU-T standard (G.100.1) that defines a
full scale *square* wave as 0 dB. A sine wave thus cannot be above -3dB
without clipping, and it is impossible for any waveform to have a
positive amplitude. See https://en.wikipedia.org/wiki/DBFS

Hence multiple conventions with a 3dB difference, and that's just for a
single real channel. I want a convention where the same signal into a R2
will have the same digital amplitude with 20 Ms/s real sampling as with
10 Ms/s complex sampling. I think I'm off by 3 dB somewhere in my own
code, which is what got me thinking about this.

Phil


Phil Karn
 

On 9/28/20 16:59, jdow wrote:
Seriously, it works. That is what happens in the rtlsdr code in the
SDR I am building and readouts are exactly as expected.
You sure about that? I know that you can't just stuff real samples into
the real and imaginary inputs of a complex FFT and directly obtain the
transform of the real sequence. You have to post-process the FFT output.
It's not terribly difficult but it does cost a little more. This is
written up in the manual for FFTW3 and in a TI app note I just found.

I.e., a 2N-point real-only FFT costs more than a N-point complex FFT,
but not nearly as much as a 2N-point complex FFT.

So by requesting a 20 Ms/s real sample stream from my R2 I avoided the
cost of libairspy's real to complex conversion, but I then had to spend
some of these savings on the extra cost of FFTW3's real-input FFT. It
was still worth it, but the savings weren't as great as I originally hoped.

Phil


jdow
 

On 20200928 17:30:42, Phil Karn wrote:
On 9/28/20 16:33, jdow wrote:
 
FS is when the peak signal voltage for all signals summed worst case
is 1.000000. It is when the A/D converter would wrap. Ain't no 3 dB
difference possible here. If at any part of a cycle the voltage could
exceed the A/D full scale value then you are in plus dBFS territory.
At least that definition has a real physical meaning.
I agree this is the preferred definition, but it's not the only one.
Think peak vs RMS. The AES (Audio Engineering Society) standard says a
full-scale sine wave is 0 dBFS, which means a full-scale square wave
will be +3dBFS. But there's an ITU-T standard (G.100.1) that defines a
full scale *square* wave as 0 dB. A sine wave thus cannot be above -3dB
without clipping, and it is impossible for any waveform to have a
positive amplitude. See https://en.wikipedia.org/wiki/DBFS

Hence multiple conventions with a 3dB difference, and that's just for a
single real channel. I want a convention where the same signal into a R2
will have the same digital amplitude with 20 Ms/s real sampling as with
10 Ms/s complex sampling. I think I'm off by 3 dB somewhere in my own
code, which is what got me thinking about this.

Phil
The A/D converter does not know RMS from Smurfs. It does know converting voltage to digits and nothing else. This has nothing to do with AES or anything else. It is full scale. You cannot readily map it to dBm, AES dB, ITU dB, or anything else meaningful. You do not have a power rating for it. There is no impedance at the A/D converter that means anything. All it means is that whatever the power is into the A/D converter it is at full scale for the peak voltage on the A/D input. 1/2 that voltage is approximately -6 dBFS. The power at your receiver input is 6 dB below the power level which starts making your spectrum look like hell whatever, that power level really is. All the other scale systems can be mapped into dBFS in the SDR world via fairly simple calibration steps, offsets on the spectrum scales.

Real and complex sampling do not change this. In the first place they are exactly the same thing. The sampling takes place in one single stream. You get quadrature because sampling is taking place with four times per cycle at the incoming center frequency. The quadrature comes automatically and is accurate to the degree that the clock triggers the sample at the same point on the actual LO output. Square wave generation helps. But a divide by four Johnson counter still has subtle imperfections. Thus the same argument that applies to "real" samples applies to complex. At the moment I is at peak of a single signal in the passband Q is zero. So the power is the same when you step forward 90 degrees and Q is maximum and I is minimum. It is still the same at any phase relationship because "power", I^2 + Q^2, stays constant. 0.707 * Vfs at 45 degrees on both I and Q come to 0.5 + 0.5 = 1.0. But that really tells you what power you might be sending to the input. It simply tells you that a fraction of a dB more is going to make a mess of your ability to detect small signals.

{^_^}


Martin Smith
 

I just got around to downloading this now, and is my habit I upload most things I download (excluding source code) to virustotal, and 13 out of 66 virus scan engines picked up 5 files as being in some way potentially malicious, see below:

spyserver.exe can easily be mistaken, it is a server that accepts commands from a remote machine and uploads (FFT and IQ) data to machines on the internet. It would be very bad if it was not being detected as something that could potentially be malicious, which it is not. It is good that it is being flagged, shows that the algorithms being used to detect potentially malicious code are actually working.

shark.dll I'm really not sure why this is being flagged, anyone have an idea ? I thought that the shark DLL was mostly DSP.

spyserver_ping.exe again sends commands to a remote machine and gets data back, can easily be detected as something that could potentially be malicious, which it is not.

airspyhf.dll I'm not sure why it is being flagged, any idea ? Maybe because it communicates at a low level with a USB device.

airspy_adsb.exe it is a server that local/remote machines connect to to download data, can easily be detected as something that could potentially be malicious, which it is not.



https://www.virustotal.com/gui/file/abaa2e7a66a74b523dcb81cfdac08f4cc4adef105c580f7b023c0938181850a5/relations
date of last scan of a file with the same hash: 2020-09-29
How many detection engines thought that something might be bad: 11 / 71
What type of file is this: Win32 EXE
What is the name of this file: spyserver.exe
SHA-256 1c28a2453cd1b2383b658531407ef52821be180b4cb4fc069a8f2b8de59feff6
Date Bundled 2020-09-27 22:40:14
File Size 643.00 KB

2020-09-28
3/70
Win32 DLL
shark.dll
SHA-256 bd8500f5da983f94a67ff900edbf7379929e4f4b7e53f9d4c43dc2c3dfe86947
Date Bundled 2020-09-21 15:20:20
File Size 326.00 KB

2020-09-29
4 / 68
Win32 EXE
spyserver_ping.exe
SHA-256 643ff6cf154eb04e2d6a8adaf596ce11d3cfe0e42d76f91617e5f6eedd66efcc
Date Bundled 2020-09-27 22:40:04
File Size 106.50 KB

2020-09-26
1 / 70
Win32 DLL
airspyhf.dll
SHA-256 fc53d024b647cc68c0ff1a9a82bd40fe20f4ac2884968df27b8ea88ff213696b
Date Bundled 2020-09-21 15:49:56
File Size 291.00 KB

2020-09-26
1 / 71
Win32 EXE
airspy_adsb.exe
SHA-256 dabc113af3a1d89d326c86f1825c17a7fb9c61506dfb3530a6eec0281cb97659
Date Bundled 2019-11-18 14:34:50
File Size 120.50 KB


Martin Smith
 

Is there any possibility that these two dll's have some type of performance debugging enabled ? If I compare them to airspy.dll which is not being flagged, it is not generating any performance debugging information.

airpsyhf.dll
https://www.virustotal.com/gui/file/fc53d024b647cc68c0ff1a9a82bd40fe20f4ac2884968df27b8ea88ff213696b/behavior
shark.dll
https://www.virustotal.com/gui/file/bd8500f5da983f94a67ff900edbf7379929e4f4b7e53f9d4c43dc2c3dfe86947/behavior

airspy.dll
https://www.virustotal.com/gui/file/54593f66f36f5991cf1528561dd7c3f3f7d5e81bd768e3935ae64bfcd6346574/detection


prog
 

Some dlls are optimized using PGO (Profile Guided Optimizations). Some average anti-viruses may get a false positive.


Martin Smith
 

If you look at the two links below those dll's are modifying entries in the registry, deleting entries in the registry (I'm assuming when finished) and launching (microsoft) applications. I can see how an virus detection engine would get a false positive.


prog
 

On Tue, Sep 29, 2020 at 02:24 PM, Martin Smith wrote:
If you look at the two links below those dll's are modifying entries in the registry, deleting entries in the registry (I'm assuming when finished) and launching (microsoft) applications. I can see how an virus detection engine would get a false positive.
If you have time to debug these average anti-viruses, get IDA and disassemble the dlls. Look for anything that could access the registry. If nothing is found, maybe it's the OS itself that is enabling some performance stuff.


Martin Smith
 

After a bit of digging, one is using a neural network, so a false positive on it's pattern matching.
SecureAge APEX - Malicious
I submitted shark.dll as a false positive to https://www.secureaplus.com/features/antivirus/report-false-positive/

The second one is surprise surprise also machine learning (neural network) based, so a false positive on it's pattern matching.
BitDefenderTheta - Gen:NN.ZedlaF.34254.uy4@amMEQZki
I submitted shark.dll as a false positive to https://www.bitdefender.com/submit/

The third one is also an Artificial Intelligence Antivirus (it is a neural network), yet another false positive on it's pattern matching.
Bkav - W32.AIDetectVM.malware2
They do not appear to have a way to submit false positives, which is not a good sign.


David J Taylor
 

From: Phil Karn
[]
I agree this is the preferred definition, but it's not the only one.
Think peak vs RMS. The AES (Audio Engineering Society) standard says a
full-scale sine wave is 0 dBFS, which means a full-scale square wave
will be +3dBFS. But there's an ITU-T standard (G.100.1) that defines a
full scale *square* wave as 0 dB. A sine wave thus cannot be above -3dB
without clipping, and it is impossible for any waveform to have a
positive amplitude. See https://en.wikipedia.org/wiki/DBFS

Hence multiple conventions with a 3dB difference, and that's just for a
single real channel. I want a convention where the same signal into a R2
will have the same digital amplitude with 20 Ms/s real sampling as with
10 Ms/s complex sampling. I think I'm off by 3 dB somewhere in my own
code, which is what got me thinking about this.

Phil
==========================================

It's the difference between peak voltage and RMS power, isn't it?

The R2 I have accepts only a single real channel, as do all the SDRs I have. With quadrature sampling you would have two signals with the same peak value, so you could measure either, but not both.

Cheers,
David
--
SatSignal Software - Quality software for you
Web: https://www.satsignal.eu
Email: david-taylor@...
Twitter: @gm8arv


jdow
 

1) There are examples of malware the Internet Storm Center has detected in their honeypots that give 0 Virus Total hits.
2) I have compiled DLLs that probably should have been detected as malware and were not for whatever reason. (I had to work HARD to get around an XP misfeature for MIDI dlls that could prevent a machine from booting. Apparently MIDI starts before networking and messing with anything networking before a user is logged in locks the machine. And ANY application starts MIDI as a general course, even "ipconfig.exe". So during boot some application or dll tried to open midi. That engaged my dll. That tried to taste the network as it was a MIDI translation device to talk midi via networking, the first to do so. I found a fix for the problem. Then years later another such DLL was spuriously caught by Windows Defender, which caused a crisis when the dll could not be run on a customer's theater machine aboard a cruise ship.)
3) The very nastiest viruses have to be detected at run time by their patterns of operation. Every copy is different.
4) Most (all?) download detection appears to be via checksums for patterns of bytes within the files. Theoretically duplicating these patterns should be difficult. BUT, "not so much" if the patterns are not big enough.

Virus detection appears to be an arcane art form. New stuff is not detected for a period of time before somebody turns it in as suspect. That period of time can be annoyingly long. It can also be gratifyingly short. So a lot of your decision MUST involves "how well do you know and trust the source for the download?" And in a very recent example on either Youssef's list here or Simon's list, I forget which, involved a generically worded link to a password protected document from a source I'd not notice posting before. (Raise your hand if you opened it and your computer is still useful.)

{^_^}

On 20200929 01:45:21, Martin Smith via groups.io wrote:
I just got around to downloading this now, and is my habit I upload most things I download (excluding source code) to virustotal, and 13 out of 66 virus scan engines picked up 5 files as being in some way potentially malicious, see below:

spyserver.exe can easily be mistaken, it is a server that accepts commands from a remote machine and uploads (FFT and IQ) data to machines on the internet. It would be very bad if it was not being detected as something that could potentially be malicious, which it is not. It is good that it is being flagged, shows that the algorithms being used to detect potentially malicious code are actually working.

shark.dll I'm really not sure why this is being flagged, anyone have an idea ? I thought that the shark DLL was mostly DSP.

spyserver_ping.exe again sends commands to a remote machine and gets data back, can easily be detected as something that could potentially be malicious, which it is not.

airspyhf.dll I'm not sure why it is being flagged, any idea ? Maybe because it communicates at a low level with a USB device.

airspy_adsb.exe it is a server that local/remote machines connect to to download data, can easily be detected as something that could potentially be malicious, which it is not.



https://www.virustotal.com/gui/file/abaa2e7a66a74b523dcb81cfdac08f4cc4adef105c580f7b023c0938181850a5/relations
date of last scan of a file with the same hash: 2020-09-29
How many detection engines thought that something might be bad: 11 / 71
What type of file is this: Win32 EXE
What is the name of this file: spyserver.exe
SHA-256	1c28a2453cd1b2383b658531407ef52821be180b4cb4fc069a8f2b8de59feff6
Date Bundled	2020-09-27 22:40:14
File Size	643.00 KB

2020-09-28
3/70
Win32 DLL
shark.dll
SHA-256	bd8500f5da983f94a67ff900edbf7379929e4f4b7e53f9d4c43dc2c3dfe86947
Date Bundled	2020-09-21 15:20:20
File Size	326.00 KB

2020-09-29
4 / 68
Win32 EXE
spyserver_ping.exe
SHA-256	643ff6cf154eb04e2d6a8adaf596ce11d3cfe0e42d76f91617e5f6eedd66efcc
Date Bundled	2020-09-27 22:40:04
File Size	106.50 KB

2020-09-26
1 / 70
Win32 DLL
airspyhf.dll
SHA-256	fc53d024b647cc68c0ff1a9a82bd40fe20f4ac2884968df27b8ea88ff213696b
Date Bundled	2020-09-21 15:49:56
File Size	291.00 KB

2020-09-26
1 / 71
Win32 EXE
airspy_adsb.exe
SHA-256	dabc113af3a1d89d326c86f1825c17a7fb9c61506dfb3530a6eec0281cb97659
Date Bundled	2019-11-18 14:34:50
File Size	120.50 KB