Software Defined Radio by the hands of a sixteen year old

SDR, or software-defined radio system is a device for working with radio, which runs a mini-computer with special software. It replaces traditional hardware components: filters, amplifiers, modulators and de-modulators. This allows you to create a radio that works with a variety of protocols. Imagine a radio that, in addition to HitFM, can receive analogue and digital television, communicate via Wi-Fi, Bluetooth and GPS, as well as detect pulsar radiation.

Now imagine an American ninth-grader who decided to make such a radio line, ordered FPGA via the Internet, a radio module, made a six-layer board, and then assembled almost 300 components onto it with his own hands. And after three revisions it all worked for him!

What is SDR

Who might need such a radiolab? Radio amateurs who have evolved great! Twenty years ago, an enthusiastic person bought a complex receiver and sat in headphones for hours, rotating frequencies in search of interesting signals. In the modern world, radio broadcasts are full of information, but all of it is digital. Listening to Wi-Fi packets with headphones is of no interest. Today, the radio amateur finds interesting digital radio stations on the air, and then selects software that parses the transmission protocol and converts the information. For example, you can receive data from telemetry of civil aviation - on the basis of this kind of information from many radio amateurs around the world, the site flightradar publishes data on aircraft.

You can now see with your own eyes how Software Defined Radio works. The University of Twente contains an exciting online SDR receiver project that immediately receives a 29MHz wide spectrum piece, after which radio amateurs can listen in parallel to various carriers of this range. Catalog of similar radio projects compiled on the site

A large role in the popularity of amateur SDR is played by the low cost of the minimum set of equipment. Inexpensive TV tuners implemented on Software-Defined Radio were discovered, and instructions appeared on the Internet on how to use such tuners to listen with their help not only the television signal. A specialized kit on the Chinese market costs only $ 35, but it comes disassembled (it’s necessary to be soldered and its charm lies) and only supports a range of 100KHz-1.7GHz. Of course, the appetite comes with eating, and very soon a radio amateur begins to look towards equipment that can accept wide frequency ranges at high speed. Let's look at what serious devices are now the most popular.

Full list on Wikipedia

In a nutshell: you can start exploring SDR with cheap RTL-SDR options. When the appetite of the researcher exceeds the small capabilities of the device, you will have to look for a replacement expensive. Devices such as Per Vices Crimson are used by very serious specialists, whose computers are sufficiently productive to process such streams of information. LimeSDR is currently just finishing a Kickstarter fundraiser. It looks very tempting: the sampling frequency is maximum for USB3.0, and the channel width is sufficient to raise six 10MHz LTE cells.

However, more recently, the choice was not so great, and if you did not arrange hackRF for $ 300, then the next option was USRP immediately for $ 750, and no compromise. In this regard, sixteen-year-old Lukas Lao Beyer decided to independently develop an SDR card and recently published a report on his project. To say that we were amazed - to say nothing, it is better to just keep silent.

"What the hell are these American schoolchildren for themselves!" - shout in the comments to the article of Lucas. People have been improving their skills for years, and this boy did everything between lessons! We decided that it was impossible to leave it that way, and contacted Lucas. In this series of articles, we will look at all aspects of creating such a device, so that Russian schoolchildren learn from their experience and do equally wonderful things. Let's start with the Russian translation of Lucas diary, in which you can observe the course of the project and its experiences in connection with it. Then we will analyze the selected solutions and try to make such a device in Russian conditions.

Hardware design

From the diary of Lucas Lao Beyer
FreeSRP is an available software-defined radio system. I developed it because I did not find devices with higher bandwidth than the $ 300 HackRF, but cheaper than the more productive $ 700 USRP. Some components still need to be improved, but the system will fully comply with the Open Source philosophy.

FreeSRP is based on the Analog Devices AD9364 transceiver. Key features:

• 56MHz band
• Frequency range 70MHz - 6GHz
• Full duplex operation.

Despite the fact that there are other alternatives like LimeSDR, I believe that FreeSRP will be in demand. The development, as expected, was incredibly educational.

I started working on the system two years ago, in the summer of 2014, when I was 16. At that time I didn’t have experience with serious work with hardware, not counting the low-performance boards for my High Altitude Balloon project. Therefore, I understood that the development of FreeSRP would be difficult in all aspects: high-speed buses (100MHz), USB3.0, signal tracks with performance up to 6GHz, complex power circuits with seven different voltages ... I really wanted to build a compact system on modern components, so I had to Get acquainted with components such as BGA or QFN.

Compare my previous board and the current one.

