FPGA SDR Training - Dev boards

[pigtwo]

Hello all,

At work I'm currently tasked with learning more about implementing a SDR in an FPGA. So I'm looking to see if there are any trainings and/or dev boards to basically get your feet wet in it. I'm very familiar with FPGA but know very little about SDR so it's difficult for me to evaluate what would give a good introduction into this area. Are there any reasonably priced dev boards for this(<$2000)? Or maybe a training for a similar price? Anything you'd recommend outside of this to learn SDR?

Is it possible to learn it on a more generic dev board and view the output with a spectrum analyzer?

Any general tips or learning resources would be greatly appreciated.

Thank you!

[rteodor]

Are there any reasonably priced dev boards for this(<$2000)?

I'm not sure I understood your requests correctly but HackRF and LimeSDR have FPGA's on them.

so it's difficult for me to evaluate what would give a good introduction into this area

A nice set of SDR lessons to watch: https://greatscottgadgets.com/sdr/

[radiolistener]

sdrlab-122-16 has pretty nice RF frontend for SDR. It has 16 bit 122 MHz ADC and 14 bit 122 MHz DAC, ARM Cortex A9 + Xilinx Zynq 7020 FPGA, 1 Gbit GMII, USB 2 and 512MB RAM on the board.

It consists all what you need for SDR development on the board.
It also has ready to use firmware for SDR receiver/transmitter, so you can test it.

It will provide you with almost top SDR performance for the price, much-much better than hack-rf or lime-sdr.

If you want more cheap solution, you can use some cheap Chinese FPGA starter kit with about 15 kLE and some high speed ADC eval-board or even some cheap Chinese AD9226 based high speed ADC module, something like this one:
https://www.aliexpress.com/item/1005003086095043.html

Such config will cost you about 100-200 USD

[colorado.rob]

The ADALM Pluto SDR from Analog Devices is designed for this and only costs about $150 $180. It has a Zynq 7010 and an AD9363 SDR chip. There are similar devices from China with a Zynq 7020 which gives more resources as the 7010 is a bit constrained. Otherwise, you can buy a dev board with an FMC adapter and get one of the AD9631 FMC development boards.

[radiolistener]

ADALM Pluto nice device, but it uses 12 bit ADC. The same as lime-sdr. It is good, but cannot provide the best performance like sdr-lab-122-16.

Also, note that devices like ADALM Pluto or Lime-sdr, uses integrated RF transceiver chip  AD9363/LMS7002M instead of dedicated high speed ADC, it means that all DSP is performed in the chip and you cannot do it in your own way, so it's parameters is limited by RF transceiver DSP limitations. All what you can do is just to change settings for hardware implemented DSP, like load filter coefficients, enable/disable some feature and thats all.

When you use dedicated high speed ADC, there is no such limitation and you can implement your own DSP stack in FPGA. So, you can do all what you want.

[KE5FX]

One of the first things you'll learn in SDR is that the number of ADC bits is not especially important.

[radiolistener]

One of the first things you'll learn in SDR is that the number of ADC bits is not especially important.

ADC bits is very-very important, but you're needs to take into account sampling ADC rate frequency, in short - ADC bits needs to be compared for the same IF bandwidth frequency.

For example sdrlab-122-16 ADC working at 122 MHz (61.44 MHz bandwidth) and has 16 bits. If you use DDC to 20 MHz IF (as I know this is a max IF bandwidth frequency for ADALM Pluto), it will give you dynamic range:

16 bit * 6.02 + 1.76 dB + 10*log10( 61.44 / 20 ) = 96.32 + 1.76 + 4.87 = 102.95 dB

In comparison ADALM Pluto uses 12 bit ADC working at 20 MHz, so it will give you dynamic range:

12 bit * 6.02 + 1.76 = 74 dB

So, now you can compare dynamic range for 20 MHz bandwidth:
- sdrlab-122-16 provides you with 102.95 dB
- ADALM Pluto provides you with 74 dB

