STEMlab RED PITAYA SDR Transceiver Build Part 4

 

In the last instalment (Part 3) of my STEMlab Red Pitaya SDR transceiver project, I covered the process of moving some of the control logic off the Red Pitaya and onto the controller module I designed around an STM32 “Blue Pill” microcontroller. This shift has given me far more reliable handling of RX/TX transitions, cleaner timing, and full control over the PE4302 attenuation stages—something the SDR software alone couldn’t provide. The effort that went into designing the controller and writing the firmware is now paying dividends, as the module has become the central piece that ties the hardware together and keeps the system predictable while I continue developing the rest of the transceiver. With the receive path behaving exactly as intended, the controller is now ready to support the next phase of the build as I move toward completing the transmit chain and integrating PureSignal.

As the build progresses, I’m really starting to appreciate the benefits of the new features being added. The digital attenuator in the receive path has already proven its worth, especially when strong nearby signals or a barrage of contest stations threaten to overload the ADC. Automatic switching of the RF preamplifier on the higher bands has also become a welcome addition, bringing weaker signals up out of the noise without me having to remember to enable it manually. These refinements make the receive chain far more robust and user‑friendly as the project continues to evolve.

In this blog post, I explore the role of audio codecs in my transceiver build, specifically how they convert analogue microphone signals into digital data for transmission, and then back into analogue audio for clean, low latency monitoring and listening. This marks an important step toward completing the audio path and integrating full voice capability into the SDR architecture.

Choosing the Right Audio Path: Hardware Codec vs. PC Audio

The Red Pitaya does not include an onboard audio codec, so it provides no direct microphone input, line‑level input, or audio output suitable for headphones or speakers. Adding a dedicated audio codec module fills this fundamental gap and allows the radio to behave like a complete SDR rather than a lab instrument adapted for RF work. While the Red Pitaya’s high‑speed ADCs and DACs excel at RF sampling, they cannot handle audio band tasks such as microphone capture, monitoring, or speaker‑level output. Integrating an external codec introduces the proper audio band ADC and DAC stages, enabling clean microphone audio, reliable monitoring, and controlled routing, essential building blocks as the project moves deeper into the transmit path and toward full voice operation and PureSignal support. 

Routing audio over a LAN connection is certainly possible when no dedicated audio codec is present, shifting all audio processing to the host PC and leaving Windows to manage microphone input and audio output. However, this approach comes with several limitations. A slow or heavily loaded PC or even minor network congestion can introduce latency, jitter, and buffering delays that make the audio feel sluggish or unstable. Beyond performance, relying on the Windows audio stack removes the tight, deterministic timing that a hardware codec provides, making features like clean sidetone, fast PTT response, and predictable monitoring more difficult to achieve. It also ties the entire audio path to the PC, reducing the radio’s independence and making the overall system more fragile compared to a design with dedicated, local audio hardware.

After spending time researching codec options and studying what other builders have used in their Red Pitaya‑based SDR projects, it quickly became clear that the WM8731 is the preferred audio codec for this type of transceiver. 

Wolfson WM8731Audio Codec - 28 PIN SSOP

I was pleased to discover that a ready-made WM8731 module is available to buy, saving me the effort of designing my own board, laying out a PCB, and having it manufactured. With the WM8731 now considered obsolete and increasingly difficult to source as a standalone IC, using a prebuilt module is by far the most practical option. The module I chose is produced by MIKRO, and it’s shown in the image below.

MIKRO CODEC PROTO - Size 41.27mm by 49.36mm

MIKRO list the board as their 506 PROTO module, and I ended up buying mine from an eBay seller because all of my usual suppliers were out of stock, likely a consequence of the WM8731 now being an obsolete device.

Next is a wiring diagram for connecting the Mikro board to the Red Pitaya.

Red Pitaya & Mikro Codec Proto Wiring Diagram.

Connecting the MikroE codec board to the RED Pitaya turned out to be a straightforward wiring job, and the firmware recognised the board immediately. One thing I did notice, however, was that having the codec in the circuit introduced a number of low‑level spurs that appeared on the Thetis waterfall even with no antenna attached. Most of these were down around −120 dBm or lower, with a few more noticeable ones between roughly −105 and −115 dBm.

Spurs visible on the 20m band with no antenna attached.

These spurs are most likely caused by low-level coupling from the codec’s power rails and clock signals into the RED Pitaya’s analogue front end. They stand out clearly with no antenna attached, but once the natural band noise is present, they’re effectively buried and have no impact on normal operation.

In an effort to reduce or eliminate the spurs, I added additional decoupling capacitors and ferrite beads to both the codec and RED Pitaya power supply feed points, but this made no noticeable difference. All of my ground connections are relatively short, so I don’t believe it’s a ground loop issue, though at this stage I’m not sure how I could prove that conclusively.

Frustrated by the spurs and increasingly curious about their cause, I spent some time searching online to see whether anyone else had encountered the same issue or found a workable solution. Unfortunately, nothing I found offered any new ideas beyond what I had already tried. I did, however, come across a company called Smart Radio Concepts, who produced a RED Pitaya based SDR transceiver known as the Charly25 SDR. They also offer a range of add‑on boards and accessories, including their own Charly 25 CODEC board, which is based on the WM8731 audio codec.

Charly 25 CODEC Board - Size 100mm by 60mm

One thing that immediately stood out to me about the Charly 25 CODEC board is that it includes a dual 7‑watt audio amplifier, something the Mikro board lacks and would require as a separate module if I continued using it. The team at Smart Radio Concepts appear to have put a lot of thought into the design of their codec board, which incorporates several nice features, including a four-layer PCB that provides proper separation between the analogue and digital grounds. They’ve also added noise‑filtering components and an I²C buffer to reduce the load on the Red Pitaya’s I²C bus.

At the time of writing this blog, the Charly 25 CODEC costs £92.98 plus shipping, whereas the Mikro board from RS components in the UK costs £20.92 plus shipping, so there is a big difference in price to consider.

I decided to order the Charly 25 CODEC board and take a chance that it might reduce the rogue spurs, even though they don’t really cause a problem in practice once they’re buried in the band noise. It still bothered me that they were there at all, so I felt it was worth trying a different approach.

With the Charly 25 CODEC installed in my transceiver build, I carried out a series of tests and confirmed that the spurious signals were still present, with no notable improvement over the Mikro board. Although that result is somewhat disappointing, I don’t regret upgrading the codec. It remains the best long‑term choice for my SDR architecture, particularly in an RF‑heavy environment where its additional onboard filtering should provide greater overall resilience.

For now, I’ll accept the spurs until I can come up with further ideas to test as part of the elimination process. If you have any suggestions, please feel free to contact me using the online form available at the top of every page on my blog.

Finally, I had hoped to share some progress on the mechanical side of housing the transceiver, but that will have to wait until my next post. I’m currently building a PCB‑cutting machine so I can accurately produce the PCB panels needed for screening enclosures and chassis components.

In the next blog post, I’ll be presenting my PCB‑cutting machine and reviewing the progress I’ve made on housing my SDR transceiver, 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.

 

 

Until next time...

73's From Andy G6LBQ

It's all about the Radio Ga Ga...