This post covers topics such as: Hardware selection challenges for DVBS/S2 demodulation
SDR-based approach using RTL SDR and leandvb
FPGA implementation using Xilinx XC7Z010 (Zynqberry board)
Test bench setup with SD card and Linux (Petalinux)
Development workflow combining Verilog/HLS and C++
Signal processing including notch filter implementation Hardware selection challenges for DVBS/S2 demodulation SDR-based approach using RTL SDR and leandvb FPGA implementation using Xilinx XC7Z010 (Zynqberry board) Test bench setup with SD card and Linux (Petalinux) Development workflow combining Verilog/HLS and C++ Signal processing including notch filter implementation So, I set myself a task – to develop a DVBS/S2 demodulator. The first solution that comes to mind is using off-the-shelf demodulator demodulator chips. But everything came down to documentation and the availability of corresponding chips on the market. While both were available for DVBS decoding (although with great difficulty), for DVBS2, either documentation was available but the chips themselves weren’t commercially available, or vice versa. As a result, only a DVBS demodulator was developed and debugged based on off-the-shelf chips (I hope we’ll describe this process in more detail in the future). This wasn’t without its challenges either: to debug it, a DVBS modulator had to be built and debugged. For this purpose, an amateur radio design was replicated: https://www.g8ajn.eyrg.net/dlsoftware1.html https://www.g8ajn.eyrg.net/dlsoftware1.html Here’s a photo of the resulting design: It’s worth noting that the DVBS modulator shown in the photo didn’t work very stably, so it had to be improved later and a second version was manufactured (the frequency synthesizer had to be replaced). As for the DVBS2 demodulator, it was decided to develop it from scratch, based on SDR (Software Defined Radio). However, to develop DVBS2 based on SDR, it’s more correct to first develop DVBS on SDR, since many decoding stages overlap, and the DVBS demodulator is obviously simpler to implement. The first step has already been taken – we have a working DVBS signal modulator, meaning we have the original DVBS signal itself. We set the modulation frequency for the generator at 1 GHz (in practice it was 999,900,000 Hz). To record this signal, we use RTL SDR – https://www.rtl-sdr.com/about-rtl-sdr/. We feed the signal from the modulator to the RTL SDR input, and the resulting IQ file with 8-bit digital sampling is output. https://www.rtl-sdr.com/about-rtl-sdr/ Next, we need to verify that the obtained IQ file is decoded correctly. I used this recorded file as the input of a software DVBS decoder and get a decoded ready transport stream file at the output, which can be opened in any media player on a computer to watch the video. As a software DVBS decoder, I used leandvb – https://www.pabr.org/radio/leandvb/leandvb.en.html. https://www.pabr.org/radio/leandvb/leandvb.en.html Of course, to implement streaming decoding, much more effort is needed, but at this stage we’ve significantly simplified our task – all further actions can be performed with the IQ file. There’s no longer any need to use physical signals. The maximum symbol rate of DVBS/S2 signals from satellite is typically 45,000 Ksym/sec. This means that digitization must be done at a sampling rate of at least 90 MHz, and then demodulation must be performed at this frequency in streaming mode. The only suitable implementation option is to use an FPGA. We’ll also need to integrate the FPGA with an ADC, but at this stage we won’t consider the analog part, since we already have an IQ file. Thus, the task comes down to the following – we need to develop a DVBS demodulator for IQ signals, operating at a minimum frequency of 90 MHz and transmitting demodulated data to the PC in streaming mode. Let’s proceed from the end. We need to get the demodulated data onto the computer. Let’s say we’ve demodulated it, but how do we transfer the data to the PC? One option is via the PCI-E bus, but that would require developing a specialized board for the data exchange; that’s too complicated. Another option is via USB. Quite feasible, except that USB connections tend to be quite unreliable, so I try not to use them unless absolutely necessary. And the third option is through an Ethernet network. This option looks most suitable. But then the FPGA must support transmission over Ethernet, and the whole solution shouldn’t be prohibitively expensive. Ultimately, the choice fell on the Xilinx XC7Z010 FPGA, which combines FPGA and CPU. The FPGA will handle demodulation, and the CPU will handle data transmission to the network (or via USB). This FPGA contains two ARM cores; one core can control the demodulation process, and the second – data transmission to the network. I chose the Zynqberry board because it contains, among other things, GPIO pins that can be connected in the future, for example, to the ADC output, and an Ethernet RJ45 network connection port. The demodulation process consists of multiple steps, each performing specific signal processing. Let’s assume we’ve completed the first step on the FPGA and obtained the output. How do we verify that we didn’t make any errors at this step and that the result is exactly as expected? After all, the slightest will cause the results of all subsequent demodulation steps to be incorrect, even if these steps themselves are implemented without errors. This means we must have a program that: performs a complete demodulation cycle of the original signal (yes, we already have such a program – it’s leandvb),
we must be able to make changes to this program so that we can feed it an intermediate signal after FPGA processing as the input signal. performs a complete demodulation cycle of the original signal (yes, we already have such a program – it’s leandvb), we must be able to make changes to this program so that we can feed it an intermediate signal after FPGA processing as the input signal. This means that it will be necessary to simultaneously make changes to both the FPGA code and the decoder software code on the PC, so that at any moment the intermediate result from the FPGA can be fed to the software demodulator and it can be seen whether the remaining part of the demodulation is occurring correctly. That is, we’ll have to program simultaneously in both the FPGA language (I used Verilog and HLS) and C++. At the development stage, there’s no need to process streaming data specifically. It’s sufficient to process data from a file at 90 MHz frequency and write them to a new file. Therefore, I created the following test setup: I write the original IQ file to an SD card, insert this card into the Zynqberry, and boot Linux (either from the same SD card or via USB-UART). Petalinux is an excellent OS for this purpose. After that, I can connect to Zynqberry via ssh through the network, and run my program from the command line via ssh, which starts the demodulation process. This process consists of the following: the program reads data from the SD card file, packet by packet, writes it to the Zynqberry’s DRAM, then initiates the transfer of this data from DRAM to the PL part of the FPGA. The processed data is written back to the DRAM and from there to a new file on the SD card. This repeats continuously packet by packet until the entire original IQ file is processed. After this, via SSH we can download the processing result and feed it to the input of our software demodulator to verify that the FPGA processing was correct. This way, each decoding stage can be developed independently of the other stages; it will be sufficient to write a file with input data for the current processing stage to the SD card. Read more in the note FPGA Test Bench (coming soon). FPGA Test Bench . Let’s look at the spectrum of the original IQ signal. In its center, a peak is clearly visible – this is a parasitic peak that will always be present due to low-frequency signal interference: It’s desirable to remove this peak before the demodulation process; for this, a notch filter must be applied. As of today (October 2025), the notch filter is fully implemented and tested in FPGA. For more information on how this is done, see the next post: Implementing a Notch Filter on an FPGA (coming soon). Implementing a Notch Filter on an FPGA Igor

Building an H.264 Decoder with Nvidia CUDA

Read My Stories

Developer

Too Long; Didn't Read

Boost your HackerNoon story @ $159.99! 🚀

Building a DVBS/S2 Demodulator from Scratch: A Journey Through SDR, FPGA, and Signal Processing

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

Building an H.264 Decoder with Nvidia CUDA

Projects to Programs: A Client-Partner Playbook for AI, Cloud & Data That Actually Moves the needle

When Simple Gets Complicated: Building Reliability Into OpenTab Payments

Build a Website Change Alert SaaS with Node.js, Puppeteer, and Stripe

FPGAs, SoCs, Microcontrollers— A Quick Rundown of IoT Devices

Building an H.264 Decoder with Nvidia CUDA

Projects to Programs: A Client-Partner Playbook for AI, Cloud & Data That Actually Moves the needle

When Simple Gets Complicated: Building Reliability Into OpenTab Payments

Build a Website Change Alert SaaS with Node.js, Puppeteer, and Stripe

FPGAs, SoCs, Microcontrollers— A Quick Rundown of IoT Devices

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps