At first glance, the ColibriNANO SDR looks like another cheap SDR dongle. But after watching [Mile Kokotov’s] review (see video below), you can see that it was built specifically for software defined radio service. When [Mile] takes the case off, you notice the heavy metal body which you don’t see on the typical cheap dongle. Of course, a low-end RTL-SDR is around $20. The ColibriNANO costs about $300–so you’d hope you get what you pay for.
The frequency range is nominally 10 kHz to 55 MHz, although if you use external filters and preamps you can get to 500 MHz. In addition to a 14-bit 122.88 megasample per second A/D converter, the device sports an Altera MAX10 FPGA.
When [ik1xpv] sets out to build a software-defined radio (SDR), he doesn’t fool around. His Breadboard RF103 sports USB 3.0, and 16-bit A/D converter that can sample up to 105 Msps, and can receive from 0 to 1800 MHz. Not bad. Thanks to the USB 3.0 port, all the signal processing occurs in the PC without the limitations of feeding data through a common sound port. You can see the device in action in the video below.
The Cypress FX3 USB device is an ARM processor, but it is only streaming data, not processing it. You can find the slightly modified firmware, a driver for using PC software, and schematics and board layouts on GitHub.
What do you get when you cross an ARM-based Linux PC and an RTL-SDR? Sounds like the start of a joke, but the answer is Outernet’s Dreamcatcher. It is a single PCB with an RTL-SDR software defined radio, an L-band LNA, and an Allwinner A13 processor with 512MB of RAM and a 1 GHz clock speed. The rtl-sdr site recently posted a good review of the $99 board.
We’ll let you read the review for yourself, but the conclusion was that despite some bugs, the board was no more expensive than pulling the parts together separately. On the other hand, if you uses, for example, a Raspberry Pi 3, you might expect more support and more performance.
Despite the L-band hardware, there is a bypass antenna jack that allows you to receive other frequencies. There’s also two SD slots, one to boot from and another for storage. Several pieces of software had trouble running on the somewhat sluggish CPU, although some software that is optimized for the particular processor used fared better. You can read the details in the review.
The board is interesting, although unless you have a special packaging problem, you are probably as well off to combine a Pi and a dongle, as we have seen so many times before. If you have more horsepower you can even make the Pi transmit, although we’d suggest some filtering if you were going to do that for real.
Forgive the click bait headline, but the latest work from [Marco Bartolucci] and [José A. del Peral-Rosado] is really great. They’re using multiple HackRFs, synchronized together, with hybrid positioning algorithms to derive more precise localization accuracy. (PDF)
Like all SDRs, the HackRF can be used to solve positioning problems using WIFi, Bluetooth, 3G, 4G, and GNSS. Multiple receivers can also be used, but this requires synchronization for time-based or frequency-based ranging. [Bartolucci] and [Peral-Rosado] present a novel solution for synchronizing these HackRFs using a few convenient ports available on the board, a bit of CPLD hacking, and a GNSS receiver with a 1 pps output.
This is technically two hacks in one, the first being a sort of master and slave setup between two HackRFs. Using the Xilinx XC2C64A CPLD on board the HackRF, [Bartolucci] and [Peral-Rosado] effectively chain two devices together. The synchronization error is below one sampling period, and more than two HackRFs can be chained together with the SYNC_IN port of each connected together in parallel. Read more about it in their pull request to the HackRF codebase.
This simplest technique will not work if the HackRF receivers must be separated, which brings us to the second hack. [Bartolucci] and [Peral-Rosado] present another option in that case: using the 1 pps output of a GNNS receiver for the synchronization pulse. As long as both HackRFs can see the sky, they can act as one. Very cool!
For those of us whose interests lie in radio, encountering our first software defined radio must have universally seemed like a miracle. Here is a surprisingly simple device, essentially a clever mixer and a set of analogue-to-digital or digital-to-analogue converters, that can import all the complex and tricky-to-set-up parts of a traditional radio to a computer, in which all signal procession can be done using software.
When your curiosity gets the better of you and you start to peer into the workings of a software defined radio though, you encounter something you won’t have seen before in a traditional radio. There are two mixers fed by a two local oscillators on the same frequency but with a 90 degree phase shift, and in a receiver the resulting mixer products are fed into two separate ADCs. You encounter the letters I and Q in relation to these two signal paths, and wonder what on earth all that means.
Most old-school remote controlled cars broadcast their controls on 27 MHz. Some software-defined radio (SDR) units will go that low. The rest, as we hardware folks like to say, is a simple matter of coding.
So kudos to [watson] for actually doing the coding. His monster drift project starts with the basics — sine and cosine waves of the right frequency — and combines them in just the right durations to spit out to an SDR, in this case a HackRF. Watch the smile on his face as he hits the enter key and the car pulls off an epic office-table 180 (video embedded below).
[Chris D] noticed that the excellent software defined radio (SDR) software gqrx will run on the Raspberry Pi now. So he married a Raspberry Pi 3, a touchscreen, an RTL-SDR dongle, and an upconverter to make a very nice receiver setup. You can see the receiver in action below.
The video is a little light on build details, but there is a shot of the setup with the pieces labeled, and you should be able to figure it out from there. Of course, gqrx works with lots of different SDR devices so you might have to make adjustments depending on what you use (for example, many of the supported dongles won’t need the upconverter that [Chris] uses).