Embedded telemetry · field notes

What a pressure logger learns when nobody tells it where it is going

A small MicroPython instrument rode along in the cabin of five commercial sectors, sampling pressure every two seconds. It has no GPS, no route, no idea it is on an aircraft at all — only a barometer and a clock. Read back afterwards against the airframe's own ADS-B altitude, it turns out to reconstruct most of the trip on its own. It also failed in three instructive ways, which is the more useful half of the story.

The run

Airframe and cabin, on one clock

Five sectors

What it found

Three things worth the trip

The altimeter mapped the route without knowing it

Two of these sectors were not point-to-point — each set down at an intermediate airport before continuing. Nothing in the logger knows that. But on both, the cabin trace descends, settles on a plateau roughly 1,100 ft above the departure field for about seventy minutes, then climbs away again. That plateau is the intermediate airport's elevation: with the doors open, cabin pressure is simply local pressure, so the instrument was reading the ground it was parked on. A barometer alone recovered the shape of the itinerary.

isa datumbmp3902 s sampling

The 787's lower cabin altitude is real, and measurable

Composite airframes are marketed on a lower cabin altitude, and the claim survives contact with a cheap sensor. The 787-8 held its cabin at 5,995 ft — effectively the 6,000 ft figure Boeing advertises. The A330-300 flown the same week ran 7,304 ft, about 1,300 ft higher, for ten hours overnight. Same passenger, same instrument, one week apart. That difference is the entire marketing claim, and it is sitting in a CSV on a microSD card.

cabin altitude1013.25 hPacross-check

Power is the constraint, not storage

One sector fragmented across eight reboots. Another lost nearly four hours mid-flight, taking an entire intermediate stop with it. A fifth was never recorded at all, because the battery was flat before boarding. Across sixty-two boots the card had consumed 7.6 MB. Everything that went wrong was a power-budget failure wearing a data-loss costume, which is the sort of thing you only learn by flying the device rather than bench-testing it.

power budgetbrown-outsd write path

The interesting bug

A clock that lies quietly

The logger syncs time over NTP when it can find a network on the ground. When it cannot, it restores the clock from the card — and the restored value carries the date forward correctly while silently losing however long the device was powered off. Timestamps stay plausible. They are simply early, and they get earlier with every reboot.

Four boots in this run had a real NTP fix. Nine did not. Nothing in the data announces which is which except one honest line in the event log, so a trace can look perfectly well-formed and still sit hours away from where it belongs. The fix was to stop trusting the logger's clock where it was not anchored, and re-derive the offset from an external reference: the airframe's own ADS-B track, which puts a hard timestamp on touchdown. That moved one sector by 4h35 and another by 3h17 — and corrected an earlier reconstruction that had anchored to the published timetable instead, which was wrong by up to 39 minutes because both aircraft landed early.

The general lesson is dull and worth repeating: a timestamp that looks reasonable is not evidence that it is right, and a device with no network is not in a position to know what time it is. Log the provenance of the clock alongside the reading, or you will not be able to tell the difference later.

Build

What it is

Raspberry Pi Pico 2 W running MicroPython. A BMP390 barometer on I²C, microSD over SPI for the log, and a low-power e-ink panel for a glanceable readout. Cabin altitude is derived from pressure against the fixed ISA sea-level datum of 1013.25 hPa — deliberately not corrected for local weather, because that is the definition of the quantity rather than an oversight.

The write path is built for sudden power loss: events are buffered in RAM while a freshly mounted card refuses I/O, the SD bus is pinned to a rate the card actually handshakes at rather than the one the driver claims, and a boot that cannot mount storage still runs and still displays. Most of the hardening in it exists because something failed in the air first.

micropythonrp2350bmp390spi / sde-inkads-b

A hobby instrument, not a certified one. Nothing here is an airworthiness measurement, and cabin altitude as recorded is a physical quantity, not a comment on any operator.

More

Back to the rest of the work

All work About