MATLAB SigDigger User manual

User’s Manual
Version 0.3.0
Gonzalo José Carracedo Carballal
June 27, 2022

Contents
1 Introduction 5
About SigDigger ................................. 5
About this manual ................................ 5
About the author ................................. 6
2 Installing SigDigger 7
GNU/Linux .................................... 7
macOS ...................................... 8
Microsoft Windows ............................... 8
Building from sources .............................. 9
Fully-automated build using BLSD (GNU/Linux only) .......... 10
Manual compilation (all systems) .................... 11
3 Basic operation 13
Interface overview ................................ 13
Configuring the signal source .......................... 14
SDR device ................................. 15
File source ................................. 16
Source parameters ............................ 17
Starting a capture ................................ 18
Real-time source tweaks ............................ 22
Adjusting the FFT ................................ 24
Listening to the radio: audio preview ...................... 26
Defining a channel ............................. 26
Minor tweaks ................................ 28
Saving audio ................................ 29
4 Channel inspection 31
Deferred inspection: the time window ..................... 32
Opening the Time window ........................ 33
Display controls .............................. 34
Basic measurements ........................... 36
Measurements over selected data .................... 37
Periodic selection ............................. 38
Saving samples .............................. 39
Carrier recovery .............................. 40
Transforms ................................. 42
3

4CONTENTS
Sampling and decision .......................... 43
Real-time inspection: inspection tabs ..................... 49
DSP chain .................................. 49
Inspection tabs ............................... 52
Using the Generic Channel Inspector tab ................ 52
Spectrum sources ............................. 55
Fine-tuning ................................. 56
Parameter estimation ........................... 57
Demodulator controls ........................... 59
Data forwarding .............................. 62
5 Panoramic spectrum 65
Interface overview ................................ 65
Strategy and partitioning ............................ 66
Saving data .................................... 67

1
Chapter
Introduction
Thank you for choosing SigDigger. The following chapters attempt to cover all the
relevant functions from the perspective of a user with minimal knowledge on digital
signal processing and radio signals. It also includes practical examples for many real-
world applications, including blind demodulation of radio signals and data acquisition
from amateur satellites.
About SigDigger
SigDigger is a free
1
graphical digital signal analyzer. Its main use case is the reverse
engineering of radio signals, in which some (or all) parameters of the signal of interest
are unknown. This is achieved by a set of features that enable interactive measuring
and guessing of the unknown parameters.
SigDigger is compatible with most SDR receivers in the consumer market thanks to
the SoapySDR
2
support library. It also supports record and playback of RF/IF sample
data to and from multiple file formats, including WAV and raw complex float I/Q.
In addition to the reverse engineering-related features, it can be used as a regular
spectrum analyzer with multiple visualization functions. It also support real-time audio
demodulation of FM, AM and SSB signals.
About this manual
This manual intends to be a continuous effort on documenting existing features of
SigDigger as thoroughly as possible. Unfortunately, as I write in English considerably
slower than in C, many of the most interesting features of the software have been left
uncovered (for now). Take this manual as a draft I will be updating from time to time.
The cover picture is a Peter de Jong attractor
3
, generated with Fyre
4
. This particular
1https://www.gnu.org/philosophy/free-sw.html
2https://github.com/pothosware/SoapySDR/wiki
3http://paulbourke.net/fractals/peterdejong/peterdejong.pdf
4https://en.wikipedia.org/wiki/Fyre_(software)
5

6CHAPTER 1. INTRODUCTION
realization of the attractor is a fractal
5
, and depicts (in words of Iban EB3FRN
6
) the
fractal nature of amateur radio as a hobby.
About the author
Gonzalo José Carracedo Carballal
7
(BatchDrake) is a software engineer with a back-
ground in cybersecurity, mathematical engineering and astrophysics. He has been in
love with radio and radioastronomy since he first watched Contact
8
circa 1997. He
likes coding for fun in his spare time and maintains a number of free software projects
in his public GitHub account9.
5https://es.wikipedia.org/wiki/Fractal
6https://www.eb3frn.net/
7https://actinid.org
8https://www.imdb.com/title/tt0118884/
9https://github.com/BatchDrake

