ADSBee: Everything we made for low cost open source ADS-B in 2025
What a year it’s been! Sometimes I have a hard time believing just how much stuff gets crammed into 365 days, and Pants for Birds had an exceptional rate of year per year in 2025.
January: ADSBee added multi-core support, network improvements, and faster CRC decoding + correction.
February: ADSBee switched to a formally verified CPR position decoder, and we sold out of the original ADSBee 1090.
March: I went to Shenzhen and ADSBee rode a weather balloon! These were unrelated events.

April: We added a new lighweight dipole antenna to the store. Behind the scenes, I was panic-redoing the entire dual band ADSBee hardware design from scratch due to a dead end with a sub-GHz radio IC I had thrown quite a bit of time into. Simultaneously, all hell broke loose in hardware land with the beginning of the 2025 trade war and “reciprocal” tariffs.
May: We debuted a number of new hardware designs, including the dual band ADSBee 1090U, the ADSBee m1090 solder down module, ADSBee PoE pant, and a breakout board for the new ADSBee 1090U’s high density debug connector. We also introduced custom designed PCB antennas for 1090MHz and 978MHz!

June: ADSBee 1090U entered production, and the first PoE pant prototypes were brought up successfully (with a little bit of rework).

July: ADSBee went to Open Sauce! My friends and I met hundreds of very cool people, and a shoutout on Jeff Geerling’s second youtube channel introduced ADSBee to many people for the first time. We also built a functioning miniature cockpit display with ADSBee in collaboration with FPVToys.net, and introduced MLAT-grade timestamps with some cursed PIO + DMA hackery, enabling the ADSBee to be used as part of a receiver array that can track aircraft transponder locations via time of flight.

August: We introduced our weatherproof outdoor ADS-B receiver, the GS3M PoE, and also debuted our own ADS-B aggregator website for testing ADSBees, whereplane.xyz!


September: ADSBee attended Commercial UAV Expo in Las Vegas, where we won an award in their “Pitch the Press” competition for innovative products, and also exhibited at Bay Area Maker Faire! The ADSBee PoE pant also had its first production run, and we introduced the indoor PoE receiver bundle in the web shop. On the firmware side of things, UAT packets were added to Mode S Beast feeds via a custom packet format that was developed in collaboration with @wiedehopf, the maintainer of many popular open source software packages that are used by online ADSB aggregators.


October: We had some adventures in IPX5 testing for the GS3M PoE, and ADSBee was featured in Make Magazine! We also debuted the ADSBee m1090 eval board in the web store, allowing customers to easily prototype applications based on the m1090 module, and ran a new production run of ADSBee 1090U’s with a BOM revision that improved high temperature operation and enabled a lower input voltage to be used (great for battery powered applications).



November: I put a GS3M PoE on my roof, and it works great! We also debuted a firmware update that significantly retooled PIO preamble detector and demoulator performance and added filters for improving position tracking performance on UAT.


December: That’s this month!
This month, we’ve released firmware version 0.9.0-rc5, which includes some buffer safety improvements, some behind-the-scenes fixes to make programming ADSBee m1090 modules on the production line easier, and TIS-B / FIS-B forwarding over WiFi! If you have an Electronic Flight Bag (EFB) device with ForeFlight or a similar EFB app that can accept TIS-B / FIS-B data over GDL90, we would love to hear some test feedback, as these packets can be hard to capture unless you’re in range of a UAT uplink broadcast facility.
At long last, the GS3M PoE is in stock and shipping to customers! I’m very excited to see more of these going out into the field. If you’re in the market for an industrial weatherproof ADS-B receiver, the GS3M PoE will happily do the job.
* Begin David Attenborough Voice *

The young, unprogrammed ADSBee m1090 wanders across the workbench in search of data, but stops to investigate a new oddity. Some kind of new cavern has appeared, with shiny, round pogo pins that seem to beckon a closer look.
Chomp!

The m1090 is squeezed tight, and before it has a chance to wriggle free, is injected with a new firmware.
010250007A-20250409-030011 wakes up with a start. What a terrible dream. Did it used to be an unprogrammed RP2040? Without a serial number? What a crazy idea. No time to dwell on it–there’s a background whisper that has become a roar, and it needs to be listened to. Airplanes.

* End David Attenborough Voice *
With the completion of a cool custom test fixture, pre-programmed and tested ADSBee m1090 modules are now available! The initial batch of prototypes is just about sold out, but I am kicking off a domestic production run shortly that will make them more widely available. Once the current stock runs out, backorders should be filled within January.
If you’re interested in ordering more than a small handful of ADSBee m1090 modules, please get in touch with me for volume pricing! Price breaks at various volumes and production locations are available depending on your needs.
A small production run of m1090 Eval Boards was completed using a portion of the remaining m1090 prototypes, and is now available! If you’re looking to try out the ADSBee m1090 for your custom application, it’s got everything you need to poke and prod the module to your heart’s content (and hook up external development boards to extend the m1090’s functionality).
Evaluation board for the ADSBee m1090 module. PCBA includes m1090 module + external LNA only, does not include sub-GHz radio or ESP32.
5 in stock (can be backordered)
If you’re curious about what cursed wire ratsnest allows you to turn the m1090 Eval Board into a full-featured ADSBee 1090U (but in more pieces), take a look at the brand new ADSBee m1090 Eval Board datasheet!
I want to express my gratitude to everyone who has made this year a wonderful lap around the sun for the ADSBee project. It’s been extremely rewarding to hear from so many people who are excited about open source ADS-B, be it on Discord, in person at trade shows and events, or via email. I’m excited for what 2026 has in store!
This month’s update is hereby christened the update of “soon”, after all the stuff that is almost (but not quite) ready for primetime. Here’s what we’ve been up to this month!
After some final tweaks to the IP65 enclosure design, initial preorders for the GS3M PoE are on track to begin shipping this week!
I’ve had an early prototype of the GS3M PoE on my roof for a few weeks, and it’s been doing quite well with the standard set of 2.2dBi waterproof dipole antennas. I’ve seen ranges in excess of 150 nautical miles and over 100 aircraft tracked simultaneously, which isn’t bad considering that it’s on top of a single story house with some pretty substantial hills and structures in the surrounding area. Long coax cables really do stack up quite a lot of loss at the frequencies used for ADS-B (1090MHz / 978MHz), so putting the receiver right at the source like the GS3M PoE does provides quite a bit more flexibility for meeting antenna gain requirements.


I’m looking forward to seeing how GS3M PoE units fare in the field! If you pre-ordered a device, keep your eyes peeled for additional installation information (including tips about waterproofing cable runs) that will be posted and forwarded to you before your unit ships. New orders placed today are expected to ship by mid to late December.
Demand for the ADSBee m1090 Eval boards has temporarily outpaced my ability to assemble them, but we have another batch coming together in the next week or so. If you’d like to try out an ADSBee m1090 module, don’t hesitate to place a backorder! Units will be shipped in early to mid December.
Evaluation board for the ADSBee m1090 module. PCBA includes m1090 module + external LNA only, does not include sub-GHz radio or ESP32.
5 in stock (can be backordered)
ADSBee firmware 0.9.0-rc4 is currently live! The release notes bury the lede a bit on how much has improved since last month’s release candidates, since RC4 is a quick hotfix applied over RC3, where the real meat and potatoes were cooked.
I spent a solid week retooling much of the ADSBee’s preamble detector and demodulator architecture, and made some key improvements to both the PIO assembly performing demodulations (limitations on maximum clock skew, faster recovery time while matching preambles), and the overall PIO architecture (a whole extra high power preamble detector / demodulator state machine added to both the ADSBee 1090U and ADSBee 1090). Collectively, these improvements have created a moderate but noticeable improvement in valid packets received per second for a number of our beta testers, including fewer packets dropped at close range (this is where the extra high power preamble detector / demodulator pair helps out most).
In addition to the PIO improvements, firmware versions RC3/RC4 introduce a new position filter for TIS-B (Traffic Information Service – Broadcast) aircraft positions received via 978MHz. I originally operated under the assumption that TIS-B positions would be quite reliable, since they are generated from radar tracks received by FAA ground stations, but in practice these positions tend to jump around quite a bit, causing aircraft to “hop” around on local receiver maps fed by the ADSBee. This hopping issue was only relevant to maps being fed with decoded locations by the ADSBee, like Foreflight and Avare, and is not present in online receiver maps like whereplane.xyz or airplanes.live, since those maps use readsb as a backend, which receives raw packets instead of decoded locations and performs its own filtering.
Firmware versions RC3/RC4 fix this issue by implementing the same velocity-based position filter introduced way back in firmware version 0.7.4 (architecture originally designed by @error414), and adapting the filter to work with UAT formatted aircraft positions instead of Mode S formatted aircraft positions. From my testing, this has quite nicely solved the hopping issue, and aircraft tracks received via TIS-B over UAT are now displayed with consistent trajectory updates on local maps.
0.9.0 stable is still on the way! The original hope was to get it out the door in mid November, but some of the retooling for RC3/RC4 took longer than expected. The good news is that it should be ready this month. Here’s what’s left on the to-do list:
Stay tuned for one or more release candidates before the official stable dual band firmware release! 🎉
A new batch of ADSBee 1090U’s has arrived in stock, and is shipping now. These receivers have some slight tweaks compared to the last revision; one resistor value in the analog front-end has been adjusted for (theoretically) improved noise immunity, the eFuse used to power the PoE pant has been swapped for a jumper resistor (to enable powering the PoE pant without issue in hot environments like attics), and the LDO has been changed to a part that enables operation with as little as 3.7V on the 5V input. This makes the ADSBee 1090U suitable for use in projects where it’s being powered from a single cell LiPo battery (so a stable 5V may not always be available).

As of 2025-10-30, all ADSBee 1090U’s sold via the online store are shipping as Rev E. If you have an ADSBee 1090U Rev D, there’s no need to upgrade for the vast majority of applications. That said, it’s certainly possible to DIY an upgrade yourself with a hot air station / tweezers and some steady hands. I’m happy to provide part numbers if anyone wants to try it themselves!
The ADSBee m1090 is our solder-down 1090MHz receiver module for OEM applications. It has everything needed to decode 1090MHz ADS-B (minus one of the gain stages that the 1090U has), and can be coupled with an external TI CC1312 and ESP32 to add dual-band receive and WiFi functionality, respectively.

The first step in getting this module to production is building an evaluation board for developers to play around with. I’m happy to announce that said evaluation boards are now shipping! I’m assembling these boards by hand / with the assistance of a low cost pick and place machine, so they’re kind of expensive and are being added to the store in small batches as I keep up with demand. Design files for the PCB are available over Discord or email (just message me)! They’ll be publicly posted soon one things are more mature (I want to keep a tight line of communication with the first devs to use the ADSBee m1090 module).

