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.
When an airplane or meteor reflects a signal from a strong transmitter such as an ATIS signal or the Graves radar in France, the received reflected signal frequency will change as the plane or meteor comes towards or away from your receiver. This is due to the Doppler effect. Its effect can be observed as the sloping lines shown in the video.
To do the recording, DE8MSH used HDSDR together with spectrum lab and an RTL-SDR.