Needless to say, the ambitiousness of the project is colossal. However, it didn’t frighten me at all, and I started from a clean slate, based only on the fact that I’ll definitely use the AD9346 transceiver, and I implement the bridge between the transceiver and USB3.0 on the FPGA. Short searches led me to the Xilinx Artix 7 and the Cypress EZ-USB FX3 controller. These toys seemed to me the best decisions in terms of price.

Based on datasheets and reference designs, I gradually prepared a schematic diagram in which I solved questions for all the other components. For development I used Altium Designer. Although it is not open source, for me it was the most intuitive package of PCB design. Many of its excellent features helped me a lot in development: life becomes much simpler if you have tools for drawing parallel tires or tracks with specific resistance. However, when I finish eliminating flaws in the design, I will redraw everything into KiCad so that more people will be more comfortable using my designs.

From design to prototype

When the circuit is ready, it's time to release the board template. For the prototype, the manufacturing price is very important, and in my budget a four-layer board from our American service OSH Park, which is famous for its low price tag for piece orders, barely fit. Suppose they have only four layers, the manufacturing parameters are very good - 5 mil tracks with the same intervals, 10 mil for holes, and also the excellent substrate Isola FR408, the quality of which depends on the radio signal.

The most important thing in the design of the board - conveniently position the components. I tried to make the connections between the components as small as possible. Of course, I struggled to make a minimum size board, which greatly influenced the price. I started drawing a signal from one side - from USB - and gradually added components along the way, until I got to the radio interface. Components outside this path (voltage regulators) were added to the remaining free spaces on the board.

From the first time, of course, it turned out not perfect, and for quite a long time I enthusiastically reworked the board, until I finally realized that everything was fine. The most severe pain came when I started to breed BGA on my four-layer board. However, I managed. The design passed all the checks, and I checked everything manually several times. I didn’t want at all to tear my hair out after making the board with an error, because this, of course, would not have been fixed.

Prototype manufacturing
After a lot of trouble, I still ordered three boards, and in January 2015 they are Hurray! - arrived. I intended to assemble the board myself, so I additionally ordered a mounting template on the film for solder paste. For installation, I used a halogen stove and a controller of my own design.

Since FreeSRP is based on a double-sided board, I first mounted the bottom layer. In the design, I placed only small components on the bottom: when I bake the board a second time when installing the upper layer, the small components will remain on the board, even upside down.

Partial assembly
I had three printed circuit boards, so I first assembled the prototype only partially. I installed only voltage regulators on one board, and because of this I discovered a problem with a 1.8V regulator. No problem, I replaced it with an external power source. But I could not eliminate the problem with the 1.3V regulator, because here the problem was a design error, so in the first revision I could not start the radio.

On the second board, I assembled the entire digital part: USB and FPGA. For the first time I had to mount BGA, and I did it manually. After long hours of intense and painstaking installation of expensive components without the right to make a mistake, I carefully put the board in the oven with trembling hands. The wait was painful, and how rejoicing I was when everything went perfect!

First start

Of course, I was incredibly afraid of the first inclusion of the board. Although the power circuits were tested on the first board, I still did not rule out that now my precious components would flare up with a blue flame. Perhaps there is some safe way to include a non-tested board. Nothing better came to my mind how to smoothly increase the current on the power supply and pray that smoke would not go anywhere.

The smoke test was successful, and the lights came on. Neither the FPGA nor the USB to the touch did not heat up. I plugged the USB into the computer, and the OS detected the Cypress chip. Then I launched the Xilinx applications, and they connected to the FPGA via JTAG. Looks like it all worked! Having examined in more detail, I certainly found an error: I crooked the USB3.0 plug, so that only the second version worked. Do not worry, we start testing in this form, and correct the problem later.

Second revision
In the second revision I needed to fix the problems with power and USB3.0 wiring. As a result, I received a fully working digital part of the board, and it was time to move on to the radio part.
At first I did not touch the transceiver, and collected all the other components. In parallel, the development of the program part of the project began. I have never programmed an FPGA before, so I had to learn Verilog from scratch. At this stage, I decided to implement a parallel interface to the USB controller. Although all parts of the project were not trivial, the development of FPGA for me was the most terrible part of the project. It is very difficult to find documentation for dummies on the use of tools and IP blocks. The messages that Vivado Design Suite wrote were for me a Chinese charter, and the inclusion of ready-made IP blocks led to hundreds of incomprehensible notifications. Most likely, I just do not know how to cook properly in this kitchen yet. Even the most minimal changes in design required a painfully long calculation by the program, so everything must be simulated - and this further complicates entry into the wonderful world of FPGA. And debug! Without the Integrated Logic Analyzer, it is absolutely impossible to debug anything, and it became free only in 2016 - before that the price was very high. Therefore, during debugging, it was necessary to transmit part of the test information by blinking the diode, and partly by the GPIO legs and watching the signal with an oscilloscope.