2
Chapter
Installing SigDigger
SigDigger is designed to work in most Unix-like operating systems. Nonetheless,
official support with precompiled binaries is only available for x86-64 based modern
GNU/Linux and macOS systems.
Precompiled releases can be downloaded directly from the GitHub page
1
. Usually, two
types of releases are available:
•Development builds, containing the latest features with minimal testing.
• Stable releases, with the latest bug-fixes and ready for inclusion in 3rd-party
repositories.
GNU/Linux
Precompiled binaries in AppImage
2
format exist for x86-64 GNU/Linux systems with
glibc version 2.27 and newer. AppImage files are self-contained executables and
therefore easy to run. Open a terminal, change to the directory in which the AppImage
file was downloaded and give execute permissions to it (this is something that needs
to be done only once):
$ chmod a+x SigDigger-0.3.0-x86_64-full.AppImage
Now you can execute by typing:
$ ./SigDigger-0.3.0-x86_64-full.AppImage
Pro Tip: The AppImage file is a container not only for SigDigger but also for suscli and
RMSViewer
a
. Depending on the file name of the AppImage, one of these tools is exe-
cuted. Some users find it handy to have these tools available from the command line
by creating symbolic links to them in directories of their $PATH variable. Assuming that
/usr/local/bin is in your $PATH and the AppImage file is in $PWD, run:
$ sudo ln -s $PWD/SigDigger-0.3.0-x86_64-full.AppImage
1https://github.com/BatchDrake/SigDigger/releases
2https://appimage.org/
7

8CHAPTER 2. INSTALLING SIGDIGGER
/usr/local/bin/SigDigger
$ sudo ln -s $PWD/SigDigger-0.3.0-x86_64-full.AppImage
/usr/local/bin/RMSViewer
$ sudo ln -s $PWD/SigDigger-0.3.0-x86_64-full.AppImage
/usr/local/bin/suscli
This will let you run SigDigger , suscli and RMSViewer from anywhere in the command
line.
ahttps://batchdrake.github.io/suscli/
macOS
Precompiled bundles are distributed in .dmg image files for x86-64 processors only.
Although there is no official support for M1 processors (yet), x86-64 bundles can still
be executed in newer computers by installing Rosetta3.
Once you have downloaded the .dmg file, opening SigDigger is straight-forward. Just
open the .dmg file and double-click the SigDigger icon to start it.
Note: SigDigger bundles are not currently being signed. You may need to authorize the
execution of SigDigger explicitly by enabling running software from unidentified developers
a
.
ahttps://support.apple.com/guide/mac-help/mh40616/mac
Microsoft Windows
Experimental builds of SigDigger for x64 Microsoft Windows systems exist, in the
form of a redistributable ZIP file containing the main SigDigger executable, along
with all its dependencies. This build was possible thanks to Ángel Fernández
4
, who
managed to port most of the Unix-specific code and linked SigDigger (along with all
its dependencies) against MinGW-w64
5
libraries. Alas, as of March 2022, only local
analyzers are supported (which is what most people normally use), with out-of-the-box
RTLSDR support. Remote analyzers (which allow sharing SDR devices in a network
with reduced bandwidth usage) will not work, partly due to the chaotic nature of
Windows polling mechanisms.
If you happen to be interested in the gory details of this limitation: any sane (and modern)
operating system provides mechanisms for programmers to put their applications to sleep
until certain event of a given set (like activity in a socket or data in a pipe) occurs. In
normal operating systems (like GNU/Linux, macOS or any Unix in general) this mechanism
is provided by a system call named poll() , which enables simultaneous monitoring of
miscellaneous objects like sockets, files, pipes, events, timers and so on. In Windows,
3https://en.wikipedia.org/wiki/Rosetta_(software)
4https://github.com/arf20
5https://www.mingw-w64.org/

