In the last instalment of my Stemlab Red Pitaya SDR transceiver project, I completed the design and build of the receiver front‑end module, which includes an RF pre‑amp, bandpass filters, and a digital attenuator. This module improves the Red Pitaya’s receiving performance and adds an extra layer of protection to the Pitaya’s ADC input.
With the new receiver front‑end built and tested, I’ve thoroughly enjoyed listening to the HF bands and evaluating the enhanced performance of the Red Pitaya when integrated with the superb Thetis software.
If you are not familiar with the Thetis software, it is an advanced SDR client originally developed for the Apache Labs ANAN transceivers, and it’s become a popular choice for Red Pitaya‑based SDR projects. It provides a highly configurable interface, low‑latency DSP, powerful filtering, and excellent visualization tools. With features like adaptive noise reduction, customizable panadapter displays, and flexible transmit/receive profiles, Thetis brings out the full potential of the Red Pitaya hardware and offers a polished, professional operating experience.
To continue documenting my SDR transceiver build, this post covers the design and construction of a dedicated controller that enhances and complements the Red Pitaya module, the heart of the project.
Connectivity Options for Interfacing Hardware to the Red Pitaya in an SDR Transceiver Build.
Building a capable SDR transceiver around the Red Pitaya requires an understanding of how to interface external RF modules, filters, amplifiers, and other hardware with the board. Fortunately, the Red Pitaya provides a set of GPIO pins via expansion headers, which can be controlled by software such as Thetis to manage and switch external hardware.
Whilst the Red Pitaya is very capable of controlling additional hardware, I decided that I wanted to enhance some of the control by designing and building a dedicated control module using an STM32 "Blue-Pill" microcontroller board.
What are the benefits of adding an STM32 based controller:
- Automatic control of the RF Preamplifier by looking at the band data logic.
- Control of attenuator logic so it is not totally dependent on Thetis control.
- Safe & reliable TX/RX sequencing with forward and reverse logic.
- PA bias control
- Thermal management with sensors and fans.
- Band logic pass through.
- Front panel display for visual feedback of hardware states.
- More expansion capabilities.
The schematic for my homebrew Red Pitaya SDR controller is shown below.
 |
| Click image to enlarge to full size! |
The STM32 “Blue Pill” development board is a surprisingly capable despite costing less than £2 from places like AliExpress, it delivers impressive performance and a specification sheet that far exceeds what you’d expect at the price point.
The STM32 “Blue Pill” pairs a 72 MHz ARM Cortex‑M3 with up to 128 KB of Flash, 20 KB of RAM, and a rich set of peripherals, including SPI, I²C, multiple UARTs, USB device support, and 12‑bit ADC channels. Its compact footprint, fast timers, and versatile GPIO make it a surprisingly capable platform for embedded control and radio projects especially given its extremely low cost.
The controller board I developed for my Red Pitaya SDR transceiver is designed to provide both enhanced functionality and robust protection for the underlying hardware. The board incorporates an onboard 5‑volt buck converter capable of supplying power directly to the Red Pitaya, supported by reverse‑polarity protection and a crowbar overvoltage circuit to ensure the supply rail remains within safe limits at all times, an essential safeguard given the cost of the Red Pitaya module.
Two independent temperature‑monitoring channels are provided: one dedicated to the Red Pitaya’s FPGA and the other to the transmit RF amplifier. These sensors feed into the STM32’s control logic, which automatically manages cooling fans to maintain stable operating temperatures. The controller also supports two PE4302 or PE4312 digital attenuators, with the microcontroller handling the required latch and hold timing and TX/RX switching. A "BCD" filter pass‑through interface manages the transmitter’s low‑pass filter banks, ensuring that the filters are only engaged during transmit operation. Additional programmable delay functions allow for precise transmit sequencing, while the STM32 also serves as an isolation and protection layer between the Red Pitaya and the external keying and PTT lines. Collectively, these features create a reliable, self‑contained control system that significantly enhances both the operational capability and protection of my Red Pitaya based sdr transceiver.
Below is an image that shows my completed Red Pitaya SDR controller board:
 |
| Red Pitaya SDR Controller Board By G6LBQ |
As shown in the image above, the “Blue Pill” module seats cleanly into a pair of header connectors. This arrangement allows the module to be removed or replaced quickly and with minimal effort.
The PCB I designed is a two‑layer board measuring 135 by 70mm, most components are mounted on the top side and only a few small SMD parts placed on the bottom. The next image shows the underside of the PCB.
 |