I didn’t get to the end of the question about clocking right away - it was only by the third attempt that the realization came that the clock signal of the transceiver needed to be turned into clock-inputs on the FPGA.
Having played enough with Verilog, I decided it’s time to solder the transceiver. I took the third board, re-installed three hundred components on it, as before, starting from the bottom. But when I soldered the upper side, the controller of my stove went on strike and did not turn off the furnace. I could not get readings on the temperature in the furnace, and it was possible to control the unit only by turning it on or off or opening the door. None of my prayers helped: a short circuit appeared on the tracks. I tried to fix it, but in vain: when turned on, the FPGA heated up. Alas, I just burned four hundred bucks in the oven, and this fact did not give me any confidence at all.

Nevertheless, I was determined to finish the project, so I broke the piggy bank, re-ordered the components and after a few weeks I made another attempt to assemble everything. You have no idea how I sweated this time, as if in the final tournament of poker! Fortunately, everything went without surprises.

The digital part in the new prototype worked perfectly. But the transceiver did not want to work, its configuration port simply did not respond. Then I noticed that the transceiver feels hot. Why he was so hot, it was not clear, because he had to sleep without a configuration. I tried unsuccessfully to find problems in nutrition. Izlazil all schemes, rechecked everything a hundred times. And then I discovered the following thing.

It turns out that I mistakenly connected two resistors in series - 698 Ohms and 536 Ohms (in total 1234 Ohms) instead of 14.3 kilohm resistors from the documentation! I replaced the resistors, and the chip stopped warming, but it still did not work. Looks like I burned him.

In general, at this moment I decided that quite a lot had already been done for such a young specialist without deep knowledge of electronics, and it was time to postpone the project. But I still have a working FPGA, so I began to have fun with it.

As a result of long experiments, I screwed up the transceiver driver and coped with the generation of test signals. I have earned a chain of signal transmission from FPGA to USB, so that further I could manage my SDR from a computer using the library on a more familiar C ++. Then I implemented the compatibility of my board with GNURadio, so now all the useful GNURadio-based programs could work with this board.

Third revision

At some point, I found strength for one more spurt and did a third revision. I corrected the annoying error with a 14.3 kilohm resistor, connected clock-inputs with FPGA, and replaced the transceiver oscillator with a chip to simplify the distribution of the clock signal and eliminate further problems.

Of course, the project went beyond the time frame and budget, but now it already seems to me that having only three revisions to a working board is not bad at all!

Also on this revision I switched to a six-layer PCB. Prototypes began to cost more, but the distance between the signal tracks increased significantly, and I reached the maximum clock frequency in the tires.

In addition, I bought excellent stainless steel patterns, which, unlike Kapton, are much easier to use.

Once the software was ready for me, I was able to immediately start the transceiver at the reception, and here they are the long-awaited first samples in GNURadio!

Finally, all the hard work has borne fruit. A few weeks later I was able to start the transmitter, and made sure that the full duplex mode took off, albeit not at full width. And then I found a new problem with the amp on the transmission, so the signal was very weak.
In any case, I have a fully functional SDR board, guys! Yes, there is still a lot to finish. I want to carefully measure the performance of the receiver and transmitter. I really want to start small-scale production, but before that I need to optimize the design a little more and be 100% sure that I didn’t leave any surprises in the board.

Formulation of the problem
Many thanks to Lucas for his detailed report, and now let's consider his decisions.
So, Lucas wanted to make a broadband, software-defined radio system with better characteristics than hackRF, and cheaper than USRP. Let's consider how the equipment of competitors is arranged.

USRP

bladeRF

hackRF

The last image looks the most concise, but all three devices have the same architecture: the signal is received from the air, digitized and transferred to USB. There are differences in details. In hackRF, the radio part is implemented in the form of several components: the signal after reception using a mixer shifts to an intermediate frequency range of 2.3-2.7GHz, then is converted into an in-phase and quadrature component of the signal, which is already digitized. Other devices solve this problem in one component - the transceiver. Conversion of a digital signal for transfer to USB, as well as control of the radio path, is carried out using FPGA or a microcontroller.

When designing the system from top to bottom, we will divide it into three parts: RF, FPGA and USB, and first we will work each block separately, and then we will figure out how to connect them together.