Each m1090 Eval Board includes an ADSBee m1090 with USB C / SWD / boot / reset broken out, a 3.3V regulator, and an external Berex BLB01 LNA that can be enabled by rotating a pair of 0402 caps to put it inline with the the SMA connector. Enabling the external LNA enabled provides performance roughly on par with an ADSBee 1090U, while connecting directly to the m1090 provides performance more in line with what might be needed in an airborne application (on drones or manned aircraft).
All SPI and function pins are broken out to the edge of the m1090 eval PCB to enable connection of an external CC1312 development board or ESP32 devkit to enable Sub-GHz receive and WiFi functionality.
Evaluation board for the ADSBee m1090 module. PCBA includes m1090 module + external LNA only, does not include sub-GHz radio or ESP32.
5 in stock (can be backordered)
Some types of environmental tests require tens or hundreds of thousands of dollars of expensive equipment, highly trained technicians, and tightly controlled test environments. Other types of tests require some guy or gal with an expensive hose nozzle and an empty parking lot. As it turns out, IPX5 testing is the second kind of testing, and is a great candidate for some DIY reliability testing at home.
The first digit in an IP rating stands for the dust ingress protection level, and the second letter stands for the water ingress protection level. An IP65 rated design has a dust ingress protection level of 6 (dust-proof), and a water ingress protection level of 5 (robust to low-pressure water jets from any direction). If either digit is an X, it means that the corresponding protection level is not being tested or addressed in that particular rating; IP6X is a dust-only protection rating, and IPX5 is a water-only protection rating. Generally, an IP65 design can be qualified by performing an IPX5 test only, since if the enclosure is robust to low pressure water jets, it is considered dust-proof by default (water ingress is the harder test to pass).
There is a large quantity of IP65 test reports like this one available on the internet from various manufacturers showcasing the environmental ratings of their products. These test reports make it easy to discern the contents of the IEC 60529 standard that defines tests for ingress protection levels without needing to actually purchase the standard, which would normally run you a cool $663 at the ANSI webstore. There’s also a handy guide to IP ratings on the wikipedia page, with some numeric values that are helpful for calibrating equipment.
At the end of the day, the IP65 test boils down to spraying an enclosure with 12.5 L/min of water from a 6.3mm diameter hose nozzle operating at a pressure of 30kPa, from 3 meters away. The enclosure should be sprayed for at least 1 minute per square meter of enclosure area, for a minimum of three minutes (for small devices, this means being sprayed for 3 minutes; very large devices need additional time under the hose). This set of requirements is very specific, but can be easily achieved by purchasing a waterproof testing hose nozzle like this one and connecting it to a standard garden hose. Adjust the ball valve till the desired pressure and flow rate are reached, use a tape measure to space your device the proper distance away, and presto! IPX5 testing to your heart’s content.




IPX5 testing of the GS3M PoE enclosure did yield a few valuable insights! Waterproofing seals can be rather particular about their torque specs, and PEM standoffs, despite being molded directly into aluminum sheets by a hydraulic press, do not form a waterproof seal (PEM has a new series of studs and standoffs that are waterproof to IPX9K, but the studs aren’t common and the standoffs haven’t been released yet). Fortunately, a bit of RTV on the inside of an enclosure with PEM standoffs installed seems to do the trick.
For sensing whether water has entered an enclosure, I found water sensitive stickers to be very helpful. A pattern of water sensitive stickers around key ingress points would usually be enough to show what was entry point was leaking (as long as I didn’t shake the enclosure around too much after completing the test). An infrared camera was also somewhat useful for finding water ingress, since there was a noticeable temperature differential between the enclosure (room temperature) and the water (cold). Interestingly, the biggest issue with using a thermal camera was the reflectivity of the aluminum enclosure itself. On a thermal camera, the aluminum box looks like an infinite mirror cube, which can make it somewhat difficult to pinpoint a leak. For a more sensitive test, specialized colorimetric developer spray can be used to coat the inside of an enclosure with color changing paint (removeable) that turns green when exposed to water.


I’m happy to say that after a few tweaks, the GS3M PoE enclosure is passing IP65!
I’m delighted to announce that ADSBee was featured in Volume 95 of Make Magazine! Special thanks to our community members who contributed photos of their projects to the article. It’s a fun read, so I’ve attached a PDF of the proof I received (including a few typos that were fixed in the final edition). As the owner of a copy of Volume 95 of Make Magazine, I can say that it’s a very cool read–I recommend picking up a copy if you have the chance!

We’re still cooking on firmware version 0.9.0! As of the time of writing this blog post, firmware version 0.9.0-rc2 is live, with some cool usability improvements like colored text in the web terminal. There’s still a number of bug fixes and additional features in the pipeline for 0.9.0 stable, so stay tuned for the next few release candidates! We should have a stable dual band release by mid-November.

Many things happened! Here are some of the things that happened, presented with varying levels of detail:

The Pants for Birds team went to Commercial UAV Expo in Las Vegas at the beginning of the month. We had a booth in the “cheap seats” (also known as the startup pavilion), and made fast friends with our neighboring booths in between conversations with attendees. We were lucky to be placed in the same row as Superwake (a Canadian startup specializing in giant solar-assisted long-endurance fixed-wing UAVs) and DroneSpotter (a US startup building remote-ID receivers and data solutions), both of whom proved to be fascinating conversation partners and great friends. It’s always fun to see other young startups throwing their best ideas at the wall to see what sticks!
Outside the startup pavilion, the expo was composed of more established companies from around the commercial UAV space, selling everything from “questionably commercial” technologies like Controlled Receive Pattern Antenna (CRPA) units used by UAVs to dodge military GPS jamming, to drone delivery companies, to FAA certified manufacturers of $16k ADS-B receivers used in airport infrastructure.









The big buzz this year seemed to center around the FAA’s proposed Part 108 regulations for beyond-visual-line-of-sight drone operation, which are poised to play a big role in reshaping the commercial UAV industry in the coming years. Our timing in attending CUAV expo was quite fortuitous, as the upcoming regulations strongly imply that drones should have ADS-B In capability in order to autonomously yield to manned aircraft. As such, the level of industry interest in a low cost and open source ADS-B receiver option was quite high.
Beyond Part 108, there was a lot of interest in NDAA compliance and domestic supply chains for drone components. US manufacturing is on the upswing but has a long way to go in order to catch up. Remote ID is also a rapidly growing field of interest, with a number of companies racing to deploy receiver hardware and build centralized databases for the data they collect. I think it’s only a matter of time before we see an open source Remote ID data exchange similar to what we have in the open source ADS-B community. Right now, the primary parties interested in Remote ID reception are usually law enforcement entities, but I think this will rapidly expand to enthusiasts and commercial entities as drone delivery begins to expand. People will want to know “what’s in that drone that just flew by”, and analysis types will want to be able to pull insights from large datasets of drone information (e.g. how many food delivery flights were there, and from what restaurants?) Building distributed networks of Remote ID receivers will be quite a bit more complicated than building networks of ADS-B receivers, since Remote ID range is much more limited due to low transmit power and overlap with already congested WiFi bands, but receivers should theoretically be relatively easy to build since they rely on WiFi hardware that is already manufactured at scale.
As part of CUAV expo, we had applied to a competition called “Pitch the Press”, where we would have the chance to describe an innovative product to a few judges in hopes of getting included in a press release from CUAV expo. I was pleasantly surprised that my pitch about ADSBee made one of the top spots! We were awarded with a nice looking wood plaque, and a Very Serious Press Release that mentions Pants for Birds alongside other actual company names (seeing this happen is still one of my favorite parts of my job).

