To do this he used an Android app called "DRM+SDR Receiver" which is available for US$4.99 on the Play store. The app supports RTL-SDR and HackRF devices. So all you need to do is set the RTL-SDR Android driver to run in Q-branch direct sampling mode, then tune to a DRM signal for it to begin decoding.
A demonstration video uploaded to his Google drive account shows clean decoding of the DRM AAC audio, as well as the app displaying Journaline and live metadata. He notes that his signal was very strong, so he only required a short wire, but DXers would need an appropriate antenna.
Over on Twitter Annunaki (@StupotSinders) has been teasing some screenshots of a GUI for DSD+ that he's been developing over the past few weeks. And now he has released the software which is called "DSDPlusUI". DSD+ is mostly command line based, so a GUI could be useful for newbies. The software can be downloaded from the DSDPlusUI groups.io page.
DSD+ (aka Digital Speech Decoder) is a free closed source program that is compatible with RTL-SDR and various other SDRs which is used to decoder digital speech protocols such as P25 P1, DMR, NXDN and more. DSD+ Fastlane is a paid upgrade which allows subscribers to receive the latest updates to the software early.
KiwiSDR have recently implemented DRM decoding into their OpenWebRX implementation. Digital Radio Mondiale (DRM) is a type of digital shortwave radio signal that is used by some international shortwave radio broadcasters. It provides superior audio quality compared to AM stations thanks to digital audio encoding.
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 to 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.
The new DRM implementation is based on DREAM 2.1.1 which is an opensource DRM decoder that can be used with any HF capable SDR. Due to computational limits of the BeagleBone singleboard computer which the KiwiSDR runs on, only one DRM channel can be decoded at any one time, restricting this capability to only one user at a time. However, if the KiwiSDR is running on the newer BeagleBone AI, it can support up to four DRM channels. KiwiSDR write that work is still ongoing to improve the code, so this situation may improve in the future.
Back in April 2019 we posted about Matt Mills' Radiocapture.com website which is a web service that you can feed that automatically captures analogue and digital trunked radio conversations with an RTL-SDR, and allows public users to play back conversations via the web interface. The Radiocapture page which shows what the software is capable of is also active at radiocapture.com/radio.
Back in April Matt was fundraising via Patreon and hoping to make development of Radiocapture his day job, but unfortunately he's had to call it quits for now. Since he no longer has time to work on it, Matt has open sourced the RF side of the software. The software description reads:
[Radiocapture-rf] is capable of using multiple networked computers and multiple SDR radios to demodulate the control channel of P25, EDACS, and Motorola trunking systems, as well as some limited support (alpha quality) for scanning for systems, LTR trunking, and "police scanner" style audio capture.
It is designed to effectively scale to an infinite capacity of trunked systems, captured transmission volume, and dongle bandwidth (more dongles = more available bandwidth, more cpus = more channels and more systems). (There is one remaining feature to be implemented to really make this work well, dongle redis autodiscovery (frontend_connect should autodiscover and use available dongles) and splitting the rc_frontend/receiver.py into one process per dongle.
The frontend initializes the SDRs in whatever configured frequency range, and presents a server interface where clients can connect and request a specific channel be created and forward to them. The frontend will then attach a channel, and output to a UDP sink (might be something better now, I forget). On the backend side, a control_demodulator is listening to that sink and doing the actual RF demodulation, which is passed into redis for distribution to other services. The backend is effectively a bunch of microservices that work together to track & record all ongoing transmissions and do some amount of deduplication. This entire setup is designed such that it can be scaled across as many servers/computers as necessary (although there are a few caveats/things I never got around to implementing in how it actually works). Recorded transmissions are decorated with a metadata scheme in their mp3 tags that is designed to be able to be loaded into the Radiocapture.com database. Finally completed mp3s are dropped into an activemq queue for publishing.
Matt notes that the software in it's current state isn't considered as "ready to distribute" as you may need some decent experience with Linux and Python to get it up and running.
Tesla vehicles have a feature where they can copy and mimic a garage door remote via a built in transmitter on the car itself. This frees you from having to carry around a garage door key fob, and you can simply open your garage door by pressing a button on the car's LCD screen.
However, some people have reportedly been having a little trouble with this feature as in some cases the garage door would begin opening, and then suddenly stop opening as if the keyfob button had been pressed twice.
Over on YouTube CWNE88 decided to investigate this problem using his HackRF and GNU Radio. From a simple waterfall he was able to determine that the Tesla actually transmits the mimic'd garage door signal for a full two seconds.
As a keypress from the original keyfob would typically result in a much shorter transmission, CWNE88 believes that the long two second transmission could in some cases be seen as two transmissions by the garage door, resulting in an open, and then close command being detected.
Over on YouTube channel Tech Minds has uploaded a short tutorial video that shows how to perform a replay attack with a HackRF and the Universal Radio Hacker software. A replay attack is when you record a control signal from a keyfob or other transmitter, and replay that signal using your recording and a TX capable radio. This allows you to take control of a wireless device without the original keyfob/transmitter. This is easy to do with simple wireless devices like doorbells, but not so easy with any system with rolling codes or more advanced security like most car key fobs.
In the video Tech Minds uses the Universal Radio Hacker software to record a signal from a wireless doorbell, save the recording, replay it with the HackRF, and also analyze it.
Universal Radio Hacker - Replay Attack With HackRF
Reddit user [Bobcalamarie] recently [posted] about how he uses his car dash mounted Android tablet along with an RTL-SDR Blog V3 and a magnetic mount antenna while sitting in traffic to track aircraft overhead.
We’ve seen something similar to this once before when [Signals Everywhere] uploaded a video showing off ADS-B reception (among other things) to a dash-mounted Windows tablet and an Android head unit.
The software used by Bobcalamarie is the Android [Avare ADS-B] software which can be found in the Google Play Store. However, other applications exist for Windows, Linux, and other operating systems as well. Some software such as [Virtual Radar Server] even allows you to set-up alerts for specific types of aircraft. Which while we wouldn’t condone it, it might come in handy for someone in traffic.
What would you do if you had an SDR installed in your vehicle? We would love to hear what you have to say in the comments below.
The transmitting side consists of a GNU Radio flowchart that encodes the text file into a binary string, modulates that binary string with Binary Phase Shift Keying (BPSK), and then transmits it using the LimeSDR.
The receiving side uses an RTL-SDR, and is based on another GNU Radio flowgraph that uses a polyphase clock sync block to synchronize the sampling time, a costas loop for fine frequency correction, an LMS DD equalizer block to compensate for multipath effects, and finally demodulation blocks that recover the bits and text file from the BPSK signal.
His results showed that he can almost recover the entire file except for the first few bytes of data which is always lost since it takes time for the clock sync and costas loop block to converge. The post goes into further detail about what each of the blocks do and some of the signal theory math behind everything. The GNU Radio GRC file is also provided if you want to try it out yourself.