So, sdrlab-122-16 has about 102.95 - 74 = 28.95 dB better dynamic range than ADALM Pluto for the same 20 MHz IF bandwidth. The same difference will be for more narrow IF bandwidth.

In addition, note that AD9363 RF transceiver used in ADALM Pluto has hardware limitations for DSP processing, you cannot change DSP implementation, so you have to put up with mediocre signal processing. It is more easy to use, because all DSP is done in hardware chip, but you can't improve DSP stack and cannot experiment. But when you use sdrlab-122-16 you can implement any kind of DSP stack as you wish, so you can experiment with more better filters, etc.

And another issue of AD9363 RF transceiver is that it uses analog mixer for down/up frequency conversion. It means that you will have mirror channels, many spurs and images and other analog receiver issues. But when you use sdrlab-122-16, it uses digital down/up frequency conversion, so there is no mirror channels and much less spurs and images. 

Of course, if you want to deal with > 60 MHz signal, with sdrlab-122-16 you're still needs to add analog mixer and it will add mirror channels, spurs and images. But if you're deal with signals below 60 MHz, sdrlab-122-16 allows you to get the best crystal clear reception from 0 Hz to 40-50 MHz, much better than ADALM Pluto or Lime-SDR. And note that ADALM Pluto and Lime-SDR cannot work at low frequency.

As I remember, ADALM Pluto works from 325 MHz to 3.8 GHz, some versions can be unlocked to work from 70 MHz. For comparison with sdrlab-122-16 you can listen even submarine communications at ELF (3-30 Hz) or VLF (3-30 kHz) bands... 

[KE5FX]

One of the first things you'll learn in SDR is that the number of ADC bits is not especially important.

ADC bits is very-very important...

OP said s/he wanted to learn, not build high-dynamic range spectrum analyzers or monitor submarines.  A $500 platform isn't necessary to learn the ropes.  12 bits is fine.  The chip in the ADALM-Pluto was designed for service at cell sites, after all.  You can get I/Q data out of it, and that's all you need to learn.

[Kalvin]

One of the first things you'll learn in SDR is that the number of ADC bits is not especially important.

ADC bits is very-very important, but you're needs to take into account sampling ADC rate frequency, in short - ADC bits needs to be compared for the same IF bandwidth frequency.

For example sdrlab-122-16 ADC working at 122 MHz (61.44 MHz bandwidth) and has 16 bits. If you use DDC to 20 MHz IF (as I know this is a max IF bandwidth frequency for ADALM Pluto), it will give you dynamic range:

16 bit * 6.02 + 1.76 dB + 10*log10( 61.44 / 20 ) = 96.32 + 1.76 + 4.87 = 102.95 dB

In comparison ADALM Pluto uses 12 bit ADC working at 20 MHz, so it will give you dynamic range:

12 bit * 6.02 + 1.76 = 74 dB

So, now you can compare dynamic range for 20 MHz bandwidth:
- sdrlab-122-16 provides you with 102.95 dB
- ADALM Pluto provides you with 74 dB

So, sdrlab-122-16 has about 102.95 - 74 = 28.95 dB better dynamic range than ADALM Pluto for the same 20 MHz IF bandwidth. The same difference will be for more narrow IF bandwidth.

Let's assume that we want to build an SDR radio with 4kHz audio bandwidth.

Pluto samples 20MHz bandwidth using a 12-bit ADC, giving 12 bit * 6.02 + 1.76 = 74 dB of dynamic range. That is the dynamic range over full 20MHz bandwidth, without any processing gain. Now, if the SDR built using Pluto has a audio bandwidth of 4kHz, the processing gain will be 10*log10(20MHz / 4kHz) = 37dB. Taking the processing gain into account, Pluto will have a dynamic range of 74 dB + 37dB = 111 dB, which is not too bad any more.