CUAV Expo was a fascinating opportunity to see what’s happening in the drone industry. Things are hopping, and it looks like the industry might finally be ready to capitalize on its potential. I think we’re finally getting to the “slope of enlightenment” on the Gartner Hype Cycle of Drones.

During the last weekend of the month, ADSBee went to Bay Area Maker Faire! As always it was a fun-filled event with lots of cool projects, art, and for some reason Steve Wozniak. It was a blast to meet people from the ADSBee discord server in real life–and we even got to meet some well known YouTubers who were attempting to explore the event incognito (with varying levels of success). If you stopped by the ADSBee booth for a friendly conversation, thank you!


The long-awaited PoE pant is back in stock and shipping now! Thanks for your patience as we brought up manufacturing for this part. The PoE pant is available individually or as part of a bundle that includes all the necessary parts for making an indoor dual-band PoE ADS-B Receiver.
Everything you need to set up an indoor PoE feeder!
17 in stock (can be backordered)
Friday 9/26 marked the release of firmware version 0.9.0-rc1, our first unstable release candidate for the 0.9.0 firmware! This is a major update that introduces dual-band receiver functionality with the addition of UAT downlink and uplink packet decoding, a new version of the CSBee protocol, the ability to feed any reporting protocol over TCP, and a good-sized pile of firmware improvements under the hood. If you’re feeling adventurous, please give the latest release candidate a try and report any bugs you encounter! We expect to go through at least a handful of release candidates before all features for 0.9.0 are implemented and fully ironed out.
Mode S Beast is a binary TCP protocol commonly used to feed open source exchanges with ADS-B data. As part of the 0.9.0 firmware, we are introducing a new packet format co-developed with @wiedehopf (maintainer of tar1090 and readsb) that improves the efficiency of sending UAT data over TCP.
Previously, UAT packets were converted to Mode S packets by each receiver for reporting using the Mode S Beast protocol, then converted back into UAT packets for use with the dump978 decoder protocol on the server side. With the new UAT packet format, receivers are able to report UAT ADSB and uplink packets directly using the format below (screenshotted from the most recent datasheet revision), preserving a significant amount of UAT data that might not otherwise be transported to the server intact while also reducing computational load on each receiver that is generating a feed.

This new packet format has already been rolled out to the popular ultrafeeder docker image (which is used to run whereplane.xyz), and should be added to adsb.im sometime in October. Additional exchanges will most likely adopt this new UAT packet format as they update their instance of readsb, although this will likely take a while. In the meantime, ADSBee devices have the option to feed with the BEAST_NO_UAT protocol, which sends Mode S packets only, to avoid causing any unhappiness upstream caused by encountering unexpected packet formats.
A special thanks to @wiedehopf for his efforts in co-designing this protocol and building / testing its server-side parser implementation!
See you on discord, and we’ll be back for next month’s update!
Happy September! Here’s what Mr. ADSBee and friends have been up to this past month.
The ADSBee team is at Commercial UAV Expo this week. Find us at booth 1212 (in the exhibitor list as “Pants for Birds LLC”). Hopefully I’ll have some cool photos and products to share in next month’s update (and maybe a few new customers).
ADSBee will be at Bay Area Maker Faire at Mare Island from September 26-28. We had a blast last year and are looking forward to seeing everyone again this year!

What a mouthful! The ADSBee GS3M PoE stands for ADSBee – Ground Station – 3 Band – Metal Enclosure – PoE. This device does exactly what it says on the tin! The ADSBee GS3M PoE is intended to be permanently installed in industrial or outdoor environments that need a PoE ADS-B receiver capable of operating in an IP65 environment between -20°C to +85°C. These environmental ratings are preliminary, pending thorough testing, but they’ve been used to dictate the electrical and mechanical design of the device.
The GS3M PoE comes with a 40x40mm M5 mounting grid on the back of its die cast aluminum enclosure. These mounting holes are created with weather-tight PEM studs recessed into the enclosure, and allow the GS3M PoE to be attached to a custom sheet-metal mounting bracket that can secure the receiver to poles / walls / horizontal struts / etc using either mounting bolts or adjustable pipe clamps.
The ADSBee GS3M PoE is still early on in its design and test cycle, but I’m excited to share more about the device as its design evolves. Under the hood, the GS3M uses ADSBee hardware and firmware, and I’m excited to bring one of the first tri-band Mode S / UAT / Remote ID receivers to market when the ADSBee eventually gets RemoteID in capability.
If you have a commercial application for the ADSBee GS3M PoE, I’d love to chat! Pricing and customization for this design is available by contacting me via Discord or email.

I’ve been hard at work getting PoE pants into production since they sold out after the initial prototype run, and I’m excited to say that a new batch is in the works! I expect production to be complete by mid-September, at which point parts will be made available in the store.
The stock of ADSBee 1090Us from the last production run is almost depleted! I expect to sell out of ADSBee 1090U’s pretty quickly in the next week or so, if Commercial UAV Expo goes well, and will be working on restocking as fast as possible. If you need an ADSBee for a project lickety split, now’s the time to grab one before they’re (temporarily) gone! I expect a brief out-of-stock period for a few weeks in the middle of September while the next batch enters production. Backorders will be enabled and orders will ship in the sequence they are received. If all goes well, we should be back up and running with ample stock levels before the end of September.

