Author: John

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!

Entry Page

This last month has been another solid wave of progress! ADSBee 1090 Rev F is looking good and I’m excited to see it move into low volume initial production very soon. Scroll to the end for an update about the ADSBee Beta! 🎉

Hardware Updates

ADSBee 1090 Rev F Bringup

Bringup of revision F of the ADSBee 1090 has proceeded quite smoothly! There were a few hiccups (I had the wrong component installed by the manufacturer for the bias tee switch MOSFET, and some of the components that I’ve had to manually populate have been difficult to solder down properly), but overall the board seems to function as intended. Major changes in this revision include:

• Redesigned RF frontend with new layout and extra gain + SAW filter stage.
• Completely redesigned analog circuit implementing a data slicer topology.
• Upgraded to a newer ESP32 (ESP32-S3).
• Rewired the inter-processor communication bus to not accidentally use reserved pins on the ESP32.
• Added a USB JTAG debug connector for programming the ESP32, and added a coprocessor SPI connector to enable addition of a UAT module at some point in the future.
• Redesigned RP2040 pinout to expose pins for a second PIO state machine from the preamble detector and demodulator PIO blocks.

With this many changes, I have been pleasantly surprised to not find any “deal breakers” so far! It appears that all 10 of the PCBs I received will be able to be used as functional devices for testing once they are fully assembled and tested.

ADSBee 1090 Rev F hardware should be sufficient for the needs of our hardware Beta! Most of the units I have hand-assembled will be used for testing internally, but a select few will be sent out to other developers participating in the Beta test. I currently am getting assembly quoted for an additional run of Rev F units, which will be made available for a larger beta as soon as I have an updated estimate of pricing.

ADSBee 3D Printed Enclosure

I designed a 3D printed enclosure for the ADSBee 1090, with enouh extra room to support an FPC WiFi antenna and external GNSS module, and openings for connectors and indicator lights, button flexures for the BOOT and RESET buttons, and an internal latch to keep it closed. It’s still a work in progress, but the OnShape designs are available below. Feel free to remix and improve the enclosure as you see fit! I’d love to hear about new designs.

ADSBee 1090 Enclosure

ADSBee 1090 Bare PCB (Rev F)

Antennas and Cables

The 1090MHz sleeve dipole antenna has been redesigned to use a much smaller outer housing. This should make the full device more compact, and will have an added benefit of saving on shipping costs.

Waterproof SMA to U.FL cables have been sourced and tested, and are currently in 100x production to support the hardware beta. My intention is to include waterproof SMA to U.FL cables in order to allow ADSBee owners to easily connect their ADSBee to a 1090MHz antenna from within a waterproof enclosure. The cost difference between waterproof and non-waterproof SMA bulkhead connectors is relatively small, so it makes sense to standardize on a single cable part for waterproof and non waterproof enclosures in order to lower the unit cost.

Flex PCB WiFi antennas have also been sourced and tested. They will eventually need to be custom tuned for their installation location relative to the ADSBee 1090 PCB within the 3D-printed enclosure, but they should function just fine for the beta without the need for fine tuning.

Firmware Improvements

Additional Mode S Downlink Formats

Decoding has been implemented for Mode S downlink formats 4 and 5 (Identity and Altitude replies). This was a bit of an adventure, and involved a fairly cursed exploration of how to decode Gillham Coded altitude information (old timey altitude encoders connected directly to transponders with a number of parallel wires, and used a novel binary protocol that was intended to only toggle a single bit at a time while incrementing or decrementing). Many thanks are owed to a kind British man named Kevin Stewart, whose old forum posts and online documentation described how to decode Gillham coded values in the context of his quest to build a DIY altimeter calibration device.

Gillham Codes have no built-in method of error checking, since a single broken wire in the bundle of wires between the altitude encoder and transponder can cause garbage altitude values to be transmitted. There is a single bit flag in the Mode S protocol that is dedicated to warning that a transponder’s altitude information may not be very robust, as it is based on a single reading from a Gillham coded altimeter.

