Building a METAR aviation weather map on an ESP32

tedder — Sun, 16 Aug 2026 16:00:00 GMT

I fly, which means I look at weather constantly. METARs — aviation routine weather reports — tell you ceiling, visibility, and flight category at any reporting station. The colors VFR/MVFR/IFR/LIFR map directly to green/blue/red/magenta in most flight planning apps. A while ago I decided to make that visual and physical: an LED strip that stays on my desk and shows current flight conditions at airports along my usual routes.

Here's how it evolved, and what I learned.

Hardware

The platform is an Adafruit QT Py ESP32-S2. It's small, has native USB, runs CircuitPython or ESP-IDF, and has enough flash and RAM for a WiFi-connected LED controller. A WS2812B strip plugs into one of the analog pins; an SSD1306 OLED 128×32 hangs on I2C for status readout.

The strip has one LED per airport. Right now I track a handful of stations — local fields and a couple of en-route ones. The OLED shows the last update time and a count of how many airports had valid METARs.

The backend: don't do METAR parsing on the microcontroller

Aviation weather APIs return JSON blobs or text, require TLS, and occasionally change schema. Parsing that on a microcontroller is painful — you burn flash on JSON libraries, you fight TLS certificate chains, and every API hiccup means you're debugging on a device with no debugger.

My approach: offload all of that to a Lambda@Edge function. The microcontroller sends a single HTTP request with a list of airport codes and gets back a simple CSV:

KPDX,VFR,0-127-0,8,0
KTTD,VFR,0-127-0,12,0
KHIO,MVFR,0-0-127,24,0

Fields: ICAO code, flight category, RGB color tuple, age in minutes, stale flag. The microcontroller splits the line, applies the color directly. No parsing, no JSON, no TLS from the device side (Lambda handles it outbound). This architecture has been solid — the device just asks "what color are these airports" and gets an answer.

Flight categories to LED colors

Category	Condition	Color
VFR	> 3000ft ceiling, > 5sm vis	Green (0, 127, 0)
MVFR	1000–3000ft or 3–5sm	Blue (0, 0, 127)
IFR	500–1000ft or 1–3sm	Red (127, 0, 0)
LIFR	< 500ft or < 1sm	Magenta (255, 22, 199)

The stale flag comes back set if the METAR is older than a threshold. I dim stale airports slightly to indicate "this data is old."

CircuitPython phase

The first version ran CircuitPython. CircuitPython is genuinely great for a project like this: the REPL is fast, you edit files over USB mass storage without any flashing ceremony, the Adafruit ecosystem has everything you need, and iteration is just save-file-watch-reload.

It held up well through about a year and a dozen feature additions. I added a web server for live airport configuration, NTP sync, a debug flag bitmask stored in NVM (persistent across reboots), a watchdog timer, and structured logging.

Then CircuitPython's networking started biting me.

The DNS problem

On certain builds of CircuitPython for the ESP32-S2, lwIP's DNS resolver would silently fail. The device appeared connected — it had an IP, it could ping — but getaddrinfo() would hang or return errors on the first few calls after boot. The workaround I ended up with was a SmartPool wrapper around socketpool.SocketPool that intercepts getaddrinfo() and falls back to raw UDP DNS against Cloudflare and Google if lwIP's resolver fails:

class SmartPool:
    def __init__(self, pool):
        self._pool = pool

    def getaddrinfo(self, host, port, *args, **kwargs):
        try:
            return self._pool.getaddrinfo(host, port, *args, **kwargs)
        except Exception:
            # Raw UDP DNS fallback to 1.1.1.1, then 8.8.8.8
            return self._raw_dns_lookup(host, port)

All the Adafruit libraries (adafruit_requests, adafruit_ntp, etc.) receive SmartPool instead of the raw pool, so the fallback is transparent. It worked — but it's the kind of thing that makes you wonder if you're approaching the floor of what CircuitPython's network stack can reliably support.

WiFi roaming detection

The device is always-on and needs to survive WiFi disconnects. CircuitPython doesn't give you a clean reconnect event — you discover the connection is dead when the next HTTP call throws. My workaround: catch the exception, set requests = None, detect None at the top of the fetch loop, reconnect, reinitialize the session. Works, but fragile.

Production reliability: debug flags and watchdog

One pattern I've carried across all my embedded projects: a 32-bit debug bitmask stored in persistent memory, and a hardware watchdog.

The bitmask lets me POST the device's health history to a monitoring endpoint. Each bit tracks a category of failure — WiFi connect failures, HTTP exceptions, NTP failures, NVM write failures. Even if the device reboots and the exception is gone, the bit stays set until explicitly cleared. When I look at the debug page later, I can see "WiFi connect failed 3+ times" even if the device is healthy now.

The watchdog is set to 60 minutes (this is an always-on device, not deep-sleep). It gets fed in the WiFi check, the METAR fetch, and the main loop. If anything hangs — which on CircuitPython occasionally happens with adafruit_requests on flaky connections — the device reboots rather than sitting stuck forever.

ESP-IDF rewrite

The CircuitPython workarounds accumulated enough that I started an ESP-IDF C rewrite. The motivating factors:

ESP-IDF WiFi is reliable in ways CircuitPython's isn't on this chip. No SmartPool, no requests = None dance, no lwIP DNS workarounds.
OTA updates. CircuitPython devices update by copying a file over USB. ESP-IDF devices can pull firmware from an HTTPS endpoint and self-update. For a device that sits on my desk, this matters less — but it's a pattern I use across all my ESP32 projects now.
Performance. The OLED rendering in CircuitPython is noticeably slow at higher refresh rates. In C it's instant.

The backend CSV format and airport list format stay identical. The behavior from outside — what the LEDs show, what the debug page returns — is the same. The rewrite is a platform swap, not a feature change.

What I'd build differently

The Lambda@Edge backend was the best decision I made early. Keeping the wire protocol simple (plain HTTP, CSV responses) meant the firmware stayed simple. Anytime the METAR API changed, I updated the Lambda — the device didn't know anything changed.

If I were starting over, I'd skip CircuitPython for a project that's always-on and WiFi-dependent. CircuitPython is excellent for sensors, USB gadgets, interactive prototyping. For a device that needs to run unattended for months on a network connection, ESP-IDF's networking stack is just more reliable.

The debug flag pattern is worth copying to any embedded project. Persistent error history — even across reboots — is invaluable when you're trying to figure out why a device that's been running for a week started acting up.

blog.tedder.dev (Posts about led)