Introducing the TAPR TangerineSDR

By Scotty Cowling, WA2DFI

TangerineSDR’s roots extend back to the 2018 ARRL/TAPR DCC in Albuquerque, NM. At that conference, the HamSCI[1] community asked for TAPR’s help in developing a Software Defined Radio that they could use to collect ionospheric and other data. This radio, dubbed the Personal Space Weather Station (PSWS), needed particular capabilities, such as very accurate time-stamping of RF samples, ability to measure small fluctuations in the earth’s magnetic field and most of all, capability to share data over a large network of receivers. 

Our first thought was to simply find the commercial SDR (out of literally dozens) that best fit the scientists’ requirements and then add to or modify the SDR hardware to obtain the required functionality. Oh, and did I mention that we have a cost goal of under $500? While the technical goals seemed achievable, the cost goal would become the hardest one to meet.

After much research by John Ackermann, N8UR, it became obvious that we were not going to find an off-the-shelf SDR with the capabilities that we need at a price within our budget, especially taking into account we were going to have to add hardware to implement our new functions. These functions included a sensitive magnetometer, a GPS Disciplined Oscillator (GPSDO), networking and authentication, 24 hours of local data storage and amplitude self-calibration circuitry, all on top of a dual-channel, 0-60MHz direct sampling (DDC) receiver with 14-bit ADCs.

I felt that we had one more requirement to meet. A project of this magnitude requires a lot of volunteer hours and a lot of TAPR resources to complete. Can we design the TangerineSDR in such a way that it could be used for tasks other than just PSWS? That way we would attract a larger user base and be able to build more boards, thereby making the hardware cheaper. A larger user base might also attract more software developers, who will create more applications for these users.

One of the ways we do this is through modularity. The concept of modularity is used heavily in the TangerineSDR by mounting the Magnetometer, Clock, RF and I/O expansion circuitry onto pluggable modules.

Basic Requirements

The PSWS is the initial use case, but there are others. Many of the basic features will be useful to other users and some will not. Here are the basic PSWS system requirements:

• Dual-channel, synchronous 14-bit direct sampling DDC receiver to 60MHz
• Eight 192kHz virtual receiver data streams
• Selectable attenuation and optional pluggable RF filtering to reduce overload
• Switchable on-board noise source for amplitude calibration
• Very accurate time stamping, to within 100ns
• Frequency accuracy, less than 30 ppb frequency error
• Gigabit Ethernet interface
• Networked receivers capable of secure communications with a global server
• Able to continuously store 24 hours of sample data history in a ring buffer
• 3-axis magnetometer with ~10nT resolution at 1 sample/second

While we don’t have space to go into detail on how we will meet all of the requirements, we can show how we will achieve some of the more important ones.

Magnetometer PMOD Board

A laboratory-grade magnetometer with enough sensitivity to be useful is very expensive and this PSWS requirement cannot be met with inexpensive cell-phone grade components. Our solution will be to “roll our own” in order to obtain a cost/performance ratio somewhere in between these two extremes.

Dave Witten, KD0EAG, has a working prototype of a remote sensor that can be mounted up to 100 feet away from the TangerineSDR hardware; for example, in your back yard away from house wiring and other antennas. The magnetometer has a resolution of 13nT and interfaces to the TangerineSDR via a standard PMOD port using a serial I2C interface.

Clock Module 

While the PSWS requires the time-stamping accuracy of a GPS Disciplined Oscillator (GPSDO), most users will not need this option. A GPSDO is expensive, so we put it on an optional pluggable module. The clock (along with the RF Modules, below) is the most performance-defining piece of the TangerineSDR design and it will have a significant cost impact in its higher-performance versions. The least performant (and least expensive) TangerineSDR will have no Clock Module. A local clock oscillator will be installed on the Data Engine (DE) board. This part will be selected as a reasonable tradeoff between performance and cost.