| Red Pitaya SDR Controller Board Bottom View |
I’ve written the custom firmware for the Blue Pill using the Arduino IDE, and so far it has performed reliably. Once I design the transmitter amplifier for the project, I may need to adjust a few software parameters, mainly the TX sequencer timing and fan‑control logic-but those changes will be straightforward. I’ve added clear, purposeful code comments throughout, so future tweaks should be quick and painless.
I chose the STM32 “Blue Pill” for this project because I’d already used it as the VFO controller in my Irwell HF Transceiver. After spending a lot of time working with it tuning the firmware, exploring its peripherals, and expanding the VFO features, I’ve become increasingly confident in programming it. I’ve also found the Blue Pill to be stable and reliable, so it was an obvious choice for this project, even if its capabilities are probably overkill for the job.
I’m using the same ILI9341 display module that I also used for my Irwell VFO, along with the same UCG graphics library. I’ve since updated the library so it works with the newer IPS version of the display, which offers far better viewing angles and overall image quality.
Here's is a picture of the display in use with the current software:
The camera on my phone doesn’t capture the display accurately, so the image quality appears worse than it is in reality. The temperature readings shown are also invalid because the sensors were not connected to the controller board at the time. The BCD data at the bottom of the screen is for debugging only and will not appear in the final software version.
STEMlab Red Pitaya Connectivity:
The Red Pitaya exposes two 16‑pin expansion connectors, labeled E1 and E2, which provide access to its digital I/O pins. These connectors also carry the I²C and SPI buses, both of which are used to interface with an external audio codec board—a topic I’ll explore in detail in the next post.
To hook up my controller module to the Red Pitaya, I first needed to bring a few signals out from the E1 and E2 headers so I could verify that the module behaved as expected. After reviewing the pin assignments on both headers, I put together a concise connection diagram as a reference, which you’ll find below.
 |
| Click image to enlarge to full size! |
Red Pitaya Firmware:
Before the Red Pitaya can be used as an SDR transceiver, it requires a custom firmware package and thanks to the excellent work by Pavel Demin a ready to use solution is available.
Pavel Demin’s SDR firmware is essential because the Red Pitaya, in its factory state, is designed as a general‑purpose measurement instrument not as a high‑performance software‑defined radio. His firmware replaces that limitation with a complete, purpose‑built SDR signal chain that unlocks the full potential of the board’s FPGA and high‑speed ADC/DAC hardware. By adding a custom digital down‑conversion and up‑conversion pipeline, carefully designed filtering, and a low‑latency Ethernet streaming protocol, the firmware transforms the Red Pitaya into a fully capable transceiver that can interface with applications like Thetis and PowerSDR. It handles everything the stock system doesn’t: real‑time DSP, HPSDR‑compatible networking, stable I/Q streaming, and the control logic needed for external modules such as audio codecs and GPIO‑based PTT. In short, it provides the radio‑specific intelligence that the hardware lacks on its own, turning the Red Pitaya from a versatile lab tool into a genuinely usable SDR platform.
You can download Pavels latest firmware from the following web link:
https://github.com/pavel-demin/red-pitaya-notes/releases
I also recommend taking a look at the documentation Pavel has put together at:
https://pavel-demin.github.io/red-pitaya-notes/
It should be noted that Pavel Demin’s SDR firmware does not provide native support for the PE4302 or PE4312 digital attenuators. However, either device can be integrated by driving it over the Red Pitaya’s SPI bus or GPIO lines, providing the SDR software application is written to handle the necessary control logic.
From my testing with Thetis version 2.10.3.11, support for the PE4302 appeared limited. I was able to control the attenuator and set the desired attenuation level, but I could not get the device to latch something that’s essential when switching between receive and transmit, and vice versa.
Fellow radio amateur Sigi, DH1KLM, made me aware of JA5AEA’s Orochi software and hardware implementation for using the PE4302 digital attenuators with the Red Pitaya. I experimented with this approach as well, but I couldn’t get it to operate correctly. The Orochi design relies on pin 5 of connector E1 and pin 6 of connector E2 to provide control logic to a CD4052N multiplexer/demultiplexer, which in turn drives the latch‑enable pins of the PE4302 attenuators.
I concluded that Thetis was not sending the control commands needed to drive the Red Pitaya logic and the PE4302 attenuators correctly. To work around this, I moved the control logic to an STM32 “Blue Pill,” and with that in place the latch‑enable line now behaves as it should when switching between receive and transmit. In theory this means one PE4302 can handle receive attenuation while a second can be used for PureSignal on transmit. I’ve tested the receive attenuator and it works reliably; the transmit‑side PureSignal attenuator will have to wait until I progress further with the project and complete the transmit chain.
Final comments:
The controller and transceiver build are now starting to come together in a way that feels solid and repeatable. With the STM32 handling the control logic and the receive‑side PE4302 behaving exactly as intended, the core architecture is finally taking shape. There’s still plenty to do, most notably completing the transmit chain and bringing the PureSignal attenuator online but the foundations are now in place and working reliably. Each step forward is confirming that the overall design is sound, and the next stages should build on this momentum as the project moves closer to a fully functional SDR transceiver.
In my next blog post I will be looking at adding an audio codec and preparing a case for the build, but for now...
Project files will be made available via the Groups.io platform by joining my G6LBQ community group, where you can discuss my projects, ask questions and help others.
Joining my group is free. Just click on the button below.
No comments:
Post a Comment
I appreciate your comments on the blog content, however the blog has been subject to idiots trying to use the comments facility as a means to post advertisements & spam so all comments are now approved and moderated.