Exploring software-defined radio (without the annoying RF) – Part 1

I needed to come up with a communications device to transmit a handful of bytes, every hour, from a small off-grid solar system to my shop about 150 feet away. The first thought was Wi-Fi, but I already have many dozens of devices on my Wi-Fi and keeping them all working is like spinning plates (for those under 50 see this video). I wanted a different solution and thought of using ultrasonic transducers configured in a software-defined radio (SDR) type framework as the transceiver. While working on the design I realized that it would be very useful for anyone that wants to explore, or teach about, the physical (PHY) layer of the SDR. (The PHY layer of the firmware takes the received signal and demodulates it, slices it, checks it, and sends the data packet off for further processing on the next layer of the OSI model. On the transmit end, it builds a modulated signal based on the data to be sent, the baud rate, and the modulation scheme selected, then sends the modulated signal to a transmitter.)

Wow the engineering world with your unique design: Design Ideas Submission Guide

Why use ultrasonics

As you will see, by using ultrasonics to send and receive the data, we eliminate the need for expensive RF equipment such as high-speed oscilloscopes, spectrum analyzers, vector network analyzers, not to mention the cost of an SDR transceiver. All signals in this system can be viewed using an inexpensive oscilloscope—a basic 10 MHz bandwidth oscilloscope will work for viewing all signals. The ultrasonic system also eliminates the need to do any FPGA programming, which can be problematic for some embedded firmware engineers. Along with these advantages we also eliminate the pesky issues of RF systems (my apologies to RF engineers) such as parasitics, tricky board routing, antenna matching, not to mention working with s-parameters and smith charts.

SDR firmware development

The last reason for exploration of an SDR on this ultrasonic system is that the developed firmware is almost exactly the same as the firmware on a high frequency SDR RF transceiver. So, any knowledge gained will translate to these larger SDR systems. For some years I wrote firmware for an SDR system that transmitted and received in the 900 MHz ISM band. The system was designed to receive 64 channels at 100k baud simultaneously, while also transmitting 16 channels at 100k baud. Although it ran on a system with 3 ARM processors and 160 GFLOPs of DSP, the PHY level code is very much the same as the code used in this ultrasonic system. If you can develop firmware on this ultrasonic system, you can develop SDR firmware on larger, RF systems.

SDR systems

As you may know SDR is one of the hot areas in electrical engineering. It is currently being designed in and used in radar, military communications, cell phone services, satellites, and even car infotainment systems. From a high level view, it strips away much of the RF design in favor of digitized reception via analog-to-digital conversion, digital signal processing, and digital-to-analog conversion as close to the transmitting antenna as possible. There are a number of different architectures of SDR that vary in the amount of RF that is replaced by digital processing. Some of these architectures are superheterodyne, direct conversion, and direct sampling. The holy grail of SDR is direct sampling as shown in Figure 1.

Figure 1 Direct sampling architecture for an SDR where the RF is digitized very early on in the receive chain and no upconversion in the transmit chain, requiring the ADCs and DACs to have very high sampling rates.

The essence of this is that the received RF is almost immediately digitized going in—no LO mixing, no down conversion. Also, the transmit side does no upconversion in frequency. I say this is the holy grail because, in high frequency RF, this is very hard to do due to the speeds involved in the analog-to-digital converters (ADCs) and digital-to-analog converters (DACs), and therefore the data rate that needs to be processed in the FPGA and/or the attached processor.

But direct sampling is doable when dealing with ultrasonic signals, in fact we’ll do this using a 16 MHz Arduino Nano and no FPGA.

The SDU-X system

Figure 2 shows the general design of a system I am calling the Software Designed Ultrasonic Transceiver or the SDU-X. The figure shows a minimum number of parts: a couple of ultrasonic transducers, a receiver amplifier/bandpass filter, an Arduino Nano, a DAC, and a transmit amplifier. Not shown is a handful of things like power supplies and some LEDs.

Figure 2 The SDU-X design with a minimum number of parts excluding power supplies and LEDs.

To assist in signal reception, there is a 3D printable parabolic dish for the receiver transducer. This dish mounts on a 3D printable tower that holds the transmitter transducer and has a set of sighting holes for aiming the dish. The dish gives about a 9 dB improvement in reception.

Current code allows for selection of different modulation types. Some are fully implemented for sending and receiving. Some are only implemented as transmitters and the receiver for that modulation type is something the user can experiment with creating. It is intended as something like a student exercise.

