Over on Kickstarter, Lambda58 LLC has released a campaign for their PicoADSB product, a self-contained 1090 MHz ADS-B receiver that replaces a typical SDR plus Raspberry Pi feeder setup with a single SD-card-sized PCB measuring 25mm x 15mm and weighing only 3 grams. At the time of this post, the campaign has reached around $12,700 against a $10,000 goal, and closes on May 16. The maximum claimed reception range is 500km+. At this time, there is no support for 978 MHz UAT, though they mention staying tuned for updates.
A photo of the board shows that it is based on an ESP32-C3-Mini-1 for the WiFi web server, and on what appears to be a separate microcontroller and an L-band tuner chip. The antenna input is fed via a U.FL connector to a 1090 MHz SAW filter, an LNA, and then the tuner. We suspect that the microcontroller is used for its ADC and for ADS-B demodulation.
PicoADSB appears to compete with ADSBee, which we previously covered. ADSBee is based on the Raspberry Pi Pico chip. However, ADSBee supports both 1090 MHz and 978 MHz on the same board, but costs a little more at US$152 for a set.
The following is a guest post submitted by Matt Larson.
The post explains how Matt Larson set up an automated atmospheric wind-sensing station using only locally obtained ADS-B data from an RTL-SDR. Matt's code is available on GitHub.
Listening to the Jet Stream - 100 Days of Wind Sensing with Stock RTL-SDR Hardware
By Matt Larson — Helena Valley Observatory, Helena, Montana
I built a passive atmospheric sensing system using a stock RTL-SDR Blog V4 kit and the included dipole antenna, with no external filtering or amplification.
Over 100 days in Helena, Montana, it logged 5+ million ADS-B messages and produced jet-level wind direction estimates with ~14° mean absolute error versus ERA5 reanalysis on favorable (zonal flow) days — within AMDAR operational reference ranges.
The system requires no aircraft cooperation, no radar, and no onboard meteorological data — only passive reception of ADS-B broadcasts and geometric analysis of reciprocal flight tracks.
This turns an RTL-SDR from a visualization tool into a measurement instrument. Instead of asking "what aircraft are overhead," you can ask "what is the atmosphere doing above me right now?"
The Bet
It started as a $50 bet with myself.
I had no formal background in atmospheric science. No lab, no funding, no institution behind me. Just a house built in 1894 in Helena, Montana, a Linux box, and a question I couldn't stop thinking about: could you use the aircraft already flying overhead as atmospheric sensors — without touching them, without their cooperation, without anything except listening?
The worst case was a $30 receiver and some wasted evenings. The best case was something I couldn't quite articulate yet.
I plugged in an RTL-SDR Blog V4 kit I bought on eBay, pointed the small dipole antenna that came in the kit at the sky, and started asking questions.
That was January 17th, 2026. One hundred days later, I'm writing this with a longitudinal archive of more than 5 million records, validated jet-level wind estimates within the AMDAR operational accuracy range, a documented terrain channeling signature for the Helena Valley, and a surface-level signal consistent with the timing and structure of the January-February 2026 Sudden Stratospheric Warming event, validated against ERA5 and radiosonde data but not independently attributable.
No dedicated 1090MHz antenna. No external filter. No fancy mast. The stock dipole that came in the kit, tuned to 1090MHz.
This is what I learned. And at the end I'll tell you exactly how to start.
What You're Actually Doing
When an aircraft equipped with ADS-B transponds, it broadcasts its GPS position, altitude, groundspeed, heading, and a timestamp. Your RTL-SDR receives that broadcast passively — you're just listening. No radar, no active emissions, no interaction with the aircraft at all.
Most people use this to watch planes on a map. That's genuinely fun. But there's more in that signal than position data.
An aircraft's groundspeed is its speed relative to the ground. Its airspeed is its speed through the air. The difference between those two numbers — the vector difference, accounting for direction — is the wind. The aircraft doesn't measure wind directly, but the relationship between what it's doing through the air and what it's doing over the ground encodes the wind field it's flying through.
The problem is that ADS-B gives you groundspeed, not airspeed. So how do you recover the wind?
The answer is geometry.
If two aircraft fly the same route in opposite directions, one sees a tailwind and one sees a headwind. The difference in their groundspeeds is twice the wind component along that axis. Divide by two, and you recover the wind — without ever measuring airspeed.
No airspeed required. No heading required. Just groundspeed and geometry.
That's the foundation of what I built: a passive atmospheric sensing station that extracts wind information from aircraft that are already flying over my valley every day whether I'm watching or not.
One important note on aircraft types: heavy jets and regional aircraft have different typical true airspeed values at the same altitude. The solver accounts for aircraft class when making TAS assumptions, and estimates are validated against external reanalysis data rather than treated as precise measurements in isolation.
The Observatory
The hardware is simple.
RTL-SDR Blog V4 kit from eBay. The small dipole that comes in the kit. Tuned to 1090MHz. A Linux machine running Arch. readsb decoding the signal. A Python pipeline I wrote from scratch to archive, segment, and analyze the data.
That's the whole stack. No proprietary software. No cloud dependencies. No subscription. Everything runs locally and everything is mine.
The software architecture has three layers.
The first is the archive. Every observation logged to JSONL files — position, altitude, groundspeed, callsign, registration, timestamp — every five seconds, continuously, without gaps. After 100 days that archive contains more than 5 million records representing roughly 300 unique aircraft per day.
The second is the Flow Lab. The atmospheric analysis pipeline. It runs four stages each night: segmentation breaks continuous aircraft tracks into straight-line level-flight segments; wind solving applies the reciprocal pair geometry to extract wind vectors per altitude layer; terrain analysis measures how strongly the valley's topography constrains aircraft tracks; and reporting produces a daily brief in plain text that I read the next morning like a weather report from my own kitchen.
The third is the Signal Lab. RF characterization — near-field and far-field RSSI variance, anomalous propagation events, terrain shadow mapping, free-space path loss residuals. The radio environment of the Helena Valley, documented day by day.
Everything automated. Everything archived. Every output reproducible from the raw JSONL files.
ADS-B Tracks Received by the ObservatorySample daily brief output from the Flow Lab pipeline
What the Methodology Requires — And What It Doesn't
I want to be honest about what this system can and cannot do before I tell you what it found, because the limitations matter as much as the results.
The reciprocal pair wind solver works under specific conditions. It needs enough aircraft flying opposing tracks at similar times and similar altitudes. On busy traffic days with good reciprocal coverage it produces clean wind estimates. On quiet days or days with limited crossing geometry it produces nothing — and says so explicitly rather than guessing.
Wind direction is recoverable with reasonable accuracy under these conditions. Wind speed carries inherent uncertainty because the solver depends on assumptions about aircraft true airspeed. Speed estimates are reported with explicit uncertainty bands and are not treated as precise measurements.
The system fails gracefully on trough days — when the jet stream is curved and the flow is complex. On those days the solver flags the output as UNRESOLVED and produces no wind estimate rather than a wrong one. Knowing when you cannot measure something is part of measuring it honestly.
Every output in the daily brief carries a label: OBSERVED FACT, DERIVED METRIC, or INFERENCE. Nothing gets promoted to a finding without meeting explicit quality gates. The methodology is documented in enough detail that anyone could replicate it and get comparable results.
What 100 Days Found
Jet-level wind direction.
The reciprocal pair solver produces daily wind direction estimates at five altitude layers. At the jet stream layer — above 36,000 feet — the day-to-day directional consistency across the archive shows a correlation of R=0.954. That's a strong unimodal signal. The jet over Helena runs westerly the vast majority of days, with documented exceptions on trough and transition days.
On days with zonal flow — when the atmosphere is well-organized and the jet is running straight — I compared estimates against ERA5 reanalysis data from the Copernicus Climate Data Store. Here are the actual numbers:
Metric
Value
ZONAL days with ERA5 comparison
N=21
Mean angular error (MAE)
14.3°
Median angular error
13.5°
Best day
0.3° error
Worst day
38.3° error
Days with STABLE solution (robust to parameter changes)
68 of 81 (84%)
Day-to-day jet direction consistency (R)
0.954
AMDAR operational target range
10–20°
A $30 kit with a stock dipole antenna on a rooftop in Montana is producing estimates that land inside the AMDAR operational accuracy range on favorable days. On trough days the system fails and says so. That's also a result.
Terrain channeling.
The Helena Valley runs roughly ENE/WSW — 75 degrees and 255 degrees. The terrain channeling index measures what fraction of low-altitude aircraft tracks align within 45 degrees of that axis.
The mean channeling index across 100 days is 0.855.
To put that plainly: the valley's terrain is so effective at constraining low-level airflow that it dominates aircraft track orientation regardless of what the synoptic weather pattern is doing that day. Aircraft aren't intentionally following the valley — their routes are set by ATC. But the wind field the terrain creates pushes their ground tracks toward the valley axis. The terrain writes its signature into the aviation data every single day, zonal or trough, January or May.
That signal is geographically structured. The channeling index is strongest in the valley core — CI above 0.90 near the center of the Prickly Pear Valley. It weakens at the eastern exits where the terrain opens toward the Missouri River drainage and the Elkhorn foothills. The valley acts like a funnel: strong forcing at the narrow western end, diminishing constraint as the terrain opens to the east. The passive observer mapped that transition without anyone telling it where to look.
Atmospheric events.
The 100-day archive contains 43 documented atmospheric events: 21 split-column events where the boundary layer and upper atmosphere were moving in opposite directions, 11 shear events with elevated mid-level turbulence signatures, 3 probable mid-level shear zones independently verified against IGRA2 radiosonde data, and 2 rough days with elevated boundary layer turbulence indices.
The March 8th event is the clearest example. The system flagged elevated turbulence at both the boundary layer and mid level simultaneously — boundary layer kinematic turbulence index 12.1 knots, mid level index 19.6 knots. IGRA2 radiosonde data confirmed a low-level jet developing through the day with 52 degrees of directional shear within the boundary layer and speed shear at the boundary layer to mid level interface. The passive observer detected the event. Independent radiosonde data confirmed the mechanism.
A surface signal consistent with the Sudden Stratospheric Warming.
In early February 2026 a major Sudden Stratospheric Warming event occurred — the polar vortex split into two lobes around February 15th, confirmed by NOAA and multiple meteorological agencies. The observatory was running continuously through this entire period.
The archive shows what happened from the ground up. In late January the jet stream over Helena was running at an estimated 88 knots westerly — consistent with the pre-SSW pattern. In mid-February the system flagged a dramatic collapse: a 73% drop in the jet proxy falling to roughly 24 knots. February 18th through 22nd showed persistent Signal Lab anomalies with anomalous propagation events clustering to the SSE. February 23rd through 25th produced two PROBABLE mid-level turbulence events verified by radiosonde — mid-level shear zones consistent with a disorganized recovering jet. February 24th was the archive's strongest validated day: four independent internal proxies converging on a jet estimate of 139 knots, confirmed against ERA5 data.
To be precise about what this means: the observatory measures aircraft groundspeed residuals — it does not measure the stratosphere directly. The archive cannot independently confirm the SSW as the cause. What it can confirm is that a surface-level signal consistent with the timing and structure of a major SSW was real, measurable, and validated against ERA5 and radiosonde data. The passive observer caught it. The independent data confirmed the structure.
A $30 kit with a stock dipole, in a kitchen, in Helena Montana.
What Happened When I Went Outside
At about day 60 I started showing the work to people.
I walked into a flight school near KHLN airport. Introduced myself, explained what I'd been building. The owner sat with me for 45 minutes. He gave me an aviation weather handbook. That conversation — a working pilot engaging seriously with what a passive ground station was measuring — told me the methodology was asking the right questions even if I didn't have all the answers yet.
I sent a cold email to an atmospheric scientist. Dr. de Haan — who I later discovered is considered the godfather of this type of science — was working in a similar space but with a more direct approach. His methodology reads meteorological data from Mode-S transponder messages directly. Mine derives it from geometry. I found out he existed after I'd already built my own approach from scratch, which was a relief — it meant I wasn't crazy, just doing it the hard way. He replied that he would review the methodology. I'm still waiting. That's honest. The door is open.
Then something unexpected happened. In a Facebook group where I'd been sharing the work, a United States Air Force F-16 pilot read what I was doing and reached out. He had one question and two comments about the wind estimation methodology — questioning the TAS assumption across aircraft types, pushing back on the turbulence classification, and suggesting vertical velocity indicators as a potentially cleaner turbulence signal than groundspeed.
He wasn't wrong on any of it. The methodology got better.
An F-16 pilot giving aerodynamic feedback to a guy with a stock dipole antenna and a Linux box in Helena Montana. Under 90 days in.
I'm telling you this not to impress but because it matters for what the approach can become. These are people who would recognize if the methodology was nonsense. They engaged because the work was honest. The outputs were constrained within what the data could actually support. The failure modes were documented. The limitations were stated.
Honest work finds its audience.
The Bigger Picture
I want to say something carefully about what this could mean beyond my valley.
The Helena Valley Observatory is one station. One fixed location. One passive receiver. Its findings describe the atmosphere above a specific valley at a specific elevation between specific mountain ranges. They do not generalize without replication.
But the methodology generalizes. Anywhere aircraft fly, the reciprocal pair geometry works. The Flow Lab pipeline is documented and reproducible. The hardware is a $30 kit with a stock antenna and a Linux machine.
There are regions of the world with almost no upper-air atmospheric data — no radiosondes, no AMDAR coverage, no radar. Some of those regions have commercial aviation flying overhead every day. The aircraft are already doing the work. Someone just needs to listen.
I'm not claiming the Helena system is ready for operational use. The methodology needs more validation, more external review, more replication at other sites. The failure modes need to be fully characterized before anyone trusts the outputs for anything beyond research.
But the proof of concept exists. One person, one 1894 house, one $30 kit with a stock dipole antenna, and 100 days of honest science. Wind estimates inside the AMDAR accuracy range. A terrain channeling signature consistent with the physical geography. A surface signal consistent with a major stratospheric event, confirmed by independent data.
The floor of what's possible with this approach is higher than I expected when I made the bet.
How to Start
Minimum setup:
RTL-SDR Blog V4 kit
Stock dipole antenna (tuned to 1090MHz)
readsb for decoding
JSON logging at 5-second intervals
A Linux machine with ~50MB/day storage
30-day baseline:
200–300 aircraft per day depending on your location
Reciprocal track pairs accumulate naturally with traffic
Wind inference becomes possible on high-traffic days
Don't build the analysis pipeline yet — let the archive grow first
Validation (don't skip this):
ERA5 reanalysis — freely available from the Copernicus Climate Data Store
IGRA2 radiosonde data — nearest upper-air station to your location
The data has to be accountable to something outside itself
The honest timeline:
The methodology I built took 100 days to stabilize. The first version of the wind solver produced plausible-looking results that turned out to be wrong in ways I couldn't detect without external validation. ERA5 and IGRA2 cross-checking revealed failure modes I didn't know existed. The system got better by failing honestly and documenting the failures.
Every location is different. Every valley has different terrain, different traffic patterns, different failure modes. The Helena findings don't transfer to your site without your own 100 days.
Start simple. Log everything. Stay honest about what you know and what you don't. Let the archive earn its findings.
The aircraft are already up there. They've been flying over your house for decades. All you're doing is listening.
Carl Laufer and the RTL-SDR.com community — for building hardware worth building with, and for creating a platform where people share what they learn.
The atmospheric science community for making ERA5 and IGRA2 data publicly available. Cross-validation against real data is what separates science from wishful thinking.
Dr. de Haan for being willing to look at the work. The flight school owner in Helena who gave me the Aviation Weather handbook and 45 minutes of honest conversation. The F-16 pilot who read what I was doing in a Facebook group and sent feedback that made the methodology better.
And the aircraft. The thousands of pilots who fly over the Helena Valley every day without knowing someone in a 132-year-old house is listening.
Matt Larson Helena Valley Observatory Helena, Montana May 2026
The observatory runs on curiosity, Linux, and a $30 bet that turned out to be worth taking.
Over on GitHub, Martin (mgrone) recently released stream1090, a new open source C++ Mode-S demodulator that takes a fundamentally different approach to finding aircraft messages. Rather than searching for the traditional preamble pulse sequence as dump1090 and readsb do, stream1090 continuously maintains shift registers and identifies valid messages based on their CRC checksum. In busy airspace where preambles can be corrupted by overlapping signals, this approach theoretically cannot miss a message as long as the data itself is intact. Since the CRC is always being computed, it can also be used for single-bit error correction.
The software supports both RTL-SDR and Airspy dongles. It's lightweight enough to run on a Raspberry Pi Zero 2W. Stream1090 is a demodulator only, designed to pipe output into readsb or dump1090-fa via socat, slotting into your existing ADS-B stack as a drop-in replacement for the demodulation stage.
If you have an ADS-B station in a high-traffic area, let us know if Stream1090 increases your message rate! There is also a discussion about it on FlightAware, where many people have indicated that they are getting great results.
Over on his blog, cynicalGSD has written a detailed post about how he extended his home ADS-B flight tracking setup to also decode ACARS. His existing system runs an RTL-SDR dongle on a Raspberry Pi feeding a database and Flask web app. Adding ACARS required a second RTL-SDR and a separate VHF dipole antenna tuned for 129–131 MHz.
ACARS (Aircraft Communications Addressing and Reporting System) is a text-based datalink that has been in use since 1978, carrying short messages between aircraft and ground stations. It includes messages such as OOOI events (Out of gate, Off ground, On ground, Into gate), pilot weather reports, maintenance fault codes, and gate and fuel data. The key feature of their implementation is cross-referencing ACARS messages with existing ADS-B records via aircraft registration and ICAO hex address, enriching flight records with precise departure and arrival timestamps from the airline's own reporting system.
The full write-up covers the database schema, Python integration using acarsdec, gain tuning tips, and the Flask web interface. cynicalGSD mentions that the code is available for anyone interested, but we didn't see a link, so please comment on his post if you are interested.
Technical Summary of cynicalGSD's ACARS + ADS-B implementation.
Thank you to Cameron from BlackAtlas LLC for submitting their project GridDown, which is an open source Android tablet-based situational awareness system designed to operate without an internet connection. At its core, it appears to be a tablet with custom software, and then you can add sensors such as an RTL-SDR for ADS-B+Remote ID, a SARSAT receiver, and a Meshtastic ESP32-S3+SX1262 device. A demonstration of the UI can be found at https://griddown.blackatlas.tech.
Cameron writes:
[GridDown is] an offline-first situational awareness platform built for emergency preparedness, field response, and tactical operations in infrastructure-degraded environments — designed to work when cell towers are down, internet is unavailable, and operators are fully off-grid.
The platform is a Progressive Web App (~120,000 lines of vanilla JavaScript, no frameworks) that runs on Samsung Galaxy tablets, laptops/PCs, and works completely offline after initial setup. It's built by BlackAtlas LLC and is available for trial at https://griddown.blackatlas.tech.
The system has many facets to it, including:
Encrypted voice and text messaging via an ESP32-S3 with SX1262 LoRa transceiver
Passive RF sensing with the ESP32-S3 and SX1262.
Three passive drone detection methods: WiFi fingerprinting, FAA Remote ID reception, and 900 MHz control/telemetry link detection
Automatic gunshot detection via a ES7210 quad-channel I2S microphone on the ESP32-S3.
Automatic RF jamming detection
SARSAT beacon receiver
SSTV Encode/Decode
Meshtastic integration
APRS via Bluetooth TNC
ADS-B reception
RadioCode gamma spectrometer integration
Offline maps
ADS-B detection is handled by a Raspberry Pi 5 running an RTL-SDR Blog V4 dongle. Cameron writes:
The Pi connects to the tablet's built-in WiFi hotspot (no internet required — the hotspot functions as a local network only), and a Node.js bridge reads aircraft data from readsb and subscribes to the Remote ID receiver's MQTT output, then serves a unified WebSocket and REST API to the tablet. GridDown renders aircraft and drone tracks as heading-rotated silhouette icons on its offline map with altitude labels, age-based alpha fade, and emergency squawk alerting (7500/7600/7700). A 10,000 mAh USB-C PD battery provides approximately 5 hours of field runtime for the Pi.
The full setup script, hub bridge, and hotspot connection scripts ship with the project.
The software is dual-licensed, with it being open source GPL v3 (note that the GitHub link appears to be broken - we have asked for clarification) for non-commercial use, or a commercial licence for hardware bundles and business deployments.
Alternatively, BlackAtlas LLC is selling ready-to-use kits, with the core tablet coming in at $799. Other bundles include the Tablet + SARSAT receiver for $1,299, the Tablet + Meshtastic bundle for $1,299, and the Tablet + ADS-B/Remote ID bundle for $1,999.
ADSBee is an open-source project that has implemented a 1090 MHz ADS-B decoder on a Raspberry Pi RP2040 microcontroller using a programmable I/O (PIO) pin.
PIO pins cannot handle RF signals, so the ADSBee front end is a critical analog circuit that enables this to work. It consists of a 1090 MHz SAW filter to remove other signals, a low-noise amplifier, and, critically, a log-power detector, which essentially converts the pulse-position-modulated 1090 MHz ADS-B signal to baseband, which the PIO can handle.
However, this same trick does not work for 978 MHz UAT, as UAT signals are not pulse position modulation like ADS-B. Instead, for UAT support, the ADSBee design takes a more traditional approach, using a CC1312 sub-GHz transceiver chip connected to the RP2040.
Finally, an ESP32 S3 is added to the stack to enable networking via WiFi, allowing for received and decoded data to be used.
The project is entirely open source on their GitHub, apart from some of their commercial PCB designs. They also have a store, where they sell pre-made kits. A kit consisting of the ADSBee, 1090 MHz Antenna, and 978 MHz costs US$152in total. They are also selling an industrial model for $995, which includes PoE power.
Thank you to Kazuya for submitting an aircraft tracking app that he's created for use with RTL-SDR dongles and dump1090. The program currently exists only as Visual C++ code and is documented in Japanese, so it may be somewhat niche and intended for advanced users to try out. Kazuya writes:
I live near Tokyo Bay, so I enjoy watching the takeoffs and landings at Haneda Airport.
The unique feature of this app is that it visualizes the descent angle, which is difficult to see on a flat map.
This app has not been available for distribution. If you are an intermediate Visual C++ user, you may be able to rebuild or modify the app.
Topographical and landmark information is in text files, allowing you to customize area information in more detail for your airport.
----
(3) Glide_Path Can be built independently.
Execution Environment Copy the folder (ADS_GLIDE_PATH) to C:.
・When using an ADS antenna Install the ADSB antenna and driver software on your PC. (As a mid-way test, you will be able to listen to radio broadcasts on your PC.) Launch dump1090_with_StdinAPL1.bat to ensure that tmp_ADS_B-0000****.txt is continually generated in C:\ADS_GLIDE_PATH\tmpDataFolder.
- Without an ADSB antenna You can use the data in DemoData (approximately 30 minutes, 6,000 entries) to check the software's operation. (Procedure) Launch Glide_Path.exe and, on the parameter change screen, set [S001] Demo Mode to 1. Exit Glide_Path.exe and restart it. The Start Demo button will appear; press it.
(4) Stdin_Apl1 Can be built independently. This is an auxiliary program when using the ADS antenna described above in (3). Stdin_Apl1.exe This program parses the standard output of dump1090.exe, provided by the ADS antenna manufacturer, into a text file and processes the data so that it can be read by Glide_Path.exe.
In his latest YouTube video, Gabe from the saveitforparts channel has uploaded an interesting video detailing how he's tracking government spy planes over his neighbourhood using SDRs to monitor ADS-B data, and Orbic hotspots to detect Stingray activity (fake cell tower basestations).
In the video, Gabe highlights how he detects and follows a suspicious aircraft, concluding that it is most likely a DEA surveillance plane. This conclusion is supported by the fact that the ADS-B data is censored on FlightRadar24, something which normally only happens with law enforcement aircraft, as well as private jets. Upon zooming in on the aircraft with a camera, various antennas and cameras are also visible on the belly. Finally, Gabe found that the plane's registration number is linked to a Texas-based shell company with connections to the DEA.
In the video Gabe also tests out the RayHunter custom firmware for Orbic mobile internet to WiFi hotspot devices. This custom firmware turns these devices into Stingray detectors. A Stingray is a fake cellular base station that is often used by law enforcement to spy on cell phone activity.
Is That Really A Government Spy Plane Over My Neighborhood?