Sdrlab-122-16 samples 61.44MHz bandwidth using a 16-bit ADC, giving 16 bit * 6.02 + 1.76 = 98 dB of dynamic range. The processing gain is 10*log10(61.44MHz / 4kHz) = 42dB. The total dynamic range is 98 dB + 42 dB = 140 dB, which is just excellent.

Although Sdrlab-122-16 will provide theoretically 29 dB more dynamic range than Pluto, the system's overall RF noise floor and ADC sampling jitter will probably even things out.

Here is a nice article about SDR and processing gain:
http://play.fallows.ca/wp/radio/software-defined-radio/sdr-receiver-processing-gain-create-virtual-bits/

[Kalvin]

An article about ADC sampling jitter affecting overall SNR:
https://www.analog.com/en/technical-articles/maximum-snr-vs-clock-jitter.html

For example if you have a 100MHz input signal, and you want 78dB of SNR you will need a clock source with less than 200fs of jitter.

[radiolistener]

Although Sdrlab-122-16 will provide theoretically 29 dB more dynamic range than Pluto, the system's overall RF noise floor and ADC sampling jitter will probably even things out.

for better jitter performance, you can use ultra low phase noise oscillator for ADC/DAC clock which is already installed on Sdrlab-122-16, and this is also why it cost more... But make sure, before buy, because some cheap models can use usual more cheap oscillator

OP said s/he wanted to learn, not build high-dynamic range spectrum analyzers or monitor submarines.  A $500 platform isn't necessary to learn the ropes.  12 bits is fine.  The chip in the ADALM-Pluto was designed for service at cell sites, after all.  You can get I/Q data out of it, and that's all you need to learn.

Yes, it cost 500 USD, which is more expensive than ADALM Pluto, but Sdrlab-122-16 allows you to implement any kind of DSP stack that you want. You can experiment with different filter types, different bit-width, different DSP stacks. On the contrary, with ADALM Pluto you will be stuck at hardware hardcoded DSP with 12-bit ADC, with no way to upgrade it, and all what you can do with it - is just to play with changing of some limited parameters.

So, it worth to think about solution with dedicated high speed ADC and good FPGA on the board. It allows you to experiment with real SDR features (with direct antenna digitization and fully programmable digital down/up conversion and processing).

Solutions based on RF transceiver chips just allows you to use hardcoded DSP stack (with many performance limitations due to complexity/cost optimizations). This is some kind of using bought mobile phone for learning ham radio. Mobile phone really allows you to use radio communications, but it cannot help you to learn how it works and cannot help to learn how to make QSO on short wave

[KE5FX]

Yes, it cost 500 USD, which is more expensive than ADALM Pluto, but Sdrlab-122-16 allows you to implement any kind of DSP stack that you want. You can experiment with different filter types, different bit-width, different DSP stacks. On the contrary, with ADALM Pluto you will be stuck at hardware hardcoded DSP

No idea where you're getting this.   The ADALM Pluto returns I/Q data to a host PC, where you can implement any DSP code you like.

Pro tip: start cheap.  When you need more speed or more bits, upgrade then.

[radiolistener]

No idea where you're getting this.   The ADALM Pluto returns I/Q data to a host PC, where you can implement any DSP code you like.

Both returns IQ data with IF to host PC.

But the difference is how this IQ stream is produced. With sdrlab-122-16 you're doing it in your own DSP stack implemented in FPGA and onboard ARM Cortex-A9 CPU with your own software/gateware. This software/gateware can be modified, replaced with another types of filters, you can use different filter order, different data processing bit-width to avoid rounding noises, you can use your own custom tweaks and DSP algorithms to produce this IQ stream. You can do all what you want with input raw ADC stream from antenna. This is what SDR is - Software Defined Radio. You define all DSP stack with your own software/gateware.

On the contrary with ADALM Pluto, you're stuck with DSP stack hardcoded in AD9363 chip. You can't modify it. You're using it as is and cannot experiment with different filters, cannot experiment with different DSP algorithms. You're just setup config registers and get result IQ stream with no way to change algorithms on how to produce it from antenna signal.

