A few years ago, I published an article asking (Is a Poor Man's 705 possible?
At that time, Ashhar VU2ESE announced work on the sBitx - an Open Source Software Defined Radio (SDR) using a Raspberry Pi 4 (RPi4.) The sBitx would be the successor to his previous project, the uBitx, a software-controlled radio using an Arduino. A PDF was published providing in-depth technical detail of the sBitx and a GitHub repo shared of code developed to date. The uBitx and sBitx are great examples reflecting the evolution of transceiver kit building.
Software-Controlled Radios
Software-controlled radios use software only to control the radio. Early examples of this include the use of Programmable Interface Controllers (PIC) with the PIC16F84 being quite popular. The PICs were pre-programmed and undocumented making them "black boxes." Replacing PICs with end-user programmable microcontrollers (MCUs) like the Arduino and open source code made software experimentation more accessible to the kit builder.
The uBitx architecture reflects a well-documented entry level software-controlled radio. Software-controlled because for it to be considered a SDR, signal processing needs to occur in the digital/compute domain. The RF section of the uBitx is mostly analog using a double conversion superhet design. The piece that is not is the si5351 i2c programmable oscillator commonly available as a breakout board module.
Diagram 1 - uBitx Architecture Model |
The si5351 and the rest of the RF section is controlled by an Arduino MCU. The Arduino also drives the display and connects to a rotary encoder for user input.
Building the kit is a combination of plugging cables and soldering connectors. You can run with the firmware included or download the Arduino source code, modify, compile, and upload your own firmware. The firmware is created using the Arduino language compiled with the Arduino Integrated Development Environment a cross-platform application installed on a PC or laptop. The Arduino has a USB port for uploading the compiled code from your PC or laptop. The Arduino language itself is based on C/C++.
Subsequent uBitx versions updated the display from LCD to a touchscreen by Nextion. Nextion displays are considered Human Machine Interfaces (HMI) with their own programmable microcontroller embedded dedicated to the task. The Nextion display is programmed using the Nextion Editor. The editor is used for GUI design and uploading the code to the display.
As a software-controlled transceiver, it is important to understand the code that is controlling and the implications of any changes you make to that code since you could damage it. If you are new to the Arduino, it is best you become familiar with it, building simple projects first and getting familiar with the IDE and the libraries it uses. The same can be said with the Nextion.
SDR using the Raspberry Pi
For many the Raspberry Pi is considered a more relatable technology to work with its single-board computer (SBC) that runs full operating systems supporting simpler popular languages like Python. The promise of introducing a Raspberry into a SDR design is more options for experimentation.
Diagram 2 - sBitx Architecture Model |
Diagram 2 is a high-level architecture model of the sBitx. The sBitx still uses a mostly analog RF section, but the MCU is replaced with a single board computer (SBC) the RPi4.
In this design, audio is routed through to an audio codec board using a WM8731. In turn, the audio is routed to the RPi4 via the SPI interface using the i2s protocol. There is also a switch from the proprietary Nextion display to commonly available touchscreens connected via DSI interface of the RPi4. The Sbitx includes a Raspberry Pi OS image with all the applications required to operate it included. The applications are compiled C.
Running operating
systems adds processing overhead and latency which limits how much signal
processing you can offload to the RPi4. This is why an audio codec board is
used and all the code that runs the RF and Display sections is compiled C.
The allure of using a Raspberry Pi is the familiarity many have with it as part of their radio stations for logging, digital modes, and SDR RX projects and installing those applications on the RPi4 used by the sBitx. But lower-level experimentation with signals and control remains in the domain of C level programming to address latency concerns.
Up to now we have been covering HF transceivers which require more discrete analog components for RF sections. What about VHF/UHF?
Building VHF/UHF SDR transceivers
Say what you want about the Baofeng UV-5R and its derivatives, but its design has contributed to experimentation starting with its core component, the RDA1846 single chip transceiver coupled to a microcontroller. While the microcontroller code is proprietary some people have either hacked similar radios to upload their own firmware (such as OpenGd77) or breadboarded began using shielded RF modules like the SA818 "walkie Talkie" module This module includes an embedded microcontroller programmed through a serial connection using AT commands reminiscent of the analogue modem days. The best representation of this in kit build is the Hackerbox #0096 Two meter kit with its high-level architecture modeled below.
Diagram 3 - VHF/UHF Architecture Model |
The design includes a SA818 module connected to a ESP32-S3 microcontroller with display and pushbutton connections to it controlling channels, PTT, etc. The kit refers you to GitHub repos for source code and compiles it using the Arduino IDE. As with the evolution of uBitx to sBitx you could replace the MCU with an SBC and Audio board to expand from RF and interface control to include applications for SDR and digital modes with display and controls updated to a TFT. With an RF module, your experimentation on the build proper is all software.
”Full Stack” SDR
The “software” in open source SDR has been targeting the lowest common denominator in languages for developers for experimentation. This includes C, Bash, and Python. When it comes to interfaces, developers have a closer relationship to web development than coding in C for displays. You can see this in practice if you have used one of the many WebSDRs on the Internet.
Diagram 4 - "Full Stack" SDR Architecture Model |
In the diagram above the application and interface sections reflect the web technologies required for a web browser to be the interface. I wrote an application and interface a few years ago (radioDASH) that will give you an idea what this looks like at the code level plus another project implemented with a LoRa transceiver on a microcontroller (HASviolet-ESP32.)
Why no HF RF modules?
In the simplest of explanations, longer wavelengths at HF frequencies require larger discrete components for filtering transmission spurs on unintended frequencies. Hence many of the QRP SDR kits out there have full RF boards with the local oscillators (that include the Si5351) on those boards controlled by a microcontroller. True SDRs like the FlexRadio use direct conversion for RF and proprietary FPGA chips for signal processing hence their expense.
Where is this all heading?
The lowest common denominator in the evolution from PICs to SDR is firmware developed in C given the low latency needs for signal processing. With the evolution from PICs to MCUs, entrants like the Arduino have made programming more accessible with its IDE and community support in code shared. But going from MCUs to SBCs only adds the ability of running peripheral applications like digital modes, logging, and radio control on the same platform. Compiled C is still necessary for any latency sensitive control.
Only when you have RF modules with embedded controllers and well documented APIs are software skill requirements relaxed. As mentioned previously, the SA818 module is configured using AT style commands via a serial port. This should sound familiar to those using dial-up or early cell modems.
When it comes to SDR experimentation consider your goals and the skillsets required before selecting the architecture model you want to pursue. This is why software-controlled radios remain the best entry level into the SDR space.
73,
Joe NE2Z
No comments:
Post a Comment
We really do not want to moderate comments, so lets keep it easy to use until it becomes an issue.