sdr

302 Articles

Fail Of The Week: The Pitfalls Of Designing A Wideband Radio

August 5, 2016 by 11 Comments

If you are someone whose interests lie in the field of RF, you won’t need telling about the endless field of new possibilities opened up by the advent of affordable software defined radio technology. If you are a designer or constructor it might be tempting to believe that these radios could reduce some of the problems facing an RF design engineer. After all, that tricky signal processing work has been moved into code, so the RF engineer’s only remaining job should be to fill the not-so-huge gap between antenna and ADC or DAC.

In some cases this is true. If you are designing an SDR front end for a relatively narrow band of frequencies, perhaps a single frequency allocation such as an amateur band, the challenges are largely the same as those you’d find in the front end of a traditional radio. The simplest SDRs are thus well within the abilities of a home constructor, for example converting a below-100kHz-wide segment of radio spectrum to the below-100kHz baseband audio bandwidth of a decent quality computer sound card which serves as both ADC and DAC. You will only need to design one set of not-very-wide filters, and the integrated circuits you’ll use will not be particularly exotic.

But what happens if the SDR you are designing is not a simple narrow-band device? [Chris Testa, KD2BMH] delivered a talk at this year’s Dayton Hamvention looking at some of the mistakes he made and pitfalls he encountered over the last few years of work on his 50MHz to 1GHz-bandwidth Whitebox handheld SDR project. It’s not a FoTW in the traditional sense in that it is not a single ignominious fail, instead it is a candid and fascinating examination of so many of the wrong turnings a would-be RF engineer can make.

The video of his talk can be found below the break, courtesy of Ham Radio Now. [Chris]’s talk is part of a longer presentation after [Bruce Perens, K6BP] who some of you may recognise from his activities when he’s not talking about digital voice and SDRs. We’re jumping in at about the 34 minute mark to catch [Chris], but [Bruce]’s talk is almost worth an article in itself..

Continue reading “Fail Of The Week: The Pitfalls Of Designing A Wideband Radio” →

Blindingly Fast ADC For Your BeagleBone

July 31, 2016 by 28 Comments

[Jason Holt] wrote in to tell about of the release of his PRUDAQ project. It’s a dual-channel 10-bit ADC cape that ties into the BeagleBone’s Programmable Realtime Units (PRUs) to shuttle through up to as much as 20 megasamples per second for each channel. That’s a lot of bandwidth!

The trick is reading the ADC out with the PRUs, which are essentially a little bit of programmable logic that’s built on to the board. With a bit of PRU code, the data can be shuttled out of the ADC and into the BeagleBone’s memory about as fast as you could wish. Indeed, it’s too fast for the demo code that [Jason] wrote, which can’t even access the RAM that fast. Instead, you’ll want to use custom kernel drivers from the BeagleLogic project (that we’ve covered here before).

But even then, if you don’t want to process the data onboard, you’ve got to get it out somehow. 100 mbit Ethernet gets you 11.2 megabytes per second, and a cherry-picked flash drive can save something like 14-18 megabytes per second. But the two 10-bit ADCs, running full-bore at 20 megasamples per second each, produces something like 50-80 megabytes per second. Point is, PRUDAQ is producing a ton of data.

So what is this cape useful for? It’s limited to the two-volt input range of the ADCs — you’ll need to precondition signals for use as a general-purpose oscilloscope. You can also multiplex the ADCs, allowing for eight inputs, but of course not at exactly the same time. But two channels at high bandwidth would make a great backend for a custom SDR setup, for instance. Getting this much ADC bandwidth into a single-board computer is an awesome trick that used to cost thousands of dollars.

We asked [Jason] why he built it, and he said he can’t tell us. It’s a Google Research project, so let the wild conjecture-fest begin!

The Problem With Software Defined Radio

July 29, 2016 by 79 Comments

There’s a problem with software defined radio. It’s not that everyone needs to re-learn what TEMPEST shielding is, and it’s not that Bluetooth is horribly broken. SDR’s biggest problem is one of bandwidth and processing. With a simple USB TV Tuner, you can listen in on aircraft, grab Landsat images from hundreds of miles up, or sniff the low-power radios used in Internet of Things things. What you can’t do is make your own WiFi adapter, and you can’t create your own LTE wireless network. This is simply a problem of getting bits from the air to a computer for processing.

At HOPE last weekend, the folks behind the very capable LimeSDR and a new company working with Lime’s hardware laid out the possibilities of what software defined radio can do if you make a link to a computer very fast, and add some processing on the SDR itself.

Continue reading “The Problem With Software Defined Radio” →

Amazing SDR Built By 16 Year Old

July 28, 2016 by 48 Comments

[Lukas] started his epic SDR-from-scratch build when he was 16. Projects like this aren’t completed overnight. (He’s now 18. We’re impressed.)

