If you are a fan of aviation and software-defined radio (SDR), chances are you've played around with tracking airplanes using ADS-B (Automatic Dependent Surveillance-Broadcast). We usually do this by building receivers to listen to the sky. But what if you wanted to test your receivers, understand the protocol deeply, or simulate fake flight paths in an RF-shielded lab?
Enter adsb-tx—an open-source, Rust-based ADS-B signal generator and transmitter built specifically for the HackRF One SDR.
CRUCIAL DISCLAIMER: Transmitting on 1090 MHz (the standard ADS-B frequency) is illegal in most countries without proper aviation authorization. This tool is intended strictly for educational and research purposes. Always use an RF-shielded environment or test on non-aviation ISM bands (like 433 MHz) with low gain.
Why Rust + HackRF?
Software-defined radio demands high performance, especially when generating baseband signals at millions of samples per second (2 Msps in this case). Rust provides the perfect blend of memory safety, speed, and modern tooling to handle raw bit manipulation, fast CRC calculations, and signal modulation without the typical C/C++ memory headaches.
Core Features
The adsb-tx tool isn't just a basic static signal spoofer. It is a full-featured CLI application designed to generate Mode S extended squitter (DF17) messages:
- Multiple Message Types: Generates Aircraft ID, Airborne Position, and Airborne Velocity messages.
- Proper CPR Encoding: It handles the complex Compact Position Reporting (CPR) algorithm natively, dispatching both even and odd position frames so receivers can lock onto an accurate global position.
- Flight Simulation: You can input a starting coordinate, altitude, speed, and heading, and the tool will simulate a moving aircraft over time, continuously updating its broadcasted coordinates.
-
Flexible Outputs: Not near your HackRF? You can output the raw binary signal directly to a file (
.bin) orstdoutfor analysis with other tools.
Under the Hood: Technical Details
If you love RF engineering and protocol design, the architecture of adsb-tx is quite elegant:
- Message Formatting: Creates 112-bit DF17 Mode S messages using a custom 24-bit CRC matching the aviation specification.
- Modulation Scheme: Uses On-Off Keying (OOK) at 2 Msps.
- Encoding: Implements Manchester encoding for the data bits, prepended by the standard ADS-B preamble (
0xA1 0x40).
The codebase is split beautifully into modules handling CLI parsing, encoding, modulation, CRC, and flight simulation, making it a great codebase to study if you want to learn how RF signals are constructed in software.
Getting Started
Assuming you have a Rust toolchain and the HackRF tools (hackrf_transfer) installed on your system, getting this running is trivial.
git clone https://github.com/ktauchathuranga/adsb-tx.git
cd adsb-tx
cargo build --release
Transmitting a Single Message
You can transmit a single stationary airborne position on a safe testing frequency (e.g., 433 MHz):
./target/release/adsb-tx single \
--icao 0x4B1A2B \
--msg-type pos \
--lat 7.0 --lon 80.0 --alt 35000 \
--freq 433000000 \
--tx-gain 0 \
--repeat 100
Simulating a Flight Path
Want to watch a plane fly across your decoder screen? Use the simulate subcommand. The tool will calculate the trajectory and emit dynamically updating position frames:
./target/release/adsb-tx simulate \
--icao 0x4B1A2B \
--callsign NOCATS \
--start-lat 7.0 \
--start-lon 80.0 \
--alt 35000 \
--speed 450 \
--heading 90 \
--duration 60 \
--update-interval 1000 \
--freq 433000000 \
--tx-gain 0
Testing Your Transmissions
If you want to verify your signals, you can loop this back into an RTL-SDR or another HackRF tuned to your test frequency using decoding tools like dump1090, SDRangel, or the author's own Rust-based adsb decoder.
Final Thoughts
The adsb-tx repository is an awesome example of using modern languages to tackle traditional RF problems. Whether you are exploring SDR for the first time, studying aviation telemetry protocols, or looking for a cool Rust side project to read through, I highly recommend checking out this repository.
Link to repo: https://github.com/ktauchathuranga/adsb-tx
Drop a star on the repo if you find it useful, and let me know in the comments what kind of SDR projects you're building!
Top comments (1)
Great breakdown of the three memory types -- the episodic/semantic/procedural taxonomy maps cleanly onto how long-term agent systems actually behave in practice.
The hybrid search approach (dense embeddings + keyword via RRF) is something I've seen underappreciated in the agent memory space. Pure vector search breaks down exactly when you need it most: precise recall of specific identifiers (order IDs, model names, timestamps). RRF gives you the best of both without a separate full-text index service -- nice to see Oracle doing this natively.
A few things I'm still thinking through after reading this:
On the ONNX in-DB embedding approach: Computing embeddings at insert time inside the database is elegant for consistency, but what happens when you swap embedding models? You'd need to re-embed everything already stored. Is there a versioning story here, or do you basically treat it as a hard migration?
On procedural memory via tool call history: This is the part most frameworks get wrong. Storing which tools were called is useful, but the harder problem is storing why they were called -- the agent's internal rationale. Have you experimented with also persisting the chain-of-thought or the intermediate reasoning step that triggered a tool call? It would make debugging agent failures much more actionable.
On scale/deployment assumptions: This setup assumes reliable cloud connectivity, which works well for cloud-native agents. But I've been working on a different constraint: robots and edge devices that need agent memory to work offline-first. The moment you have intermittent connectivity, a Spring AI + Oracle architecture needs a local persistence fallback. For those scenarios, I've been using moteDB (an embedded Rust database designed for embodied AI), which lets the agent maintain its memory layers locally and sync when connectivity is restored.
What's the failure mode when Oracle DB is unreachable mid-conversation? Does the agent degrade gracefully, or does it error out?