I finally got around to setting up a custom aggregator for ADSBees! Feel free to point a Mode S Beast feed from your ADSBee to feed.whereplane.xyz on port 30004. If you’d like to see traffic data gathered from the handful of ADSBees that are already feeding whereplane, hop on over to globe.whereplane.xyz.
Whereplane.xyz is intended to provide some basic benchmarking of ADSBee receiver performance and coverage, and isn’t intended to compete with serious exchanges like airplanes.live or others with tens of thousands of feeders. Future ADSBee firmware versions will have feed.whereplane.xyz as a feed URI that is enabled by default (it can always be turned off, of course). I’m excited to see new feeds pop up around the world as the project grows! So far we’ve already made it to 3 continents–which one will be next?
Dual band firmware with UAT reception is in progress and moving along well, but still needs some stability improvements and features before it can enter the release candidate process. Stay tuned to Discord for 0.9.0-rc1, the first version of the dual band firmware! There’s been quite a few changes requested by people since the original 0.8.2 firmware release, so I expect 0.9.0 to have quite a few major features and changes that will need testing. If you are using ADSBee in a high reliability application, I don’t recommend migrating off of 0.8.2 until we have a stable 0.9.0 release. On the other hand, if you want the latest and greatest and you’re down for some adventure, we’d love to have you along for the ride!
For one example of how deep this firmware update goes, I’ve completely overhauled the CSBee protocol to version 2, which now includes even more exhaustive information for each aircraft, including aircraft dimensions (transmitted while on the ground), both baro and GNSS altitudes and altitude rates for each aircraft (when available), and more. Version 2 of CSBee also adds UAT aircraft along with their custom flags and data fields (which differ in protocol and contents from those of Mode S aircraft). If you’re curious about what this looks like, I’ve attached a snippet of the new CSBee protocol section of the datasheet below!
Under the hood, deep structural changes to the firmware have made the ADSBee’s aircraft dictionary capable of holding and looking up multiple different types of aircraft with varied internal data structures. These upgrades mean that the ADSBee aircraft dictionary can be expanded relatively easily to include aircraft other than Mode S or UAT aircraft in the future, such as RemoteID drones, ADS-L emitters, and more. Stay tuned, this will be an exciting month in firmware land!
In this month’s loosely structured collection of words and punctuation:
Open Sauce was an absolute blast! A whole lot of fun (and not much sleep) was had. An absolutely worthwhile annual adventure.
This year at the Open Sauce booth, we brought:







To those of you who heard about the project for the first time at Open Sauce, and decided to tag along–welcome! We’re very happy to have you.
Also, we got a shoutout from Jeff Geerling! I highly recommend watching his vlogs from Open Sauce to get an idea of just how nuts the event was.
ADSBee 1090U Preorders are 100% shipped, and new orders are being fulfilled in 1-2 days! We’ve been sending packages across the US and across the world, and I’m excited for everyone to begin turning on their new receivers.
The ADSBee PoE Pant went live and has since sold out, but I’m working on getting more back in stock (the initial stock was a relatively small supply of prototypes–I’m gearing up for a proper manufacturing run this month). Fortunately, we still have an ample supply of ADSBee 1090Us and the necessary antennas to make things go, and I’m going to try my best to line up subsequent production runs such that we don’t encounter any unexpected stock shortages.
This month marked the release of firmware version 0.8.0 (and two subsequent patch releases, bringing the latest firmware version to 0.8.2). This new firmware update includes a hefty refactor of the SPI coprocessor communication system, providing vastly improved interprocessor communication reliability, and also makes a number of smaller usability improvements:
All new ADSBee 1090Us are currently shipping with firmware version 0.8.2. If you got an ADSBee 1090U from the beginning of the preorder batch, it may be flashed with 0.8.0 or 0.8.1–I recommend doing a quick firmware update before diving in!
If I seem a little bit excited about MLAT timestamps, it’s because I’m a LOT excited about MLAT timestamps! What I thought would be a quick bug fix turned into a massive week-long side quest (with excellent support from @wiedehopf). Long story short, ADSBee is now very good at counting time, with a resolution of just over 2 nanoseconds. This makes its timestamps accurate enough that they can be used to triangulate aircraft positions. Exciting!!

If you’re interested in learning more, or want to learn how the sausage is made, read on!
One of the lesser known uses of an ADS-B receiver is multi-lateration, or MLAT. Multiple receivers in different locations on the ground can receive a packet from an aircraft simultaneously. With knowledge of each receiver’s location, and a relative timestamp when each device received the packet from the aircraft, an MLAT server can determine the exact location of the aircraft when it transmitted the packet. This is quite useful in a number of scenarios, since not every packet that an aircraft transmits contains its location, and some aircraft don’t transmit their location at all (e.g. military aircraft). By synchronizing the reception of any valid Mode S packet transmitted by these aircraft, we can decipher their locations, and can often do so with higher resolution than we could with ADS-B locations alone, since ADS-B location normally only updates at around 2Hz, assuming every position packet is received successfully.
Thanks to the work of a number of open source contributors over the years, there exists a robust network of ground-based ADS-B receivers already being used for MLAT around the world. In order to join this MLAT receiver network, an ADS-B receiver needs to speak a specialized mlat-client protocol, and also needs to be able to provide a data stream of received packets with a associated relative timestamp for each packet. The relative timestamp takes the form of a 64-bit 12MHz counter value (ADSBee uses a 48Mhz counter, but this gets divided down to provide a 12MHz value to the MLAT server). Its absolute starting point (e.g. what time corresponds to a timer value of 0) is unimportant, since the MLAT server can “zero” the timestamp across multiple receivers when they receive a packet from the same aircraft. However, the counter must increment with consistent timing (ie. There can’t be any “jitter” in how long one tick of the timer takes), as this would defeat the receiver’s ability to accurately determine the range of an aircraft based on time of flight duration. This jitter requirement is rather strict; since the speed of light is 3e8 m/s, we can see that an uncertainty of 1us in the timestamp of a packet would lead to a range uncertainty of 1e-6 s * 3e8 m/s = 300 m! This kind of sensitivity to even the slightest timestamp uncertainty means that many of the simpler approaches to capturing a timestamp on an embedded device, such as using an interrupt to read a timer, are not workable solutions for capturing an MLAT timestamp. For instance, interrupts on the RP2040, even running directly from RAM, can have a timing uncertainty of around half a microsecond to multiple microseconds, depending on their priority and when they are triggered.