BUILDING FROM SOURCES 9
however, there is a myriad of different, mutually incompatible polling mechanisms that do
not work for all types of objects. In particular, the Windows equivalent of poll() (named
WaitForMultipleObjects ) will not work with Winsock sockets, which has its own polling
function (named WSAPoll which, on the other hand, is slow and only works with sockets).
Additionaly, MinGW-w64 has its own poll implementation which has been flawed for years
and whose behavior is not compatible with the one you would expect in Unix. This is
catastrophic for the remote analyzer support, which needs to mix sockets and certain
anonymous pipe to know when to cancel certain blocking operations (like hitting "Stop" in
the middle of a connection).
The solution to this issue is hard. It is hard, because it involves multiple threads using the
corresponding implementation of poll that works for each possible subset of objects. If you
are interested in this subject and want to provide a better solution (or do some progress in
this direction), feel free to contact me at BatchDr[email protected].
Building from sources
SigDigger has been designed to be easily built in Unix-like systems. Nonetheless, the
following dependencies are required:
•A modern C/C++ compiler (GCC or clang)
•Git
•CMake (version 3.5.1 or newer)
•libsndfile
•libfftw3
•volk (version 1.0 or newer)
•SoapySDR (version 0.5 or newer)
•libxml 2.0
•PortAudio 2.0
•Qt 5 (at least 5.15)
•cURL
•ALSA libraries (for GNU/Linux targets only)
Any mainstream GNU/Linux distribution should maintain packages for these depen-
dencies in their public repositories, under one name or another. In the particular case
of Debian-based systems (like Ubuntu), all of these dependencies can be installed
with a single command:

10 CHAPTER 2. INSTALLING SIGDIGGER
$ sudo apt install build-essential cmake qtbase5-dev libsndfile1-dev
libvolk1-dev libcurl4-openssl-dev libfftw3-dev
soapysdr-module-all libsoapysdr-dev libxml2-dev portaudio19-dev
libasound2-dev
In macOS systems with brew , the procedure is a bit more complicated as it involves
installing Qt 5 manually and preparing SoapySDR taps.
The first step is installing –in this order– Xcode (available from Apple’s developer
website6) and Qt 5.15 (tutorial here7).
Once both Xcode and Qt are installed, run the following commands as regular user:
$ brew install libsndfile volk curl fftw
$ brew tap pothosware/homebrew-pothos && brew update
$ brew install pothossoapy
$ rm -f /usr/local/lib/libSoapySDR.0.8.dylib
$ brew install soapyrtlsdr soapyhackrf soapybladerf soapyairspy
soapyairspyhf soapyredpitaya soapyiris limesuite soapyplutosdr
$ brew install libxml2
$ brew install portaudio
Once all dependencies have been satisfied, the user can choose one of the following
ways to compile SigDigger:
Fully-automated build using BLSD (GNU/Linux only)
BLSD (short for Build Latest SigDigger from Develop) is a shell script that builds
SigDigger from development branch and installs it inside a subdirectory of the current
working directory. This is an option for users that do not want to install files in system-
wide locations or have no root access to their system.
The resulting directory (named blsd-dir ) contains a folder named SigDigger that
can be placed anywhere in the system. Inside the SigDigger folder two executable
launcher scripts can be found: SigDigger and suscli . The user may run any of
these directly from the command line.
Running BLSD is straight-forward. You can download the script from here
8
, give
execute permissions to it and run it as regular user:
$ chmod a+x blsd
$ ./blsd
A variety of options can be passed to blsd ’s command line, instructing it to enable / dis-
able support for specific features. In particular, –disable-alsa can be used to disable
ALSA support in Linux targets (which is known to cause sound issues in Raspberry Pi 4).
6https://developer.apple.com/download/
7https://doc.qt.io/qt-5/gettingstarted.html
8http://actinid.org/blsd

BUILDING FROM SOURCES 11
–disable-portaudio disables PortAudio support as well (which in Windows and macOS
targets implies disabling audio completely).
Once blsd has finished successfully, navigate to the resulting folder to run SigDigger
normally:
$ cd blsd-dir/SigDigger
$ ./SigDigger
Manual compilation (all systems)
This is the option you would choose if you do not have GNU/Linux or want to install
SigDigger system-wide. Before building SigDigger, you have to ask yourself which
branch do you want to build (master for the latest stable release, develop for the one
with the latest features). In order to clone from master, run:
$ git clone https://github.com/BatchDrake/sigutils
$ git clone https://github.com/BatchDrake/suscan
$ git clone https://github.com/BatchDrake/SuWidget
$ git clone https://github.com/BatchDrake/SigDigger
In order to clone from develop, you have to specify the branch explicitly:
$ git clone -b develop https://github.com/BatchDrake/sigutils
$ git clone -b develop https://github.com/BatchDrake/suscan
$ git clone -b develop https://github.com/BatchDrake/SuWidget
$ git clone -b develop https://github.com/BatchDrake/SigDigger
Now, in this order, build and install sigutils:
$ cd sigutils
$ mkdir build && cd build
$ cmake ..
$ make
$ sudo make install
$ cd ../..
Build and install suscan:
$ cd suscan
$ mkdir build && cd build
$ cmake ..
$ make
$ sudo make install
$ cd ../..
Build and install SuWidgets:
$ cd SuWidgets
$ qmake SuWidgetsLib.pro
$ make
$ sudo make install