Gillham coded transponder outputs (just a bunch o’ wires) have since been superseded by a number of more robust communication protocols between altimeters and transponders on aircraft (e.g. serial protocols with checksums), but for some reason the Gillham codes themselves are still used for encoding altitude data in 56-bit Mode S packets.

Decoding has also been added for Navigation Integrity and Navigation Accuracy information provided by aircraft via ADS-B (Mode S downlink format 17). This should provide some additional interesting details, such as the approximate dimensions of an aircraft (when on the ground), as well as a number of numerical values which describe the robustness of the location information provided by the GNSS system on board the aircraft.

CSBee Protocol

CSBee (Comma Separated Bee values) is an information-rich plain text protocol based on the popular Aerobits CSV protocol, but with a number of additional fields. A PDF excerpt from the draft datasheet describing the CSBee protocol is included below.

Oversampling in PIO!

One of the issues that I’ve encountered repeatedly with decode performance has been that spurious noise can cause the PIO preamble detector or demodulator state machines to follow a stray edge into the wrong state, causing offsets in recovered clocks and garbled bits. After a few weeks of hard thinking, I convinced myself that it might be possible to refactor the PIO code to include oversampling (sampling the digital input signal from the data slicer circuit multiple times and then taking a majority-wins approach to classifying state of the pin as HI or LO). What followed was many days of PIO assembly hell and some rather difficult debugging, but I’m very happy to report that oversampling works, and seems to yield a significant improvement in both the integrity of detected preambles as well as the success rate at decoding Mode S messages! I neglected to get real numbers, but by John’s precision vibeometer I can confirm that the decode rate has improved by something like 2x-4x in most cases.

Inter-Processor Communication

To address the need for bidirectional communication between the RP2040 and ESP32, I implemented a custom SPI protocol. This took a bit longer than I anticipated, and was slightly over 1000 lines of code once everything was tested and working. The main complexities derived from communication being asymmetric (the RP2040 is the master and can talk whenever it likes, whereas the ESP32 is a slave and has to request communication explicitly from the master), and breaking large transactions into smaller 64-Byte chunks that could be easily handled by both the RP2040 and ESP32 without the need for huge buffers. The protocol is mostly going to be used for very frequent short communication between processors, as the RP2040 streams transponder packet information to the ESP32, but also must be able to handle medium sized data transfers (like sending over a few hundred byte large struct containing settings information) and larger data transfers (eventually, a full firmware image up to 16MB in size might need to be shuffled over SPI from the ESP32 to the RP2040 for an OTA update).

Initial tests seem to show the protocol working well! I’ve included a short GIF of transfers between the RP2040 and ESP32. Transfers shown in the GIF tested sending data with and without forced acknowledgements, writing and reading from a scratch register, and transferring large blocks of data that had to be broken into multiple messages.

🎉ADSBee Beta🎉

The primary factor gating the ADSBee Hardware Beta has been receiver performance. I didn’t want to send out units that I wasn’t sure that beta testers would be excited to use, and predictably, the majority of that boiled down to whether the ADSBee 1090 was good at receiving ADS-B and Mode S packets. Over the course of the last month, testing results have convinced me that the significant overhaul of receiver hardware in the transition from ADSBee 1090 Rev E to Rev F and the impactful improvements made to ADSBee decode logic have reached the performance targets necessary to begin manufacturing for the ADSBee Hardware Beta.

In my testing, while the ADSBee 1090 isn’t as sensitive as the best software defined radios that have dedicated pre-filters and LNAs targeted for use exclusively on 1090MHz, the ADSBee 1090 is approaching performance parity with extremely common unfiltered SDRs (like the RTL-SDR V3) and existing (much more expensive) embedded receivers like the uAvionix PingRx. I’m not yet done improving the decode logic, and I have a few more things in the pipeline that will hopefully improve receive performance further–but I’m convinced that Rev F hardware will be up to the task as-is for many of the applications that users have been excited about!

Performance comparison between an ADSBee 1090 and a uAvionix PingRX running off of the same antenna:

Performance comparison between an RTL-SDR v3 dongle and an ADSBee 1090 running off of the same antenna:

