Tagged: rtl-sdr

WHY2025 Conference: Passive and Active RADAR using Software Defined Radio

Videos from the WHY2025 (What Hackers Yearn) have recently been uploaded to YouTube, and there is one interesting talk by Jean-Michel Friedt titled "Passive and active RADAR using Software Defined Radio". 

RAdio-frequency Detection And Ranging (RADAR) aims at using electromagnetic signals for detecting target location and motion. We demonstrate in this talk various RADAR architectures using dual-channel coherent Software Defined Radio (SDR) receivers and the associated signal processing techniques relying heavily on cross-correlations. Embedded systems are tackled, with a Raspberry Pi providing enough computational power for recording and post-processing.

RAdio-frequency Detection And Ranging (RADAR) aims at using electromagnetic signals for detecting target location and motion. Being constantly illuminated with electromagnetic smog, we can benefit from existing radiofrequency emitters meeting RADAR requirements -- strong power and wide bandwidth -- for passive RADAR measurements where no active emitter is needed, using only coherent passive dual-channel Software Defined Radio (SDR) receivers for passive recording of existing signals. If existing signals are unsuitable, we can use the same principle with non-cooperative emitters such as a Wi-Fi dongle in an active RADAR setup.

All processing flowcharts are implemented using GNU Radio for real time acquisition, and GNU/Octave or Python for post-processing: generic principles will be demonstrated, applicable to all sorts of receiver hardware. We will conclude with Synthetic Aperture RADAR (SAR) where antenna motion is used to simulate wide aperture receiving antennas, adding azimuth resolution to range resolution.

Supporting documents are found a https://github.com/jmfriedt/SDR-GB-SAR or https://github.com/jmfriedt/passive_radar orhttps://github.com/jmfriedt/sentinel1_pbr

WHY 2025 - Passive and active RADAR using Software Defined Radio

PiCar – A DIY Car Radio Head Unit made from a Raspberry Pi and RTL-SDR

Thank you to Vinnie Moscaritolo for writing in and sharing with us PiCar, a project to develop a homebrew car radio head unit out of a Raspberry Pi and RTL-SDR. The advantage of PiCar over a standard vehicle head unit is that PiCar is not just a broadcast AM/FM tuner, but is also capable of tuning to and scanning for other signals, such as public safety. In addition, Vinnie has also added various other features to PiCar, such as a GPS nav system, and CAN bus snooper.

Vinnie writes:

What happens when a radio nerd with a Jeep and a Raspberry Pi decides factory dashboards are too boring? You get PiCar — a DIY car radio replacement with a VFD display, a couple of knobs, and a whole lot of hacker soul.

Built around RTL-SDR and Raspberry Pi, PiCar does AM/FM, GPS nav, CAN bus snooping, 1-wire sensors, and even streams tunes from your iPhone — all without draining your Jeep’s battery. It's not just a head unit, it's a rolling testbed for software-defined radio, CAN hacking, and embedded Linux audio.

Vinnie has posted a full 9-part series on PiCar over on his blog. The series covers the why and the how, with several demonstration pictures and videos.

PiCar - Raspberry Pi Car Radio Project

The PiCar head unit
The PiCar head unit

Decentralizing AIS: Trustless Maritime Tracking with SDR

Recently, Owen Taylor, the CEO of WAKE (Worldwide AIS Network), wrote in to us asking if they could promote their project, which is a decentralized AIS aggregation network based on receivers like RTL-SDR. The twist compared to existing aggregators like marinetraffic.com is that WAKE aims to reward users via a crypto token and simultaneously solve the distributed verification problem to avoid problems like spoofing and poor transparency. 

The post below is their own words, and we note that we are not affiliated with WAKE.


Every second, ships transmit short bursts of data over VHF, broadcasting their position, speed, course, and identity. This is AIS (Automatic Identification System), an open, unencrypted protocol that lets vessels, ports, and coastal authorities maintain a shared picture of maritime traffic. Beyond collision avoidance, AIS feeds into port logistics, environmental monitoring, search and rescue operations, and even the financial analysis that drives global commodities trading.

For years, much of this coverage has been built on a mix of official receivers, satellites and a scattered network of volunteers, many of them SDR hobbyists streaming data from antennas on rooftops and coastal hills.

This model works, until it doesn’t. AIS has a well-known weakness: there’s no built-in authentication. Anyone can transmit a valid-looking AIS message. That opens the door to errors and deliberate spoofing, and right now there’s no universal method for verifying what’s real.

How AIS Works

AIS operates on two dedicated VHF channels, 161.975 MHz and 162.025 MHz, using 9600 bps Gaussian Minimum Shift Keying (GMSK) modulation. Transmissions follow a self-organizing time division multiple access (SOTDMA) scheme, where each station selects its own time slots to avoid collisions.

