Most air-cargo tracker specifications describe radio suspension as a feature. One line on a datasheet, usually beside the battery figure: flight mode supported.
It is not a feature. It is a state machine that has to behave correctly on an aircraft nobody from the engineering team is sitting on, and the useful version of the requirement is a short list of things it has to be able to demonstrate.
Carrier documents say less than people expect. Lufthansa Cargo's current device overview, version V.23 dated May 2026, puts the whole obligation in one sentence: "Data transmission must be suspended and disabled during flight in order to comply to air safety regulations." An older Lufthansa document, Rev. 07 of February 2024, adds a technical expectation for devices transmitting above 100 mW - "Automated and prolonged radio suspension during flight using multiple modes of redundancy" - and one line that quietly sets the acceptance bar: "Deactivation has to be verified in aircraft environment."
Regulators give the principle rather than the implementation. FAA's cargo hazards guidance requires only that powered devices "will not interfere with aircraft," pointing at 14 CFR § 91.21. EASA is clearer about who decides: "EASA does neither certify nor approve cargo tracking devices", and "Operators remain responsible to authorise the use of PEDs on board their aircraft."
So the specification is thin on purpose, and the engineering burden sits with whoever built the device. Five things have to hold.
One. The device has to know it is airborne, and be wrong safely
Detection is usually some combination of barometric pressure change, loss of cellular service, accelerometer signature, and time since last fix. Each has a failure mode. Pressure changes in a climate-controlled warehouse and inside a pressurised hold are not as different as a bench test suggests. Cellular service disappears in tunnels, cold rooms, and the middle of a stack of steel containers.
The question is not "does it detect flight." It is "what happens when it guesses wrong, in both directions." A device that decides it is flying in a warehouse goes quiet for hours and nobody notices until the data is missing. A device that decides it has landed while still in the air transmits when it should not. Only one of those is a safety issue, and it is the one that has to be biased against.
Two. Suppression has to cover every radio, not just the modem
Lufthansa's phrase is "multiple modes of redundancy," and the reason is that a modern shipment tracker is rarely a single-radio device. Cellular, Bluetooth advertising, Wi-Fi scanning for position, sometimes a sub-GHz link to a sensor tag. Disabling the cellular stack while a Bluetooth beacon continues to advertise every second is not radio suppression, it is a partial answer that happens to look complete on a spectrum analyser pointed at the wrong band.
Wi-Fi scanning is the one most often missed, because it is filed mentally under positioning rather than transmission. Scanning is transmission.
Three. Sampling does not stop when the radio does
This is the difference between a device that goes quiet and a device that goes blind, and on a temperature-controlled shipment it is the whole point. A flight is often the longest single leg of the journey and frequently the harshest. If the sensing schedule is tied to the reporting schedule, then switching off reporting switches off the evidence for exactly the hours the consignee will ask about.
Two clocks, not one. Sample on its own cadence, transmit on another, and let the second one be interrupted without touching the first.
Four. The buffer has to survive a reset, and replay in the right order
A long-haul flight plus ground handling plus a customs hold can put a device offline well past the design assumption. The buffer has to be sized for the worst leg rather than the average one, and it has to say what it does when it fills: overwrite the oldest readings, stop recording, or thin the sample rate. All three are defensible. Silently doing one of them while the datasheet implies another is not.
Then there is the reset. Batteries brown out in cold holds, and cold does unhelpful things to cell impedance before it does anything visible to a fuel gauge. If a reset clears the buffer, the device has lost the flight. If the buffer survives but the records replay stamped with the time they were uploaded rather than the time they were taken, the device has produced a timeline that is wrong in a way nobody downstream can detect.
Five. Reconnect has to be boring
On landing, a few hundred devices in the same hold all decide within a minute or two that service is back. What they do next is a design decision that gets made by default far too often: every device dials immediately, uploads its entire backlog at once, and some fraction fails partway through and retries from the beginning.
Staggered reconnect with jitter, resumable upload, idempotent records with stable identifiers so a duplicate is recognisable as a duplicate. None of this is exotic. It is simply the part that never appears in a bench test, because a bench test has one device on it.
Why the list is short, and why it is still hard
Every item above is ordinary embedded engineering. What makes the set difficult is that none of it is visible from the outside, and almost none of it is testable in the environment where it matters.
Consider what different kinds of evidence actually cover.
| Evidence | What it shows | What it leaves open |
|---|---|---|
| Bench test in a chamber | Detection thresholds and radio-off behaviour under controlled inputs | False positives in real environments; multi-device reconnect; reset during a real cold soak |
| Spectrum measurement | That the bands measured are quiet | Bands not measured; scanning behaviour; intermittent advertising between sweeps |
| A real flight log | The whole sequence on one route, with real timestamps | Whether the next production batch behaves the same way |
| Production test at end of line | That each unit carries the firmware and radio configuration that was validated | Field behaviour, thermal margin, anything time-dependent |
The last row is the one that gets skipped, and it is the one that decides whether the other three still mean anything six months later. A validated state machine is a property of a firmware build and a radio configuration, not of a model name. If the end-of-line test does not check which build is on the unit and that suppression actually engages, then the flight log from the pilot batch is a statement about the pilot batch.
None of this makes a device acceptable to any particular airline, which stays an operator decision made per carrier and, as several carrier documents note, per routing. It makes the device honest, which is a lower bar and a necessary one.
Questions that come up
Is a flight mode that only pauses uploads good enough?
No, on two counts. Pausing uploads while other radios continue to transmit does not meet a requirement to suspend and disable transmission, and pausing uploads in a way that also pauses sensing destroys the record for the longest leg of the journey. The two schedules need to be independent.
Does automatic detection have to be automatic?
Lufthansa's Rev. 07 guidance asks for automated suspension with multiple modes of redundancy for devices above 100 mW, which implies detection rather than a manual switch. Manual arming shifts the failure mode to the person handing over the freight, which is a worse place for it. Both approaches need the same verification: that transmission actually stops.
How long should the offline buffer be?
Long enough for the worst leg the device will see, not the average one - a long-haul sector plus ground handling plus a customs hold, sampled at the cadence the shipment requires. The number matters less than stating the overflow policy, because a buffer that silently overwrites and a buffer that silently stops look identical in a datasheet and produce very different records.
Why does replay order matter if every record has a timestamp?
Because the timestamp is often applied at the wrong moment. A record stamped when it reaches the server rather than when the sensor read it produces a plausible-looking timeline in which a flight's worth of readings all occur in the same minute after landing. Sample time has to be captured on the device and carried through the upload unchanged.
Does a passing IATA assessment settle any of this?
Not on its own. The IATA Air Cargo Device Assessment validates a device against Recommended Practice 1693 for electromagnetic compatibility and battery safety, and IATA states plainly that it "does not substitute airline approval for device use on board." Behaviour in flight remains something each operator authorises, and something the device still has to do correctly.
Before the next batch ships, pull one unit off the line, read back its firmware build, put it in a chamber, and watch every radio it has go quiet.