In my roadtest application, I suggested that I could go as far as running rtl_433 directly on the RedPitaya, inside its Linux OS and talking directly to the FPGA like the original apps are doing.
For this, one would need to compile both the FPGA part and the Linux part and then transfer the binaries to the RedPitaya.
Because the SDR applications are from Pavel Demin, I used his instructions: https://pavel-demin.github.io/red-pitaya-notes/development-machine/.
It guides through the creation of a virtual machine, running Debian 13, aiming at accessing it remotely. Sadly, this was not such a great idea because it assumes the host system is offering a X-Window compatible system that can get forwarded via SSH. Under Windows, this is not working with latest versions, so I resorted to create a fully graphical environment inside a Linux VM using my usual Manjaro (Arch based) distribution.
The first thing to download is the AMD Unified installer at version 2025.2. Beware, it needs more than 100G of free disk space, and you must register an account with AMD before accessing it.
During setup, refuse using the latest version, make sure to use the one you downloaded and to select the following item: Devices -> SOC -> Zynq 7000 all programmable
At the end of the installation, you should have this file: /opt/Xilinx/2025.2/Vitis/settings64.sh
If it’s missing, you must restart installation (yay!) after having installed the libtinfo5 and libncurses5 package libraries. There are no warning/error messages telling you this, it’s just sheer luck that Pavel was hit by this as well and gave the solution. For Arch based distributions, you will get those libs from the ncurses5-compat-libs in the AUR which also needs gcc and make from the official repos.
Following Pavel’s documentation, compiling is thus as simple as that:
source /opt/Xilinx/2025.2/Vitis/settings64.sh
make NAME=xxxx bit
This creates the FPGA configuration that needs to be uploaded to it, as can be seen in the start.sh script.
Compiling for the program itself is not so easy as it involves cross compiling from a Linux machine to another architecture (x86_64 to arm64).
There are no recommended IDEs, only a few talks about using Vivado’s own GUI for the FPGA while leaving aside the Linux part. If you are used to Arduino, Microchip or even ST, well, you’re on your own here. Personally, I went with VSCode and SFTP for transferring the compiled binaries to the board.
To help with cross compiling, I asked my favorite agents to chime in, but it was more of a slop loop than anything else. Indeed, it kept asking me to get information from the RedPitaya that were contradicting the information it read in Pavel’s sources. For instance, it insisted on targeting MUSL instead of LIBC which led to all sorts of complications that, in the end, are not needed at all!
But after the better of ten hours, I was able to get a rtl_433 binary that runs on the RedPitaya directly, whose sources are here: https://github.com/obones/rtl_433/tree/redpitaya
Sadly, it stops almost immediately with a “Bus error” message which hints at the fact that the FPGA is not properly initializing the shared buffers that are needed by the host application. No remote debug was attempted, I did not pursue that idea with help from LLMs to get this done.
Perusing the docs, I figured that this could be because Pavel’s make file create a .bit file that is pushed to the FPGA via /dev/xdevcfg when current recommendations are to use a .bit.bin file created manually, as found deep in the developer’s guide: https://redpitaya.readthedocs.io/en/latest/developerGuide/fpga/getting_started/reprogram_fpga.html
Sadly, using the recommended way to get a .bit.bin file and installing it via fpgautil only leads to a board reboot!
Initial development effort was done on the “sdr_receiver” program from Pavel, which allows for 490MHz but on 8 parallel receivers that have only about 6KHz bandwidth which is really poor.
But there is the “sdr_receiver_wide” project that has much larger bandwidth and should thus allow for wider coverage.
However, it relies on a CMA kernel module to reserve a memory region for the FPGA to write into and the host code to read from.
It is given as compiled into Pavel’s SD card image, but because I’m not using it, I tried to build it as a dynamic module for RP OS 3. For this, it appears we need to build directly on the RepPitaya, which means getting the right kernel headers.
The end goal is thus to build a cma.ko file that, once loaded, gives us the /dev/cma device file needed for sdr_receiver_wide.
The Linux headers are retrievable from https://github.com/RedPitaya/linux-xlnx.git
But after another good five hours of frustrating exchanges with a few LLM models, this has gone nowhere.
However, using a custom kernel module might not be necessary at all if using stock CMA that is already built in the standard RP OS image.
Suggested change in sdr_receiver_wide.c:
#define RAM_PHYS 0x2000000 /* from monitor -r */
#define RAM_SIZE (2048*4096)
fd = open("/dev/mem", O_RDWR); /* no O_SYNC */
cfg = mmap(NULL, sysconf(_SC_PAGESIZE), PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0x40000000);
sts = mmap(NULL, sysconf(_SC_PAGESIZE), PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0x41000000);
ram = mmap(NULL, RAM_SIZE, PROT_READ|PROT_WRITE, MAP_SHARED, fd, RAM_PHYS);
close(fd);
...
*rx_addr = RAM_PHYS;
Sadly, this is not yet tested because of the FPGA issues.
What would really help would be to get hold of the changes made to Pavel’s code so that it integrates into the current OS version, as mentioned in the documentation:
The applications listed above are third-party applications, as they are ported directly from Pavel Demin’s Alpine Linux image. Please note that we synchronise the applications with each official Red Pitaya OS release, so they may not reflect the latest community updates. For access to the latest community updates, please check the Pavel Demin's Red Pitaya Notes GitHub.
The only details one can get are those printed on the console welcome message:
##############################################################################
# Red Pitaya GNU/Linux Ecosystem
# Version: 3.00-e00665135
# Build: 57
# Branch: origin/master
# Commit: e00665135eb4fc09aa8a81298b702ff501e8469d
# U-Boot: redpitaya-v2026.1
# Linux Kernel: Release_2026.1
# SDR bundle: SDR-bundle-82-cbecbdd4.zip
##############################################################################
Where is this SDR bundle zip file coming from? How was it built? There is definitely not enough information to get the required inspiration to reproduce the changes on other projects.
And because I have not received any answers to my requests on the help forum, once again, I’m stuck.
This blog is part of 7-part series for my Red Pitaya STEMlab 125-14 PRO Gen 2 Starter Kit roadtest:
Blog 1 – Unboxing the Red Pitaya STEMlab 125-14 PRO Gen 2 Starter Kit
Blog 2 – First contact with the Red Pitaya STEMlab 125-14 PRO Gen 2
Blog 3 – Oscilloscope application in the Red Pitaya STEMlab 125-14 PRO Gen 2
Blog 4 – Logic analyzer application in the Red Pitaya STEMlab 125-14 PRO Gen 2
Blog 5 – Software defined radio with the Red Pitaya STEMlab 125-14 PRO Gen 2
Blog 6 – Developing for the Red Pitaya STEMlab 125-14 PRO Gen 2
Red Pitaya STEMlab 125-14 PRO Gen 2 roadtest report
