Over on YouTube user radiosification has uploaded a video tutorial that shows how to decode, follow and listen to NXDN/IDAS trunking radio signals. NXDN/IDAS is a narrowband digital voice protocol commonly used with handheld radio terminals.
In the tutorial radiosification explains how to set up DSDPlus and its frequencies text file to automatically listen to and track conversations using the control channel. SDR# is initially used to find the NXDN control and voice channels, which are then entered into the text file. Using this method only DSDPlus and its corresponding receiver FMP is used. Trunking software like Unitrunker is not needed.
Radiosification also notes that the method he presents can also be used for other digital trunking systems such as P25 as well.
All electronic devices emit some sort of unintentional RF signals which can be received by an eavesdropping radio. These unintentional signals are sometimes referred to as TEMPEST, after the NSA and NATO specification which aims to ensure that electronic devices containing sensitive information cannot be spied upon through unintentional radio emissions, sounds or vibrations. TEMPEST can also refers to the opposite, which is spying on unsecured electronic devices by these means.
In their experiments they set up an AES implementation on an FPGA, and used a simple wire loop antenna and RTL-SDR to measure and record the RF emissions. By then doing some analysis on the recorded signal they are able to fairly easily extract the AES encryption key, thus defeating the encryption.
Further testing in an anechoic chamber showed that with a discone antenna they were able to recover the keys from up to a meter away. A directional antenna could probably reach even further distances.
In the past we’ve seen a similar attack using a Funcube dongle, which is an SDR similar to the RTL-SDR. In that attack they were able to remotely recover encryption keys from a laptop running GnuPC. Also, somewhat related is Disney’s EM Sense which uses an RTL-SDR to identify electronic devices by their RF emissions.
Aerial TV is an Android app that allows you to watch DVB-T TV with an RTL-SDR on a mobile device. We posted about Aerial TV back in April and it was available on the Google Play store back then. Unfortunately Aerial TV has recently been banned from the Google Play store as apparently the app can be used to display copyrighted material from TV. The author writes the following on a Facebook post:
Google Play has suspended Aerial TV due to “[Aerial TV] claims to provide copyrighted contents from TV channels”. According to Google apps that display live TV are of “questionable nature”. I am trying to clarify what they mean. I would like to apologize to all affected users. If you have any concerns, feel free to get in touch with Google directly.
This is quite odd and probably a mistake. But if you are looking for Aerial TV it is now available on the Amazon app store with a current 35% discount. If you bought the app on the Google Play store then to get new updates you will need to uninstall it, contact the developer for a refund, and then purchase it again on the Amazon store. More info about that is available on the Facebook page. Updates about it’s availability will always be provided on the official website at aerialtv.eu.
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.
A possible meteor detection in SDR#.Aircraft detection doppler
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.
SDR-Console is a popular RTL-SDR compatible multi purpose SDR software package which is similar to programs like SDR#, HDSDR and SDRuno. Currently SDR-Console V2 is the stable version and SDR-Console V3 is in a beta state. A few days ago SDR-Console V3 Preview 6 was released. It comes with some very interesting new features including a built in Airspy server, a recording scheduler, a new feature called signal history and a new receivers pane.
“Signal History” takes the signal strength of the given bandwidth each 50 milliseconds, which can be saved in a CSV file. It is also shown in three different speeds on a display.
“Receivers’ Pane” shows up to six combos of spectrum/spectrogram of the complete up to 24 parallel demodulators (they additionally can be shown in the Matrix, as in former versions).
“Signal History” offers many applications, to name just three:
analyze fading and its structure with an unsurpassed time resolution of 50 ms
document fade-in and fade out
measure signal-to-noise ratio of signals
In addition Nils has also uploaded a very useful 19 page PDF where he writes step by step instructions and shows numerous examples of the new signal history tool.
DK8OK’s SDR-Console V3 P6 Screenshot. Showing multiple receiver panes and the new signal history feature.DK8OK’s screenshot of the signal history toolbox.
Over on his YouTube channel Adam 9A4QV has uploaded a video that shows him receiving the NOAA 19 HRPT signal at 1698 MHz with his HackRF, LNA4ALL and the simple circularly polarized cooking pot antenna that we saw in his last videos.
HRPT stands for High Resolution Picture Transmission and is a digital protocol that is used on some satellites to transmit much higher resolution weather images when compared to the APT signal that most people are familiar with receiving. The HRPT signal is available on NOAA19, which also transmits APT. However, unlike APT which is at 137 MHz, HRPT is at 1698 MHz, and is typically a much weaker signal requiring a higher gain motorized tracking antenna.
However in the video Adam shows that a simple cooking pot antenna used indoors is enough to receive the signal (weakly). The signal is probably not strong enough to achieve a decoded image, but perhaps some tweaks might improve the result.
Over on his Reddit thread about the video Adam mentions that a 90cm dish, with a proper feed and two LNA4ALLs should be able to receive the HRPT signal easily. User devnulling also gives some very useful comments on how the software side could be set up if you were able to achieve a high enough SNR.
GNU Radio has HRPT blocks in the main tree (gr-noaa) that work well for decoding and then David Taylor has HRPT reader which will generate an image from the decode GR output. http://www.satsignal.eu/software/hrpt.htm
http://usa-satcom.com has a paid HRPT decoder that runs on windows that has some improvements for lower SNR locking and works very well.
– devnulling
On a previous post we showed @uhf_satcom‘s HRPT results where he used a motorized tracking L-band antenna and HackRF to receive the signal. Some HRPT image examples can be found in that post.
NOAA-19 HRPT 1698MHz with HackRF + LNA4ALL + Pot antenna
HD Radio is a high definition terrestrial digital broadcast signal that is only used in North America. It is easily recognized by the two rectangular blocks on either side of a broadcast FM station signal on a spectrum analyzer/waterfall display. Since HD Radio uses a proprietary protocol, finding a way to decode it has been difficult and so this signal has been inaccessible to SDR users for a long time. Back in February of this year we posted about Phil Burrs attempt, where he was able to create a partial implementation (up to layer 2) of the HD Radio standard, but didn’t get far enough to decode any audio in layer 3.
However, now cyber security researcher ‘Theori’ has created a full RTL-SDR based decoder for the HD Radio protocol. In his post Theori explains that the HD Radio system is split into three layers. Layer 1 finds the signals and does decoding and error correction. Layer 2 is a multiplexing layer, which allows various layer 3 applications to share the bandwidth. Layer 3 is the audio data layer. In his post he explains how these layers work in detail.
One of the main findings was the discovery of the audio compression codec. Theori found that the codec was essentially HE-AAC with some minor modifications. The modifications were minor enough that he was able to adapt the open source FAAD2 library for HD Radio audio decoding.
Theori’s code is open source and available on GitHub. The code includes the patch to modify FAAD2 for HD Radio and it is automatically applied during the build. A sample file for testing the decoder is also provided and we tested the decoder with the sample and it worked well. The decoding can also be performed in real time and examples of that are also on the git readme.
This paper describes a new method for the synchronisation of multiple low-cost open source software-defined radios (SDR). This solution enables the use of low-cost SDRs in interesting navigation applications, such as hybrid positioning algorithms, interference localisation, and cooperative positioning among others. Time synchronisation is achieved thanks to a time pulse that can be generated either by one of the SDRs or by an external source, such as a GNSS receiver providing 1PPS signal. Experimental results show that the proposed method effectively reduces the synchronisation offset between multiple SDRs, to less than one sampling period.
In simple terms, hybrid positioning is the process of using multiple signals such as WiFi, Bluetooth and cell phone signals etc together to get an accurate position of the receiver. By using several sources localization accuracy can be improved, but to do this each receiver much be precisely synchronized to the same clock source.
The system they created uses a 1PPS GNSS based time source connected to the SYNC_IN inputs on both HackRFs. The synchronization code is run in hardware on the HackRF’s onboard CPLD (complex programmable logic device). Furthermore they also write the following regarding the system and code which has been adopted into the HackRF repository:
A new time synchronization feature has been recently adopted in the HackRF official repository thanks to the collaboration between SPCOMNAV group, Università di Bologna, and the European Space Agency (ESA).
This contribution allows any user to precisely synchronize multiple HackRF devices below 50 ns, by means of a minor hardware modification and the firmware update.
More information about the driver updates and instructions for use can be found in this Git pull request. The team also write that their work was presented at the NAVITEC 2016 conference.
HackRF Synchronization with a 1PPS GNSS Reference.