An AIS message can carry vessel identity (MMSI), position (latitude, longitude), speed over ground (SOG), course over ground (COG), navigational status, and other voyage data. Ships transmit at intervals from every few seconds (for fast-moving craft) to every few minutes (for anchored vessels).

For terrestrial reception, the chain looks familiar to any SDR operator:

Antenna → RTL-SDR (or similar) → AIS decoder software → Data feed.

Noise floor, antenna gain, and local RF environment all influence range, which for a coastal VHF station is typically 20–40 nautical miles. Higher elevations and directional antennas can stretch this significantly.

The Current Aggregation Model

Global AIS coverage today comes from a mix of satellite AIS for open-ocean tracking and terrestrial AIS for coastal areas, ports, and choke points. The terrestrial component is heavily dependent on a patchwork of volunteer-operated receivers, often nothing more than a VHF antenna, an RTL-SDR, and a small computer feeding data into a central platform.

Commercial services like MarineTraffic (now owned by Kpler), VesselFinder, and AISHub aggregate these feeds into global datasets that are then resold to shipping companies, commodity traders, insurers, and governments. The scale is impressive, but it comes at a cost to transparency.

In a recent video circulating on Reddit, the CEO of Kpler openly described their “monopoly” on maritime data, built on the volunteers giving up their data for free. While this may be good for their commercial positioning, it also highlights the underlying issue: a small number of companies effectively control access to AIS data, much of which was gathered for free from hobbyists.

From a technical perspective, the aggregation model has another weakness: it is built on trust. If a feed sends false data, whether through AIS spoofing, misconfigured hardware, or bad GPS input, that information can still enter the global record. Most platforms only filter out data that is obviously invalid, and there is no universal multi-source verification or cryptographic proof of authenticity in the AIS ecosystem.

The Data Integrity Problem

AIS is intentionally open and unencrypted to encourage wide adoption and interoperability. The downside is that nothing stops someone from transmitting a false position for a real ship or inventing an entirely fake vessel.

Spoofing incidents have been documented around the world. “Ghost ships” have appeared hundreds of miles inland. Vessel positions have been falsified to hide illegal fishing or smuggling. In some regions, ships broadcast fake locations to evade sanctions or mislead competitors.

Because AIS is used for everything from traffic management to environmental compliance, bad data has real consequences. It can mislead port authorities, disrupt logistics chains, and undermine safety systems that depend on knowing exactly who is nearby.

Distributed Verification

When we talk about “distributed” in this context, we mean a network of many independent AIS receivers,  owned and operated by different people in different locations, all working together to validate the same signals. No single entity has control over the data pipeline, and no single point of failure can compromise the entire dataset.

This approach aligns with what’s known as DePIN (Decentralized Physical Infrastructure Networks). In a DePIN, real-world hardware, in this case, AIS receiving stations powered by RTL-SDR dongles, is deployed by a distributed community, and the data it produces is aggregated, validated, and made available on a blockchain. Contributors are often incentivized for their role in maintaining the physical infrastructure and supplying high-quality data.

Applied to AIS, DePIN solves the monopoly and trust problem by creating:

  • Redundancy — multiple stations cover the same area, making spoofing and errors easier to detect.

  • Transparency — all verification events can be independently audited.

  • Resilience — coverage doesn’t vanish if one provider shuts down or changes terms.

From a technical perspective, defeating AIS spoofing requires proving that a received message is both authentic and physically plausible. A distributed verification system can achieve this by:

  1. Time of Arrival (TOA) Checks
    Comparing reception timestamps across geographically separated receivers. A false signal transmitted from shore will produce a different TOA pattern than one from a vessel at sea.

  2. Motion Consistency
    Checking positions against realistic limits for speed, acceleration, and turn rate. If a ship appears to jump 50 nautical miles in a minute, it fails.

  3. Cross-Coverage Triangulation
    Using relative signal strength and geometry between receivers to estimate origin and compare it to the reported position.

  4. Peer Agreement
    Looking for identical messages confirmed by several uncorrelated receivers. Messages verified by multiple independent nodes have a much higher trust score.

Once these checks are complete, the verification results, not necessarily the raw AIS payload, can be recorded on a tamper-proof, public ledger (such as a blockchain). This creates a permanent, auditable history of which AIS messages passed validation and when, allowing anyone to verify the integrity of past data without relying on a single company’s database.

Incentivizing a Trustless AIS Network

WAKE (Worldwide AIS Network) applies distributed verification principles to AIS in a way that directly involves and rewards the SDR community. At its core, WAKE is a decentralized network of independently operated AIS receivers, often built around RTL-SDRs or similar hardware,  working together to validate and record maritime data in a public, tamper-proof ledger.