12 CHAPTER 2. INSTALLING SIGDIGGER
And finish by building and installing SigDigger:
$ cd SigDigger
$ qmake SigDigger.pro
$ make
$ sudo make install
Now you should be able to execute SigDigger from the command line by typing:
$ SigDigger
Note: unless specified, everything will be installed under /usr/local . While this works for
many users, you may need to update your environment variables for the previous commands
to work:
$ export LD_LIBRARY_PATH=/usr/local/lib:"$LD_LIBRARY_PATH"
$ export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig:"$PKG_CONFIG_PATH"
$ export PATH=/usr/local/bin:"$PATH"
In case you wanted to install SigDigger somewhere else (e.g. /usr), you must pass
-DCMAKE_INSTALL_PREFIX=/usr to every cmake invocation, PREFIX=/usr to every qmake
invocation and an additional SUWIDGETS_PREFIX=/usr to SigDigger’s qmake invocation.

3
Chapter
Basic operation
Although SigDigger’s UI seems a bit overwhelming at first, the things you may want to
do with it usually boil down to one of the following:
•Listen to voice channels (AM / FM / LSB / USB)
•Capture a signal for a few seconds and analyze the waveform interactively.
•Configure a modem and visualize / forward the demodulated data.
Of course, we cannot reduce all SigDigger use cases to these three. However, for
real-world applications, most of the things you want to do with an unknown signal
involve either listening to it, studying its waveform or configuring a modem to extract
data bits.
This chapter attempts to cover –in a somewhat excessive detail– all the necessary
steps to arrive to at least the first use case. At the end of this chapter, you will find
that most of the time these steps need to be followed only once.
Interface overview
SigDigger’s main window can be divided in 5 areas:
1. The spectrum view, displaying the power spectral density of the signal in real
time. The spectrum view also enables the interactive selection of channels by
means of an adjustable filter box (shaded green rectangle with a vertical red
line).
2. The waterfall, displaying a spectrogram of the latest seconds of the signal.
3. The toolbar, from which one can start/stop the signal capture, configure the
application and manage bookmarks.
4. The time slider, which enables random positioning when the signal is being
played back from a capture file (hidden in real-time signal sources)
13

14 CHAPTER 3. BASIC OPERATION
5. The side bar, which provides different analysis and visualization functions related
to the signal being captured.
The toolbar provides shortcut buttons to the most frequently used operations. From
left to right, these operations are Start/Stop capture,Settings,Add bookmark,Manage
bookmarks and About SigDigger.
Other SigDigger functions are directly available from the side bar, grouped in 4 cate-
gories: Audio preview (used to play the channel defined by the filter box), Signal source
(used to perform different adjustments to the signal source in real time), Inspection
(used to inspect the contents of the selected channel in different ways) and FFT (used
to adjust different parameters of the spectrum / waterfall view).
Since the side bar serves as a container for many different controls that cannot fit
in a single window, each group can be expanded / collapsed by clicking on its title.
Optionally, the side bar can be hidden completely by dragging its left side to the right.
Configuring the signal source
The first step prior to any signal analysis is telling SigDigger where to read samples
from. This is done by means of the Settings dialog, either by clicking the corresponding

CONFIGURING THE SIGNAL SOURCE 15
button in the toolbar or by pressing Ctrl+S (+S in macOS).
The settings dialog consists of several tabs: Source,Colors,GUI behavior,TLE
Sources and Location. By default, the Source tab –corresponding to the configu-
ration of the signal source– is shown.
Any saved signal source configuration with a name is called a profile. SigDigger relies
on a profile named UI profile to load and save its signal source configuration. The
Source tab is simply an editor of this profile, with additional functions to make copies
of it with different names ( Save as... ) and overwrite it with the contents of existing
profiles (Load profile).
We usually start by defining the physical origin of the signal source. This is done by
checking one of the two radio buttons provided by the Source tab: SDR device (which,
as its name suggests, enables real-time data acquisition from a SDR receiver) and
File source (used to playback previously captured signals).
SDR device
Checking the SDR device radio button enables the Device drop-down list. From this list
you can choose any of the SDR devices detected during startup. Other device-related
options you can tweak are the channel number
1
, the bandwidth of the receiver’s
1You usually want this set to zero