Technically ADALM Pluto is not SDR at all, because it doesn't allows you to change DSP program for processing raw ADC data flow. There is no programming for AD9363 chip, it's DSP algorithms is hardcoded inside chip and cannot be modified. So, you cannot say that this is software defined radio.

In short:
- sdrlab-122-16 structure: antenna signal => high speed ADC => your own DSP program => GMII/USB protocol  => IF IQ data for PC
- ADALM-Pluto structure: antenna signal => AD9363 with hardcoded DSP => GMII/USB protocol  =>  IF IQ data for PC

[KE5FX]

The part of the DSP chain that generates I/Q data is not the "interesting" part -- it's simply a quadrature DDS or CORDIC core, a multiplier, and some rudimentary FIR or CIC filters.  On the AD936x chips, the mixer stage is an old-school analog solution, in fact. 

Going forward, most SDR chips will implement this logic on-die as the AD936x parts do, doing the mixing in either the analog or digital domains.  That way it doesn't have to be done at the full ADC clock rate using an expensive ASIC or FPGA with an extremely wide/fast data bus.

If you still want to go through the exercise of implementing this stuff, you can feel free to do so with the I/Q stream on the PC, of course.  Or on the Pluto's Zynq chip, on either the PS or PL side.  But I suspect most students are more interested in what happens after the data has been converted to baseband.  That's where things like the GNU Radio flow graph come into play.

[radiolistener]

The part of the DSP chain that generates I/Q data is not the "interesting" part -- it's simply a quadrature DDS or CORDIC core, a multiplier, and some rudimentary FIR or CIC filters.

No, this is the most important part which defines technical specification of receiver (dynamic range, image rejection, spurious performance, DSP artifact presence, etc).

Simple DDC with simple CORDIC NCO and simple CIC+FIR leads to very-very dirty signal with bad spur performance, unwanted images, artefacts and dynamic range degradation.

But on the other side very good DDC and clean NCO is not simple at all, it is very hard to implement due to high speed requirements and a lot of required computational resources, in other words it requires a lot of high speed FPGA resources, such as hardware multipliers and more LE, in addition it leads to high current consumption. This is why AD936x uses simplified DSP - to reduce power consumption and simplify on-chip logic, just to get low cost at moderate output signal quality.

If you want to get the best output signal quality, to minimize unwanted spurs, images, DSP artifacts and improve dynamic range, you're needs to implement your own DSP on FPGA. Good DSP is not simple. For example, if you want to work with > 120 dB dynamic range, you will have problems with simple CORDIC NCO, because it's output will not be clean enough.

The same with filters. If you use CIC filter, you already get images. If you use simple 256-tap FIR it's not enough for 100 dB dynamic range. But 1024 and more tap filter requires much more computational resources. From my practice, FIR filter with 1024 tap and 18-bit coefficients is not enough for 120 dB dynamic range, so I'm using 24 bit coefficients, it barely covers 120 dB or even a little worse, but gives very significant improvements in comparison with 18-bit coefficients. All this eats a lot of FPGA resources.

If you working with > 120 dB dynamic range, you're needs about 24-bit data flow at full ADC speed, plus extended resolution for CIC and FIR accumulators to avoid overflow, so accumulators needs to be up to 96-bit and sometimes even more. All this is not easy at very high speed, because it involves very large amount of computation resources and they all needs to be synchronized and work in realtime at very high frequency.

If you simplify DSP it will have a lot of spurs, images and worse dynamic range, it's acceptable for cellular network, where these AD936x intended to work. But if you want to get better signal reception with less unwanted DSP artifacts and high dynamic range, it requires much more complicated DSP processing. So, AD936x is not an option and you will needs to implement your own DSP chain in a high speed FPGA which should have enough resources...

This is not simple task, because you're always need to sacrifice processing quality to keep within the available resources and processing frequency.

[radiolistener]

