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.
The first panel of ADSBee 1090U’s (one was removed for testing).Testing sub-GHz radio input impedance (tuned to UAT frequency).Testing packet capture with 1090Mhz receiver.
Testing RF frontend gain on 1090MHz receiver.
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!
🩳 ADSBee PoE Pant is working!
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).
💽 Firmware Version 0.8.0
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!
🤖 See you at Open Sauce!
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:
Hardware
ADSBee 1090U
ADSBee m1090
ADSBee PoE Pant
PCB antennas for 1090MHz and 978Mhz
Event announcement: Commercial UAV Expo
🔧 Hardware Updates
👀 ADSBee 1090U is (almost) here!
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!
🐁 Like ADSBee 1090, but small
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.
🔌 PoE? PoE!
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!
📶 PCB Antennas
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!
🎮 New Event: Commercial UAV Expo!
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!
🤖 ADSBee will be at Open Sauce!
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.
📶 New Ultra-Lightweight Dipole Antenna In Stock
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.
🤫 New Hardware is on the way (slowly)
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!
I’m writing this update from the Hong Kong airport on a rapidly depleting laptop battery, so it’ll be a little hastier than usual!
🌱 ADSBee in the Field
Testing of ADSBee 1090 in various ground and air-based applications continues! If you’ve ever wondered what ADS-B looks like from 4500ft, here’s a nice screenshot from one of our beta testers. 🎈
🔧 Firmware News
🏁 Release Candidate System
Beginning with firmware 0.7.5, pre-release versions of the firmware will be published as “release candidates”. This will allow more uniform testing of new firmware versions across the community, instead of ye olde “download this binary from a random hotfix branch’s CI pipeline output”. If you’d like to get in on the action, you can get started by trying out 0.7.5 release candidate 3 (0.7.5-rc3 for short)!
Starting in firmware version 0.7.5, firmware version provided by the AT+DEVICE_INFO command, and displayed in the web console, will reflect both the semantic version of the firmware (e.g. 0.7.5), as well as the release candidate (e.g. rc3). If no release candidate is provided, the firmware version is a stable release.
Please note that running release candidates is only recommended for testers who are interested in helping find bugs while trying out the latest and greatest features! If you’re using ADSBee for something important, or don’t want to deal with the headache of unexpected behaviors, I recommend sticking with stable releases.
🐛 Bug Alert: Firmware 0.7.4
Firmware 0.7.4, released last month, contains a number of usability fixes for MAVLINK, but breaks the webpage serial console. This bug snuck past testing, since this release was primarily intended to address features used by local (e.g. USB / serial) consumers of ADSBee aircraft data. If you’re using ADSBee to feed a online exchange, or otherwise interacting with an ADSBee using the web console, it’s recommended to revert to firmware version 0.7.3 for the time being.
🚧 Under Construction: Firmware 0.7.5
Firmware 0.7.5 is in active development, and will fix a laundry list of issues that have been discovered in firmware 0.7.4 (including the network console bug). It’s also slated to introduce some major new features, which I’ll dive into with more depth once it’s released. For now, here’s a high level overview of what’s happening in the latest PR as well as those that have already been merged this month:
Adds a real-time position filter that rejects invalid locations decoded from valid CPR packets. This is a relatively rare occurrence, but very occasionally results in single-sample invalid aircraft positions, since the current receiver firmware does not apply any filter to aircraft locations based on velocity or previously known location. Implementing this feature in a performant manner was somewhat difficult, as the RP2040 does not have an FPU, and calculating distances between points on Earth requires some yucky trig functions and floating point math. My current solution involves some rather large custom-generated fixed point haversine and arcsine or square root lookup tables, as well as a small amount of floating point math. These functions add about 20-30us of latency to the ingestion of decoded position packets, which should work fine for most applications (not_great_not_terrible.jpg), but I’m still looking for ways to make it faster! Many thanks to @error414 for his original discovery of this bug, as well as his clever position filter implementation!
Reworks packet received timestamps to properly advance with a 48MHz clock instead of the 125MHz CPU clock (thanks to @wiedehopf for pointing out this issue and suggesting the fix). Work is ongoing to improve timestamp jitter, as ADSBees currently have too much clock jitter to be used properly as MLAT receivers.
Support for future hardware iterations that will not include EEPROM (settings stored in flash).
Support for future hardware iterations that include a UAT receiver.
If you’d like to help test things out, take a look at 0.7.5-rc3 and post about bugs on Discord!
⚙️ Hardware News
🥲 New hardware when?
The ADSBee store has been sitting empty for a few weeks since the original hardware batch sold out. Rest assured, a new batch is in the works! The new production batch will feature a quantity of receivers with dual-band hardware, and I’m still sorting out the details of making sure the prototype hardware is working right. Sit tight for a formal announcement soonish! We should be on track to kick off production once any tweaks from bringup of the hardware prototypes are integrated into the new design.
🏬💻 Huaqiangbei is lit 🔥
I went to China for the last two weeks of the month to catch up with family, visit some contract manufacturers, and check out the electronics markets in Huaqiangbei, Shenzhen. I’ve heard people bemoan the decline of the electronics markets in Shenzhen over the past few years, and always wanted to visit there myself to see what the markets are like.
I can say, unequivocally, that the electronics markets are still kicking, and absolutely awesome! With my grade school level Mandarin, I was able to haul home, at great prices (I swear that it would have been financially insane not to buy all of this):
Numerous reels of 0402 and 0201 resistors and capacitors.
A partial reel of log power detector ICs.
A vibratory screw feeder.
A torque-limited screw gun.
A custom designed two-part EMI shield can (including custom sheet metal stamp tooling).
A spot welder.
A preheater hotplate for PCBA rework.
Custom made RF cables.
0201 resistor and capacitor sample books.
More stuff I’ve inevitably forgotten about until I dig through my giant duffel bag tomorrow.
If you ever have a chance to visit the markets, and you like hardware, and you know someone who has some ability to converse in Mandarin, I can absolutely 1000% strongly recommend the trip. It was like being a kid in an infinite candy shop!
I think that my experience at the electronics markets was best encapsulated by my first interaction with a vendor there, who happened to sell RF cables. I pointed to a weird looking SMA to dual OD1.13 U.FL cable splitter and asked the vendor if they were in stock. She replied that they had to be custom ordered, and she didn’t have any available. I asked what the lead time was, expecting it to be a few weeks (if I was lucky, maybe it was a few days and I’d be able to pick up samples before I left). She replied “20 minutes”. I placed the order and a small army of helpers appeared in the rear of the booth and began assembling and soldering 10 sets of custom cables. I walked away with 10 custom made RF splitter cable samples, for the price of 50 yuan (about $7 USD).
Anyways, enjoy the pictures! If you are planning on visiting the electronics markets, and want some pointers for good vendors that I found, shoot me a message on discord. I now have a ream of WeChat contacts with names like “<indiscernible Chinese character> Very Nice Resistor Lady” (English label added by me) and I’d be more than happy to share them with people.
A picture of the booths on one floor (of 4ish) in one of multiple buildings devoted exclusively to mobile phone parts.Smartphone chips a la carte.Ground level floor of one of the electronic component buildings. The booths at ground level tended to be smaller and piled higher with parts in some of the Huaqiang Electronics World buildings.Upper floor booths tended to be larger, with some having back rooms for stock. Foot traffic was generally lower, and the floor was less chaotic. Doing business with these booths would inevitably result in them inviting me in for tea (yes please) or a smoke (no thanks).A map of a single floor in one sub-building at Huaqiang electronics world.Now, multiply that map by 7. Then, multiply that by 5 (for separate sub-buildings), then multiply that again for the other electronics markets on the same street!A mobile phone repair tool both.My favorite tool booth in the SEG electronics building. Never have I seen such a handsome collection of electronics tools in such a small space. This booth had oscilloscopes, power supplies, a line of fluke stuff, thermal cameras, a full spread of microscopes, a full corner of Quick hot air stations, vibratory screw feeders (multiple models), screw guns (multiple models and torques), crimpers, hand tools, spot welders, etc…and a very friendly shop owner to boot!A shop that sells only reflow ovens (including the giant conveyor belt models).
Ok, we’re a little late on this one, but who knows how many days there are in February, anways?
February marked the release of some major improvements to the ADSBee 1090 firmware, and a key milestone for the project. Here’s what’s changed!
Firmware Version 0.7.3
CPR Decoder and Message Demodulation Fixes
Firmware version 0.7.3 re-implemented the Compact Position Reporting (CPR) decoder algorithm used by the ADSBee 1090 to use a formally verified CPR decoder provided by NASA, providing much better position decode accuracy than the previous custom solution. According to beta testers, instances of aircraft with poor signal quality “jumping around” on the map due to incorrectly decoded position message sequences are greatly reduced.
An aside: in these days of unprecedented government “efficiency,” I’d like to express my sincere gratitude to civil servants who make contributions to infrastructure that benefits us all. The researchers at NASA Langley who put the time and effort into writing and formally verifying a CPR decoder, and then releasing it as an open source tool for the world, have made a material contribution to the safety and efficacy of the ADSBee project and a number of other (very important) projects that use the same codebase to make the skies a little bit safer all around the world. If you’d like to drop a token in their bucket, consider giving their github repo a star (as of writing, it only has 13), or send their NASA contact (Cesar Munoz, cesar.a.munoz@nasa.gov) an email to let him know that his team’s work is appreciated.
Another major improvement to receiver performance in the 0.7.3 update was the fixing of a message demodulation bug caused by the message demodulator PIO state machine failing to halt at the end of a message. This caused the last word of received transponder messages to often end up garbled, greatly reducing the valid message receive rate. With some careful changes to the interactions between the PIO preamble detector and demodulator state machines, the demodulators are now halting properly and valid message decode rates are way up! ADSBee is now consistently outperforming unfiltered SDR-based ADSB receivers (like the RTL-SDR v3) and competitor FPGA-based receivers (Aerobits TT-SC1) in receive range, and aircraft tracks are much smoother than in previous firmware releases.
ADSBee 1090 receiving from an antenna in my attic.RTL-SDR v3 receiving from the same antenna, on a power splitter with the ADSBee.
MAVLINK Debugging and Field Testing
Firmware version 0.7.3 also introduced a host of compatibility fixes for working with various platforms that communicate with MAVLINK, including iNAV, mwptools, and QGroundControl. Many thanks to our dedicated beta testers, who worked through bugs ranging from intermittent ADSBee crashes (caused by ingesting unexpected binary data and overflowing some buffers) to issues with other applications’ MAVLINK decoder implementations. As a result of their many hours of testing and helpful feedback, ADSBee is working well with MAVLINK interfaces of all types!
ADSBee installed in a Heewing VTOL for winter flight testing. A+ sticker placement! Photo credit to @error414 on Discord.
Some of our beta testers have installed ADSBee 1090’s into remote-controlled aircraft of various sizes in order to enhance situational awareness and aid in avoiding areas where full-scale aircraft are operating. I’ve loved seeing the various creative builds, including some modifications to the included 1090MHz coaxial sleeve dipole antenna to reduce weight. We will hopefully have some lighter weight 1090MHz antennas in stock soon!
ADSBee 1090 installed in a fixed wing UAV. Photo credit to @error414 on Discord.Some clever hacks to reduce the mass of the 1090MHz coaxial sleeve dipole included in the beta kit. Photo credit to @error414 on Discord.
Additional Stability Improvements
Firmware version 0.7.3 also introduced a host of additional stability improvements to the firmware. This update fixed some bugs that previously made the ADSBee incompatible with software like PyPi (hilariously, PyPi was opening USB ports with a default baud rate that matched the magic baud rate used by the RP2040 to initiate a reboot automatically), and also fixed a number of bugs that were in 0.7.2 with the addition of multicore processing. The full list of changes is too long to describe here, so please feel free to check out the release notes if you’re interested!
Firmware Update 0.7.4
Firmware update 0.7.4 is a much smaller update than 0.7.3, and mostly cleans up a few loose ends with MAVLINK reporting (a few additional flags were missing from 0.7.3, and weren’t noticed without additional testing). This update also increases the maximum allowable callsign length to 8 characters, and stops removing trailing spaces from aircraft callsigns.
An interesting aside on aircraft callsigns: rules dicatate that aircraft can only use a maximum of 7 characters in their callsign (e.g. SWA1162), but the callsign field in ADS-B messages is actually 8 characters long. While the vast majority of aircraft do in fact have 7 character callsigns, some ground vehicles, ground obstacles, transponders being tested, and a few other edge cases do regularly utilize 8 characters in their callsigns. Now, ADSBee should be able to receive those messages as well!
ADSBee 1090 Beta Kits Sold Out (For Now)!
Thanks to our enthusiastic beta testers, we’ve reached the end of our original stock of ADSBee 1090 beta units! There may be some small quantities of additional units available if devices get released from rework or testing, but all units from the initial beta batch have happily found their homes. The data that we’ve gathered during this first phase of the project has been invaluable for improving the firmware and guiding future revisions of the design. Firmware updates will continue to be released regularly, and we have a new generation of hardware making its way down the pipe. Stay tuned for what’s next!
Happy January! This month’s progress on the ADSBee project included a number of impactful firmware updates that added features requested by the community and fixed some important bugs. As of firmware version 0.7.2, here’s what I’ve been cooking!
One of the top requests from our beta testers was the ability to download and restore settings from an ADSBee, allowing devices to be cloned and also allowing settings to be restored after a firmware update.
Most firmware updates don’t overwrite device settings, but some major updates (like transitioning from 0.6.X to 0.7.X) do make changes to the settings schema, meaning that feed settings and WiFi network information need to be re-configured after the firmware is upgraded. The new settings download and restore features turn this into a two-click operation!
There was some amount of debate about how best to implement settings download and restore functionality, but I eventually settled on using the existing AT command interface since it’s the most stable and backward-compatible control interface for the ADSBee. Sending all control commands (including USB console, Web Console, and remote script interaction) through a single command interface makes adding new features much easier, and reduces the risk for differing behaviors between interfaces.
Fortunately for me, utilizing the AT command interface in this manner made implementing settings download and restore features quite straightforward. Hitting the “download settings” button triggers a new AT command called AT+SETTINGS?DUMP, which prints all of the current device settings to the console in AT command format. This output gets captured by the javascript on the Web UI webpage, which saves it as a .settings text file. Clicking the “Restore Settings” button prompts the user to upload a .settings text file, and then applies the AT commands within that file to the ADSBee via the web console.
NOTE: Currently, restoring settings from a .settings file requires a user to manually run AT+SETTINGS=SAVE afterwards to make the new settings persist. This will be patched in a future update so that restored settings are persisted between reboots automatically.
Web UI now includes buttons for downloading and restoring ADSBee settings.Downloaded settings come in the form of a .txt file with AT commands.
🛜 Hostnames and mDNS Support
ADSBee receivers can now set their own network hostname with the AT+HOSTNAME command! This is very useful if you have multiple ADSBees on your network that you’d like to differentiate (without remembering serial numbers), or if you just want a convenient way to find the Web UI of your ADSBee without bookmarking an IP address.
In order to allow users to visit ADSBee web UIs at <hostname>.local, mDNS services have been added to the ADSBee firmware, so ADSBees can self-report their hostnames to other devices on the same network.
mDNS hostnames for other devices can also be used as feed endpoints! For instance, I have a readsb docker image on my laptop that I use to test the Mode S Beast output, and the hostname of the laptop is bird-book-pro.local. Instead of fishing around for my IP address to use as a feed endpoint, I can set the feed URI using the hostname for a slightly less fussy experience.
Example of accessing an ADSBee using its mDNS hostname.Example of feeding an mDNS hostname with an ADSBee.
🏓 Table-Based CRC
Previous implementations of CRC calculation for ADS-B and Mode S packets on ADSBee utilized an algorithmic technique that involved a number of repeated calculations. As of firmware 0.7.2, ADSBee calculates checksums using a pre-calculated table stored in flash memory, allowing checksums to be computed much faster and saving valuable processor cycles for more interesting things.
The CRC lookup table is essentially a 256-word array, with each word corresponding to a possible CRC Byte value as a processor is walking along a message. Instead of performing a rolling CRC on the message at every bit index, the processor can instead feed a full Byte of the message (along with some other info) into the CRC table and receive the pre-computed CRC value in return. Bits to Bytes, that’s roughly an 8x speedup!
Here’s what a 24-bit CRC table looks like.
If you’re interested in poking around or making your own table-based CRC calculator, the pre-calculated tables, interface code, as well as the Python script I wrote for generating CRC tables (and correction tables, more on that later), are available here in the GitHub repository.
Invalid ADS-B packets received by the ADSBee now have their “syndromes” (XOR of calculated and received checksums) compared to a pre-generated table of known syndromes corresponding to single bit errors at each location in the message. This allows single bit flips to be corrected, and a fraction of invalid packets to be recovered. In my testing, this seems to result in something like a 5-10% increase in decode rate, but results may vary.
Implementation of 1-bit CRC correction included porting the packet digesting code on the ADSBee onto the second processor core of the RP2040. This means that the ADSBee RP2040 application is now multi-core, with double the available compute resources! I’m excited to see how this windfall of processor cycles could be used in future application features.
While porting the RP2040 application to multiple cores, I found a nasty gotcha! If I put any significant amount of code onto Core 1 on the RP2040, Core 0 would execute until the start of the Core 1 code, and then crash. I could keep things working on both cores while using extremely small commands, like GPIO toggles, on Core 1, but anything more complex (like a printf) caused things to hardfault.
Eventually, I tracked down some very useful Raspberry Pi forum threads and a wonderful website writeup by Pete Warden that explain the issue quite well. For some reason, the Raspberry Pi foundation decided to dedicate an extremely small amount of stack memory to Core 0 (SCRATCH Y) by default, and located this stack just above the stack for Core 1 (SCRATCH X). When a single threaded application running on Core 0 exceeds its stack limit, it stomps on the stack of Core 1 before continuing to write into the much larger memory block dedicated to the Heap memory space.
The ADSBee application running on Core 0 uses a lot of stack memory, mostly due to my preference for pre-allocating buffers on the stack for most data transfer and processing tasks, as a bit of an embedded hack to avoid dealing with malloc, free, and the inevitable memory leaks they might bring. As a result, the Core 0 application absolutely obliterates the Core 1 stack space, which is normally not noticeable, as long as Core 1 doesn’t attempt to load or execute any code. As soon as I started up Core 1, it began writing into random parts of the Core 0 applications stack, causing aforementioned hardfaults.
Fortunately, the solution to this problem was relatively simple. Currently, there is very little memory used in the Core 1 stack, since it mostly reads from buffers that were already allocated on the Core 0 stack. Thus, by editing the linker scripts to allocate SCRATCH Y as Core 1 (small application), and SCRATCH X as Core 1 (big application), Core 1 would be free to overflow into stack memory without stomping on Core 0 along the way. With this change, multi-core applications seem to be running without issue, and firmware update 0.7.2 includes multi-core processing for checksum correction.
The linker files that I edited to resolve this issue are available on the GitHub repository, in case you or a friend find yourself in the same scenario!
🐛 Bug Fixes Galore!
A number of bug fixes were introduced with firmware updates this month. Here’s a few!
ADSBees now properly set their unique receiver IDs when communicating with online aggregators like airplanes.live, adsb.lol, adsb.fi, etc. UUIDs set with the AT+FEED command are propagated into the Mode S Best feed during initial creation of the TCP socket stream, allowing a map of your local ADSBee’s feed to be queried from the aggregator using their API. Take a look at the instructions in this part of the README for some tips on accessing your local map! The instructions vary for each aggregator. If you have some details about how to access feed metrics or a local map for an additional aggregator, please drop me a note in Discord so that I can add the information to the quick start guide.
Mode S Beast feeds from the ADSBee now properly scale their RSSI values for detected aircraft.
A nasty Compact Position Reporting decode issue was introduced in firmware 0.7.1, and then fixed shortly afterwards in 0.7.2 (oops)! This bug affected aircraft positions reported over local interfaces (CSBee, MAVLINK, GDL90) but didn’t affect raw feeds like Mode S Beast.
The handshaking process used to update firmware over the network has been modified, and updates are now much more stable (but certainly not perfect–it may still take one or two tries to get a firmware to load properly onto an ADSBee over the network). There will be more work on this feature in the future!
Build issues related to application linking order have been fixed! This was a cause for some intermittent build failures that varied by machine (there was a race condition that could cause some firmware images to be linked before they were built).
A bug that caused one packet to be dropped during every SPI transaction between the RP2040 and ESP32 has been fixed (off by one, go figure). This wasn’t very noticeable in previous firmwares, but with checksum validation and correction on the RP2040, the ADSBee switched to only forwarding valid ADSB packets between the RP2040 and ESP32, making dropped packets much more apparent.
🚀 GitHub CI Builds
The ADSBee GitHub repository now has Continuous Integration (CI) builds enabled via GitHub Actions. These builds automatically build and run unit tests, then build and link firmware applications for both the RP2040 and ESP32, and produce the combined firmware artifacts for loading the application onto the ADSBee via USB (.uf2 file) or via the network bootloader (.ota file).
In addition to the automatic unit tests being a good goof check to ensure that pull requests don’t break things, this CI build functionality means that anyone can easily compile their own firmware for the ADSBee without a local build environment! While I wouldn’t recommend this approach for serious development (building via CI is sloooooow, and offers no debugger functionality), it does mean that it’s simpler than ever to try out a code change on your ADSBee receiver. Yay open source! 🌈✨
More to come!
I have many more features and improvements in the pipeline for this year, and I’m just as excited about the ADSBee project as ever. Stay tuned to Discord (and the mailing list) for more info!
Happy almost-new-year! It’s been another busy month, with some solid firmware progress on the ADSBee 1090. This update contains some usual month-in-review information about newly released features, but also includes a bit of blab at the end about how OTA firmware updates work for ADSBee, as a treat!
Firmware Version 0.7.0
OTA firmware upgrade capability (experimental)
Network diagnostic and configuration features
ADSBee PyPi package
Ethernet support (very experimental)
Deep Dive: How do OTA firmware updates work for ADSBee?
Firmware Version 0.7.0
This month’s biggest milestone was the release of firmware version 0.7.0, which includes some much-awaited features that should be very welcome for network users of the ADSBee 1090!
OTA Firmware Upgrade Capability
Since the initial inception of the ADSBee 1090, my intention has always been to make it easy to cram into small or generally difficult to access spaces (e.g. attics, boxes on roofs / trees, etc) that might have better ADSB reception than more accessible alternatives. There are a number of creative solutions available for getting power to these spaces in order to run an ADSBee, but until now it’s been generally inadvisable to put an ADSBee in said difficult-to-access spaces due to the need to physically access the device in order to upgrade firmware over USB.
With the release of firmware 0.7.0, users can now send firmware upgrades to their ADSBee 1090 remotely. Each firmware release after 0.7.0 will now include both the usual .uf2 file, for upgrading firmware over USB in DFU mode, and a new .ota file, which uses a custom file format to allow firmware binaries to be flashed over the network using a web browser or a Python script (more on the Python stuff later). This feature is still considered “experimental”, in that there are still a few bugs that can make a firmware upgrade fail under some circumstances, but the firmware and bootloader architecture of the ADSBee make it very resistant to “bricking” itself by attempting to boot an invalid firwmare image, since each firmware needs to pass a multi-step CRC check before it’s used. In all the cases that I have tested, a failed firmware upgrade (resulting from network disconnection, software bugs, or other issues) can be circumvented by attempting the upgrade again.
Network Diagnostic and Configuration Features
It’s now easier than ever to debug network connectivity issues on an ADSBee 1090 via the command line interface by using the new AT+NETWORK_INFO? AT command. ADSBees queried with this command will reply with the connection status of each of their network interfaces, as well as the IP and MAC address of all clients connected to their WiFi Access Point, if enabled.
ADSBee 1090’s can also have a custom hostname configured via the AT+HOSTNAME command. This is handy if you’d like to differentiate multiple ADSBee devices on your network, for instance one ADSBee 1090 can be named “adsbee-attic” while another might be labelled “adsbee-portable”. mDNS hasn’t been activated yet in ADSBee firmware, so hostnames can’t be used to ping ADSBee devices or navigate to their local webpages, but that’s coming soon!
ADSBee PyPi Package
If you enjoy Python scripting and have a fun project you’d like to integrate with an ADSBee, you’ll be pleased to learn that the ADSBee python library I originally wrote for programming and testing ADSBee 1090’s in production is now available as a PyPi package! Getting started is as simple as pip install adsbee. The library includes a number of utility functions for sending and receiving AT commands over serial or network connections, and also includes a function that can execute fully automated firmware updates over aforementioned serial or network connections.
The Python library is still in its infancy, and is pretty much an internal tool that I’ve just blasted into the public world with very little in the way of documentation. I’ll be improving features and documentation in future releases, but if you’d like to get started with it in the meantime, the functions are well commented and I’ll be happy to provide examples and guidance on Discord. The source code for the library can be found here: as always, PRs are welcomed!
Experimental Ethernet Support
ADSBee 1090’s can now be connected to Ethernet! Although Ethernet connectivity isn’t yet reliable in all circumstances, devices connected to a W5500 Lite module as shown below can join a network, get assigned an IP address, and feed endpoints over the internet! Just be sure to enable the Ethernet interface with AT+ETHERNET=1.
Right now the Ethernet connectivity feature is a bit of an experiment, and isn’t considered “stable”. Future updates will focus on improving robustness and adding additional hardware and firmware features for Ethernet connectivity. Stay tuned!
How do OTA Firmware Updates work for ADSBee?
Updating firmware on an embedded device can be a bit tricky, since allowing firmware to update itself inevitably leads to the possibility that a device may update itself with the wrong firmware, or put the right firmware in the wrong place, leading to an unbootable or unusable configuration known colloqually as a “bricked” device.
In order to avoid this scenario, embedded devices like ADSBee that are being updated Over The Air (OTA) typically follow a few rules (well, probably a lot of rules, but here’s two that I know are important):
Don’t update the code that is currently being executed.
Don’t execute code unless it’s been verified to be correct.
Don’t update the code that is currently being executed.
Rule #1 seems obvious, since rewriting the very code that you are executing can lead to some problematic behavior. Typically rule #1 is accomplished by having either a factory-flashed bootloader that is in charge of updating applications and is never updated itself after leaving the factory, or with a system of multiple firmware partitions that can update each other.
The factory-flashed bootloader method is what’s currently used when ADSBee devices are updated over USB using the USB DFU (Device Firmware Upgrade) method. A bootloader has been permanently programmed into the ROM of the RP2040 during manufacturing on the Raspberry Pi Foundation’s production line, and this bootloader is capable of receiving .uf2-formatted firmware binaries over USB and programming them into the flash memory attached to the RP2040.
The downside of the factory-flashed bootloader method is that once this bootloader is installed, there’s no going back. Whatever protocol was programmed into the bootloader for updating device firmware will be the protocol that is used until the end of time for updating the product with new firmware. In the case of things like network firmware updates, which can be more complex and may be expanded with additional features over time, having a bootloader that’s frozen in time can become a problem as the software on the rest of the system evolves. Since ADSBee 1090 is intended to be delivered to beta customers half-baked and iterated on to fix bugs and fulfill newly discovered feature requests, I chose to implement the multi-partition firmware update method instead.
An ADSBee 1090 is kind of like a sleeping whale.
According to my google search results, unlike snails, whales are widely understood to sleep more than three. To my knowledge, many other mammals, like humans, are not very good at sleeping underwater (or perhaps more accurately, waking up after going to sleep underwater). How does a whale sleep without drowning?
Apparently, whales have a nifty trick up their sleeve. Whales can sleep one hemisphere of their brain at a time, allowing the other hemisphere to stay aware of the whale’s surroundings and move to the surface to breathe. Whale sleep behaviors vary between species, but whales can generally sleep while swimming slowly, or while bobbing around near the surface nearly motionless, like the sperm whales that are doing a great log impression in the image above (credit to Scientific American for the pic).
Much like a sleepy whale, the ADSBee’s firmware storage is divided into two application sectors, called FLASH_APP0 and FLASH_APP1. Each sector is identical in size and can store just under 8MB of code. When firmware in FLASH_APP0 is executed, it has access to the APP1 sector and can happily erase, write, and read firmware in that sector to its hearts content. Conversely, when firmware in FLASH_APP1 is executed, it has access to the FLASH_APP0 sector and can erase / read / write firmware in that section of storage without risk of overwriting itself.
When a firmware update is initiated, the application that is currently running on the ADSBee 1090 receives a firmware image that it writes into the complementary flash sector. Once this newly written firmware is verified to be correct, the microcontroller can “jump” into the new sector to begin executing that code.
There’s one piece of the puzzle remaining: when the ADSBee first boots up, how do we know which section to jump into first? This is where the FLASH_BL region comes in. FLASH_BL contains a very small bootloader whose only job is to check which partition was flashed most recently, and whether said partition is valid. If a partition is freshly flashed and is properly verified, the bootloader picks that partition to jump into. If a partition is freshly flashed but fails checksum verification, the bootloader falls back to the older firmware in the complementary partition.
Don’t execute code unless it’s verified to be correct.
Like billions of devices around the world, ADSBee 1090 relies on Cyclic Redundancy Checks to verify that chunks of firmware images being sent over the air, and complete firmware images, are correct (i.e. no bit flips introduced in transit, or other errors). Each chunk of data transferred over the air includes a CRC32 calculated over its bytes that is used to verify the integrity of the received data packet and corresponding chunk of firmware programmed in flash. Likewise, each firmware partition is pre-pended in flash with a binary header that indicates the status of the firmware partition and includes a CRC32 value for verifying its contents. Using these CRC values, the ADSBee is able to confirm that bits haven’t been flipped during transit, and that they have been programmed to flash successfully, before executing a newly flashed firmware image.
What are the steps to an OTA update?
OTA updates are a bit of a song and dance, with a few commands for putting the ADSBee into a firmware update mode, and then a bidirectional transmit and reply process used for sending the firmware binary in chunks over the serial connection normally used for AT commands.
Before any data chunks can start flying, it all starts with a .ota file. The .ota file is a new file format I invented, probably out of a lack of understanding of existing solutions, for flashing the ADSBee. Each .ota file contains two verisons of the firmware. One version is compiled for FLASH_APP0, and one is compiled for FLASH_APP1. This is a bit of a kludge, but was necessary since ARM M0+ cores don’t support Position Independent Code (code that can be run without a knowledge of where it is in flash).
Enjoy this screenshot from the firmware reference guide that I wrote! Note that in this case, we only have two applications, but the .ota file format is generalizable to an arbitrary number of application sectors.
Once an ADSBee-flashing program has read in the .ota file, the next step is to tell the ADSBee to enter a firmware update mode and then send over the relevant chunks of data. This is done over the AT command interface using the procedure below.
And that’s about it! Right now there are two programs written for updating ADSBee 1090’s over the air. One is written into the adsbee python library, and one is baked into the ADSBee 1090’s own webpage as a javascript application, allowing firmware images to be uploaded directly from any web browser. Updating firmware over the air currently takes just under 2 minutes (most of this time is spent erasing and writing flash, which seems to be quite slow). I’m sure there’s some additional optimizations that can be made to speed things up further; if you have any cool ideas about updating firmware (or see something that I goofed in my OTA process), I’d love to hear from you!
Acknowledgements
Many thanks to Brian Starkey for his excellent writeup of a similar Pi Pico bootloader project, which was a useful reference when implementing my own bootloader.
Hunter Adams also has a fantastic bootloader for the Pico that served as additional inspiration for my implementation.
Both of the aforementioned sources focused on bootloaders with a single application partition, but nevertheless contained many of valuable tidbits that came in handy when developing my multi-partition bootloader!
🎊Here’s to 2025! 🎊
It’s been a fantastic year on the ADSBee project! In just around 6 months this project has gone from a janky little prototype sitting on my workbench, to a janky little product sitting in homes around the USA, and around the world (as far away as Ireland and Australia)! Thanks for following along and making this project worth working on. Stay tuned, there’s lots more to come!
Happy post-Thanksgiving! Here’s what we’ve been up to this month.
TL; DR
ADSBee 1090 preorders are 100% shipped!
Documentation
Huge firmware update (0.6.2)
ADSBee 1090 Preorders 100% Shipped 📦🚀
All ADSBee 1090 preorders have been shipped, and should be arriving shortly! Many beta testers have already had a chance to try out their devices, and a number of them are currently feeding aggregator sites like airplanes.live and adsb.fi.
As of the time of writing, new orders for the ADSBee 1090 Beta Kit ship in 1-2 business days.
Some ADSBee 1090’s being programmed and tested before shipping.
Documentation 📄
Documentation for the ADSBee 1090 has been updated and improved! There’s now a quick-start guide with details about how to set up and configure an ADSBee, and the datasheet has been updated with a comprehensive description of all of the available AT commands.
ADSBee 1090 Firmware 0.6.2 💻
Besides shipping devices, most of my time this month was dedicated to a significant firmware update, which is now released as firmware version 0.6.2. This update includes a wide range of new firmware features and bug fixes. The full list of new features is available in the release notes, but I’ll go over two big ones here!
ADSBee 1090 Web UI
The most visible new feature is the web UI hosted by the ADSBee 1090’s ESP32 module. At the top of the page, a simulated terminal window allows direct input of AT commands to the ADSBee 1090’s command line interface, providing an easy way to interact with the ADSBee 1090’s configuration capabilities over a network connection. The bottom section of the UI includes a dashboard which presents metrics about how packets are being decoded, as well as information about currently active feeds.
The Web UI can be accessed by visiting the ADSBee’s IP address (192.168.4.1) on its self-hosted WiFi network, or by visiting its assigned IP address on an external WiFi network (you’ll need to instruct the ADSBee to join the network first using the serial command line interface).
Not-So-Secret Feature: because the console on the web UI is implemented as a WebSocket, you can connect to it from any device on the network by opening a WebSocket targeted to ws://<ADSBee IP address>/console. Happy hacking!
Mode S Beast Feeding
The ADSBee 1090’s Mode S Beast feed capability is just beginning to stretch its legs! ADSBee can now feed arbitrary IP addresses (e.g. 192.168.1.103) and DNS addresses (e.g. feed.adsb.fi) with demodulated Mode S packets in Mode S Beast format. Feed URIs and ports can be configured via the `AT+FEED` command.
What’s Next? 🔮
Upcoming Firmware Features
Here are a few major firmware features that I’m actively working on, or will be working on shortly! If you’d like to request features and bugfixes, please open or comment on an issue in the GitHub repository! Engagement is always appreciated, and issues let me prioritize what features are needed the most urgently.
If you are interested in contributing to any of these features (or others), please get in touch via Discord! Pull requests are always welcomed–let’s harness the power of open source together. 🌈📈
Network Bootloader
I’m currently developing a network bootloader which will allow users to update the firmware on their ADSBee remotely. This will be especially useful for anyone who wants to put their ADSBee somewhere less easily accessible, e.g. an attic space or a tree! Implementing this network bootloader is a bit of a complicated task that has been at least a month in the making, with some cursed adventures in linker files and CMake dependencies along the way. Fortunately, things are shaping up nicely, and it should be ready for (experimental) release soon!
Ethernet Support
The hardware on ADSBee 1090 has been designed from the beginning with Ethernet support in mind. The software driver for a W5500 Ethernet IC has been already been baked into the firmware on the ESP32, so in theory it shouldn’t be too hard to whack a proper Ethernet driver into the firmware and get something working with some janky hookup wire and a W5500 Lite module. Combined with a USB C PoE splitter, this could let users install their ADSBee 1090 in any PoE accessible location! Stay tuned for some fun prototyping on Discord. As long as I haven’t absolutely goofed some pinouts on the ESP32, we should be able to put together something that works!
Checksum Correction
One of the primary inhibitors of ADSBee 1090 performance has been demodulated packets with invalid checksums. These packets may be a symptom of some algorithmic errors under the hood in PIO demodulation, or could be related to the analog response time of various parts of the electronic frontend of the ADSBee’s custom receiver. Either way, there seems to be a pretty substantial pile of packets laying around with very serviceable signal strength and signal quality metrics, which nonetheless don’t resolve to a valid checksum. I’m excited to dedicate some time to implementing CRC correction techniques to see if any of these packets can be recovered! I’m hopeful that analyzing bit flip locations within demodulated messages might also offer some clues about what’s causing the invalid decodes in the first place, to see if additional receiver improvements can be made.
Manufacturing Improvements
The ADSBee Beta’s purpose is to collect feedback and performance / reliability data ahead of mass production of ADSBee 1090 in Q1 of 2025. I’m spending a good deal of time putting together data systems and test fixtures to provide traceability for devices through the manufacturing process. These might be fun topics for a writeup or a video in the future!
In the meantime, a good deal of effort is being dedicated to improving yield with the current manufacturing run. Some components on the ADSBee 1090 have proven to be remarkably temperature sensitive, requiring tweaks to some parts of the assembly process and additional testing before each device is shipped. Manufacturing and reliability testing will be an increasingly large focus moving forward. If you have a Beta unit that exhibits any weird / unexpected hardware behaviors, please get in touch! I’m very eager to learn about any and all failure device failure modes, and will happily replace any hardware that has failed due to manufacturing defects.
Let’s send it!
I’m so excited to see what everyone does with their ADSBee! Join the party on Discord and tell us what you’re building with your receiver.
Welcome to the it’s-still-technically-just-barely-October update! It’s been a crazy month and we’re making great progress leading up to the shipment of ADSBee 1090 Beta units.
TL; DR
ADSBee 1090 Beta pre-orders launched!
Receiver performance improvements in hardware and firmware.
ESP32 network firmware features.
Field testing in cool places.
Beta PCBAs in manufacturing and test!
🎉🚀ADSBee 1090 Pre-Orders Launched!🚀🎉
ADSBee 1090 pre-orders were launched on October 4, and are now more than 50% sold out! I think that all of the beta testers on our waiting list have had the chance to place a pre-order by now, so I’m lifting the one-per-customer limit. If you have an interesting application for a handful of ADSBee 1090 beta kits, now’s your chance to go wild! Beta kits come fully assembled in a 3D-printed enclosure with a WiFi antenna (internal) and a 1090MHz antenna (external). Preorders ship in Early November™ (I’m counting anything before November 14th at 11:59pm as “early November”).
Since the last update, there have been significant strides in receiver performance due to upgrades to both hardware and firmware on the ADSBee 1090. All of these changes have made it through to manufacturing, and I’m happy to report that ADSBee 1090 Beta units will be up to date with the latest and greatest aspects of the design! Three major improvements to the receiver design (two firmware, one hardware) are documented in the sections below.
ADSBee 1090 previously utilized a single PIO state machine for detecting message preambles and triggering the demodulator state machine. This was sufficient for good performance in most scenarios, but had a vulnerability in situations where noise pulses might trigger a high pulse just before the beginning of a valid preamble. The single preamble detector would ingest the stray noise pulse and begin its preamble search routine, and would thus still be in the midst of searching for the subsequent bits of a preamble when the first bits of an actual valid preamble would roll in. This could cause the preamble detector to miss valid preambles when they were preceded by some amount of noise.
The solution that I’ve implemented to address this issue is to have two preamble detectors operating simultaneously on separate state machines, in a round-robin sequence. Each preamble detector waits until the complementary preamble detector has already latched onto a rising edge before beginning its own preamble search, thus ensuring that the two preamble detectors don’t (usually) end up demodulating the same message. This means that the ADSBee 1090 can respond instantaneously to a rising edge with a preamble match routine, even if one of its preamble detectors is already occupied. This also adds a bit more wiggle-room for the preamble detector to perform its reset sequence after it aborts an invalid preamble match, as the complementary preamble detector is scanning for the next rising edge (previously, the ADSBee 1090 was completely blind to incoming preambles while its sole preamble detector was resetting).
In the oscilloscope screenshot below, we can see two interleaved preamble detectors triggering on messages (spikes on the blue trace, which shows raw RF power). The yellow trace corresponds to the first preamble detector, and the orange trace corresponds to the second preamble detector. The green trace shows the digital waveform being fed into the RP2040, which is being filtered for message preambles. We can see that there’s quite a bit of noise even when no message is present!
Hardware Performance Improvement: Analog Frontend Filter Capacitor Change
After more extensive evaluation of ADSBee 1090 Rev F’s performance on the bench and in the field in close proximity to aircraft, I discovered that it had significant difficulty with high power messages (e.g. messages from a close-by aircraft with a well aligned antenna radiation pattern). After a decent amount of debugging and poking at various parts of the receiver, I came to the conclusion that the additional gain stage on the ADSBee 1090 Rev F, which improved its overall receive range, was having the unfortunate effect of overloading the analog data slicer circuit in charge of converting RF power levels from the logarithmic power detector in the RF frontend into digital pulses being fed into the RP2040.
High power signals would present to the analog circuit as a high amplitude signal with a decently sized DC offset. The limited slew rate of the RC filter tasked with obtaining the centerline of the signal resulted in falling edges in the message preamble and start of the message failing to register, thereby leading to the ADSBee 1090 missing the message entirely.
The trace below shows a simulated aircraft message from a HackRF on the lab bench. RF power level is shown in orange, the filtered centerline of the power level is shown in blue, and the digital waveform output by the data slicer circuit is shown in yellow. Note that the preamble shape shown in yellow is incorrect, and the troughs between pulses don’t begin showing up correctly until a few bit periods into the message body. The incorrect preamble shape meant that the ADSBee 1090 wouldn’t trigger either of its preamble detectors, and the corrupted bits at the start of the message meant that even if a preamble detector had triggered, the message would have failed its checksum and been discarded.
The solution to this issue turned out to be relatively simple; the value of a single filter capacitor in the data slicer circuit needed to be adjusted in order to improve the rise time of the RC filter tracking the centerline of the RF power level. Dropping the value of a single capacitor from 1nF to 200pF resulted in a marked improvement to message demodulation capabilities with high power signals. The oscilloscope screenshot below shows a message demodulation from a live aircraft with the new 200pF filter capacitor. Note the increased responsiveness of the blue line to RF power levels!
Rework instructions have been released for upgrading from Rev F to Rev H (the rev of the PCB with the new filter capacitor value). These instructions are only meant for use by 1-2 hardcore early testers who received Rev F hardware and wanted to try out soldering themselves, but I’ve made the document public in case anyone is curious about what the upgrade procedure looks like. All ADSBee 1090 Beta Kits that are currently on preorder will ship as Rev H, so no need to worry about this part change if you haven’t received hardware already!
Even with the improved responsiveness of the data slicer analog circuit provided by the upgrade to Rev H hardware, messages from very nearby aircraft were still being missed. While the improved responsiveness of the RF power level centerline RC filter meant that the message body was being demodulated correctly, the first pulse pair of the preamble sequence would occasionally blend into a single larger pulse due to the initial rise time required for the centerline filter capacitor to charge up to the DC offset presented by the message. This mangled preamble would be rejected by the ADSBee 1090’s preamble detector, causing the high-power message to be lost.
Further decreasing the value of the centerline filter capacitor proved to be impractical, as it resulted in additional noise in the message body that caused a degradation in receive rate for valid packets. Fortunately, I was able to further improve performance with decoding nearby aircraft messages by implementing a firmware improvement in the form of a third preamble detector dedicated to detecting mangled preambles from high-power transmissions. This preamble detector operates separately from the round-robin preamble detectors used for detecting well-formed preambles, and proved to be somewhat tricky to cram into the remaining state machine in the PIO peripherals. One unexpected bonus of this creative code stuffing exercise is that the GPIOA pin header on the ADSBee 1090 now serves as a “nearby aircraft” indicator pin, as it is used to transfer the demodulation interval pulses between the high power preamble detector and its corresponding demodulator state machine.
Message reception of nearby aircraft is greatly improved with the addition of the high-power preamble detector, allowing the ADSBee 1090 to demodulate packets from aircraft that are both very close to the receiver (<2 miles) and very far away (100+ miles) simultaneously. The packet receive rate for close-range aircraft still certainly has room for improvement, and may warrant further attention in the future. I’m excited to hear about user experiences during the Beta in a diverse range of operating conditions, as this will surely inform design decisions for the ADSBee 1090 firmware as well as future hardware designs.
Network Firmware Features 🛜
The ESP32 on the ADSBee 1090 is finally coming into its own! This month saw significant performance and stability improvements in the interprocessor communication and WiFi network firmware on the ESP32. As of firmware 0.5.1, the ADSBee 1090 can create its own WiFi network (Access Point mode) while simultaneously joining an external WiFi network (Station mode). Network credentials, WiFi settings (e.g. WiFi channel for Access Point mode), and IP addresses of upstream devices to be fed with received aircraft packets can all be adjusted via the AT command interface.
GDL90 over WiFi
The ADSBee 1090 now supports GDL90 over WiFi, enabling integration with popular electronic flight bag apps like Avare on Android, and Foreflight on iOS.
Aircraft received by the ADSBee 1090 being displayed on Avare, a free Electronic Flight Bag app for Android.
Setup is simple! Each ADSBee 1090 comes pre-programmed to broadcast its own WiFi network out of the box. Joining the uniquely named WiFi network (e.g. ADSBee1090-0240907000005) will result in your device receiving GDL90 packets over UDP port 4000, the standard port used by most electronic flight bag and ADS-B viewer apps for receiving aircraft information. The default password to this network is “yummyflowers”, and up to 6 devices can be connected at once (this number might increase in the future if testing shows that we’ve still got some spare CPU cycles once the firmware is fully cooked). The network SSID and password can be customized over the ADSBee 1090’s AT command interface.
Mode S Beast Over WiFi
This feature is still in progress, but is making good headway! The ADSBee 1090 will soon be able to feed raw transponder packet messages to local and remote ADS-B packet decoders (e.g. computers running dump1090 / tar1090 / readsb) via TCP. Firmware 0.5.1 has successfully fed packets to an instance of tar1090 running on my local network, but the feature isn’t quite ready for prime time just yet. Stay tuned for more progress very soon!
Bay Area Maker Faire 🤖🏅
I had the exciting opportunity to exhibit ADSBee 1090 at Bay Area Maker Faire. Many thanks to my friends who helped staff the booth, and another thank you to those of you who stopped by to say hi and learn about the project!
Booth, with friends!
From Mare Island we were able to see aircraft as far away as Modesto. I had hopes that our table might have a good view of SFO, but alas we were situated in a brick building surrounded by metal and electrical equipment. The direction of SFO was blocked by multiple large brick and concrete industrial buildings as well as a hill, so we didn’t have a chance to see much of anything in that direction, but we did pick up lots of aircraft towards the east!
The banner stand and antenna mount behind the booth was janked together with some 3D printed brackets, wood from Home Depot, and some used lighting stands that I bought from Facebook Marketplace the day before. The lighting stands allowed me to mount a 5.5dBi colinear dipole antenna just above the metal fence that was behind our booth, providing reasonable eastward reception and enough aircraft to make the interactive flight display somewhat interesting to look at.
To my delight and surprise, we were selected to receive an editor’s choice award! The friendly editor of Make Magazine gave us a little blue ribbon and a modest but certainly appreciated sense of accomplishment.
We must have given out at least 600 ADSBee stickers during the course of Maker Faire, so if you see them appearing on various belongings owned by children and/or turbo nerds located in or adjacent to the Bay Area, it’s a good bet that you know they came from!
ADSBee 1090 in the field 🌾✈️
I brought the ADSBee 1090 along with me to two airshows and a number of trips to the local airport. Can’t miss a good opportunity for data gathering!
L-39’s in formation at the Salinas airshow.L-39 formation as seen via ADSBee.A very regular hat.Backpack mounted ADSBee for fleet week.Close range testing at the airport.
Manufacturing in Progress! 🏭
Manufacturing of the Beta batch of ADSBee 1090’s is in progress! As of the writing of this post, all PCBA assembly and initial program / test is complete. The remaining time before ADSBee ships will be utilized for cramming in some last-minute firmware improvements and additional testing to try screening out potential manufacturing defects that may not have been noticed during program and test.
I will be exhibiting ADSBee 1090 at this year’s Bay Area Maker Faire from October 18-20! Come by to chat about ADSB, airplanes, firmware, 3D printing, or anything you’re interested in. Also, see what $300 worth of bee stickers looks like (please save me from my own madness and take a few). Hope to see you there!
