RF

For his Hackaday Prize entry, [Adam] is working on an open source, extensible 915 and 433 MHz radio designed for robotics, drones, weather balloons, and all the other fun projects that sub-Gigaherts radio enables.

The design of this radio module is based around the ADF7023 RF transceiver, a very capable and very cheap chip that transmits in the usual ISM bands. The rest of the circuit is an STM32 ARM Cortex M0+, with USB, UART, and SPI connectivity, with support for a battery for those mobile projects.

This project is a low-resource mesh networking stack and mote with battery-powered routers based on state synchronization. The target is for the stack to use less than 2kb SRAM. Nodes use low power listening and an adaptive gossip protocol to synchronize key/values pairs with each other without relying on explicit routing or per-node addressing.

For example, a light might transmit (/lamp, {“state”:”on”}) to the mesh. Write (/lamp, {“state”:”off”}) to the mesh, and the lamp application will notice. The powerful but simple state synchronization primitive allows you to update the state of the mesh to update the world, and update the state of the world to express the same on the mesh. Trivially bridged to a private MQTT server and managed with off-the-shelf MQTT applications.

This is the same chip used in most all of the RTL-SDR dongles, as well as the Airspy and numerous other radios. The chip is a versatile front-end with reasonable sensitivity and wide tuning range.

The design presented here is almost an exact implementation of the Mfg’s suggested demo design from the datasheet, implemented on the OSHpark 4-layer PCB process and provides a simple 4-pin interface with power, ground and I2C bus for controlling the tuner. A broad-band RF input and 10MHz IF output are provided on SMA connectors.

The breakout PCB design and STM32F0 firmware for the Rafael R820T2 tuner chip are shared on GitHub:

There are certain design guidelines for PCBs that don’t make a lot of sense, and practices that seem excessive and unnecessary. Often these are motivated by the black magic that is RF transmission. This is either an unfortunate and unintended consequence of electronic circuits, or a magical and useful feature of them, and a lot of design time goes into reducing or removing these effects or tuning them.

You’re wondering how important this is for your projects and whether you should worry about unintentional radiated emissions [..]

Building a software defined radio (SDR) involves many trades offs. But one of the most fundamental is should you use an FPGA or a CPU to do the processing. Of course, if you are piping data to a PC, the answer is probably a CPU. But if you are doing the whole system, it is a vexing choice.

The FPGA can handle lots of data all at one time but is somewhat more difficult to develop and modify. CPUs using software are flexible–especially for coding user interfaces, networking connections, and the like) but don’t always have enough horsepower to cope with signal processing tasks (and, yes, it depends on the CPU).

[Eric Brombaugh] sidestepped that trade off. He used a board with both an ARM processor and an ICE FPGA at the heart of his SDR design. He uses three custom boards: one is the CPU/FPGA board, another is a 10-bit converter that can sample at 40 MSPS (sufficient to decode to 20 MHz), and an I2S DAC to produce audio. Each board has its own page linked from the main project.Z

On the hardware side, the design is based on two Silicon Labs 4463 transceiver ICs and an STM32F302CBT6 ARM Cortex M4 microcontroller. One of the SiLabs ICs acts as a transceiver, while the other IC works as a receiver only. In receiver mode, each IC tunes to a different channel. When a transmission is scheduled, the ICs swap channels if the transceiver is not listening on the next transmit channel. This configuration may be construed as a violation of the AIS specification, but it makes for a much simpler PCB layout and negates the need for a 3-position RF switch.