The first TangerineSDR use case is a very demanding one: the PSWS. The PSWS requires very accurate frequency stability as well as a very accurate data arrival time stamp, down to 100ns (or at least as close as we can afford to get to that accuracy). Since this will require a GPS to stabilize or discipline the oscillator (hence the name GPS Disciplined Oscillator), this Clock Module will be expensive. For others who do not need the performance (and expense) of the GPSDO Clock Module, we will design an intermediate-performance Clock Module that will focus more on low phase-noise rather than highly accurate time stamping. John, N8UR and Rick Hambly, W2GPS, are working on the GPSDO Clock Module.

RF Module

The first (of many to follow) RF Module will be a dual-channel, 0-60MHz direct sampling (DDC) receiver with 14-bit ADCs and amplitude calibration. There will be two 14-bit data paths from the ADCs to the RFM connector. Each channel has an on-board noise source that can be switched onto the receive path for amplitude calibration. Each channel also has an optional in-line filter that can be used for additional shaping of the front-end response. These are typically used for high-pass or notch filters to prevent ADC overload. A passive step attenuator is used in order to keep as few active components as possible ahead of the ADC. The clock for the ADCs can come from the either the clock oscillator installed on the DE or from the Clock Module, if one is present. Tom McDermott, N5EG, is working on the first to be released RF Module.

I/O Expansion (LEAF) Module

The TangerineSDR I/O expansion module is called a LEAF for Low-speed Expansion Adapter Fixture. The DE is designed to accommodate the higher-performance LEAF module as well as a Raspberry Pi Hat (Hardware Attached on Top), Arduino shield and a Beagle Bone Cape (due to its cape-like shape). 

What distinguishes the LEAF Module from the Hat/Shield/Cape boards is the addition of a high-speed M.2 connector on the DE on the edge opposite the RPi low-speed expansion connector. This allows the LEAF to interface to higher speed devices, such as the Xilinx Ultra96 Board [2], which has a high-speed I/O expansion port. Many LEAF boards are planned, including ones that have Arduino Shield connectors, Cape connectors, a Click [3] interface, and others.

Networking and Authentication

The TangerineSDR block diagram is shown in Figure 1. Notice that the SBC is paired with the SDR hardware [the Data Engine (DE) and its associated boards]. This gives us all the networking and authenticating software that is included in the Linux operating system running on the SBC. It also allows us to easily create software applications to customize the capabilities of the TangerineSDR.

Data Throughput

A common problem with many current SDRs is the lack of consistent high-speed data paths from RF to the computer. There are three wide, high-speed buses (two 17-bit inputs and one 14-bit output) between each RF Module and the FPGA. These buses can be differential (LVDS) or single-ended (LVCMOS), individually programmable in the FPGA. The two input buses are used for digitized receive data from Analog-to-Digital Converters (ADCs) and the output port is used to send transmit data to a Digital-to-Analog Converter (DAC). Each of these three buses is capable of sustained transfer rates of over 500MByte/s. Only the most expensive SDR models provide these kinds of data rates between the antenna and the FPGA. 

A high-bandwidth path from the ADC to the FPGA (which we have) does little good if the data path from the FPGA to the PC is restricted in bandwidth. For example, the 100Mbit/s data rate of Fast Ethernet can accommodate a 16-bit I/Q data stream of 100M bit/s / 32 bit/sample = 3.125Msps. This is before we account for the channel overhead of about 6%, leaving us with just under 3Msps. GbE will boost this to about 30Msps, but if we increase the sample width from 16 bits to 24 bits, our I/Q sample becomes 6 bytes (48 bits). Doing the math (1G bit/s / 48 bit/sample) * 0.94 efficiency) = 19.5Msps.

At HF frequencies and narrowband modes, either 30Msps of 20Msps of simultaneous bandwidth is adequate, but at VHF, UHF and above, it may not be. The TangerineSDR implements a three-port GbE switch (FPGA-RJ45-RJ45) that allows the reasonably high-speed data communications discussed above. TangerineSDR also implements one USB 3.0 SuperSpeed port. This port is one full-duplex lane at 5Gbit/s or roughly 5 times the speed of GbE. The SBC is unlikely to be able to keep up at this breakneck speed, but higher-powered computers can.