In the WAKE model, contributors run AIS stations that submit decoded messages to the network. These messages are cross-checked against others received in the same geographic area. A message is only accepted if it passes both multi-receiver consensus and physics-based checks such as motion consistency and TOA analysis. This ensures that false or spoofed data is rejected before it ever reaches the historical record.

For the SDR community, this represents an evolution of an existing role. Many hobbyists already contribute AIS feeds without recognition or compensation. In WAKE, you’re not just relaying what you receive, you’re part of a validation mesh that makes AIS data more secure and tamper-resistant.

Because WAKE is built on a trustless model, no single operator, including WAKE itself can alter or suppress verified data. The integrity of the maritime picture is maintained collectively, with every contributor helping to keep it honest.

For SDR operators, the incentive is clear: you can keep doing what you already do best, running reliable receivers with clean reception and precise timing, but now with direct rewards for your contribution and the satisfaction of helping build a more open, diverse, and verifiable AIS data ecosystem.

You can learn more about WAKE Here.

Closing Thoughts

AIS has transformed maritime safety and logistics, but it was designed for trust, not for security. That’s fine when all players are honest, but as spoofing incidents have shown, trust alone isn’t enough.

A verification layer built on distributed SDR receivers is one of the most promising paths toward a tamper-proof global AIS dataset. It’s not about replacing the existing AIS ecosystem, but strengthening it.

The SDR community is uniquely positioned to lead that shift. By participating in networks that focus on data integrity, you can help ensure the maritime picture is as accurate tomorrow as it was yesterday, and maybe even fill in the parts of the map no one else can see.

Understanding Single Sideband Modulation Through GNU Radio and RTL-SDR

Thank you to Paul Maine for writing in and sharing his latest tutorial video, which explains how Single Sideband (SSB) modulation works. In the video, Paul explains the concept and mathematical principles behind SSB by showing how to create an SSB receiver using GNU Radio and an RTL-SDR.

Paul writes:

Paul Maine “ The SDR Guy” recently released a video about Single Side Band (SSB). 

The SDR Guy shows how to create a single sideband receiver using GNU Radio and an RTL-SDR. He also shows how to modulate SSB signals. Paul collaborated with Gary Schafer in the production of this video. Gary has created a must read blog post on SSB.

Paul answers the question: What is SSB and what’s the advantage when compared to Amplitude Modulation. He used SDR++ to capture an IQ file using an RTL-SDR and his HF antenna and is included in his resources. This allows you to use the resources he has provided to demodulate SSB even if you don’t have an HF antenna.

In fact, you don’t even need to have an SDR. A GitHub link is provided in the video description to all flowgraphs and IQ files discussed in the video. Lastly, The SDR Guy has included a complete Upper and Lower Side Band receiver that’s implemented in GNU Radio using an RTL-SDR!

Be sure to look at his YouTube Channel (paulmaine6433). He has many other SDR related videos.

E17 Create Single Sideband Receivers with GNU Radio and RTL-SDR

An SSB receiver in GNU Radio
An SSB receiver in GNU Radio

RF Analyzer V2.0 Released: RTL-SDR Compatible Android App

Thank you to Dennis Mantz @dennismantz for writing in and sharing with us the news that RF Analyzer V2.0 has been released for Android devices. RF Analyzer is a popular multimode Android app compatible with a vast number of SDRs, including the RTL-SDR. It also now supports the RTL-SDR Blog V4!

To use the app, you'll need a compatible RTL-SDR such as the RTL-SDR Blog V3/V4, an Android Phone or Tablet with USB OTG support, and a USB-OTG adapter. 

The new V2.0 is a complete rewrite from scratch. Dennis notes the improvements to the app below.

The app has been completely rewritten from scratch. It now features a modern Material Design UI, a more powerful and intuitive interface, and improved performance across the board.

- Support for demodulation while app is in the background
- Improved stability, demodulation and recording features
- Integrated user manual and contextual help
- Added support for RTL-SDR Blog v4

The app is not free, but it is priced at only a few dollars, and there is a 7-day free trial with 60-minute time limit per session. The full feature list is shown below:

- Works with HackRF, RTL-SDR, or pre-recorded IQ files
- View live spectrum (FFT) and waterfall plots
- Demodulate AM, FM, SSB, and CW signals
- Record raw IQ samples for offline analysis
- A responsive and modern Material Design interface
- Scroll, zoom, and tune through the bands
- Built-in context-aware help and a full offline in-app manual

RF Analyzer V2.0 Running on an Android Mobile
RF Analyzer V2.0 Running on an Android Mobile
RF Analyzer V2.0 On a Tablet
RF Analyzer V2.0 On a Tablet

Dennis has also uploaded a video tutorial explaining how to use RF Analzyer V2.0, and there is a full online user manual available here.

RF Analyzer 2.0 - Quick Start Tutorial - Android SDR App