16 CHAPTER 3. BASIC OPERATION
antialiasing filter2or the antenna used for reception.
You may have noticed that all frequency controls feature –in addition to two vertical arrows–
two horizontal arrows. The latter switch between frequency units (Hz, kHz, MHz...) while the
former add or subtract one frequency unit to the current value.
File source
If File source is checked, the Browse... button lets you choose the file from which
samples will be read. SigDigger will attempt to mimic the original data acquisition
speed directly from the configured sample rate (although this can be adjusted). The
Loop check box is used to inform SigDigger whether the file source should be rewound
to its start once the playback hits the end.
Many SDR applications –including SigDigger– follow a set of fixed set of naming rules
when it comes to storing sample data to a file. SigDigger is aware of several of these
rules: when a file whose name looks like the one produced by a 3rd-party application
is selected, it extracts fields like sample rate, frequency and date/time to adjust the
Source tab parameters accordingly.
2
Changing the sample rate of the source will alter the value of the bandwidth automatically. Note
not all SDR devices support bandwidth adjustment.

CONFIGURING THE SIGNAL SOURCE 17
While SigDigger may guess many parameters of the signal source directly from the
file name, this automatic detection may fail. In these cases, the Format drop-down
list can be used to specify the format of the input file by hand. Currently, the following
file formats are supported:
• Raw complex 32 bit float. Header-less file containing a sequence of pairs of
32-bit IEEE-754 floating point numbers (little endian). The first element of the
pair is the I component. This is the format used internally by SigDigger for I/Q
data representation. Other applications –like Gqrx
3
– store capture data in this
format.
• Raw complex 8 bit unsigned. Header-less file. I/Q data is encoded as pairs of
two bytes, ranging from 0 to 255. This is basically the unprocessed ADC output
of some 8-bit SDR receivers, like RTL-SDR.
• Raw complex 16 bit signed. Header-less I/Q data as pairs of two 16-bit signed
integers.
• WAV file. Used by applications like HDSDR
4
. These applications leverage the
stereo channels to store I/Q data and the WAV header to store both the sample
rate and format.
Source parameters
Once the source type has been set, the second most important parameter you need
to provide is the sample rate. The sample rate is a fundamental parameter that
determines both how fast signal data is consumed by SigDigger and the frequency
span of the spectrum. Higher sample rates imply wider frequency spans
5
but also
higher CPU usage.
If you are not sure what to put here, I recommend setting it to a value close to 1 or 2
Msps
6
. Modern computers handle these rates rather well and you will still be able to
fit several FM stations in the spectrum.
For file sources, the sample rate is a mere unit conversion factor between the number of
samples consumed and the elapsed time. While SigDigger will attempt to deliver samples
For SDR sources, however, the sample rate also determines the minimum average speed
at which data must be consumed in order to prevent sample loss. In particular, for a N -bit
receiver running at a sample rate fs, its data delivery rate has a lower bound given by:
R= 2Nfs×10−6Mbit/s (3.1)
3https://gqrx.dk/
4https://www.hdsdr.de/
5
The theory says that –for complex samples– the sample rate matches the frequency span. In
practice, frequencies near the edges of the spectrum are useless due to aliasing and/or the attenuation
of the antialiasing filter. This will ring a bell to AirSpy Mini users.
61 Msps = 106sps = one million samples per second.