On the ADSBee, there were a few challenges encountered on the path to generating a 48MHz timer capable of capturing relative timestamps of incoming packets from the PIO peripheral with low jitter. The first was the challenge of synthesizing the timer itself. The RP2040 only has one 64-bit hardware timer, which is used for the global microsecond timebase. Given that this microsecond timer is used for all kinds of tasks throughout the code, it seemed unwise to repurpose it to run at a higher clock rate. Alternatively, there is a watchdog timer, which is also used by the firmware for important things, and a few other hardware timers which also lack the depth to capture a full 64-bit count. Fortunately, an ADSBee contributor (@gwoplock) noticed that the RP2040 has one unused SysTick timer per core, which includes a fractional clock divider that can be set to provide a custom clock rate. Earlier this year, with some debugging help from another contributor @wiedehopf (who also happens to be the maintainer for the most popular open-source ADS-B decoders and MLAT software), I was able to get this unused SysTick timer configured as a 48MHz counter with 24-bit width, and added an interrupt to count the number of timer wraps in order to fill in the remaining 40 bits required for a 64-bit timer. At 48MHz, a 24-bit timer doesn’t last very long, so wraps occur every 0.134 seconds or so—but by setting the interrupt priority of the timer wrap counter Interrupt Service Routine (ISR) to be higher than other interrupts, I can effectively avoid an interrupt reading the timer when it has a pending wrap that hasn’t been counted.
With the 48MHz counter synthesized via the SysTick timer and a custom ISR, the task of assigning a timestamp to each incoming decoded packet remained. I originally tried the smooth brain approach of simply reading the 48MHz counter inside the ISR that triggered at the beginning of a demodulation, when the preamble detector PIO kicks off its adjacent demodulator PIO state machine, but the jitter in this interrupt timing proved to be too severe. Minute timing variations of a fraction of a microsecond between the moment the preamble was detected to the moment the MLAT timer was read caused my timestamps to “jitter” by enough that the MLAT server was unable to get a good synchronization between my ADSBee test receivers and adjacent receivers in the same area (many thanks to @wiedehopf for helping me set up tests for this step)!
I knew that I needed some way to read the 48MHz MLAT counter in a deterministic manner that would not be affected by the variable latency of interrupt execution on the RP2040. Most web searches for similar questions regarding edge timing suggested using PIO blocks, but all of the PIO blocks on the RP2040 were already utilized as preamble detectors or demodulators or associated machinery. Other suggestions mentioned using DMA, but after some initial excitement I was disappointed to learn that the SysTick timer used for the 48MHz counter was specific to each processor core, and was not accessible to the DMA peripheral.
My thinking wandered to the PWM peripherals on the RP2040 that can be utilized as timers. On other families of microcontrollers, hardware timers can be used to capture the timing of a rising edge on GPIO. If I could repurpose a PWM peripheral as a timer that started counting the moment a message preamble was matched (by triggering on the same GPIO rising edge used to trigger a PIO demodulator), I could then read that timer value in my ISR that fired at the beginning of message demodulation to effectively de-jitter my 48MHz packet timestamp! The packet timestamp would just need to be the 48MHz counter value read in the ISR, minus the value of the PWM counter, which started counting up from 0 at 48Mhz when the demodulation interval began (and before the ISR had a chance to fire). The depth of a PWM timer was only 16 bits, but given that the demodulation begin ISR was expected to fire within a few microseconds of the timer beginning to count, I would not need to worry about overflow before the timer counter would be read.
Tragically, upon closer examination of the layout of the RP2040 PWM peripherals, I realized that I would not be able to assign a separate PWM timer to each of the GPIOs used for triggering demodulation PIOs. Each of the PWM timers has only a handful of pins that can be used as triggers, and adjacent pins are often assigned to the same PWM timer. The specific layout of the ADSBee PCB would require three adjacent pins to each trigger different PWM timers, which would sadly not be in the cards for the RP2040.
After this latest setback, I returned to the drawing board once again, and ended up with a harebrained scheme that quickly emerged as the only remaining viable option that I could think of. A 16-bit PWM timer counts continuously at 48MHz, and a DMA channel captures its value upon the beginning of a demodulation interval. This DMA channel is triggered via PIO using a FIFO pull command slotted into the demodulator state machine’s digital oversampling code, since it was the last remaining place I could fit an extra instruction in the PIO logic (only 32 instructions are allowed per PIO block, and I’ve used absolutely all of them). When the demodulation begin interrupt fires, the interrupt service routine reads the value of the same PWM timer, and then subtracts the value captured by the DMA channel in order to create a 16-bit “jitter correction” value. This jitter correction value is then subtracted from the value of the 48MHz MLAT timer, as read from within the demod begin ISR. Each of the three preamble detector / demodulator state machine pairs has its own DMA channel dedicated to capturing the PWM timer timestamp on demod begin, so no DMA PWM timer captures end up stepping on top of other PWM timer captures. Simultaneous execution of demod begin ISRs also isn’t an issue unless one ISR is stalled for longer than about 1.3ms (the time it takes the 16-bit PWM timer to roll over).
With some luck, it worked! Voila, 48Mhz de-jittered MLAT timestamps on the RP2040! No FPGA or continuous sampling code required.
I’m quite excited about the long-term prospects of utilizing 48MHz timestamps on the ADSBee for MLAT purposes. Using a higher frequency sampling clock than most SDRs (which timestamp around 12MHz) should in theory allow ADSBees to get better range accuracy, which in turn means that MLAT receiver arrays could be concentrated into smaller areas than might otherwise be required. I’m particularly interested in the possibilities around integrating MLAT timestamping with Pulse Per Second (PPS) and position outputs from GNSS receivers, which could allow clusters of ADSBees (fixed or on the move) to provide MLAT demodulation capability to a networked server receiving all of their datastreams. Cracking the high resolution, low-jitter timestamp problem opens a new horizon of possibilities for ADSBee, and I’m excited to see where the road goes next!
ADSBee can’t feed MLAT data on its own, because it’s (currently) too dumb to understand how to compress files in gzip format, a quirk of the JSON-based protocols that the open source MLAT servers use. In order to feed MLAT, you’ll want to spin up an ultrafeeder docker container and use that to run the actual mlat-client software. The side benefit of this is that you get a cool local tar1090 map, and can feed even more websites than you could with the ADSBee alone, without worrying about bogging down the ESP32. There’s an example docker compose here, but you’ll want to at least change the MLAT_USER field so that you don’t steal the UID of my test device.
UAT firmware is coming! It’s currently in development and should be released in the next few weeks. Join the discord if you’re interested in trying it first!
The ADSBee team will be at two more events this year!
Commercial UAV Expo (September 2-4, Las Vegas)
(Pssst, contact me on Discord if you want a free ticket to CUAV expo. They made me pay a lot of money but at least I can give out free tickets.)
In this month’s update:
ADSBee 1090U preorders have been open for a few weeks, and the manufacturing side of things is progressing well! First articles off the production line passed functional tests, and the full run of 100x receivers has been completed and delivered from the contract manufacturter. I’m working on a few updates to firmware along with design and manufacturing of some accessories like the 3D-printed dual band antenna case before these devices ship to customers. Devices are on track to ship in early July (sometime in the next week or two). Many thanks to those of you who have already ordered an ADSBee 1090U kit! I’m excited to get these receivers into your hands.