An SDU-X system, as seen in Figure 3, consists of two assemblies: one is called the Requester and the other the Responder. The hardware (PCBA) is the same for both, but they have different compiles of the firmware. When running, the Requester will send out a transmission asking for data from the Responder or for an action to be executed by the Responder. In the current firmware, the requested data can be something like the Responders SNR measurements, or a value from onboard analog input or digital I/O status. This data is transmitted back to the Requester who can then print it out on a serial port (available in the Arduino IDE). Requested actions can, for example, include having the Responder blink its LEDs or set some digital I/O high or low.

Figure 3 SDU-X system architecture with a Requester and Responder assembly connected to two 3D-printable parabolic dish antennas for the receiver transducer.

The SDU-X schematic

Let’s look at the schematic in Figure 4.

Figure 4 Schematic of the SDU-X system with the receiver transducer (upper left) and transmitter transducer (upper right).

On the upper left side, we see the receiver transducer connected to an op-amp (U1A) acting as a band-pass filter with an adjustable gain of up to 100 (40 dB). Typically, this gain is just set to the maximum, unless the units are a few feet apart. The -3 dB roll-off frequencies are at about 7 kHz and 90 kHz. The transducer itself is also a good filter centered at 40 kHz. From my testing the 40 kHz acoustic band seems to be pretty quiet, so filtering of the input is not very critical.

Following the first stage is an op-amp (U1B) configured as a Sallen-Key band-pass filter with a gain around 10 (20 dB). When combined with the first stage, the receiver amplifier gives a total gain of 1000 (60 dB). The -3 dB roll-off frequencies of the combined two stages are at 38 kHz and 42 kHz, cleaning up the signal even further. The 0 to +5 V output of this amplifier is then run to an analog input pin of the Arduino Nano which is internally connected to the Nano’s 10-bit ADC.

Moving to the upper right of the schematic, we can see a pair of op-amps. The upper one (IC U6A) is configured as a non-inverting amplifier with a high-pass response rolling off -3 dB at around 1.5 kHz. The lower op-amp (IC U6B) circuit is configured as an inverting amplifier with about the same high pass response. When the outputs of these circuits are tied to the transmitter transducer they act as a differential driver, allowing the transducer to see a signal of approximately +/-12 V. Low-pass output filtering relies on the filter characteristics of the transmit transducer, which works very well. The transducer response rolls off -3dB at roughly +/-1 kHz. Note that the two resistors (R37 And R38) on the output the op-amps are to aid in stability, if needed, in driving the highly capacitive transducer. The input to these two op-amps comes from an 8-bit DAC (IC U3) which is driven directly from the Nano. Note that the two dual op-amps are TL082’s, selected primarily for the slew rate.

That’s essentially the complete direct sampling systems hardware.

A few more parts round out the schematic. The power supply generates 3 voltages; +8 VDC to power the Nano, +5 VDC to power the receiver op-amps and LEDs, and +15 VDC to power the transmit circuits op-amps. There are a couple of red/green bi-color LEDs on the board also, along with a few green LEDs for power indicators. The output power is a 10 to 13 VDC at 100 mA minimum. A simple AC adapter works fine.

There are spare digital I/O and analog inputs and a small proto area for experimentation and new features. Also, on the PCB are several strategic test points to monitor analog in and out as well as for use in monitoring streams of internal data such as received samples, correlation shape, flagging sync times, etc. Some test points are appropriately spaced and sized to allow for use with an oscilloscope probe ground spring for convenient hands-free probing.

Exploring software-defined radio (without the annoying RF) – Part 2

In the next installment, we will look at the firmware in the SDU- X. In the meantime, the PCB, schematic, 3D files for the parabolic towers, design notes, and firmware can be found at: https://www.thingiverse.com/thing:6268613

Damian Bonicatto is a consulting engineer with decades of experience in embedded hardware, firmware, and system design. He holds over 30 patents.

Phoenix Bonicatto is a freelance writer.

<!–
googletag.cmd.push(function() { googletag.display(‘div-gpt-ad-native’); });
–>

The post Exploring software-defined radio (without the annoying RF) – Part 1 appeared first on EDN.

Exploring software-defined radio (without the annoying RF) – Part 1

Become a member

Become a member

Become a subscriber

Become a sponsor