Phone screenshot from portable ADSBee 1090 testing outside of SFO:

OK that’s cool dude but when is the Beta?

Pre-orders for ADSBee Beta units will be opened soon, once I have solid quotes back from my contract manufacturer for Revision F of the PCBA. I expect pricing to be in the sub $85 range. All Beta units will include a 3D printed case, SMA antenna connector, WiFi antenna, and 1090MHz antenna. If manufacturing proceeds smoothly, the lead time for beta units will be about 1 month after preorders close.

In the meantime, I have a few hand-assembled units that will be made available to developers. If you are interested in contributing to firmware, please reach out to me on Discord and I’ll see about getting you some hardware!

I’ve been working hard on ADSBee 1090 since the July update. Here’s what I’ve been up to since y’all last heard from me!

TL; DR Redesigned the analog and RF frontend of the ADSBee 1090, new rev with cool features (ADSBee 1090 Rev F) coming soon. Also, lots of firmware work! Hardware beta details still TBD pending bringup of the new rev.

Testing ADSBee 1090 Rev E

In late July, I took some ADSBee 1090 Rev E PCBAs with me on a trip, and had a grand time collecting aircraft contacts and adding features to the RP2040 firmware. Important additions include bringup of our new 64kbit EEPROM (which should be large enough to store any feeder IP addresses, WiFi passwords, etc. that we might need), addition of Mode S Beast protocol as serial output, and implementation of a high resolution 12MHz timer for multilateration (with wonderful assistance from one of our community members, @gwoplock).

During the course of the trip, I was able to demonstrate some rather long range contacts even with a relatively primitive base station setup, but I did notice that the receiver performance suffered when aircraft were too close to the receiver. Once I got back home, I started some relatively squishy / qualitative benchmarking against a few software defined radio dongles and an off-the-shelf FPGA-based receiver (uAvionix PingRx). While the results weren’t very precise, it became apparent that some improvements to the ADSBee 1090’s receive performance would be necessary for the device to be a competitive solution. After a few weeks of using ADSBee 1090 Rev E, it was also clear that there were a few too many knobs that required fiddling from the user (receive gain adjustment, positive and negative trigger thresholds), which indicated unnecessary complexity and room for improvement in the UX. Thus began a few weeks of some pretty aggressive redesign of the RF frontend and analog circuitry on the ADSBee 1090, culminating in releasing ADSBee 1090 Rev F to manufacturing yesterday (2024-08-17).

Analog Redesign

Analog circuitry redesign consisted of etching some teeny tiny PCBs (bodge boards) in my garage with room for a few analog components, then VHBing the bodge board onto the back of an ADSBee 1090 and tapping into the circuit via test points or pads on the front of the board. I iterated through four separate analog designs before I finally settled on a relatively popular topology called a Data Slicer (commonly used for decoding an AC Manchester coded signal with some level of DC bias). This topology has the side benefit of removing an op amp and analog switch from the circuit, which frees up space and BOM cost for RF frontend improvements.

The final design no longer requires a user to set receive gain and two trigger thresholds, since it automatically adjusts to fit the signal amplitude of aircraft at various ranges, and only requires a single adjustable DC bias that can be set to properly ignore the noise floor. My hope is that most users will never have to change this value, which will be set to a reasonable default in firmware, and may only need to adjust it if they are doing some advanced maneuvers before the ADSBee 1090’s RF input, like adding a cavity filter or an additional Low Noise Amplifier (LNA).

RF Redesign

Poking and prodding at the ADSBee 1090 Rev E circuit has indicated that range for the ADSBee 1090 can be significantly improved through an additional LNA gain stage. I etched a PCB to allow the addition of said gain stage using the same LNA part number as already exists on the ADSBee 1090 (Berex BLB01), and also evaluated performance with an off-the-shelf LNA. Both LNAs yielded a significant increase in number of aircraft tracked, so I’m excited to see what end to end performance looks like with a properly integrated dual gain stage RF frontend.