Here’s a case (a honeycomb? a hive?) of ADSBees waiting for functional test and shipping!


As noted in the product description and preorder announcement, ADSBee 1090U’s will ship with single-band receiver firmware, and full dual band capability will be enabled via a future firmware update. I’m doing everything I can to convince myself that the receiver hardware on the dual-band radio is rock solid before shipping out these devices, so that the dual-band firmware update goes smoothly. I expect to have dual-band packet receive functionality working before devices ship, but a fully polished dual band receiver implementation (with full decode and reporting capabilities) will take a bit of time to get right–and I’m excited to have the help of the community in testing those new features!
Thanks to some firmware tweaks that will be available in the upcoming 0.8.0 firmware release, operation over Ethernet using the ADSBee 1090 PoE Pant is reliable! If you are interested in purchasing a device from the prototype run, please shoot me an email or a discord message. I have a very limited quantity of boards available for users who would like to try them out, and will be working on setting up proper manufacturing for these PCBAs once the dust settles from the devices that are currently in flight (likely sometime in early August).
The photo below shows what the PoE pant looks like when it’s stacked onto an ADSBee 1090 (or 1090U). I’m working on a 3D printed enclosure that can fit the ADSBee 1090 PoE pant and mount the board stack with some proper standoffs. The ADSBee 1090 + PoE pant can be powered over PoE (as the name suggests), or via USB (shown below), if you want to run network comms over a non-PoE Ethernet cable.
For best performance, it’s recommended to disable the WiFi Station and WiFi Access Point functionalities on the ADSBee when using Ethernet, since the network stacks seem to like hogging the same parts of heap memory. It’s possible that this limitation could be removed in a future firmware revision with some additional optimization, but for now ADSBee 1090’s running Ethernet should be considered Ethernet-only network devices (UART / USB / etc still work fine).

I’ve been working on a significant firmware update for ADSBee 1090’s and 1090U’s this month. Firmware version 0.8.0 introduces a significant refactor of the coprocessor SPI bus driver at the heart of what makes ADSBee a multi-processor device, providing significantly improved communication bandwidth before processors and much smoother OTA updates (which place the coprocessor SPI bus under heavy load by transfering large firmware images between devices). This firmware update is currently on Release Candidate 5 in case you’d like to try it out–but I’m working on squeezing a few more small tweaks before making it official. Stay tuned for an announcement when the firmware is ready!
ADSBee will be at Open Sauce in San Mateo, CA from July 18-20th. If you are in the area, I’d love to meet you! We have a number of fun ADSBee-related projects and displays planned for the event, and I’ve once again ordered a truly ludicrous quantity of ADSBee stickers. There will also be a limited quantity of ADSBee 1090U receivers and accessories for sale, in case you desire the instant gratification of Purchasing a Good or Service from a Real Live Person (one of my favorite activities as a consumer). I hope to see you there!


Happy May! I’ve been working on pumping out some new hardware designs this month–let’s take a look at what’s cooking! Some of these are just about ready for release as a Real Product That You Can Buy, so keep your eyes peeled for preorder announcements in the coming weeks!
In this update:
The vast majority (something like >90%) of aircraft which transmit their location in-flight do so on 1090MHz via ADS-B. However, some aircraft like gliders transmit more specialized protocols on different frequencies (FLARM, 868 MHz/ 915MHz). In the United States, some general aviation aircraft transmit their location on 978MHz via a protocol called UAT. In many scenarios, the locations of these non-1090MHz aircraft are re-broadcast onto the standard 1090MHz frequency via repeaters (ADS-R, aka. ADS-B Rebroadcast), but these re-broadcasting stations are usually only present in regions with relatively high traffic density. For a fully self-contained receiver to provide complete situational awareness, it is obvious that a single-band solution may not be sufficient in all scenarios.
For the past few months, I’ve been working on a new generation of the ADSBee receiver design, which incorporates a sub-GHz radio for dual-band reception, with an initial performance target of receiving both 1090MHz ADS-B as well as 978MHz UAT. I’ve named it the ADSBee 1090U, where U originally stood for “UAT”, but has since evolved to stand for “Universal”, since the hardware may eventually target additional sub-GHz protocols like FLARM.
The second radio on the ADSBee 1090U can be tuned to a variety of frequencies, and has a built-in microcontroller that will allow message demodulation and decode to be fully self-contained. This compartmentalization of decode workload will reduce processor overhead for the RP2040 main processor, which may be busy with decoding the relatively high volume of messages on the 1090MHz standard frequency.


