Most police departments is the USA have now upgraded or are in the process of upgrading their radio systems to P25 Phase 2 digital radio. The frequencies can easily be received with an RTL-SDR, but a decoder is required to be able to actually listen to the voice. Software like SDRTrunk and DSDPlus can decode P25 Phase 1, but at the moment the only software that is capable of decoding P25 Phase 1 AND 2 is a program called OP25. However, OP25 has a reputation of being fairly difficult to set up as it does not have a simple to use GUI, and requires Linux.
Over on John's Tech Blog, John has uploaded a very helpful step by step tutorial that should help with those trying to get OP25 to work. The tutorial assumes that you have Ubuntu 18.04 already installed, and then starts from downloading and installing OP25. The next steps involve setting up OP25 for the particular system in your area, which mostly involves just editing a spreadsheet to input frequency data from radioreference.com. John also mentions that he's been able to get OP25 running perfectly on a Raspberry Pi 3 B+ as well, with less than 40% CPU usage.
In the video below John reviews some of the steps, and shows OP25 running and decoding voice.
Over on YouTube user Jan de Jong has uploaded a few screenshots and sounds on a video which shows that he was able to receive the ultrasonic sound of bats by connecting a small piezo speaker to an SDRplay RSP1A.
The piezo speaker used in reverse as a microphone appears to pickup bat echolocation sound waves which are typically between 20 to 200 kHz. The piezo is resonant in the 40 - 55 kHz range and converts sounds from that range into electric pulses that can be received directly by the RSP1A.
Researchers at Virginia Tech, the University of Electronic Science and Technology of China and Microsoft recently released a paper discussing how they were able to perform a GPS spoofing attack that was able to divert drivers to a wrong destination (pdf) without being noticed. The hardware they used to perform the attack was low cost and made from off the shelf hardware. It consisted of a Raspberry Pi 3, HackRF SDR, small whip antenna and a mobile battery pack, together forming a total cost of only $225. The HackRF is a transmit capable SDR.
The idea is to use the HackRF to create a fake GPS signal that causes Google Maps running on an Android phone to believe that it's current location is different. They use a clever algorithm that ensures that the spoofed GPS location remains consistent with the actual physical road networks, to avoid the driver noticing that anything is wrong.
The attack is limited in that it relies on the driver paying attention only to the turn by turn directions, and not looking closely at the map, or having knowledge of the roads already. For example, spoofing to a nearby location on another road can make the GPS give the wrong 'left/right' audio direction. However, in their real world tests they were able to show that 95% of test subjects followed the spoofed navigation to an incorrect destination.
In past posts we've seen the HackRF and other transmit capable SDRs used to spoof GPS in other situations too. For example some players of the once popular Pokemon Go augmented reality game were cheating by using a HackRF to spoof GPS. Others have used GPS spoofing to bypass drone no-fly restrictions, and divert a superyacht. It is also believed that the Iranian government used GPS spoofing to safely divert and capture an American stealth drone back in 2011.
Over on his YouTube channel Tech Minds has recently uploaded a video that demonstrates and shows how to use the rtl_433 software with an RTL-SDR to decode 433 MHz ISM band low power devices. Typically these devices include things like home wireless temperature and weather sensors, tire pressure sensors, remote controls, and other various sensors.
In the video he sets up an RTL-SDR and magmount antenna by his window and is able to receive data from several of his neighbors weather stations, and some car key remotes. He shows how to run the software on both Linux and on Windows.
How To Decode 433Mhz Low Power Devices Using RTL433 And A RTL-SDR Receiver
A radiosonde is a small weather sensor package that is typically attached to a weather balloon. As it rises into the atmosphere it measures parameters such as temperature, humidity, pressure, GPS location etc, and transmits this data back down to a receiver base station using a radio signal. The RS41 is one of the newer radiosonde modules sold by radiosonde manufacturer Vaisala, and is currently one of the most popular radiosondes in use by meteorological agencies. The signal is typically found at around 400 MHz and can be received with an RTL-SDR and an antenna tuned for 400 MHz. We have a general tutorial on radiosonde decoding available here.
There are several software packages that can decode RS41 data, such as the multi-radiosonde decoder Windows program called SondeMonitor (25 euros), or the free Linux command line software called RS. Recently a new free Windows GUI based RS41 decoder has been released by IW1GIS. The software can display on Google maps the current location and previous path of the radiosonde, as well as it's weather data telemetry.
Main features are:
Directly decoding of GFSK signal received by the FM radio receiver (the use of a Software Defined Radio is recommended).
Capability to connect and command SDRSharp software by mean of Net Remote Control plugin.
Advanced frequencies scan and decode: RS41 Tracker is able to look for RS41 radiosonde signal in a given list of frequencies, starting the radiosonde decoding when a valid signal is detected.
Real time showing radiosonde position on google map (internet connection is required)
Map auto centered on radiosonde position
Map type selectable by user (road, satellite, hybrid, terrain).
Burst killer detailed information and launch time estimation.
Radiosonde RAW data save
Post processing of RS41 RAW data file
Tracking information (elevation, bearing, slant range)
Over on our forums user thewraith2008 has just released news about his new software called TETRA Trunk Tracker. The software works in conjunction with the TETRA demodulator plugin for SDR#. It works by using two dongles, one to monitor a TETRA trunking channel, and the other to decode voice audio, although a single receiver mode is also available which works with a reduced and fixed bandwidth.
The post reads:
TETRA Trunk Tracker will follow calls on a TETRA network.
TETRA Trunk Tracker reads DATA that is output from the SDR# plug-in TETRA Demodulator (by TSSDR) via the 'Network Info' calls log window.
It interprets this DATA to determine when a call is set-up, then instructs SDR# (VC) to move to the carrier (frequency) that the call will be on.
It will also watch out for other PDUs to determine when a SSI starts or completes transmissions and when calls are complete (Released).
A basic call recording (All or Selective call recording).
Display current call details with list of seen SSIs for that call. (SSI populate as they TX).
GSSI holding - will only allow calls with selected GSSI to be heard.
Call lockout based on GSSI. Can be unchecked in list to lockout GSSI.
Call Priority. (Only normal version)
GSSI weighted 0-9, 9 is highest. If on active call and other call event occurs, if new call has higher
priority then will switch to it.
Collect/Save all seen GSSIs with Labels and Priority, By Network.
Collect/Save seen SSIs with Labels and Last seen Date/Time, By Network.
Set a call time-out. Returns to idle state if call does not see a release PDU after X time in seconds.
Log call events to screen and file, if enabled.
Log raw CC and VC PDU messages as seen by the 'TETRA Demodulator' plug-in, if enabled.
Log GSSI daily call activity. (Simple version does not play calls when this is selected)
Set base frequency via UI.
Set CC park carrier # via UI.
Set VC park carrier # via UI.
Suppress some PDUs. (unchecked is mainly for testing only)
Suppress lockout messages.
Sort SSI and GSSIs/Lockouts (by GSSI). This only occurs on start-up.
Country Code label, defined via file (shown as menu item)
Network label, defined via file (shown in tool tip where MNC,LA is in 'Call Details' panel)
Location Area label, defined via file (shown in tool tip where MNC,LA is in 'Call Details' panel) Only shown when Network label used.
Ignores Encrypted PDUs (with no reference to them)
Set a seen GSSI priority via UI.
Update a seen GSSI/SSI label via UI.
Call active indicator.
Restore SDR# windows to a defined position.
If the TETRA Demodulator does not work for you this program will do nothing to change that.
This is the third release of this program. (TETRA Trunk Tracker v0.99.6) And 2nd release for (TETRA Trunk Tracker v0.99.6s - Simple)
Two versions are available:
Normal (Uses 2 SDR# and 2 Dongles) with TETRA Demodulator and Net Remote plug-ins
Simple (Uses 1 SDR# and 1 Dongles with some features not available) with TETRA Demodulator and Net Remote plug-ins
Backup your "Tetra-trunk-tracker.dat" settings file. Then delete "Tetra-trunk-tracker.dat" as it has changed and old one will cause error on load.
Some work as gone into trying to make TETRA Trunk Tracker easier to run once the initial setup has been done.
A MCC (Country Code) label file is included for your convenience "TETRA_mcc.txt".
It has only been tested on Windows 7 - Professional SP1 (32 bit), English
You MUST have a PC that is capable of running SDR# x 2 with the TETRA plug-in. (Not overloaded CPU usage.)
It is in alpha stage. This means is may contain errors that may cause issues with the other programs it works with. i.e. crashing them or itself.
The TETRA plug-in currently been developed by TSSDR is also in early development. Because of this any changes made in plug-in releases most likely will break this program.
I have created it to suit my needs. And it currently works for me with the TETRA network I monitor.
I make no claim that it will work for other networks.
Please read the provided files for set-up and usage:
I have tried to be as thorough as possible with the documentation to explain usage and features. I believe any questions can be answered by reading these files. These files most likely are not complete and contain errors and are not laid out as good as they could be.
It only works with the provided TETRA plug-in supplied in zip. (2018-June-06). This version uses a custom compiled version of 'Net Remote' supplied in zip
It is only meant to be a temporary solution until something better comes along.
A few weeks ago we posted about some experimental work going on with Time Difference of Arrival (TDoA) direction finding techniques on KiwiSDR units. The idea is that public KiwiSDRs distributed around the world can be used to pinpoint the physical locations of any 0 - 30 MHz transmitter using the TDoA technique. This feature has recently been activated and can be accessed for free via any KiwiSDR.
The KiwiSDR is a US$299 HF SDR that can monitor the entire 0 - 30 MHz band at once. It is designed to be web-based and shared, meaning that the KiwiSDR owner, or anyone that they've given access, can tune and listen to it via a web browser over the internet. Many public KiwiSDRs can be found and browsed from the list at sdr.hu or by signal strength and location on this website.
One thing that KiwiSDRs have is a GPS input which allows the KiwiSDR to run from an accurate clock, as well as providing positional data. Time Difference of Arrival (TDoA) is a direction finding technique that relies on measuring the difference in time that a signal is received at over multiple receivers spread out over some distance. In order to do this an accurate clock that is synchronized with each receiver is required. GPS provides this and is able to accurately sync KiwiSDR clocks worldwide.
Just recently all KiwiSDRs were pushed with a beta update (changelog) that enables easy TDoA direction finding to be performed with them. Since many KiwiSDRs are public, this means that right now anyone can browse to a KiwiSDR web interface and start a direction finding computation. You don't even need to own a KiwiSDR to do this so this is the first freely accessible RF direction finding system available to the public. This could be useful for locating signals like numbers stations, military transmissions, pirate stations, jammers and unknown sources of noise.
Running a TDoA job is as simple as using the KiwiSDR OpenWebRX GUI interface to select a signal and choose two or more receivers to use in the calculation.
If you want to try this out then it's easiest to start with VLF/LF or MW stations (less than 1.6 MHz) as these signals tend to propagate to receivers only via direct ground wave. HF sky wave signals are a bit more difficult to locate as they tend to travel longer distances by skipping, bouncing and refracting around the ionosphere, so it is difficult to determine exactly where they are coming from since the bounces result in a difficult to predict time delay. But if you know the rough location of the transmitter, you can try and select nearby KiwiSDR receivers, which will hopefully ensure that the signals are received directly via ground wave, and not via sky wave. More advanced users could try using receivers spaced further away, but at similar distances from the expected transmitter location. This will hopefully ensure that all the receivers have identical skip distances, and thus identical delays.
To get started follow these steps (and we also recommend reading the Help text, which is available by clicking the 'Help' button on the TDoA extension):
Open a KiwiSDR that can receive some signals that you are interested in locating. You can browse KiwiSDRs by map and signal strength quality on this website.
With the 'extension' drop down menu in the bottom right controls window choose TDoA and double check that the receiver modulation mode is set to 'IQ'.
You should now see a map on the top half of the screen. This map displays all KiwiSDRs in the world that have GPS enabled and thus can be used for TDoA.
The map also displays several known transmitters in white with green markers that can be used as TDoA practice. Clicking on a known transmitter will automatically tune the KiwiSDR to that station.
Tune to the signal that you are interesting in locating. Make sure that the receiver bandwidth covers the signal.
Now you need to find two or more KiwiSDRs on the map that can receive the signal that you're interested in locating. (Two will give you a line of possible locations, whilst three may allow you to pinpoint the signal. But we recommend starting with only two or three first as more receivers can cause the calculation to fail).
To test and see if a KiwiSDRs from the map can receive the signal, double click on its marker. This will open the selected KiwiSDR in a new browser window, with it tuned to the station of interest. If you have a rough idea on where the transmitter is located, try to select KiwiSDRs such that they surround the transmitter.
Once you've found a KiwiSDR that receives your signal of interest, close the second KiwiSDR receiver window that you just opened, and go back to the original KiwiSDR window. Now instead of double clicking just click once on the KiwiSDR pin on the map that you confirmed reception with. This will add that KiwiSDR to the window in the bottom left. This window displays the KiwiSDRs that will be used in the TDoA calculation.
Make sure that it shows "XX GPS fixes/min" beside a selected KiwiSDR. If you get an error, remove that KiwiSDR and choose another.
When you've found two or more KiwiSDRs that receive the signal of interest, position the map to where you'd like the TDoA result heat map to be displayed. The positioning of the KiwiSDR map will determine where the TDoA heat map plot is displayed.
Click the 'submit' button to begin the TDoA calculations. The KiwiSDR server will gather 30 seconds of samples from each of your selected KiwiSDRs, and then run the TDoA algorithm on the KiwiSDR server. The whole process should take about 1-3 minutes to complete.
Once completed you can view the results by using the drop down menu next to the submit button to choose the 'TDoA Map'
The KiwiSDR TDoA feature is still in testing and can be a little buggy. If you get "Octave Error", try refreshing the KiwiSDR page and trying again with different receivers. Sometimes you'll also get an error saying that the GPS of a KiwiSDR hasn't updated in a while. In this case just remove that receiver and choose another one. We also find that if you're zoomed too far out on the map, the TDoA algorithm will sometimes return 'Octave error'. Try zooming in a bit closer to the approximately expected location. KiwiSDRs can also only support four simultaneous users at a time, so during peak periods it's possible that some may become busy.
Over on the KiwiSDR forums Martin G8JNJ has also provided a list of helpful tips that he's discovered. For example he recommends choosing KiwiSDRs that are spaced evenly around the estimated transmitter location (if known). Ideally they should also be chosen an opposing pairs (e.g. one pair north and south of the transmitter, and one east and west of it).
We tested the new TDoA feature a few times. Below are some examples of the results we achieved.
USA: NLK @ 24.6 kHz.
This is a Naval transmitter located in Seattle, Washington. With three receivers surrounding the transmitter, we were able to get a pretty close location marker, that is confirmed with the known location.
Europe: DCF77 Time Beacon @ 77.5 kHz.
This is a German long wave time beacon transmitter. Again with three receivers we were able to pinpoint the signal fairly accurately.
Australia: Local MW Radio Station @ 549 kHz.
Here we tried to locate an Australian MW station. Unfortunately in Australia there is a lack of KiwiSDRs, and of the ones that are there, only three had GPS enabled and could receive the MW station, and two of those were right next to each other. With only effectively two stations we could only obtain a line of possible locations. Comparing with the known location plotted on Google Maps we confirmed that the transmitter is indeed located on the line.
We also tested a few signals at higher frequencies. As mentioned previously, anything above VLF/LF/MW (ie the HF bands) is a lot more difficult to locate since the signal can bounce around the atmosphere and can case extra delays to occur in the signal arrival time. The extra delays can cause problems with the time of arrival measurements. Thus for these signals it's important to find receivers close to the transmitter, or receivers spaced further away at the same distance so they each have identical skip distances, and thus identical delays.
When locating an HF signal that is in a completely unknown location we recommend starting with only two or three receivers, checking the heat map, and slowly adding more receivers in the hot parts of the heat map and removing receivers that turn out to be in the cooler areas. This way you can slowly narrow down the receivers to ones that are closer to the signal source, and are thus more likely to receive the signal directly, rather than via ionosphere bounces.
The Buzzer (UVB-76)
Using the just previously mentioned technique we attempted to locate the source of the Buzzer (UVB-76), a Russian numbers station at 4.625 MHz. Eventually we came to the results shown below. According to the heat map the buzzer appears to be located somewhere in the vicinity of St. Petersburg. Back in 2014 the numbers station researchers at priyom.org received an anonymous tip from a member citing a transmitter location just north of St. Petersburg. The TDoA heat map results seem to confirm that the anonymous tipper is correct.
Right now the biggest problem appears to be the lack of active KiwiSDRs around the world. The more active KiwiSDRs there are, the better the direction finding results can be. At the moment Northern Europe and the USA are fairly well represented, but the rest of the world is not. Asia, Africa, Russia and South America are especially lacking. Also not all KiwiSDRs are utilizing the GPS feature. If you are running a KiwiSDR please do consider activating the GPS option. Another issue is that many KiwiSDRs suffer from poor reception and bad antenna setups, so not all active receivers are actually useful.
In the future we expect this feature to only improve, with the people behind it, John Seamons and Christoph Mayer, working hard to improve results. For example one possible future improvement is utilizing ray-tracing techniques to try and take into account delays caused by sky-bounce propagation. Update (15 July 2018): You can now also plot results over Google Maps.
If you want to purchase a KiwiSDR and contribute to the worlds first freely accessible TDoA system, you can purchase it immediately on Amazon or Seeed Studios for $299, or wait for a sale to occur on massdrop.com, where it is often discounted by up to US$100.
Thank you to Reiichiro Nakano for submitting news about his work on converting the Pascal based meteor_decoder software into a C++ GNU Radio block. meteor_decoder is a decoder for the Meteor M2 weather image satellite. Meteor M2 is a Russian weather satellite that transmits images down in the digital LRPT format. This provides much higher resolution images compared to the NOAA APT signals. With an RTL-SDR, appropriate satellite antenna and decoding software it is possible to receive these images.
Reiichiro works for Infostellar, which appears to be a Japanese company aiming to connect satellites to the internet via distributed and shared ground stations. It appears to be somewhat similar to the SatNOGs project. Reiichiro writes:
Just wanted to share a simple project I built for my company Infostellar, in the past week. I converted https://github.com/artlav/meteor_decoder to C++ and placed it within a GNURadio block for direct decoding of Meteor M2 images. It's a sink that expects soft QPSK demodulated signed bytes. Once the flowgraph stops running, it parses out received packets and dumps the received Meteor images in a specified location.