In addition, I etched some test boards for qualifying an alternative SAW filter from another manufacturer that promised similar performance characteristics with slightly lower insertion loss. Through some supply chain finagling, I’ve been able to get pricing for SAW filter components down from ~$15 each at 100x quantity (crazy, absurd, absolutely wild) to the $1 range. If people are interested in some 1090MHz SAW filter boards (just the filter and some connectors, nothing else), shoot me a message on Discord or via email and I can look at cooking up a group buy of some properly laid out and enclosed filter PCBAs.

ADSBee Rev F’s RF frontend includes a number of the goodies above, with two cascaded LNA and SAW filter stages. I’ve also moved the first SAW filter stage behind the first LNA stage in an attempt to improve SNR in typical environments. This means that if you’re in a really, really noisy environment or have a relatively wideband antenna, you might need an additional filter in front of ADSBee 1090, but I think this will be a relatively rare occurrence.

I also added test ports to enable proper characterization of gain and noise factor of the ADSBee 1090’s RF signal chain, as well as characterization of the narrowband input match on the AD8313. This will hopefully allow me to flesh out any gremlins that might still be hiding in the RF frontend and hindering receiver performance.

Lastly, a switchable bias tee circuit (3.3V out, 200mA) was added to the RF input to allow the ADSBee 1090 to power an external LNA before its first stage, if so desired. I don’t anticipate many users needing this feature, but for now, it’s there if someone wants it!

ADSBee 1090 Rev F

Here it is! Rev F looks pretty similar to Rev E on the surface, but includes the following improvements:

• Overhauled analog circuitry with a design that automatically adjusts sensitivity to different transmit power levels. This should hopefully remove the “doughnut effect” we were seeing on Rev E, which made the receiver only sensitive to aircraft in a relatively narrow band of radial distances. The new circuit uses fewer expensive components (no op amp or analog switches), so this BOM cost and board space savings has been reinvested into improvements to the RF frontend.
• Moved to a two-stage amplifier with double SAW filters. Added MHF3 connectors for characterizing noise figure of the RF input stage and characterizing the narrowband impedance match of the AD8313. I’m hopeful that we can improve our signal to noise ratio by a few dB here.
• Provisions for utilizing 2x PIO state machines as interleaved demodulators. In theory this could let us keep scanning for preambles even in the midst of decoding a message.
• Fixed an ESP32 SPI trace issue that was causing crashes (SPI lines were previously shared with ESP32 internal flash memory).
• Added ESP32 JTAG USB connector.
• Switchable bias tee for external LNA.
• JST-SH connector footprint for connecting to another board via the coprocessor SPI bus plus a few GPIOs. The hope is to use this for development of a UAT receiver add-on at some point down the road.
• Switching the EMI can to a two-piece design that allows the cover to be removed and replaced without desoldering anything.

I’m excited to get my hands on a few of these boards to see what they can do. Feel free to follow the adventure on Discord, or check in for an update next month! If Rev F proves itself Worthy, the ADSBee Hardware Beta will kick into drive in earnest. Thank you to all of our (very patient) Beta testers!

If you’d like to join the mailing list for the Hardware Beta (if you got this update as an email, you’re already on it), feel free to sign up here.

Pants for Birds will be at Open Sauce 2024! I will be showcasing some ADSBee 1090 units, and hanging out with some cool friends who are bringing projects of their own:

• Giant LED panel info display displaying aircraft information.
• Snake! Running on a factorio CPU with a real-life interactive LED display / arcade panel.
• Team Mario Kart: Mario Kart, but if each kart was being driven by two squirrels, one of whom controlled steering and one of whome controlled acceleration.
• Interactive ADS-B data visualization written in a very cool upcoming open-source data visualization tool.

Say hi if you see us!

After doodling around with projects for a few years under the Pants for Birds name, I’m excited to announce that Pants for Birds is now a registered California LLC! I’ve changed my day job to part-time status, and will be pursuing commercialization of open source hardware products under the Pants for Birds brand.

The first “real” product will be an open-source ADS-B receiver based on the RP2040 microcontroller. This project has been warming in the oven for a number of years, and I’m excited to boot it across the line and turn it into a fully featured product. Let’s see how this goes!