Getting a new (rather large) microcontroller to fit onto the same PCB footprint as the original ADSBee 1090 was quite difficult, but I’m happy to say that it looks like I pulled it off! Some of the debug connector footprints and test points needed to be consolidated to a 40-pin high density connector, but the overall developer experience is actually a bit nicer than on the original ADSBee 1090, since the high density debug connector gets connected to a dedicated rigid-flex breakout PCBA that provides a USB JTAG connector for the ESP32, dedicated SWD connectors for both the RP2040 and the sub-GHz radio, and 2.54mm pin headers that expose a number of important nets for easy poking with a logic analyzer.

The firmware for the sub-GHz radio is heavily work in progress, since there’s a number of moving parts involved in getting the sub-GHz radio firmware image compiled using the existing ADSBee toolchain + development workflow, baked into the RP2040 firmware image, and then flashed onto the sub-GHz radio over SPI using a custom bootloader software. I expect the ADSBee 1090U to ship with self-firmware flashing capability for the sub-GHz radio and basic validation of sub-GHz radio RF performance, but full-featured decoding of UAT messages will most likely be released as a series of firmware updates that can be applied to devices after they ship.
I’m happy to say that bringup of the latest revision of the ADSBee 1090U is proceeding well, and I expect to be able to open preorders within the next week or two. Stay tuned for an announcement via Discord and the email list!

I’ve received interest from a number of designers regarding building ADSBee into custom systems. I’m happy to say–I’m working on it! Things are still in the early stages, but here’s a sneak preview of a solder-down module that small-ifies the guts of the ADSBee 1090 (original single-band version) and turns it into a solder down module that requires zero external components to function, beyond an RF connector.
This module, called the ADSBee m1090, can be built directly into PCBAs like drone flight controllers, radio motherboards, and more! If you have an application where you think the ADSBee m1090 would be a good fit, please drop me an email or a Discord message. I have a few samples that will be available to send out to beta testers once I get my production test fixturing adapted to this new form factor.
Bringing Ethernet + PoE support to the ADSBee 1090 (and ADSBee 1090U) has been a long-standing ask from members of the ADSBee community. There is currently some partially-baked support for Ethernet connectivity built-into the ESP32 firmware of the ADSBee, but wiring up an external W5500 module can be a bit of a pain. I’m excited to say that progress is being made on the hardware side of things! I have a design for a PoE pant (like a hat, but on the other side) for the ADSBee 1090 and 1090U that will be getting prototyped and tested pretty soon. The PoE pant will be capable of providing both power and Ethernet connectivity to the ADSBee in a conveniently small form factor, which should allow miniature ADS-B receivers to be easily deployed just about anywhere you can run an Ethernet cable from a PoE equipped switch!

I’ve been working with a manufacturer to create custom-designed PCB antennas tuned specifically for mounting on foam or plastic surfaces. These antennas are much smaller and lighter than the existing 1090MHz collinear sleeve dipole antennas in the store, allowing them to be installed in a variety of locations. Using a PCB substrate for the antenna instead of a flexible printed circuit (FPC) substrate adds a little bit of weight, but makes the antenna much more robust against de-tuning from the dielectric constant of the surface that it’s mounted to, and helps the antenna keep its shape (and corresponding gain pattern) in situations where other antennas might be deformed.
Some potential good homes for these antennas would be on the inside of a plastic weatherproof enclosure for a fully self-contained receiver base station, or on an RC aircraft or quadcopter with an ADSBee installed or sense and avoid applications.
I have antennas on order in both 1090MHz and 978MHz form factors, and will add them to the store as soon as I receive them!

I’m excited to announce that I’ll be attending Commercial UAV Expo this year as an exhibitor! The event runs from September 2-4 in Las Vegas, and includes a wide variety of vendors specializing in just about every drone-related technology. I’m looking forward to sharing about ADS-B receivers, and maybe making a blog post about the event if I can find enough cool things to take pictures of (that part should be pretty easy).
If you’re planning on attending the expo, please drop me a line via Discord or email! I’d love to meet up and chat.
I’m pleased to present the following high level summary of progress made by engineering and operations staff at Pants for Birds LLC in the month of April. In fewer words, here’s what I’ve been up to this month!
We got in, again! If you haven’t heard about Open Sauce, I highly recommend checking it out. It’s a fantastic event filled with thousands of makers and sciencey types, showing off all the cool and ridiculous things they’ve been building just for the heck of it. We’d love to see you there!
Last year’s Open Sauce was the first time I debuted the ADSBee project at an in-person event. A substantial portion of y’all who are reading this update on the website or via the mailing list found out about ADSBee after passing by the booth last year, and I’m excited to see both new and familiar faces this time around.
This year will be bigger and better, with new hardware and some fun projects. If you have a fun project featuring an ADSBee you’d like to show off at Open Sauce, I’d love to hear from you (shoot me a message on Discord)! If the stars align, I may also have some new receiver hardware available for sale at the event.
I’ve received a limited quanitty of ultra-lightweight TBS crossfire-style dipole antennas tuned to 1090MHz that were designed and manufactured by a friend of the ADSBee project. If you’d like a lightweight antenna to install in your drone or other weight-sensitive ADSBee application, they’re in stock in the store now!

Weighing in at 0.8 grams, including the mass of 13 cm of OD1.13 coax, they’re hard to beat when it comes to weight! For best results, install them in a vertically polarized orientation, anchored to a low dielectric constant material (ie. mostly made of air) in a manner that the wires won’t get too bendy. For instance, taping the antenna to the vertical tail of a foam aircraft would probably work great.
I’ve been hard at work on an updated version of the receiver hardware, with the intention of supporting dual band reception for the USA and potentially other countries. Currently, ADSBee only supports 1090MHz Mode S, which is an international standard used by the majority of aircraft with transponders, but there are still some gaps in coverage like 978MHz UAT (a protocol used by some small aircraft in the US). I hope to have more details on this upcoming design soon! There is still some design / test iteration to be done on hacky prototype hardware, and the ongoing trade war has made manufacturing a bit of a mess at the moment. I hope to have more details to share shortly, either in next month’s update or earlier!