We think of radio navigation and direction finding as something fairly modern. However, it might surprise you that direction finding is nearly as old as radio itself. In 1888, Heinrich Hertz noted that signals were strongest when in one orientation of a loop antenna and weakest 90 degrees rotated. By 1900, experimenters noted dipoles exhibit similar behavior and it wasn’t long before antennas were made to rotate to either maximize signal or locate the transmitter.
Of course, there is one problem. You can’t actually tell which side of the antenna is pointing to the signal with a loop or a dipole. So if the antenna is pointing north, the signal might be to the north but it could also be to the south. Still, in some cases that’s enough information.
John Stone patented a system like this in 1901. Well-known radio experimenter Lee De Forest also had a novel system in 1904. These systems all suffered from a variety of issues. At shortwave frequencies, multipath propagation can confuse the receiver and while longwave signals need very large antennas. Most of the antennas moved, but some — like one by Marconi — used multiple elements and a switch.
However, there are special cases where these limitations are acceptable. For example, when Pan Am needed to navigate airplanes over the ocean in the 1930s, Hugo Leuteritz who had worked at RCA before Pan Am, used a loop antenna at the airport to locate a transmitter on the plane. Since you knew which side of the antenna the airplane must be on, the bidirectional detection wasn’t a problem.
Fox hunting, or direction finding, is a favorite pastime in the ham radio community where radio operators attempt to triangulate the position of a radio transmission. While it may have required a large amount of expensive equipment in the past, like most ham radio operations the advent of software-defined radio (SDR) has helped revolutionize this aspect of the hobby as well. [Aaron] shows us how to make use of SDR for direction finding using his custom SDR-based Linux distribution called DragonOS.
We have mentioned DragonOS before, but every iteration seems to add new features. This time it includes implementation of a software package called DF-Aggregator. The software (from [ckoval7]), along with the rest of DragonOS, is loaded onto a set of (typically at least three) networked Raspberry Pis. The networked computers can communicate information about the radio waves they receive, and make direction finding another capable feature found in this distribution.
[Aaron] has a few videos showing the process of setting this up and using it, and all of the software is available for attempting something like this on your own. While the future of ham radio as a hobby does remain in doubt, projects like this which bring classic ham activities to the SDR realm really go a long way to reviving it.
Many of us now carry a phone that can give us detailed directions from where we are to a destination of our choosing. This luxury became commonplace over the last decade plus, replacing the pen-and-paper solution of consulting a map to plan a trip and writing down steps along the way. During the trip we would have to manually keep track of which step we’re on, but wouldn’t it have been nice to have the car do that automatically? [Ars Technica] showed us that innovators were marketing solutions for automatic step by step driving directions in a car over a 100 years ago.
Systems like the Jones Live-Map obviously predated GPS satellites, so they used vehicle odometry. Given a starting point and a mechanical link to the drivetrain, these machines can calculate miles traversed and scroll to the corresponding place in the list of instructions. This is a concept that has been used in many different contexts since, including the “Next Bus in 7 Minutes” type of display at bus stops. Because a bus runs a fixed route, it is possible to determine location of a bus given its odometer reading transmitted over radio. This was useful before the days of cheap GPS receiver and cellular modems. But the odometry systems would go awry if a bus rerouted due to accidents or weather, and obviously the same would apply to those old school systems as well. Taking a detour or, as the article stated, even erratic driving would accumulate errors by the end of the trip.
The other shortcoming is that these systems predated text-to-speech, so reading the fine print on those wheels became a predecessor to today’s distracted driving problem. One of the patent diagrams explained the solution is to hand the device to a passenger to read. But if there’s a copilot available for reading, they can just as easily track the manual list of directions or use a map directly. The limited utility relative to complexity and cost is probably why those systems faded away. But the desire to solve the problem never faded, so every time new technology became available, someone would try again. Just as they did with a tape casette system in the 1970s and the computerized Etak in the 1980s.
Direction finding has long been a pastime of the ham radio community. Fox hunts and other DF events have entertained many, as they swept their antennas hunting for a transmitter. As with rock and roll and flared pants, time changes all things, and [Corrosive] has been experimenting with a very modern way to go about direction finding with SDR.
The work is made possible through the use of Kerberos SDR, a device which is essentially four RTL-SDR radios operating in unison. By fitting these with the appropriate antennas and running the right calibrations, the hardware can be used as a powerful direction finding tool.
[Corrosive] demonstrates this ably, by fitting the rig to his car and driving around on the hunt for a transmitter. Hunting for a P25 control station, he demonstrates the configuration of the hardware to help find the FM modulated signal. The software part of the equation is integrated with GPS maps, so one can follow the bearing towards the signal source while data is collected. Over time, the software takes more samples until it builds up an expected location for the transmitter.
The setup is remarkably effective, and largely does all of the heavy lifting, leaving the user to simply handle driving the car. The heat mapping feature is also incredibly cool, and would look great in your next spy movie. We’ve featured Kerberos SDR before, and fully expect to see more great work on this platform. Video after the break.
If you carry a smartphone around in your pocket, you have a GPS navigation system, a compass, an altimeter, and a very powerful computer at your fingertips. It’s the greatest navigational device ever created. To use this sextant of the modern era you’ve got to look down at a screen. You need to carry a phone around with you. It’s just not natural.
For this entry into the Hackaday Prize, [Vojtech Pavlovsky] has an innovative solution to direction finding that will give you a sixth sense. It’s a headband that turns your temples into the input for a clever way to find yourself around the city or a forest, and it does it with just an Arduino and a few other bits.
The idea behind the Ariadne Headband is to create a haptic navigation system for blind people, runners, bikers, or really anybody. It does this by mounting four vibration motors on a headband, connecting those motors to an Arduino, sniffing data from a digital compass, and getting data over Bluetooth from an Android app.
All of these parts come together to form a new sense — a sense of direction. By simply telling the app to make sure you’re always oriented North, or to guide you along the grid of city streets, this headband becomes an inconspicuous and extraordinarily useful way to get around.
When it comes to finding what direction a radio signal is coming from, the best and cheapest way to accomplish the task is usually a Yagi and getting dizzy. There are other methods, and at Shmoocon this last weekend, [Michael Ossmann] and [Schuyler St. Leger] demonstrated pseudo-doppler direction finding using cheap, off-the-shelf software defined radio hardware.
The hardware for this build is, of course, the HackRF, but this pseudo-doppler requires antenna switching. That means length-matched antennas, and switching antennas without interrupts or other CPU delays. This required an add-on board for the HackRF dubbed the Opera Cake. This board is effectively an eight-input antenna switcher using the state configurable timer found in the LPC43xx found on the HackRF.
The key technique for pseudo-doppler is basically switching between an array of antennas mounted in a circle. By switching through these antennas very, very quickly — on the order of hundreds of thousands of times per second — you can measure the Doppler shift of a transmitter.
However, teasing out a distinct signal from a bunch of antennas virtually whizzing about isn’t exactly easy. If you look at what the HackRF an Opera Cake receive on a waterfall display, you’ll find a big peak around where you expect, and copies of that signal trailing off, separated by whatever your antenna switching frequency is. This was initially a problem for [Schuyler] and [Ossmann]’s experiments. Spinning the antennas at 20 kHz meant there was only 20 kHz difference in these copies, resulting in a mess that can’t be decoded. The solution was to virtually spin these antennas much faster, resulting in more separation, and a clean signal.
There are significant challenges when it comes to finding the direction of modern radio targets. Internet of Things things sometimes have very short packet duration, modulation interferes with antenna rotation, and packet detection must maintain the phase. That said, is this technique actually able to find the direction of IoT garbage devices? Yes, the demo on stage was simply finding the direction of one of the wireless microphones for the talk. It mostly worked, but the guys have some ideas for the future that would make this technique work a little better. They’re going to try phase demodulation instead of only frequency-based demodulation. They’re also going to try asymmetric antenna arrays and pseudorandom antenna switching. With any luck, this is going to become an easy and cheap way to do pseudo-doppler direction finding, all enabled by a few dollars in hardware and a laser-cut jig to hold a few antennas.
It seem [Balint] is becoming somewhat of a SDR guru around these parts; in the past few months, he’s gotten a USB TV tuner receiver working with GNU Radio, started a software defined radio tutorial YouTube channel, and even used this project to listen in on conversations between airplanes and air traffic control. This time, [Balint] is back using this cheap USB TV tuner forradio direction finding and running HDSDR in Linux and OS X.
[Balint]’s radio direction finding presentation goes over traditional means of direction finding using the doppler effect and mechanically rotated antennas. Because [Balint] is dealing with frequencies around 150MHz (about 2 meter wavelength), building a physical direction finding setup requires spinning antennas at around 40,000 RPM; much to fast for any hardware build. [Balint]’s solution was to attach 4 antennas around the circumference of a circle and electronically switch between them many thousands of times a second. [Balint] put up a wiki page going over all the theory and implementation details of his build.
[Balint] also put wrote up a neat app to control software defined radios – including the Realtek TV dongle – over a network. Spread over a wide enough geographic area, it could become extremely easy for anyone to play air traffic controller. The BorIP Server can also be used to run HDSDR in Linux and OS X under Wine; just connect HDSDR to the network loopback on the same machine, and you get around Wine’s distaste for accessing hardware natively.
Awesome work, and we can’t wait to see what comes out of [Balint]’s laboratory next.
Edit: instead of the dongle, [Balnt] is using a ‘real’ software radio board. A lot of people are messaging him asking if the same method of direction finding is possible with the dongle. Here’s what [Balint] has to say:
The trick, as I see it, would be to create some (more or less simple) additional hardware to take the clock signal straight off the dongle’s on-board oscillator and divide it down for use with the antenna switch, i.e. 28 MHz à tens of kHz (this is the bit that’s done in ‘software’ on the FPGA). One problem still remains however: the counter needs to remain calibrated against the known direction the antenna was pointing at the time – otherwise a stop/start of the data stream from the dongle will mean the direction will go out of sync by 90/180/270 degrees each stop/start. Perhaps someone will figure out an elegant solution for this slight hurdle!