Typical SDRs provide only one communications interface usually at a lower throughput than on the RF side. This limits the simultaneous bandwidth and/or the number of output streams. TangerineSDR provides both GbE and SS USB 3.0 at 5Gbit/s communications interfaces. Future DE implementations have an upgrade path to 10Gigabit Ethernet (10GE) or 40Gigabit Ethernet (40GE) or future higher-speed versions of USB. TangerineSDR can’t eliminate the data rate restrictions of the interfaces, but we can at least minimize them by implementing multiple high-speed communications channels to the outside world.

Reducing the Output Data Rate

What is the FPGA going to do with all this data? We can reduce the data rate using a mathematical process known as decimation. By performing decimation on a stream of data, we reduce the data rate. At the same time, we reduce the information content of the stream. It may seem obvious that (for example) a 122.88Msps data stream contains more data than a 192Ksps data stream, but how we derive the lower-rate stream from the higher-rate stream is not so obvious.

We will leave that discussion for later; let it suffice to say that we will need these slower data rates. Even with GbE, we will require some reduction of the input data rate. And here is a thought to ponder: it is not likely that our SBC will be able to keep up with the demodulation and filtering (DSP tasks traditionally performed by the PC in an SDR system) at full Gigabit Ethernet speeds. The characteristics of Ethernet networking will allow the FPGA to split the high-speed input stream into many smaller (decimated) output streams that can be directed at multiple SBCs (or more powerful PCs). The higher the communications speed, the more streams we can accommodate. Remember, there are two very high-speed input streams from each RF Module. 

Modularity

A mechanical mock-up was made (see Figure 2) from copper-clad PCB stock and the actual connectors used in the design. The GbE and USB 3.0 circuitry are part of the DE, while the Clock Module (CKM), the three RF Modules (RFMs) and the LEAF are pluggable options. The CKM and LEAF Modules mount on the top side of the DE while RFM0 and RFM1 mount underneath the DE. RFM2 is shown to the left (under the coin) and plugs into the left side of the DE. It accepts an existing RF board and will be used to bring up the DE before other RFMs are available. A typical PMOD expansion board is shown plugged into the right side of the DE; this is where the magnetometer will go.

Use Cases

Now that we have described the hardware, what can we use it for? In other words, what are our use cases? They vary from simple (listen to SSB on my favorite 40M frequency) to difficult (PSWS). Following is a partial list of TangerineSDR use cases. If you have others, please let me know.

• PSWS
• Satellite Ground Station (requires new RF Modules)
• High Performance HF transceiver
• WSPRnet/RBN on multiple bands simultaneously
• HF noise sniffing/calibrated receiver
• Remotely controlled stations
• Radio Astronomy (Project Jove [4], SARA [5] pulsar detection)
• Academic Learning

For More Information

The TangerineSDR project is open source and we are making as many use cases for the hardware as we can. Stay tuned as we cover the evolution of the TangerineSDR here and in QEX magazine. TAPR’s involvement with OpenHPSDR started more than a decade ago. I suspect to see an awful lot of TangerineSDR development the next decade!

For more information, visit our web site, TangerineSDR.com. You will find a wealth of links, video and audio recordings and how to subscribe to the TAPR TangerineSDR e-mail list. We also have a weekly Teamspeak VoIP online net on Monday evenings at 2100 Eastern Time (currently 0200Z on Tuesday). See the webpage for instructions on how to participate. I also encourage you to subscribe to QEX [6] magazine for more technical information on TangerineSDR and many other interesting projects.

Notes:

[1] Ham Radio Science Citizen Investigation, or HamSCI, is a group of hams and scientists (many are both) dedicated to advancing scientific research through amateur radio activities. Visit hamsci.org for more information.

[2] Ultra96 MPSoC FPGA development board. See 96boards.org/product/ultra96

[3] Click is a small I/O module that uses mikroBUS^TM. See mikroe.com/mikrobus

[4] Project Jove studies radio emissions from the planet Jupiter, the Sun and our galaxy. See radiojove.gsfc.nasa.gov

[5] Society of Amateur Radio Astronomers (SARA). See radio-astronomy.org

[6] QEX, the ARRL Forum for Communications Experimenters. See arrl.org/qex