ESP32 Plane Radar: an ADS-B radar on a round display you can build tonight
Open-source ESP32 firmware for a 1.28″ round display that shows live ADS-B aircraft around your location as a sonar-style plane radar.
At a glance
- What is it?
- Plane Radar is open firmware for an ESP32-C3 Super Mini and a 1.28-inch round GC9A01 display that shows live ADS-B aircraft around your configured location as a sonar-style radar, with a captive Wi-Fi portal, range presets, airport runway overlays and a 3D-printed case. MIT licensed, with web-flashable release images.
- Who is it for?
- ESP32 Plane Radar fits makers and aviation hobbyists who want a small, complete build: two common parts, a printed case, browser flashing and a live ADS-B radar with runway overlays on the desk afterwards. It does not fit anyone wanting serious reception range, since it consumes a community aggregator rather than receiving aircraft directly, or anyone unwilling to do seven wires of soldering.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 20 days ago.
- What is it written in?
- Mainly C++, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 17, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
A desk gadget with real data underneath
The project is a piece of hardware firmware with a narrow, complete job: an ESP32-C3 Super Mini driving a 1.28-inch round GC9A01 display at 240 by 240, showing a circular ADS-B radar of live aircraft around a location you configure, with aircraft positions fetched from the adsb.fi open-data API roughly every five seconds.
Completeness is the differentiator here. The repository is not just firmware: a 3D-printed case with STL files and assembly instructions ships on a maker-models platform, release images exist for web flashing without a toolchain, CI builds on every push, and the documentation covers wiring, configuration, setup and troubleshooting. This is a project designed to be built by other people, which is rarer than it sounds in the ESP32 display genre.
The audience writes itself: aviation enthusiasts, plane spotters who want a desk toy with real traffic, and makers looking for an evening build with a satisfying visual payoff. None of it requires touching a compiler unless you want to.
First boot: the captive portal
Setup is done the way consumer devices do it, which is the correct choice for a gadget with no keyboard. On first boot with no saved credentials, the device broadcasts an access point named PlaneRadar-Setup, and connecting to it opens a captive portal at a local hostname or the conventional gateway address, both shown on the yellow setup screen. You set your home network and save.
The same portal remains available after the device joins your network, reachable at the mDNS hostname or the device's LAN address, for changing Wi-Fi, location, units or the runway overlay at any time. Custom settings persist in the device's non-volatile storage: latitude and longitude for the radar centre and the ADS-B query position, a miles-versus-kilometres display toggle, and the airport runway overlay switch.
The reset story is finished properly: holding the BOOT button for three seconds clears Wi-Fi, location and units and reboots into the setup portal, holding BOOT at power-on forces the same reset, and after a reset the device shows the setup screen immediately rather than looping on stale credentials. That last behaviour is the kind of detail that separates firmware that has been used from firmware that has been flashed.
The radar, drawn with intent
The display design is specified down to the pixel-level decisions. A dark blue background with subdued green rings and crosshairs, cardinal letters at the bezel, the range label on the east spoke, a white centre dot, all governed by a theme header in the source. Range presets cycle with a short tap of the BOOT button, five, ten, fifteen or twenty-five kilometres, saved to flash, with the outer aircraft scale running a third beyond the label so approaching traffic is visible before it crosses.
Aircraft rendering has two regimes. Inside the outer ring, each aircraft is a red heading triangle with a magenta speed vector clipped at the ring, tagged with callsign, type and altitude. Outside the ring but within the fetch radius, aircraft become small red dots on the screen rim at the correct bearing, an explicit direction cue rather than a distance-accurate plot, and they promote to full symbols on crossing the ring. Tag placement follows a rule, toward the centre so labels never leave the round viewport, and ground aircraft are hidden by default.
The runway overlay is the flourish: major-airport runway strips from the OurAirports dataset drawn in teal with one ICAO label per airport, toggleable from the portal, regenerable from a build script that refreshes the embedded list. A gadget that knows where the runways are is a gadget someone cared about.
Build paths: toolchain, browser, or none
Three build paths cover three kinds of builders. With PlatformIO installed and the seven-wire harness between display and board wired per the pin table, the classic path is two commands:
pio run -t upload
pio device monitorThe second path needs no toolchain: a web-flashable single binary is published for browser-based flashing over USB, targeted at the ESP32-C3's four-megabyte flash, entered by putting the board into download mode, holding BOOT and tapping RESET.
The third path is building the merged image yourself:
chmod +x scripts/merge-firmware.sh # once
./scripts/merge-firmware.shwriting a release binary, with a no-rebuild flag for when firmware is already built, and an equivalent PlatformIO-only route through the merge target. Continuous integration builds merged and split binaries as artifacts on every push to the main branch, which is why the release images stay current with the source.
Wiring is a seven-line table, power, ground, reset, chip select, data-command, data and clock, plus the BOOT button on GPIO 9. Serial runs at 115200 baud, with USB CDC on boot enabled for the Super Mini variant.
Configuration surface, and the data source
Behaviour lives in one configuration header, documented as a table: the portal's access-point name, address and mDNS hostname, with a build flag noted for mDNS support; Wi-Fi timing covering connect attempts, reconnect grace and portal timeout; the BOOT pin's tap and hold thresholds; display SPI pins, inversion, RGB order and write speed; the default location used until the portal overrides it; and the ADS-B poll interval with the ground-aircraft toggle. Range presets live in their own header.
The data source is the adsb.fi open API, version three, with the fetch radius scaling alongside the active range preset so rim dots always have data behind them. Choosing a community aggregator over a commercial API keeps the gadget free to run forever, at the dependency cost any third-party endpoint carries: if the aggregator changes or rate-limits, the radar's update loop feels it. The poll interval default of five seconds is the throttle.
The licence is MIT, releases are tagged with v1.1.3 current as of 2026-08-31, and the last push was the same day.
Who should build it, and the alternatives
The fit is the maker who wants a contained weekend project with a daily-use payoff: a handful of common parts, a printed case, browser flashing, and a desk object that quietly shows the sky working. The optional-configurable philosophy, portal over serial, presets over recompiling, means the non-programmer spouse test is actually passable.
The alternatives are the phone and the dedicated receiver. Flight-tracking apps and websites show vastly more data for free, with no build, but they live on a phone screen and none of them is an object on your desk. A dedicated ADS-B receiver with a proper aerial, feeding one of the aggregators, is a deeper hobby with real range, more parts and more antenna theory; this project deliberately consumes the aggregate rather than building it, which is the right scope for furniture.
Between those poles, Plane Radar's value is the object itself: round, live, silent, and honest about being a direction cue past the ring rather than a surveillance tool. As a piece of designed firmware, it is also a readable reference for captive-portal setup, NVS persistence and round-display rendering on the C3.
Editorial conclusion
ESP32 Plane Radar fits makers and aviation hobbyists who want a small, complete build: two common parts, a printed case, browser flashing and a live ADS-B radar with runway overlays on the desk afterwards. It does not fit anyone wanting serious reception range, since it consumes a community aggregator rather than receiving aircraft directly, or anyone unwilling to do seven wires of soldering. Verify first: that adsb.fi coverage is reasonable at your location, that your display is the GC9A01 the pin table assumes, and whether you will flash the web image or install PlatformIO. The licence is MIT, and the last push was on 2026-08-31.
Frequently asked questions
Can I build a DIY flight tracker display?
Yes, and this project is a complete path: ESP32-C3 and a round GC9A01 display, open MIT firmware with a web-flashable image, a captive Wi-Fi portal for setup, and published 3D-printable case files. It renders live ADS-B aircraft from a community aggregator rather than receiving them itself.
How is the ESP32 Plane Radar configured?
Through a web portal: a captive setup access point on first boot, then the same portal on the device's LAN address for changing Wi-Fi, location, units and the runway overlay. Range presets cycle with a short tap of the BOOT button, and a three-second hold resets everything.
Where does the aircraft data come from?
From the adsb.fi open-data API, polled about every five seconds, with the fetch radius scaled to the active range preset. Ground aircraft are hidden by default, and the dependency is the trade: the radar is only as alive as the community aggregator behind it.
Community notes