If you still want to go through the exercise of implementing this stuff, you can feel free to do so with the I/Q stream on the PC, of course.  Or on the Pluto's Zynq chip, on either the PS or PL side.  But I suspect most students are more interested in what happens after the data has been converted to baseband.  That's where things like the GNU Radio flow graph come into play.

Yes, but when your DSP before IF IQ stream is hardcoded, this is not SDR. May be you can name it Quasi-SDR, but this is not SDR. This is actually DSP post processing, something like audio sound improvements with DSP in operating system, like equalizer, echo effect, etc. The main SDR magic happens when you processing digitized antenna signal into IF and that part of DSP is implemented as a program and can be replaced with easy firmware update. This is where all unwanted artifacts, spurs and images appears in a cheap receivers

[Kalvin]

About customizing Pluto: You can customize ADALM Pluto, so it is not completely a black box. You can have access to the Zynq 7000 FPGA connected to AD9363, and you will have access to the registers and the baseband RX/TX I and Q signal paths. The FPGA has ARM CPU running Linux, which allows you to create your own application(s) etc. The documentation and the source code is freely available from Analog Devices's site. Probably this customization will take some coffee, sweat and tears, but it is doable.

I have not been brave enough trying to rebuild the stuff, so I cannot comment on how easy or hard it really is.

----

Here is general information about ADALM Pluto:
https://wiki.analog.com/university/tools/pluto

In the section "HDL and Embedded Software Resources" one can find HDL related stuff (ADALM-PLUTO for Developers):
https://wiki.analog.com/university/tools/pluto/developers

The people who typical read these pages are those who write custom software or HDL (for the FPGA) that run directly on the Pluto device. This may put the Pluto in different modes, and support different external USB devices (including USB/LAB, or USB/WiFi), extending the capabilities of the device, or completely changing the data that is transferred to the host.

Using Pluto with Windows SDR radio, and the hacks for extending the frequency range and enabling the second CPU core:
https://www.sdr-radio.com/pluto

----

ADALM Pluto may not be an optimal solution for a person who wants to create a standalone SDR using an FPGA. However, it is a relatively inexpensive way to get started when experimenting SDR transceivers and different algorithms.

As KE5FX wrote, the RF front end is pretty boring, and the interesting stuff happens after getting the baseband signals I and Q. Pluto and GNU Radio work pretty well together, and GNU Radio makes it quite easy to try different receiver and transmitter algorithms:
https://wiki.gnuradio.org/index.php/PlutoSDR_Source

If I have understood correctly, it is also possible to run (at least some) GNU Radio blocks inside Pluto.

Unfortunately Pluto is not suitable for HF frequencies below 70MHz, but it is suitable for VHF and UHF communication in range 70MHz - 6GHz (after tweaking the boot loader settings).

Please bear in mind that Pluto doesn't have any filtering in TX (or in RX for that matter), so it will emit lots of harmonics if the TX is connected to an antenna without proper filtering. This may cause problems with radio devices nearby. Also, it is illegal to transmit on the frequencies that you are not licensed for, so be careful.

Since Pluto doesn't have any RX filtering either, it may be useful/necessary to use an external bandstop filtering for 80MHz - 108MHz, because the local FM stations may easily saturate the RX front-end and/or ruin the RX sensitivity.

[radar_macgyver]

Sdrlab-122-16 samples 61.44MHz bandwidth using a 16-bit ADC, giving 16 bit * 6.02 + 1.76 = 98 dB of dynamic range. The processing gain is 10*log10(61.44MHz / 4kHz) = 42dB. The total dynamic range is 98 dB + 42 dB = 140 dB, which is just excellent.