RF part
The radio module in such a system is the most fragile thing. Discrete bits must turn into a wave and fly to the antenna with the necessary power. For this, a whole lot of wonderful things were needed before: filters, interpolators, decimators, digital-to-analog converters, synthesizers, mixers and various amplifiers. There is still a class of people who prefer to independently control every aspect of their radio module and collect them from small pieces. What is the preferred solution to the student? Of course, he will be glad if one superchip solves all these problems for him. Here are the options:

Like in hackRF
Michael Ossmann, by the way, is also a radio amateur, not a radio professional, and the only reason why he did not decide on the radio part in his project in the form of one smart piece of silicon is the dollars that would be required for this. Michael chose a compromise: he uses three pieces of silicon and saves about half the cost, which makes hackRF so affordable. The hackRF radio signal comes to RFFC5071, which lowers the frequency to ~ 2.5GHz (this is called LO synthesis), then this signal enters the narrowband MAX2837 transceiver, turns into a baseband and goes to MAX5864 in this form - this is just digital-analog (and back) converter.

AD9364
Analog Devices produce excellent transceivers that are often used in various SDR projects. Above the diagram shows that such a chip, for example, feels comfortable on USRP devices. You can buy a chip from the manufacturer on the AD-FMCOMMS4-EBZ demo board, which in principle is a ready-made primitive SDR.

LMS6002D
Lime Micro chips are used in a variety of systems (bladeRF, for example), including the Russian SDR development umTRX, and this year they swung to their own SDR system and successfully collected on Kickstarter the tools to run LimeSDR in production. In general, Lucas had the right to use this chip in his work, he is beautiful, and his main drawback is that the range of received frequencies is half as much as that of the AD9364.

So in the end, Lucas chose the option with the AD9364, and immediately ordered it.

FPGA selection
The most difficult thing when choosing a FPGA is to decide Altera or Xilinx. These companies, like Sony and Nintendo, produce equally cool hardware, and the devil is only in the details. What is the difference between Altera and Xilinx?

Altera is famous for the very long support of its microchips. The Xilinx Vivado development environment only works with the latest (seventh) series of chips, while Altera's Quartus supports even the Flex 10K, which is fifteen years old since its first release. At the time of the start of the project, the Xilinx debugging software cost $ 700 (and became free only this year), while at Altera it is free. Altera's IP blocks (pre-built software libraries) can be tried during the demo period with restrictions. As a result, for the beginner amateur Altera looks preferable. But in Xilinx the smarter DSP part, it has not only multiplication (as in Altera), but also an addition with a battery, which reduces the number of logical blocks needed to solve the problem.

But Lucas chose Xilinx. He claims that because of the price, but I think that at random (compare, Xilinx Aritx-7 and Altera Cyclone V).

How to choose a specific model of the chip from Xilinx? Two years ago, the choice was between Spartan-6 and Artix-7, which are considered low-cost Xilinx offer. Spartan-6 is no longer necessary because Vivado software does not support it.

All BGA Artix-7 families are compatible with what is called pin-to-pin, so Lukas would just stick further on the model 50T, deciding to decide on a specific model when the software is ready and the performance requirements for the chip are precisely determined.

What FPGAs are used in other similar projects?

The author hackRF did not put the FPGA, and chose a cheaper technology - CPLD, which is, let's say, a simplified version of the FPGA. As a result, he can practically do nothing useful in it and generally plans to exclude the FPGA from his design, transferring the transceiver control to the USB controller chip.

USB3.0
It remains to determine the solution for USB3.0. The most popular solution here is the Cypress FX3 microcontroller, and it’s hard to think of reasons not to use it. However, consider the alternatives.

The first thing that comes to mind is FTDI FT60x - a microcontroller in a QFN package. FTDI Company is famous for the fact that it likes to produce drivers that intentionally kill your chip, if it is a fake. If for USB2.0 the chips of this company were considered de facto standard, then in USB3.0 they, unfortunately, missed their market with such a strange attitude towards end-user equipment and low quality software.

Another option is to take the transceiver from Texas Instruments TUSB1310A, and implement the MAC layer in the FPGA. The transceiver costs $ 20 cheaper than a Cypress FX3 microcontroller, and I find it difficult to comment on why Lucas did not do that.

PCB manufacturing
If you want to program more than have fun with a soldering iron, I would recommend to make a prototype on the finished board. A good list of ready-made boards on different FPGAs can be found on a special site . For this particular project, there is an ideal version of the finished board with USB3.0 and Artix 7 FPGA, you just have to switch the transceiver and you can immediately start experimenting.

However, Lucas in this project were interested in all stages. Moreover, he even wanted to mount the board himself. Prototypes Lucas made in OSH Park - this is a very popular service among American students. (10$ ), . , , , . .

. Requirements:

• 5 mil=0,127
• 5 mil=0,127
• 10 mil=0,254
• : 74 * 108mm

: . , . , , . , EasyEDA, . , . , , .

, :

• , AD9364 USB
• USB
• PC, .

C++ libusb. , , - , GNU Radio.

GNU Radio, gr-osmosdr, SDR. , . , (, Gqrx, AirProbe/gr-gsm). , , .

gr-osmosdr, SDR. , , . , .. — work — GNU Radio. , , , , . , :

, gr-osmosdr freesrp.

GNU Radio , - . . , .

, GNU Radio "probe rate", :

GNU Radio. . .

. GNU Radio (sink block).

, : 32- , 12- (I Q) . Integrated Logic Analyzer 12- , .

I Q .

GNU Radio , - . , freesrp, . , :

. . I, Q , — I Q:

, - , USB-: , . , :

, . AD9364, .

GNU Radio
. GSM Zigbee , gr-gsm and gr-ieee802-15-4.

GSM
GNU Radio external modules are built via cmake, so everything is simple:

mkdir build # Creates a blank directory for the build to run in cd build cmake .. # Load CMake build script in root of the module's directory and run it make # Run the CMake-generated makefile sudo make install # Install the module sudo ldconfig 

The gr-gsm package comes with a number of trial applications. The most interesting are grgsm_scanner and grgsm_livemon. Using the first one, you can search for GSM broadcasting and isolate some identifiers from them, as well as get a list of base stations.

Look, by the way, I specify the code of my freesrp board as an argument - and everything works. This is a very pleasant feeling.

The second application allows you to tune into one of the GSM channels, decrypt the data and send it to your local network where you can listen to them via Wireshark. I added a gr-fosphor module to the program to make the screenshot more colorful:

802.15.4 (Zigbee)

I had several XBee modules at home, and I decided to interact with them. In this example, I wanted to check the sending of data.

Installing a module is as easy as with gr-gsm. The examples that come with the library are made for the Rime communication stack, so I cut off everything from Zigbee itself and added the TCP Server block so that you can connect and send data over the local network:

For example, I wrote two Python scripts: one connects to the XBee via USB, and the other clings to the TCP ports in GNU Radio. And then I just sent text messages through the 802.15.4 protocol, like in a chat.

About driver development
Design FPGA and USB controller
Now my FPGA does nothing special, except as an interface between the transceiver and USB. Due to the ease of implementation, I launched the driver from AD9364 on MicroBlaze, which performs setup and calibration. The driver communicates with USB via UART. Soon I will transfer this driver to a USB controller.

The AD9364 outputs samples to a 12-bit port, alternating between I and Q. There is another 12-bit port where you need to send outgoing I \ Q values. Also, the transceiver provides DDR-clock depending on the selected sampling rate. In the input signal circuit, reverse interleaving and folding into a 24-bit queue occur.

The USB controller has a DMA mechanism, where the FPGA can directly write (and read from there) data via a 32-bit bus. Therefore, when the FPGA has accumulated enough data in the queue, and FX3 is ready to receive, the state machine transferred the data.

Now I use only 24 bits of the available 32. One I \ Q sample fits in, and I simply discard the remaining 8 bits. But for full duplex data transfer, all 32 bits will need to be used.

The USB controller provides the following control points:

• INTERRUPT OUT - sends commands to Microblaze on driver AD9364
• INTERRUPT IN - accepts errors or responses to these commands.
• BULK OUT - for sending data
• BULK IN - for receiving data

Once enabled, FPGA can be configured via INTERRUPT OUT.

Libfreesrp
The library for interacting with FreeSRP is very simple. The libusb interface is used for receiving and sending. This allows data to be queued for optimal processing by the operating system. The user specifies the callback that will be called if new data arrives or the send buffers are released.

Plans
Dmitry Stolnikov from gr-osmosdr has already contacted me and offered to merge my changes into the main branch of the library. I will soon finish polishing it and do it.

When I get rid of MicroBlaze and transfer the driver to FX3, the FPGA is almost completely free. I would like to use this for experiments with real-time signal processing right on the FPGA.

I'd like to get more accurate performance characteristics of the radio part. I did not come close to this one step, because I have no instruments, and there are many other things to do.

Product release

In April, Lucas launched crowdfunding for his product and received the first batch of orders for $ 20,000 (that is, about fifty copies).

After the shipment of this game, it will be possible to say with confidence that the prototype has turned into a product, and this is a wonderful finale of a six-year long history of a sixteen-year-old kid who has brought together the present Software Defined Radio.

Help links
→ FreeSRP schematic
→ FPGA sources
→ USB Controller Sources
→ Project site