If you’ve ever heard the sound of an aircraft passing overhead and looked at an online plane tracker to try and figure out what it was, then you’ve interacted with ADS-B. It’s a protocol designed to enable easier aircraft monitoring, and it just so happens you can decode it yourself with the right hardware and software — which is how [John McNelly] came to develop ADSBee, an open source ADS-B receiver based around an RP2040.
ADS-B uses on–off keying (OOK) at 1 Mbps, and operates at 1090 MHz. This might seem like a rather difficult protocol to decode on a microcontroller, but the RP2040’s PIO is up to the task. All it takes is a bit of optimization, and a some basic RF components to amplify and digitize the signals.
However, not all aircraft utilize the 1090 MHz ADS-B implementation, and instead use a related protocol called UAT. Operating at 978 MHz, a second receiver is needed for decoding UAT traffic data, which is where the CC1312 comes into play. ADSBee may even be the first open source implementation of a UAT decoder!
What’s quite impressive is the various form factors the module is available in. Ranging from small solder-down modules to weatherproof outdoor base stations, nearly every potential need for an ADS-B receiver is covered. With POE or ESP32 S3 options available, there is no shortage of networking options either!
ADSBees have been placed in numerous locations, ranging from base stations to drones. One user even built out a tiny flight display cluster complete with traffic indicators into an FPV drone.
This isn’t the first time we have seen ADS-B receivers used by drone enthusiasts, but this is certainly the most feature rich and complete receiver we have come across.
A very expensive PCB for a single SDR purpose.
I feel like that might be missing the point. I’m a private pilot and built the raspberry pi system with two SDR receivers to do the same thing. It is significantly larger and requires a fairly large power bank to work reliably and for a few hours. This is significantly more compact, works seemingly out of the box, and very likely use this much less power than running an entire raspberry pi 3.
I feel like this is a fantastic project I would love to try out as an extra ADSB system to use with Avare
Agreed.
I’ve used my SDR to do ADS-B reception in the past for the heck of it. A BladeRf micro with the ADS-B firmware install, by comparison this dedicated board is a fraction of the price and purpose built.
In my past research I didn’t see too many decent reception setups using cheaper equipment; the cheapest SDR receivers and decoders weren’t particularly reliable with ADS-B, with particular hardware versions being more, or less capable of valid reception.
as a pilot, do the support channels, and liability issues / insurance come into play with stuff like this as well? (purchase and plug in, vs hacking together a stratux and dealing with that ball of string… they both need a screen of some sort too right?)
You can buy fully complete preassembled StratuX units if you want.
Both the StratuX and Garmin Stratus and other similar GPS/ADSB pucks are designed to be tethered to a tablet with an EFB app such as Foreflight, which serves as the display.
If there was an accident of some kind and they found that you were using a homebuilt GPS/ADS-B puck and they felt it contributed to the accident somehow, I could conceivably see that being a factor, but I’ve never heard of it ever coming up before. It would be quite a stretch to prove, I think. Especially since if you are in VFR you are always required to see and avoid anyways, and if you are IFR then ATC shares responsibility for traffic separation since you can’t see and avoid. Under no circumstances should your ADSB information be your sole method of traffic avoidance – although it is a handy tool. So even if your unit was completely borked, that would never absolve a pilot of the responsibility to avoid traffic using their Mk 1 eyeballs.
The only accident report I have ever seen that mentioned a Stratux was one where someone dropped a battery while loading the plane and then tossed it in the backseat under the canopy cover. It then caught fire.
In those circumstances where you are required to have ADSB equipment, you are only required to have the transmitter portion. The receiver and display is optional, and is used as a means of better orientation and awareness, not as a primary means of avoiding a collision.
As a glider pilot, I don’t have ADSB equipment, but I would love to have a receiver connected to my phone to increase my awareness of power aircraft. The glider community has a similar system in use called FLARM, unfortunately the protocol is proprietary. It is used much more in other countries than the US. I’ve been following the ADSBee project for a few months now, and I will almost certainly be getting one. I’ve played around with using SDR devices, they just draw way too much power to be very useful.
Check the OGN protocol, it’s very similar to flarm, but open. It’s quite popular in Europe.
With the lifetime FLARM update that was released there is now the v7 protocol that other devices are using. Look up Moshe Braners for of SoftRF.
Stratux is a well known project that has done open source 978 Mhz UAT for a long time, probably long before ADSBee.
The missing detail in this hack is how to get the TI CC1310/12 to decode UAT which it is not designed to do.
The UATradio for Stratux has a really neat backstory on how it came to be.
CC1312 rx’s the packet probably with a syncword indicator for the correct packet, then passes it to the rp2040 for the actual decoding
The Stratux UATradio is a TI CC1310 that does the full decoding on chip.
You can actually do UAT TX with this chipset.
Really it’s the first open source implementation of embedded UAT decoding (that I know of), using a TI RF MCU (CC1312). Other implementations have been on SDR’s using dump978, or on closed source firmware running on similar RF MCUs (CC1310, etc).
This project also has (as far as I know), the first open source dockerized build environment for the TI LPF2 SDK, which was not easy to put together. This frees up development from TI’s Code Composer Studio IDE and has a lot of neat perks like cloud CI and easier integration with code from other MCUs. This same build environment can be used for TI’s full range of LPF2 RF MCUs, so I’m excited to see people try things out.
I really like that it is fully open source, but unfortunately there is closed source application (ADS-B SPY – ADSB decoder) for the airspy mini/R2 (and RTL-SDR dongles) that will run circles around it at receiving squawk’s from airplanes. The downsides are that it is closed source, only available for a few OS’es (Windows, Linux) , limited architectures (x86_64, ARM64, ARMHF) and limited hardware (airspy mini and airspy R2) but the really big upside which is totally phenomenal is that it can detect and fully decode multiple overlapping squawks from multiple airplanes simultaneously (2, 3 and maybe even 4 planes at once depending on the dynamic range of the receiver) these would typically be discarded by most other software as being totally impossible to detect let alone decode.
I really wish the developer would open source their software, but they historically have had bad experiences with multiple really stupid people ignoring their licensing, copying and pasting their code, when they had no right to do so, claiming it as their own code and changing the license.
Something out there is better, so this sucks?!
No it does not, but with better software it could be improved. And being open source beats closed any day because people who may know more about how to tweak the algorithm used might decide to contribute. But there might not be enough processing power available in the chosen hardware implement the more complex processing required.
I wanted to know how this samples the radio — how does it differ from SDR? In my imagination, maybe it was using PIO to sample RF directly! But from the schematic posted on reddit, it is based on a “quadrature demodulator chip” — it basically is an SDR. The unique thing is that instead of sending the SDR’s output over USB to a host computer, it does all the protocol processing on an RP2040. But you still need some sort of host just to display the data, though I could imagine very simple solutions there as well esp since you can presumably re-flash it with custom firmware that might drive a little LCD.
I’m sure it has its uses but from my perspective, like toyzareus says, seems pricey compared to rtl sdr.
The 1090MHz portion is an RF power detector behind a pair of filters, which might be limiting in an area with lots of planes transmitting.
Oh! neato! I guess the schematic i found is for the UAT side
Here’s the schematic! https://github.com/CoolNamesAllTaken/adsbee/blob/main/kicad/adsbee_1090u/010250002-D_adsbee_1090u-schematic.pdf
On the 1090MHz side, it uses a discrete RF frontend with a log-amp architecture feeding into a data slicer, that puts digital pulses into the RP2040 for decoding via PIO (preamble detection and manchester decoding).
The 978MHz side is a TI RF MCU running a custom firmware for decoding 978MHz UAT (downlink and uplink messages).
The ADSBee is intended to work with an electronic flight bag display like an iPad running foreflight, but also has a bunch of data feed options that people have used to power all kinds of projects. The same device can send data to your iPad, or to a website like airplanes.live where its feed can be combined with those of hundreds of other devices. Data is also available locally over USB / UART for various embedded project use cases (cool LED displays, drone autopilots, etc).
If this could feed fr24 etc then it would be very cool. If only to get the Gold/Business account for free.
Indeed it can! It is quite a chunky docs website (in a good way the more docs the better). But it can feed aggregators.
FlightRadar24 has some tricky requirements for feeding (I think they need a VPN connection from the device that is feeding). Currently ADSBee only feeds open source exchanges like airplanes.live / adsb.lol / adsb.fi, or exchanges that can accept Mode S Beast over TCP as a feed format.
Nice project. I’ll be curious to see the BoM because it seems very expensive for what it is
Check out the schematic:
https://github.com/CoolNamesAllTaken/adsbee/blob/main/kicad/adsbee_1090/adsbee_1090.pdf
If you make a cheaper version, please let us know.
I’ve seen a few people who have made non SDR 1090 RX’s. The FPGA’s and filters needed are a bit pricey.
It seems well priced for what it is, but it’s functional competitor is an rpi0 (or even zero 2 W) and rtlsdr and compared to that it costs more for less.
Great to see open source! I fly with RTL-SDR hooked up to an android running Dump1090. Plenty sensitive to show traffic nearby which matters and sometimes up to 100 miles away. Something open source to feed into Aera moving map would be cat’s meow.
I saw this in Make magazine!
Please don’t actually attempt to use DIY radio equipment in the cockpit -it’s literally illegal.
What specific regulation are you referring to?
CFR.14.imadeitupentirely