Summary
On v1.1.1 and v1.1.2, the radar connects to WiFi fine and the config/status page loads normally, but the aircraft list never populates — every single fetch fails with a JSON parse error. v1.0.0 works correctly with the exact same location/network/hardware. This looks like a regression introduced somewhere between v1.0.0 and v1.1.1, not an API, network, or location issue.
Environment
- Board: ESP32-C3 Super Mini
- Display: 1.28" round GC9A01
- Tested firmware: v1.0.0 (works), v1.1.1 (broken), v1.1.2 (broken) — same board, same WiFi, same two test locations for all three
Steps to reproduce
- Flash
plane-radar-v1.1.1.bin or plane-radar-v1.1.2.bin, complete WiFi setup, set any valid lat/lon.
- Device connects to WiFi and shows the nearest airport code, but aircraft never populate and the display never appears to refresh.
- Connect via USB, watch serial monitor at 115200 baud — see repeating
adsb: JSON parse error: InvalidInput on every fetch cycle.
- Re-flash
plane-radar-v1.0.0.bin with identical WiFi/location settings — works correctly, aircraft populate and refresh normally.
Bisection
- v1.0.0: works correctly
- v1.1.1: broken (same error as v1.1.2, below)
- v1.1.2: broken
Since v1.1.1 is already broken, the regression was introduced in the v1.0.0 → v1.1.1 range. Per the release notes, that range added:
- Runway overlay (major airport runway data, loaded from an embedded dataset)
- Allow configuration after initial setup
- Double-buffering added to
radar_display
Observed behavior (serial log, v1.1.2, representative of v1.1.1 too)
Tested at two very different locations — busy hub airspace (Charlotte, NC) and quiet airspace (Asheville, NC) — same error both times, first fetch attempt, regardless of aircraft count in range:
[15:03:10]adsb: JSON parse error: InvalidInput
...
[15:03:13]Connected: <SSID> IP 192.168.1.127
[15:03:25]adsb: JSON parse error: InvalidInput
[15:03:36]adsb: JSON parse error: InvalidInput
[15:03:47]adsb: JSON parse error: InvalidInput
Confirming the API itself is fine
Ran the equivalent request from a computer on the same network for both test locations:
curl -k -v "https://opendata.adsb.fi/api/v3/lat/35.16260/lon/-81.04110/dist/13.5"
curl -k -v "https://opendata.adsb.fi/api/v3/lat/35.369442/lon/-82.512647/dist/13.5"
Both return clean HTTP/2 200 responses with valid, well-formed JSON (38 aircraft and 10 aircraft respectively). Since v1.0.0 successfully parses responses from this same API/location, the API itself is not the issue — something changed in the firmware's HTTP fetch or parsing path between v1.0.0 and v1.1.1.
Suspected cause
Given the timing lines up with v1.1.1's changes, my leading guess is the double-buffering added to radar_display. On an ESP32-C3 (~320KB total RAM), permanently reserving a second full 240×240 framebuffer is a substantial, ongoing allocation. That could leave too little free heap available during the HTTPS fetch (TLS handshake buffers + HTTPClient response buffer + ArduinoJson document), causing the response body to be read incompletely or corrupted before parsing — which would produce a consistent InvalidInput regardless of location or aircraft count, exactly as observed. The runway overlay data (additional embedded dataset held in memory) could be a contributing factor as well.
Suggested fix / ask
Could free heap be checked immediately before/after the HTTPS fetch in v1.1.1/v1.1.2 vs. v1.0.0, to confirm whether double-buffering (and/or the runway dataset) is eating into the memory needed for a reliable fetch+parse? If so, either making double-buffering optional/toggleable, or increasing the HTTPClient/JSON buffer's resilience to low-memory conditions, would likely resolve this.
Happy to test a build with double-buffering disabled, or provide free-heap logging, if that would help narrow it down further.
Summary
On v1.1.1 and v1.1.2, the radar connects to WiFi fine and the config/status page loads normally, but the aircraft list never populates — every single fetch fails with a JSON parse error. v1.0.0 works correctly with the exact same location/network/hardware. This looks like a regression introduced somewhere between v1.0.0 and v1.1.1, not an API, network, or location issue.
Environment
Steps to reproduce
plane-radar-v1.1.1.binorplane-radar-v1.1.2.bin, complete WiFi setup, set any valid lat/lon.adsb: JSON parse error: InvalidInputon every fetch cycle.plane-radar-v1.0.0.binwith identical WiFi/location settings — works correctly, aircraft populate and refresh normally.Bisection
Since v1.1.1 is already broken, the regression was introduced in the v1.0.0 → v1.1.1 range. Per the release notes, that range added:
radar_displayObserved behavior (serial log, v1.1.2, representative of v1.1.1 too)
Tested at two very different locations — busy hub airspace (Charlotte, NC) and quiet airspace (Asheville, NC) — same error both times, first fetch attempt, regardless of aircraft count in range:
Confirming the API itself is fine
Ran the equivalent request from a computer on the same network for both test locations:
Both return clean HTTP/2 200 responses with valid, well-formed JSON (38 aircraft and 10 aircraft respectively). Since v1.0.0 successfully parses responses from this same API/location, the API itself is not the issue — something changed in the firmware's HTTP fetch or parsing path between v1.0.0 and v1.1.1.
Suspected cause
Given the timing lines up with v1.1.1's changes, my leading guess is the double-buffering added to
radar_display. On an ESP32-C3 (~320KB total RAM), permanently reserving a second full 240×240 framebuffer is a substantial, ongoing allocation. That could leave too little free heap available during the HTTPS fetch (TLS handshake buffers + HTTPClient response buffer + ArduinoJson document), causing the response body to be read incompletely or corrupted before parsing — which would produce a consistentInvalidInputregardless of location or aircraft count, exactly as observed. The runway overlay data (additional embedded dataset held in memory) could be a contributing factor as well.Suggested fix / ask
Could free heap be checked immediately before/after the HTTPS fetch in v1.1.1/v1.1.2 vs. v1.0.0, to confirm whether double-buffering (and/or the runway dataset) is eating into the memory needed for a reliable fetch+parse? If so, either making double-buffering optional/toggleable, or increasing the HTTPClient/JSON buffer's resilience to low-memory conditions, would likely resolve this.
Happy to test a build with double-buffering disabled, or provide free-heap logging, if that would help narrow it down further.