A Browsable Archive of Historical Weather Satellite Data

Thank you to Meti for writing in and sharing his browsable archive of historical weather satellite data (further information here). The archive is designed to store weather satellite data, whether in baseband IQ format, frames, or images, for scientific, educational, or preservation purposes.

With NOAA POES now fully shut down, the archive could be useful for individuals who didn't have the opportunity to decode a NOAA satellite for real, or perhaps for those who will want to relive their old hobby one day. Meti writes:

I've been working on setting a weather satellite data archive up; a lot of these incredible satellites are lost to time because people didn't save the data or had it deteriorate over the years, as has been proven with the ongoing POES decommissioning!

My goal is to create a browsable archive of historical satellite data that is downloadable and re-decodable by others who didn't and/or don't have the opportunity to catch the satellites in question themselves for scientific, educational, or just preservative purposes.

I've been working hard asking around various people and groups for the possibility of them keeping some data from as many different satellites as possible, but still have large gaps in several satellites. I was wondering if it were possible to try to publish this archival effort on the blog to try to get more outreach than word of mouth?

The archive currently stands at 430 gigabytes of data with about 100 more awaiting processing due to missing pipelines, already spanning more than 4 decades!

The archive currently stores a variety of different satellites and their data products, and some in the archive even have the raw IQ data, which occupies a significant amount of hard drive space.

However, Meti notes that many satellites are still missing from the archive, and he would like to reach out to the community for submissions. If you have any data from the following, please reach out to Meti.

GEO:
- Meteosat wefax
- Meteosat xRIT (Only have very limited data)
- GOES-N LRIT/MDL/GVAR/Sounder SD (Before it became EWS-G! So over the US)
- Elektro-L1 xRIT/RDAS

LEO:
- NOAA APT older than NOAA 12
- NOAA HRPT from any sat besides 15/18/19
- Seastar (OrbView-2) HRPT
- MetOp LRPT !!! (Metop-A transmitted for a few days) - Meteor M1 HRPT
- Meteor 3M APT/HRPT
- Meteor 1/Priroda/2 APT (other than Meteor 2-21. NOT M2!)
- FengYun 2A/B/C/D/E/F (S-)VISSR (Or LRIT)
- Fengyun 1 CHRPT

Catch-all
- Any L-band prior to ~2000
- Any VHF prior to ~1990
- Any anomalies - instrument failures leading to strange receptions (i.e. NOAA 17 failing APT broadcasts). THIS IS EXCLUDING NOAA-15 post 2020 and any user-side issues (weak reception, sample drops etc.)

You can find more information about the project and how to contribute on this linked page.

Satellite Archive. Currently over 430 GB Archived.
Satellite Archive. Currently over 430 GB Archived.

Amateur Weather Satellite Reception Beyond NOAA POES

With the recent decommissioning of NOAA POES (NOAA-15, NOAA-18, NOAA-19), many amateur weather satellite hobbyists might be asking themselves if the hobby is now dead.

While NOAA POES satellites were the easiest stepping stones into amateur weather satellite reception, the hobby has seen massive strides in enabling easier reception of other satellites over the past few years. Furthermore, in the near future, various new satellites are scheduled for launch, which should be receivable by amateurs.

Over on his blog, Jacopo has created a detailed post showing what satellites amateur hobbyists can still receive on the L-band and S-band. Some receivable satellites include Meteor-M,  Metop, Arctic Weather Satellite (AWS), STERNA, Elektro-L, GOES, EWS-G, Jason-3, UVSQSat-NG, DMSP, HINODE, ISS DATV and Proba 2.

While almost all of these satellites (apart from Meteor-M's LRPT 137 MHz signal) require a satellite dish and L-band, S-band, or X-band feed, recent products like our Discovery Dish can make setting up an L-band or S-band system significantly easier.

The Meteor-M series of satellites
The Meteor-M series of satellites

Moving SatDump Towards V2.0.0

Over on the SatDump blog developers Aang23 and Lego11 have recently uploaded a post discussing their plans to move SatDump towards Version 2.0.0. SatDump is currently the most comprehensive and popular software for SDR users wanting to decode images and data from satellites. 

The developers note that their update frequency has slowed down recently due to their focus on V2.0.0. The new version introduces significant under-the-hood changes that will make SatDump easier to manage and develop in the future, and also focuses on improved documentation.  

Users of SatDump will also see an improved GUI, new functionality such as crop, an SSTV decoder, support and improvements for a wide range of satellites, any many other improvements discussed in the post. 

We note that V2.0.0 has not yet been released. The post notes that at some point in the near future they will begin merging the new V2.0.0 branch into master, followed by frequency alpha releases, before finally releasing an official V2.0.0. 

SatDump V2.0.0 ALPHA with new GUI
SatDump V2.0.0 ALPHA with new GUI