The SNR of high-speed ADCs rarely follows the 6N + 1.76 formula. They often specify either an SNR in dB, or an "effective number of bits", which is just the SNR divided by 6. State of the art ADCs as of a few years ago (I haven't been keeping up with them recently) don't exceed an SNR of about 74 dB (effective bits = 12.5). The reason one has a larger bit count is for linearity. A 12 bit ADC may have an SNR of 74 dB, and linearity (SFDR) corresponding to 12 bits. Higher bit count ADCs will still have about 74 dB SNR, but the linearity (and hence SFDR) will improve. If one is digitizing a large bandwidth at a time, or a weak signal in the presence of a strong blocker, linearity is important. If the RF front-end already presents a relatively narrow-band signal to the ADC, the SFDR spec is not as important.

[radiolistener]

State of the art ADCs as of a few years ago (I haven't been keeping up with them recently) don't exceed an SNR of about 74 dB (effective bits = 12.5). The reason one has a larger bit count is for linearity. A 12 bit ADC may have an SNR of 74 dB, and linearity (SFDR) corresponding to 12 bits. Higher bit count ADCs will still have about 74 dB SNR

As I know, sdrlab-122-16 uses LTC2185, this is not "State of the art ADC", according to the datasheet it has:

SNR = 76.8 dB
SFDR = 90 dB

And yes, SNR=76.8 dB correspond to ENOB = 12.5 bit, but don't forgot that any ADC has real SNR worse than theoretical. And 12 bit ADC will have ENOB about 10-11 bit max.

This is not the best, you can find other ADC with better SNR.

If you're looking for something better, you can try for example LTC2217 16 bit high speed ADC, according to the datasheet it has:

SNR = 81.3 dB
SFDR = 100 dB
IMD = 100 dBc

SNR = 81.3 dB corresponds to ENOB = 13.2 bits.

[colorado.rob]

Now, if the SDR built using Pluto has a audio bandwidth of 4kHz, the processing gain will be 10*log10(20MHz / 4kHz) = 37dB. Taking the processing gain into account, Pluto will have a dynamic range of 74 dB + 37dB = 111 dB, which is not too bad any more.
...
Here is a nice article about SDR and processing gain:
http://play.fallows.ca/wp/radio/software-defined-radio/sdr-receiver-processing-gain-create-virtual-bits/

If that formula were the whole truth, you could only get 18dB of dynamic bandwidth from a PDM microphone at 3Mb/s sample rate when converting to 48ksps. This is the part that makes DSP fun. And a reminder that one does not need RF to do DSP. You can do reasonable DSP using just 1-bit I/Os on an FPGA.

[TWMIV]

And another issue of AD9363 RF transceiver is that it uses analog mixer for down/up frequency conversion. It means that you will have mirror channels, many spurs and images and other analog receiver issues. But when you use sdrlab-122-16, it uses digital down/up frequency conversion, so there is no mirror channels and much less spurs and images. 

As soon as you enter into a strong signal environment you are going to have the majority of your DR eaten up, especially if you are attempting to interrogate small signals in that environment. While it requires proper frequency planning and some skill, a multi-conversion front end is going to work better unless you are in an incredibly controlled environment.

Spurs and images are dealt with during frequency planning and mirror channels are not an issue as you should know which Nyquist region you want to operate in. Run direct conversion for your first bandwidth chunk and then run the next 18+ GHz of spectrum into the 2nd or 3rd Nyquist region. Simply relying on DDC's are not going to get you very far when you are out in the real world.

The 122-16 seems to be decent but I am surprised they used the VCXO they did. The Crystek cvss-945 for ~$30 is the best that I have found and measured on the market.

[radar_macgyver]

This is not the best, you can find other ADC with better SNR.

You're right - I didn't specify that I had limited my search to ADCs >= 200 MSPS. At the time, I settled on the ADS5485, with 75.8 dB SNR. There were newer parts available, but their SNR was not any better. In the same family, one could consider the ADS5482, at 105 MSPS, with 80.8 dB SNR. However, when coupled to an FPGA downconverter to a 1 MSPS IQ stream with corresponding band-limiting, the equivalent noise power achieved will be the same, since the downconversion ratio is smaller.

Anyway, my point remains that one cannot use the 6N formula directly to estimate SNR of high speed ADCs.