The project itself is a Software-Defined Radio built on top of the 12-bit Analog Devices AD9364 transceiver IC. A big fat FPGA takes the data and runs it off to a USB 3.0 interface, which is necessary for the amount of data this thing will be producing — he’s got it receiving 56 MHz of bandwidth. In short, this is an SDR peripheral that’s in the big leagues.

After two years of work and (only!) three revision, [Lukas] got the thing working. Read his writeup for the blow-by-blow account. In the end, a 6-layer board was necessary for the routing to get the full speed out of the clocking, and he discovered the reason that you use exactly the specified bias resistors — the expensive ADC chip gets very hot. But he didn’t give up, and in the end he pulled off a project of immense complexity. In his own words:

I have discovered that taking on large projects, even when not knowing how to tackle problems that might arise, is a very effective way of learning for me. It’s just important to be persistent, as I’ve seen that almost any problem can be solved on your own — which is incredibly rewarding — even if you get stuck and seem to not make progress for a while.

[Lukas] is now working on the software. He’s already got a hacked osmocom driver working, so it plays nice with GNURadio.

Of course, there are tons of ways to get into SDR without building your own from scratch, but we applaud [Lukas] for going the hard way. If you’re tempted to follow in his footsteps, have a look at [Michael Ossmann]’s great talk on making the RF design process as tractable as possible.

Pokemon Go Cheat Fools GPS With Software Defined Radio

July 19, 2016 by 59 Comments

Using Xcode to spoof GPS locations in Pokemon Go (like we saw this morning) isn’t that much of a hack, and frankly, it’s not even a legit GPS spoof. After all, it’s not like we’re using an SDR to spoof the physical GPS signal to cheat Pokemon Go.

To [Stefan Kiese], this isn’t much more than an exercise. He’s not even playing Pokemon Go. To squeeze a usable GPS signal out of his HackRF One, a $300 Software Defined Radio, [Stefan] uses an external precision clock. This makes up for the insufficient calibration of the HackRF’s internal clock, although he points out that this might also be fixed entirely in software.

Continue reading “Pokemon Go Cheat Fools GPS With Software Defined Radio” →

LuaRadio Brings More Options To SDR

July 6, 2016 by 4 Comments

GNURadio is the swiss-army-knife of software-defined radio suites: it does everything and anything. It has a great GUI overlayer that makes creating radio flows fairly simple. There are only two areas where we could quibble with the whole system — it’s a gigantic suite of software, and it’s a lot harder to code up in Python than it is to use the GUI.

[Vanya Sergeev] started up his LuaRadio project to deal with these shortcomings. If you’re looking for the full-GUI experience, you’re barking up the wrong tree here. LuaRadio is aimed at keeping things easy to code and keeping the codebase small and tidy.

That doesn’t mean that it departs entirely from GNURadio’s very successful flow-graph programming paradigm, however, and if you’re comfortable with the procedure of hooking up a signal source to a filter block to an output, you’ll be doing fine here as well. Check out the obligatory FM radio demo — the “hello world” of SDR — and you’ll see how it works: instantiate the various blocks in code, and then issue “connect” commands to link them together.

LuaRadio’s main selling points are its size and the ease of programming it by hand. It’s got great documentation to boot. It’s written as a library that’s embeddable in your C code, so that you can write standalone programs that make use of its functionality.

LuaRadio is a new project and it doesn’t have a GUI either. It may not be the ideal introduction to SDR if you’re afraid of typing. (If you are new to SDR, start here.) But if you want to code up your SDR by coding, or run your radio on smaller devices, it’s probably worth a look. It’s at v0.1.1, so we’re looking forward to hearing more from LuaRadio in the future. Any of you out there use it? We’d love to hear in the comments.

GPS And SDR Combine Forces

June 25, 2016 by 33 Comments

Software-defined radio (or SDR) is a relatively new (to average tinkerers, at least) way of sending and receiving radio signals. The interest in SDR exploded recently with the realization that cheap USB TV tuner cards could be used to start exploring the frequency spectrum at an extremely reduced cost. One of the reasons that this is so advantageous is because of all of the options that a general-purpose computer opens up that go beyond transmitting and receiving, as [Chris] shows with his project that ties SDR together with GPS.

The goal of the project was to automatically tune a radio to the local police department’s frequency, regardless of location. To do this, a GPS receiver on a computer reports information about the current location. A JavaScript program feeds the location data to the SDR, which automatically tunes to the local emergency services frequencies. Of course, this relies on good data for what those frequencies are, but this is public information in most cases (at least in the US).

There are a lot of opportunities here for anyone with SDR. Maybe an emergency alert system that can tune to weather broadcasts if there’s a weather alert, or any of a number of other captivating projects. As for this project, [Chris] plans to use Google’s voice recognition software to transcribe the broadcasts as well. The world of SDR is at your fingertips to do anything you can imagine! And, if you’re looking to get started in it, be sure to check out the original post covering those USB TV tuner dongles.