Over on YouTube Meine Videokasetten has posted a video showing how he's been using an RTL-SDR to detect aircraft landing and taking off via the scatter on a VOR beacon. VOR (aka VHF Omnidirectional Range) is a navigational beacon that is transmitted between 108 MHz and 117.95 MHz from a site usually at an airport. Although as it is an older technology it is slowly being phased out in some places.
An interesting observation can be made that is unrelated to the actual operation and use of VOR navigation. When an aircraft passes near the VOR beacon it results in the signal reflecting and scattering off the metal aircraft body. As the aircraft is moving quickly, it also results in a frequency doppler shift that can be seen on an RF waterfall display.
In his video Meine Videokasetten uses an RTL-SDR and OpenWebRX to receive the VOR signal. He then pipes the audio output of that signal into Speclab which allows him to get significantly increased FFT resolution for the waterfall. This increased resolution allows him to clearly see the doppler scattering effects of aircraft on the VOR transmission. He notes that it's possible from the scattering to determine if an aircraft is taking off or landing.
Passive doppler radar on VOR beacon transmitter .:°:. A let's test it out
We note that back in 2015 we posted about the ability to "fingerprint" aircraft using this technique. Different types of aircraft will result in unique patterns on the waterfall. In that post they used analogue TV carriers which are not very common in most countries anymore, so it's good to see that this can be used with VOR signals too.
Thanks to Luigi (aka @luigifcruz and PU2SPY) for writing in and submitting to us his LimeSDR based doppler radar blog post. The LimeSDR Mini is a low cost two port TX and RX capable SDR. Luigi's doppler based radar makes use of one TX port to transmit the radar signal, and the RX port to receive the reflection. The idea is that the if the object being measured is moving, the received reflected signal will be altered in phase due to the doppler effect.
In terms of hardware, Luigi's radar uses the LimeSDR Mini as the TX/RX radio, a Raspberry Pi 3 as the computing hardware, an SPF5189Z based LNA on the RX side, and two cantenna antennas. It transmits a continuous wave signal at 2.4 GHz.
On the software side it uses a GNU Radio program to transmit, receive and process the returned signal. Luigi's post goes over the DSP concepts in greater detail, but the basic idea is to measure the phase shift between the transmitted and reflected signal via a Multiply Conjugate block, and then decimate the output to increase the resolution. The result is then output on a frequency domain waterfall graph. The GNU Radio is all open source and available on Luigi's Github.
In order to test the system Luigi first set up a test to measure an electric fan's blade speed. The result was clearly visible line in the spectrogram which moved depending on the speed setting that the fan was set to.
Software Defined Radar - Continuous Wave Doppler Radar w/ LimeSDR
In his second test Luigi measures the speed of vehicles by placing the radar on the sidewalk, pointed at cars. The result was clear indication of the vehicle passes as shown by the longer vertical lines on the graph below. The smaller lines have been attributed to pedestrians passing by.
In a third test, Luigi measured vehicle speeds in tougher conditions, with the radar placed 50 meters away from the highway, at 45 degrees, and with weeds in the way. The radar still generated obvious lines indicating vehicles passes. Finally, in his fourth test, Luigi tested the speed accuracy of his radar by measuring a car driving at a known speed. The results showed excellent accuracy.
Software Defined Radar - Continuous Wave Doppler Radar w/ LimeSDR
Over on his blog author Daniel Estevez has described how he's been listening to aircraft reflections from a 2.3 GHz 2W beacon. The beacon is 10km away from Daniels location and transmits a tone and CW identification at 2320.865 MHz. As aircraft fly nearby to his location Daniel was able to observe aircraft reflections of the beacon, and was able to match them with ADS-B position and velocity reports.
The hardware that he used was a LimeSDR and a 9dBi 2.4GHz planar WiFi antenna patch. By aiming the antenna away from the transmitter, and using his car as a shield to block the transmitter he was able to receive some reflections. Daniel recorded several reflections including one produced by a nearby car.
By combining his results with ADS-B data he was able to superimpose the results, and color aircraft tracks by either a negative or positive doppler shift which was observed from the reflection. By combining the ADS-B data with the time stamps, he was also able to mark the reflections from each aircraft.
Last week we posted about Micheal Ossmann and Schuyler St. Leger's talk on Pseudo-Doppler direction finding with the HackRF. The talk was streamed live from Schmoocon 18, but there doesn't seem to be an recorded version of the talk available as of yet. However, Hackaday have written up a decent summary of their talk.
In their direction finding experiments they use the 'Opera Cake' add-on board for the HackRF, which is essentially an antenna switcher board. It allows you to connect multiple antennas to it, and choose which antenna you want to listen to. By connecting several of the same type of antennas to the Opera Cake and spacing them out in a square, pseudo-doppler measurements can be taken by quickly switching between each antenna. During the presentation they were able to demonstrate their setup by finding the direction of the microphone used in the talk.
If/when the talk is released for viewing we will be sure to post it on the blog for those who are interested.
Thanks to Dave for submitting news of his recent release of his Python script called dopplerscript. This is a tool that can help people automate the reception and decoding of the Meteor M2 weather satellite in Linux with GNU Radio by providing a tool for automatic Doppler correction. He writes:
gr-gpredict-doppler is an out-of-tree gnuradio block for getting doppler updates from gpredict into a flowgraph. I’ve written a small python script (based on pyephem) that replaces gpredict for generating the doppler updates. This script allows one to automate scripting the reception of Meteor M2 satellite transmissions while compensating for the doppler shift.
dopplerscript is a command-line tool to input satellite doppler shifts into a gnuradio flowgraph. The doppler.py script replaces gpredict as the source for doppler frequency updates in gr-gpredict-doppler, making it easy to script satellite reception.
As low earth orbit satellites fly very quickly overhead, the signal will be affected by the doppler effect, thus shifting the frequency as it moves towards and away from you. Tools like this can be used to predict and compensate for this effect and thus providing better signal processing. Meteor M2 is a Russian weather satellite in low earth orbit which transmits digital LRPT weather satellite images that can be received with an RTL-SDR or other SDR.
Over on his blog Dave Venne has been documenting his attempts at using National Weather Service (NWS) broadcasts for forward scatter meteor detection with an RTL-SDR. Forward scatter meteor detection is a passive method for detecting meteors as they enter the atmosphere. When a meteor enters the atmosphere it leaves behind a trail of highly RF reflective ionized air. This ionized air can reflect far away signals from strong transmitters directly into your receiving antenna, thus detecting a meteor.
Typically signals from analog TV and broadcast FM stations are preferred as they are near the optimal frequency for reflection of the ionized trails. However, Dave lives in an area where the broadcast FM spectrum is completely saturated with signals, leaving no empty frequencies to detect meteors. Instead Dave decided to try and use NWS signals at 160 MHz. In the USA there are seven frequencies for NWS and they are physically spaced out so that normally only one transmitter can be heard. Thus tuning to a far away station should produce nothing but static unless a meteor is reflecting its signal. Dave however does note that the 160 MHz frequency is less than optimal for detection and you can expect about 14 dB less reflected signal from meteors.
So far Dave has been able to detect several ‘blips’ with his cross-dipole antenna, RTL-SDR and SDR#. He also uses the Chronolapse freeware software to perform timelapse screenshots of the SDR# waterfall, so that the waterfall can be reviewed later. Unfortunately, most of the blips appear to have been aircraft as they seem to coincide with local air activity, and exhibit a Doppler shift characteristic that is typical of aircraft. He notes that the idea may still work for others who do not live near an airport.
We note that if you are interested in detecting aircraft via passive forward scatter and their Doppler patterns, then this previous post on just that may interest you.
The idea was to analyze the Doppler from the head echoes and and see if something useful can be extracted from them.
We detected a meteor from two distant locations and measured Doppler and Doppler slope at those locations. The we tried to find solutions to the meteor equation by brute force until we obtain a big number of them. Then we plotted those solutions in the sky and we see some of them pass near a known active radiant at the time of observation. Then, we checked the velocity of those solutions near the known radiant and found they are quite similar to the velocity of the known radiant, so we concluded probably they come from that radiant.
But they can come from everywhere else in the sky along the solution lines! There is not guarantee these meteors to be Geminids, although probabilities are high. Once all the possible radiants of a meteor are plotted into the sky, there is no way to know who of all them was the real one. Doppler only measurement from two different places is not enough to determine a meteor radiant. But don’t forget with some meteors, suspect to come from a known shower, the possible results includes the right radiant at the known meteor velocity for that radiant, so there seems to be some solid base fundamentals in this experiment.
Initially they ran into a little trouble with their sound cards, as it turns out that sound cards don’t exactly sample at their exact specified sample rate. After properly resampling their sound files they were able to create a stereo wav file (one receiver on the left channel, one receiver on the right channel) which showed that the doppler signature was different in each location. The video below shows this wav file.
Double station meteor head echoes
Using the information from their two separate recordings, they were able to do some doppler math, and determine a set of possible locations for the radiant of the meteors (it was not possible to pinpoint the exact location due to there being no inverse to the doppler equation). The radiant of a meteor shower is the point in the sky at which the meteors appear to be originating from. Although their solution couldn’t exactly pinpoint the location, some of the possible solutions from most meteors passed through the known radiant of the Geminids meteor shower. With more measurement locations the exact location could be pinpointed more accurately.
Programmer Andres has recently been working on creating a toolset for receiving AX.25 packets (FSK 9600) from satellites with an RTL-SDR or other software defined radio. The AX.25 protocol is commonly used for APRS packet radio or telemetry in amateur radio satellites. Andres’ programs focus on using a true UNIX philosophy of piping data between different programs. The toolset consists of doppler correction and demodulation tools and the piping philosophy is demonstrated in the following example:
rtl_sdr | doppler | demod | multimon-ng
rtl_sdr receives raw IQ data from satellites which is then piped to “doppler” which corrects doppler offset. Zero centered baseband signal is piped to “demod” which outputs demodulated audio suitable for multimon-ng to do actual AX.25 packet decoding.
Such pipeline is intended for resource constrained embedded platforms like RaspberryPi or BeagleBoneBlack where running full blown SDR software would be too much.
The doppler corrector tool works by using the same libraries for calculating satellite positions as those used in Gpredict and the demod tool uses the liquid-dsp library to demodulate the IQ stream.
More information about Andres’ project can be found in these three blog posts that he has written.