18 CHAPTER 3. BASIC OPERATION
For instance, the RTL-SDR –a 8-bit SDR– running at 3.2 Msps will deliver data at more than
51.2 Mbit/s. This imposes restrictions to applications like rtl-tcp , which are limited not
only by the CPU power but also by the speed of the network interface.
With the source type and the sample rate, you have already defined the most important
parameters of the signal source. Other source parameters you may want to adjust
before hitting OK are:
• Frequency: the frequency at which the SDR receiver’s tuner should be set at
startup. You can also set the frequency interactively in the spectrum view’s LCD.
For file sources this value is merely informative.
• LNB frequency: this is a value that is substracted to the previous frequency
prior to setting the SDR’s tuner frequency. Used when your signal has been
frequency-shited by upconverters (like UpNooelec’s Ham It
7
) or downconvert-
ers (like Satellite TV LNBs). The sign of this frequency must be positive for
downconverters and negative for upconverters.
• Decimation: Defines sample averaging. Useful for SDR receivers with poor ADC
resolution. A decimation of N samples will divide the effective sample rate by
N. If you do not know what this is, leave it set to 1.
• DC Remove: Asks the receiver to attempt to remove the central peak in the
spectrum. Not all receivers support this feature.
• Freq. correction: Fine-tune the receiver’s local oscillator for precise frequency
calibration in parts-per-million. Not all receivers support this feature.
• Source time: For file sources, defines the time at which the capture was taken.
Needed for Doppler corrections.
I left Analyzer type out of the list intentionally. This option is used to offload acquisition
and some of the processing to a remote computer. For now, we will leave it set to
Local.
Starting a capture
Click OK in the settings dialog to accept the changes and press the Start/Stop capture
button. If all settings were correct, you should see activity both in the spectrum and
the waterfall.
7https://www.nooelec.com/store/ham-it-up.html

STARTING A CAPTURE 19
The 7-segment display in the top-left corner is referred as the LCD. The leftmost number
is the spectrum’s central frequency and, for SDR sources, is directly connected to the
receiver’s tuner. You can adjust the frequency in real time from here, either by clicking
on it and typing it with the keyboard, o by scrolling the digits with the mouse wheel.
The smaller numbers are the LNB frequency (with identical meaning as in the settings
dialog) and the demodulator frequency. The latter can be used to define the central
frequency of a channel we want to analyze.
The numbers between the spectrum and the waterfall are referred as the frequency
axis. Scrolling the mouse wheel here zooms the spectrum horizontally. Dragging
with the left mouse button moves the spectrum from left to right. Dragging with the
middle mouse button also sets the receiver’s frequency, having the same behavior as
adjusting the LCD manually8.
8
Some users (especially SDR# users) expect this dragging behavior to be reversed. This can be
adjusted in the Settings dialog →GUI behavior and checking Use left mouse button to drag
and change center frequency.

20 CHAPTER 3. BASIC OPERATION
The scale on the left is referred to as the vertical axis and it is normally in decibels (dB).
The user can choose among several reference units in dB (dBFS, dBW, dBK, dbJy...)
and magnitudes (1 mag ≈ − 4 dB ). As with the frequency axis, mouse whell zooms
and mouse dragging adjusts position.
Other useful visualization options can be found in the View menu. In particular, you
can overlay bandplan information on the frequency by checking some of the entries
under View → Band plans. This is particularly useful in HF, where many bands coexist
in a frequency span of a few MHz:
Finally, clicking / dragging anywhere else in the spectrum / waterfall sets the central
frequency of the filter box. We will get back to this later.
Details on spectrum normalization. While most signal analyzers (both hardware and soft-
ware) rely on the square of the absolute value of the FFT to display the spectrum, not all of
them agree in the way it is normalized. SigDigger relies on the following formula to calculate
the PSD:
P SD(f) = 10log10


U
Nfs





N−1
X
k=0
wkxke−j2π⌊f
fs⌋k




2
(3.2)
Where f is the frequency of the spectrum bin (in Hz), xk is the k -th sample in the FFT buffer,
wk is the k -th sample of the window function buffer, fs the sample rate, and N the FFT buffer
size. U is certain constant that does not depend neither on fs nor N . U can be adjusted by
the user to relate the PSD to physical units.
This normalization (1 /N fs ) makes sure that the PSD is (at least) proportional to units of
power per unit frequency. If the underlying acquisition device is well-behaved (i.e. sampling
is performed after an appropriate anti-alias filtering, and the response of the device does
not depend on the sample rate) and fed with a white noise source, the represented noise
floor is independent of the sample rate configuration.
Note this well-behavedness is something we would expect from most SDR devices (in which
aliasing is generally considered a bad thing) and not from oscilloscopes (in which the RMS is
usually the quantity that should be respected). In SDR devices the bandwidth of the antialias
filter before the ADC is somewhat proportional to the sample rate, and therefore the noise
power arriving at the ADC is scaled down in the same proportion (hence the 1 /fs scaling).
In oscilloscopes, however, filters are usually fixed or manually selectable among a reduced
set).