KiwiSDR design review
Version 2.1 – February 2016
John Seamons, ZL/KF6VO
jks@jks.com
Summary
This document describes the design of KiwiSDR, a software-defined radio (SDR)
add-on board (so-called "cape") for the popular BeagleBone Black single-board
computer. Although the first PCBs have been constructed, design feedback is still sought from experts
in the community before more units are manufactured. Click for the live receiver in New Zealand.
There are also now two beta units, at the University of Victoria, B.C., Canada and the SK3W Contest
Station, Sweden. The KiwiSDRs are registered on the SDR.hu network. Complete sources are on
github.
The design is open-source / open-hardware with full details available to anyone (including PCB
layout). The project leverages much existing open SDR technology, but especially the pioneering work
of Pieter-Tjerk de Boer, PA3FWM, the creator of WebSDR, Andrew Holme's Homemade GPS
Receiver and OpenWebRX from András Retzler, HA7ILM.
© bluebison.net
If a reasonable retail price target can be achieved the intent is to produce and sell boards. Some form of
crowd funding is being considered to bootstrap initial production and fund up-front costs such as
regulatory compliance testing. The minimum-threshold aspect of crowd funding will also provide a
good estimate of overall interest in the project given how crowded the SDR space is these days.
TOC 1
How you can help
I welcome advice of any kind. Especially if you see an error or misconception on my part. There is also
a list of open questions at the end of each description section you can help answer. A lot of the design is
"cookbook" based on my limited understanding of certain areas (e.g. RF design, EMI/EMC). Even if
you only read one paragraph, and email one comment (jks@jks.com), you will be doing me a huge
favor. Sincere thanks in advance. (click on user interface images below for full size)
TOC 2
Table of Contents (clickable)
1 Objectives 6
2 Description and Features 6
3 Applications 7
4 Status 7
5 Design Philosophy 7
5.1.1 Price-point and trade-offs 7
5.1.2 Active antenna 8
5.1.3 Beagle as host 8
5.1.4 Enclosure 8
5.1.5 Mission creep 8
5.1.6 Second generation 8
6 Detailed Design Description 9
6.1 Hardware overview 9
6.2 Software Overview 13
6.3 VLF-HF SDR 14
6.3.1 Front-end 14
6.3.2 ADC 14
6.3.3 ADC clock 14
6.3.4 Performance 15
6.3.5 FPGA logic 15
6.3.6 IQ mixer 16
6.3.7 CIC Filters 17
6.3.8 Audio channels 17
6.3.9 CIC filter optimization 17
6.3.10 No FIR filter hack – audio 18
6.3.11 Waterfall channels 18
6.3.12 Waterfall overlapped sampling 19
6.3.13 No FIR filter hack – waterfall 19
6.3.14 Baseband processing 20
6.4 Software-Defined GPS Receiver 21
6.4.1 Front-end 21
6.4.2 GPSDO possibilities 21
6.4.3 FPGA logic 21
6.4.4 Logic optimization 23
6.4.5 Software 23
6.4.6 ADC clock frequency correction via GPS timing 23
6.5 Beagle Cape Interface 24
6.5.1 SPI 24
6.5.2 Expansion port 24
6.5.3 EEPROM 24
6.6 Power supplies 25
6.6.1 Custom Beagle power supply 25
6.6.2 Interaction with Beagle 25
6.6.3 5V input internal / external source select 25
TOC 3
6.6.4 3.3V digital from Beagle 25
6.6.5 FPGA power-up sequencing 26
6.6.6 1.0V SMPS 26
6.6.7 3.3V analog rail LDOs 26
6.6.8 Current requirements & power dissipation analysis 26
6.7 Active Antenna 30
6.7.1 Version schematics 30
6.7.2 Coupling bandwidth 30
6.7.3 Transistor selection 30
6.7.4 Power supply 31
6.7.5 Bias tee 31
6.7.6 Feed-line connection 31
6.7.7 Grounding 32
6.7.8 Enclosure 32
6.8 Active Antenna – Power Injector (bias tee) 33
6.8.1 Filtering 33
6.8.2 Input protection 33
6.8.3 Voltage & current distribution 33
6.8.4 Diode noise 34
6.8.5 Bias tee 34
6.9 Software 35
6.9.1 Source code 35
6.9.2 Embedded CPU (eCPU) 35
6.9.3 Beagle application 35
6.9.4 FPGA development 37
6.9.5 Verilog 38
6.9.6 Version checking, serial number 38
7 PCB 39
7.1 BeagleBone cape compatibility 39
7.1.1 PCB size 39
7.1.2 Beagle interface 40
7.2 Mixed-signal PCB design 40
7.2.1 General layout 40
7.2.2 RF shields 42
7.2.3 GPS 42
7.2.4 ADC 42
7.2.5 Edge via stitching 42
7.3 PCB specifications 43
7.3.1 Layer count 43
7.3.2 Surface finish 43
7.3.3 PCB stackup 43
7.3.4 Layer assignment 44
7.3.5 Controlled impedance 44
7.4 Layout design rules 44
7.4.1 Unit choice and layout grid 44
7.4.2 Traces and vias 44
7.4.3 SMD pad connection to planes 45
TOC 4
7.4.4 Planes / zones 45
7.5 Other PCB elements 46
7.5.1 Fiducials 46
7.5.2 Tooling holes 46
7.5.3 Panelization 46
7.5.4 Edge keepout 46
7.5.5 Test pads 46
7.5.6 Layer ID 46
7.6 Thermal / RF ground via-in-pad 46
7.6.1 Existing solutions 47
7.6.2 KiCAD footprint solution 47
7.7 FPGA BGA issues 50
7.7.1 Power planes 50
7.7.2 Traces and vias 54
7.7.3 Bypass caps 55
8 EMC / EMI 57
8.1.1 Proximity to Beagle 57
8.1.2 SMPS switching transient propagation 57
8.1.3 Clock harmonics within the GPS L1 bandwidth 57
8.1.4 Certification 59
9 DFM 61
9.1 Parts commonality 61
9.2 Minimizing high assembly-cost parts 61
9.2.1 Through hole 61
9.2.2 Fine pitch 61
9.3 Placement spacing 61
9.4 BGA inspection clearance 61
9.5 QFN pad pullback 62
9.6 Copper warping / twisting during reflow 62
9.7 SMD tombstoning / shifting 62
9.8 Reverse header soldering 62
9.9 Test methodology 63
9.9.1 RF source 63
9.9.2 JTAG 63
10 Bill of Materials 64
11 Schematics and Files 65
12 Risks 66
13 Abbreviations 67
TOC 5
1 Objectives
I wanted to design an SDR that provides certain features, at a low price point, that I felt wasn't covered
by current devices. The SDR must be web-accessible and simple to setup and use.
I also want to provide a self-contained platform for experimentation with SDR and GPS techniques. In
this respect the project has a lot in common with the recent HackRF and BladeRF projects.
Most importantly, I'd really like to see a significant number of web-enabled wide-band SDRs deployed
in diverse locations world-wide because that makes possible some really interesting applications and
experiments.
2 Description and Features
KiwiSDR has several components:
• SDR covering the 10 KHz to 30 MHz (VLF-HF) spectrum.
• LTC 14-bit 65 MHz ADC.
• Xilinx Artix-7 A35 FPGA.
• Integrated software-defined GPS receiver.
• Skyworks SE4150L GPS front-end.
• VLF-HF active antenna and associated power injector PCBs.
And these features:
• Browser-based interface allowing four simultaneous user web connections.
• Each connection tunes an independent receiver channel over the entire spectrum.
• Waterfall tunes independently of audio and includes zooming and panning.
• Multi-channel, parallel DDC design using bit-width optimized CIC filters.
• Good performance at VLF/LF since I personally spend time monitoring those frequencies.
• Automatic frequency calibration via received GPS timing.
• Bill-of-materials (BOM) cost of ~ US$100 (build quantity 100, less PCB & assembly).
• Easy hardware and software setup. Browser-based configuration interface.
The user will be required to purchase the Beagle, plug the SDR into the cape connectors, install a
couple of software packages and open up an incoming port through whatever Internet router may exist.
An antenna solution must also be provided although the included active antenna should help in this
regard. A $10 GPS puck antenna will work fine. An adequate power supply to the Beagle (e.g. 5V @
2A) will be required.
Four channels of audio and waterfall streamed over the Internet 24/7 requires about 30 GB per month.
This is a common cap for many residential broadband plans. An automatic dynamic-DNS system is
already part of the software so a web link to the SDR is immediately available with no configuration.
TOC 6
Of course the system can be configured to only allow connections from the local network and ignore
Internet connection requests.
3 Applications
In addition to simply monitoring signals a number of applications and experiments are possible.
Applications possible if many KiwiSDRs are deployed world-wide:
• Time-of-arrival direction finding, assisted by having accurate GPS time & location info.
(similar to the VLF TOA/TOGA lightning detection of blitzortung.org)
• Experiments with location-diversity reception, as opposed to the usual frequency-diversity.
• Source of world-wide data for GPS common-view experiments.
Other applications:
• Education and experimentation platform for SDR and SD-GPS techniques.
• Decoder for WWVB's new PSK modulation format (similarly with DCF77 in Germany)
• Weak signal integration detection.
• Development of speciality I/Q demodulators. A WSPR decoder has been demonstrated.
4 Status
The schematic and layout have been captured using KiCAD. Several PCBs have been fabricated and
assembled. BOM output from KiCAD is post-processed to provide a file suitable for uploading to
octopart.com for quotation.
FPGA Verilog and application code development is working and draws on the efforts of many opensource projects. System bandwidth / throughput analysis has been made. The contract manufacturer
who built the prototypes has quoted me a very attractive price for building 100 units.
5 Design Philosophy
KiwiSDR attempts to fit in the cost and performance gap between USB dongle-style, or fixed DDC
chip, devices ($20 - $200, 8-12 bit ADC) and full 16-bit SDRs ($700 - $3500). At the same time
offering wide-band, web-enabled capabilities not always found even on the more expensive SDRs.
5.1.1 Price-point and trade-offs
Given the BOM cost, a possible retail price is very roughly in the US$250 - $350 range. There have
been no calculations for distribution or other indirect costs yet. Since many of the applications require a
significant number of units being placed world-wide a low price-point is essential. Ruthless trade-offs
in component choice vs specifications are required (e.g. $24 14-bit @ 65 MSPS ADC vs $80 16-bit @
TOC 7
130 MSPS).
5.1.2 Active antenna
The idea is to include the PCBs for an active antenna and associated power injector as part of the
project. This way a user could get the receiver working by only having to add an antenna enclosure,
feed-line and AC power source. The (components) BOM incremental cost to do this is only about 10%,
similar to the cost of adding the SD-GPS. For manufacturing these additional PCBs would simply be
part of a larger panelized design with appropriate slot routing and break-away tabs.
Inclusion of the active antenna is very much an open question however. Perhaps it is best sold as an
added cost option.
5.1.3 Beagle as host
Using the US$55 BeagleBone Black as the host is an absolute no-brainer from every perspective. For
the money that kind of equivalent functionality cannot be designed into the SDR. Since the intent is for
the user to leave the SDR connected to the Internet full-time a solution requiring a dedicated PC is
much less attractive. As of early 2016 there is a compatible, but even lower cost, BeagleBone Green for
US$39. It lacks the HDMI interface, which we don't use anyway, and is simply a potential source of
interference.
5.1.4 Enclosure
The intent is to sell the board without an enclosure. There are existing enclosures for the Beagle
although most do not meet the size requirements given our extended-length PCB. It is possible a
top/bottom acrylic plate design similar to early HackRF units could be made.
5.1.5 Mission creep
I specifically avoided adding any SRAM external to the FGPA or bringing additional FPGA I/Os out to
an expansion connector for cost and possible noise-source reasons (and also the time and complexity to
route those PCB traces and validate the functionality of the interfaces). A second generation of the
board might include them. But note that expansion I/Os to the Beagle are included.
5.1.6 Second generation
A second generation of the board might also include a Gigabit Ethernet PHY and RJ45 since opensource GE MAC FPGA cores are pretty common. This would allow experimentation with full
bandwidth FFT-based SDR techniques as opposed to DDC (the openHPSDR folks are calling this
technique "Direct Fourier Conversion" [DFC] – essentially what WebSDR uses). There has also been
the idea of including UHF/VHF spectrum capabilities such as a low-cost AIS (marine vessel tracking at
162 MHz) and ADS-B (aircraft tracking at 1090 MHz). Maybe this is best done with a daughter board.
TOC 8
6 Detailed Design Description
The design can be divided into seven parts:
• VLF-HF SDR
• Software-Defined GPS receiver
• Beagle cape interface
• Power supplies
• Active antenna
• Active antenna power injector (bias tee)
• Software
6.1 Hardware overview
The hardware overview diagram below shows the major components of the board.
Inside the RF shield cans are the SDR and GPS front-end circuits. The SDR has a 30 MHz LPF and
+20 dB preamp ahead of the ADC. A 65 MHz XO clocks the ADC and is one of the clock inputs to the
FPGA.
The GPS front-end chip has a 16.384 MHz TCXO which similarly clocks the FPGA.
Communication with the Beagle is over the standard cape 0.1” header connectors. All data is moved
over a 48 MHz SPI link. The FPGA is downloaded from the application running on the Beagle.
Additional Beagle I/Os are connected to the FPGA for future expansion, e.g. a higher performance
parallel port. An EEPROM containing cape header-use configuration information is provided according
to the Beagle specification.
TOC 9
Most of the board power is provided from regulators connected to the 5V source from the Beagle that
passes through the headers. Only some 3.3V is taken from the Beagle directly to run the FPGA IO pins
and the EEPROM. A switching regulator provides the relatively high current for the FPGA core while
linear LDOs are used for the remaining supplies including quiet supplies for the ADC and GPS.
The FPGA Clock Domains diagram below shows the Verilog module organization inside the FPGA.
The built-in dual-port 36 kbit BRAM (block RAM) memories of the FPGA provide isolation between
clock domains, as well as some synchronization primitives I wrote. The bus looking structure in the
middle is really a series of dedicated connections, many of which are multiplexed. The SPI and eCPU
blocks are from Andrew Holme's open-source Homemade GPS Receiver.
The eCPU is a tiny 32-bit stack-based embedded CPU Andrew designed. The eCPU instruction
memory is downloaded over the SPI after the FPGA is programmed. In addition to Andrew's code to
support the GPS I added code to efficiently control registers in the SDR logic and assist with data
transfer to the SPI. The eCPU runs at the modest 16 MHz clock to make synchronization with the GPS
logic easier.
TOC 10
The image below is the floor-plan of the FPGA. The Xilinx A35 can currently fit 4 SDR channels along
with a 12 channel SD-GPS and one eCPU.
The device utilization is:
• 60% of the logic slices
• 93% of the BRAMs
• 40% of the DSPs
The limiting factor is the number of BRAMs in this configuration. So a design with a more efficient
use of BRAMs might allow another SDR channel to be added. Up to 16 GPS channels (and likely
more) will fit because each additional tracking demodulator only requires an additional two DSP slices
and no additional BRAMs. But in practice more GPS channels don't seem to be needed.
Note that since the audio and waterfall DDCs are independently tunable (and zoomable in the case of
the waterfall) this means there are really 8 distinct DDCs in the FPGA.
TOC 11
TOC 12
6.2 Software Overview
The figure below shows the distribution of the software signal processing tasks (including Verilog). The
FPGA only performs DDC at the audio channel bandwidth and at the selected visible spectrum span.
The FFT and baseband audio processing are performed on the Beagle. Finally, the user's browser, via
Javascript, converts the FFT output into the waterfall and spectrum displays. The audio stream is
interpolated from the 8.25 kHz Internet transport rate to the native audio output rate (typically 44.1 or
48 kbps but others are supported). These tasks are repeated for each simultaneous receiver channel and
corresponding internet browser connection.
TOC 13
6.3 VLF-HF SDR
6.3.1 Front-end
Referring to the ADC schematic, the antenna connection is via a 2 position screw-post terminal block.
As detailed in the active antenna section the use of a terminal block for the connection of bare wires is
in the interest of simplicity. In parallel to that PCB pads exist for an edge-launch SMA or BNC
connector.
A low-capacitance TVS across the input attempts to provide some transient protection.
Next are two parallel DC blocking caps. A range of values are used to be somewhat broadband. This is
followed by a 7-pole Chebyshev 30 MHz low pass filter from EI9GQ. Transformer 1:4 coupling (50 to
200Z) to the preamp was considered, but I wasn't able to find one that fit the height requirement of the
RF shield and still had a low enough frequency response (which is proportional to transformer size).
The Mini-Circuits TC4-1TX is “useable” to 200 kHz according to the data sheet. It would fit but
probably has unacceptable attenuation at 10 kHz. So single-ended resistive impedance matching was
done using the values specified in table 5-4 of LTC app note 123. A 40 MHz LC LPF follows to band
limit the preamp broadband noise. The LTC 6401-20 +20 dB differential ADC driver preamp is several
generations old but very reasonably priced. The high performance of the latest generation devices is not
required at these low frequencies.
Some SDRs include a software-selectable attenuator before the preamp. This was left out for cost
reasons. Experience has shown that a 14-bit ADC has sufficient dynamic range using an active antenna
with “shortwave receiver”-level performance goals.
6.3.2 ADC
The LTC2248 14-bit 65 MHz ADC is relatively inexpensive ($28 Q100) compared to 16-bit and > 65
MHz clock rate parts. I am willing to accept a performance compromise above 25 MHz (close to
Nyquist) in exchange for a cheaper ADC as this SDR is not intended to be a receiver with exceptional
performance on the 10 meter Ham band. It would be nice to use a part with LVDS outputs for EMI
reasons but they are twice as expensive.
Series resistors on the ADC end of all digital outputs will be used to limit edge rates and switching
noise. The value of 100R comes from page 3 of this app note assuming a 65 MHz sample clock and
worst case 15 pF output loading.
6.3.3 ADC clock
The clock is a Conner-Winfield CWX823 series XO which is a reasonably priced oscillator ($2) with
good phase noise performance (< 1ps rms phase jitter). But as several excellent LTC app notes mention
(here and here) one has to be very careful about drawing conclusions from published phase noise specs.
Fortunately, clock jitter is going to translate into much less ADC noise with a 65 MHz sample clock
TOC 14
than by using, say, an ADC with a 400 MHz clock. The clock jitter vs SNR vs frequency graphs in the
app notes make this clear.
The XO output drives the ADC with as short a connection as possible, but also drives a NC7Z126
buffer connected to the FPGA as suggested by the ADC data-sheet. Any frequency error is corrected in
the software with GPS timing as described in the SD-GPS section.
Questions:
• Anyone have a favorite low-cost ADC clock part suggestion?
6.3.4 Performance
No dynamic range or noise-figure analysis has been made yet. PA3FWM told me that his WebSDR
never seems to toggle the top two bits of his 16-bit ADC even with the strong LW & BCB signals at the
receiver location. Noise floor and spurious response will just have to be empirically measured. Same
for other performance metrics such as strong signal handling and effectiveness of the 30 MHz LPF.
6.3.5 FPGA logic
The figure below shows the classic digital down-conversion (DDC) architecture of the SDR. The audio
and waterfall Verilog code is replicated for as many channels as are configured.
TOC 15
6.3.6 IQ mixer
Each DDC begins with an IQ mixer. Traditionally the DDS part is implemented with a CORDIC
configured to generate the sin/cos clocks for the mixers and in most cases to simultaneously do the
mixer multiplies as well (see openHPSDR's Hermes or James Ahlstrom's HiQSDR project Verilog for
examples). But with the DSP slices modern FPGAs provide there is no need to use CORDIC anymore.
The Xilinx Vivado design tool has license-free DDS “intellectual-property (IP)” generators that are
easy to use. A DDS configured with a 32-bit phase increment input, 15-bit output and internal 13-bit
phase angle uses only one 36 kbit BRAM for the lookup table and 0-2 DSP slices (option) for the phase
accumulator. The last two bits of effective phase angle are the result of some phase dithering applied to
the output. This results in a 90 dB SFDR which is pretty good. Without the dithering, achieving 90 dB
TOC 16
would require 3.5 BRAMs which are the limiting factor in our design.
Two DSP slices are used for the mixer multipliers.
When I originally tried the Verilog CORDIC with multiple channels I immediately ran out of the
limited number of logic blocks that support the carry-chains needed by the long adders (typically 1/3 –
1/2 of the total number of logic blocks depending on the FPGA). This problem is compounded by the
long adders used in the CIC filters. 22-bits are used from the mixer multipliers as inputs to the CIC
filters.
6.3.7 CIC Filters
Several implementations of the Cascaded Integrator-Comb (CIC) filter in Verilog were developed.
These were written mostly to decrease the number of logic slices used given the large number of CICs
in the SDR. They are described below.
6.3.8 Audio channels
Two cascaded CIC filters, CIC1 and CIC2 are used as is seen in most SDR designs. CIC1 is a 3 stage
filter with 18 output bits and a decimation of 256. CIC2 is a 5 stage filter with 24 output bits and a
decimation of 31. It was found that 24-bits was needed to get sufficient dynamic range in the audio.
This is not surprising given that the AGC occurs downstream from this point. This gives an audio rate
of 8.25 kHz which is a convenient number for the built-in WSPR data demodulator. It will probably be
made wider eventually.
One issue I have never found an explanation for is why you typically see two separate CIC filters
cascaded together. I understand the effect of increasing the number of stages in a single filter and how
filter bit-growth is a function of stages and decimation factor. For example, I implemented the waterfall
by splitting the decimation across two CICs and compared it to performing all the decimation in a
single stage and there was no visible difference at all. Sure, the single CIC version will have vastly
longer registers due to the increased decimation (87-bits for decimation 256*31=7936 and 22-bits of
input). Maybe the difference has to do with power consumption and speed limitations of older FPGA
devices. With a single CIC all of those 87-bit integrator registers and adders are clocking at the full
ADC sample rate. Older FPGAs might not have been able to do carry-propagation for those longer
adders at the required clock rate. The other possibility is that the composite filter response of two
cascaded CICs of different stage lengths is more efficient than a single CIC.
Questions:
• Can anyone explain the reasons for cascading multiple CICs seen in so many SDR designs? Is it
simply for the reasons I mention? (Some feedback I've received says yes)
6.3.9 CIC filter optimization
Several optimizations have been made. One that is particularly useful in saving logic slices is an
implementation of an algorithm to optimally prune the length of the registers, and hence adders, used in
the filters. This is possible for example with CIC2 because only the upper 24 output bits are being used
TOC 17
of the 48-bit comb register length. This introduces a certain level of quantization error. The error can be
back-propagated up through the comb and integrator stages, successively shortening the register length
of each stage just to the point of maintaining the error level, but not adding to it. A section on my
website describes the implementation which is automatically run from the Makefile of the project and
auto-generates the necessary Verilog files.
Another optimization is to note that since decimation in a CIC is usually performed between the
integrator and comb sections the comb section of CIC2 is only clocked at 8.25 kHz. This is slow
enough that a fully sequential implementation is possible, using only one 48-bit DSP slice to replace all
the adders and 1/2 BRAM to replace the registers. A little state machine coordinates the sequential
movement of data. This is currently used in the audio channels and saves many logic slices. There is
also the possibility of processing all the CIC2 combs across all the audio channels in a single sequential
module if there are sufficient state machine cycles to do so. This experiment remains to be done. This
processing could even be done on the Beagle, but it requires roughly twice as much data per channel be
moved across the SPI. An even more ambitious experiment would be to sequentialize starting at the
comb section of CIC1. The CIC1 decimation factor would likely have to be increased to slow down the
output rate enough to have sufficient sequential processing clock cycles.
6.3.10 No FIR filter hack – audio
Traditionally an FIR filter follows the CIC to correct the CIC passband droop (i.e. sinc-shaped
response, see figure 11). For the audio channels the FIR can be easily done on the Beagle at the audio
rate. But in hardware the FIR is somewhat expensive to implement, especially since there are 8 DDCs
in total. However it was found that the post-CIC FIR requirement for the audio could be side-stepped in
a slightly disgusting way. The decimation is set 2x lower which passes 2x more audio bandwidth to the
Beagle than needed. Now only the first half of the CIC uncompensated response is used where the
droop is within 2 or 3 dB which is fine for our purposes. The rest of the data is simply thrown away.
There is already an adjustable FIR filter used by the demodulators that does the ultimate bandpass
filtering. So an additional FIR running on the Beagle isn't required. See below for what was done with
the waterfall. The FIRs on the Beagle are implemented with FFT convolution. It has been pointed out
to me that CIC droop compensation can be applied to the FFT output of the FIR filter by simple
multiplication. This would solve the problem nicely.
6.3.11 Waterfall channels
In many SDR programs the waterfall/spectrum display shows the entire maximum bandwidth of the
receiver (“bandscope” or “panadapter” in ham radio terminology). Sample data for the display FFT
comes directly from the ADC at the full sample rate, but in low-throughput chunks. A second waterfall
derived from audio channel data may show just the bandwidth of the audio channel before any postDDC passband filtering (typically < 10 kHz). In contrast, the WebSDR waterfall is a full Zoom FFT
acting more like a traditional spectrum analyzer. This has the nice effect of allowing you to be listening
on a set frequency while panning and zooming the waterfall anywhere else in the spectrum looking for
more signals. In our case this requires that the waterfall be implemented with a separate DDC. So in
effect our 4 channel SDR is really 8 fully independent DDC channels.
To provide the 12 levels of zooming the waterfall CIC filters implement power-of-two variable
TOC 18
decimation from 1 (pass-through mode) to 1024. For a 2048-point FFT, mapping to a 1024 pixel
display (to give a sharp looking display), this gives an RBW of ~30 kHz at minimum zoom (span 30
MHz) and RBW ~15 Hz at maximum zoom (span ~15 kHz). The FFT used is actually 8192 points due
to the FIR filtering hack mentioned below. So this requires a sampler memory of 8k samples. 16-bits
was found to be the optimum bit width for full display dynamic range.
6.3.12 Waterfall overlapped sampling
An interesting issue occurs with the waterfall generation at higher zoom levels. There is a crossover
point at which it takes more time to accumulate samples for the waterfall FFT than the desired screen
update rate. An example: Suppose you want a waterfall that updates at 50 Hz / 20 msec (i.e. draws 50
display lines/sec). Samples for an FFT need to be time-continuous at the full sample rate. So at
minimum zoom 8k samples need to be taken at 65 MHz. This takes 126 usec. No problem doing that
every 20 msec.
Now consider a waterfall zoomed in 1024x (RBW ~64 Hz, span ~64 kHz). It takes 1024 times as long
to accumulate the 8k samples because the DDC has to process 8k*1024 samples at 65 MHz to output
8k samples after decimation. This takes 63 msec. Obviously a problem when trying to update every 20
msec.
This is generally known as the “ acquisition time problem”. One solution is to overlap the sampling.
There is no reason you have to construct each display line from non-overlapping samples taken 63
msec apart resulting in a display that only updates at 16 Hz. Every 20 msec you can simply look at the
previous 20 msec worth of data in the sampling buffer while the DDC runs along taking 63 msec to
capture 8k worth of new samples. This works just fine.
Interestingly, the WebSDR has a similar consideration in the frequency domain since it is FFT not
DDC-based. A multi-megapoint FFT running on a GPU being fed the full ADC bandwidth over gigabit
Ethernet, which is how it supports hundreds of simultaneous users (some design details are here). A
truly astonishing feat in my opinion.
6.3.13 No FIR filter hack – waterfall
Implementing a CIC-compensation FIR filter for the waterfall is even more problematic than for the
audio because of the variable decimation used, e.g. at zoom decimation 2 the FIR must run at 32 MHz.
Like the audio case the FIR is side-stepped by decimating 2x less, passing 2x more data and computing
a 2x larger FFT on the host. The upper half of the FFT output which contains amplitude values that are
distorted by the attenuated CIC input data are simply throw away. This makes computational sense
since an FFT is an O(N log2N) process, i.e. an 8k FFT doesn't take much longer than a 4k. For example
at zoom level 3 (span 3.75 MHz) the waterfall decimation is set to 2^(3-1)=4 (span 7.5 MHz) instead of
2^3=8 and the upper half of the FFT ignored. Coincidentally it was found that trying to use the full CIC
passband didn't work anyway. The upper half was usually filled with aliasing artifacts, probably a result
of our low ADC clock rate to max ADC input frequency ratio. The same post-FFT gain adjustment as
in the audio channels can be used to compensate for the CIC droop.
Questions:
TOC 19
• I have a bad feeling I'm missing the importance of having the FIR filter before the FFT. But the
waterfalls look fine and the audio sounds pretty good. This aspect needs more research and
testing. Any advice? Remember that high-performance is not a goal with this SDR.
6.3.14 Baseband processing
After the DDCs the data stored in the FIFOs and sample memories are transferred to the Beagle where
all baseband processing occurs. For audio this is bandpass filtering, AGC, demodulation and S-meter
generation. For the waterfall it is the FFT and display processing.
TOC 20
Loading...