Data uploads
Flight logs upload themselves. Land, recover the rocket, and by the time you're back at the flight line the flight is usually already in your AltimeterCloud account, charted and ready to explore. There are no storage limits on the archive, every flight you ever upload stays there, and each one can be downloaded whenever you like, as the original signed .aclz file or as ready-made CSV. This page covers how the transfer actually works, because it is engineered for the environment rockets actually fly in: remote sites, weak signal, and a modem that has other jobs to do at the same time.
When uploads happen
The cellular radio is off during flight, as aviation and telecoms regulations require, so uploading is a ground activity. Once landing is detected and the radio is restored, the upload begins on its own, and if the landing spot has poor signal the device keeps retrying, every minute for the first twenty minutes, then backs off to conserve power. Nothing is ever at stake in a failed attempt: the flight sits safely in storage, exactly as covered on the Data storage page, and the upload completes whenever the device next has usable connectivity, surviving power-offs and days in a range box along the way. A flight is only ever marked done when the cloud has verified it complete.
How the transfer works
A flight log travels as a stream of 900-byte chunks, each one encrypted, authenticated and carrying its own integrity check, over the UDP data channel described on the Compression & Encryption page. The device first reserves the transfer with the cloud, then sends chunks in bursts sized to the network it's actually on, larger bursts on LTE-M, smaller on the slower NB-IoT, with deliberate pauses between bursts so the modem is never monopolised: live tracking, status and your commands keep flowing throughout an upload. The pacing between packets is a setting, tunable from the website, so a site with dreadful signal can trade speed for reliability.
Then comes the part that makes weak-signal uploads dependable: reconciliation. After a burst settles, the device asks the cloud exactly which chunks it holds, and the cloud answers with what's missing; only those chunks are sent again, and the cycle repeats until nothing is missing. Packet loss therefore costs retransmission of the lost pieces alone, never a restart, and a transfer interrupted halfway continues from what's absent rather than from the beginning. Even the settling time before each check is adaptive: it scales with the measured round-trip to the server, so a user far from the server, a congested cell, or the naturally slower NB-IoT all get the right wait automatically rather than a one-size guess.
When things go badly
Persistent trouble is handled with patience rather than stubbornness. A run of consecutive send failures pauses the upload, with retries a few minutes apart before backing off entirely, because hammering a dead link wastes battery that tracking might need. Whatever happens, the ordering of guarantees holds: the flight is on the device, the device knows it hasn't finished, and the cloud accepts nothing unverified, so the worst outcome of the worst signal is a delay, never a loss and never a corrupted flight in your account. The server independently checks each completed file's signature before it's archived, so what appears in your account is provably the flight your device recorded.
In your account
Once uploaded, the flight appears in your AltimeterCloud account with the full interactive charts, and it stays there with no storage limits. Every archived flight offers downloads of both the original .aclz, byte-identical to what the device produced, signature intact, and a converted CSV for spreadsheets and your own analysis, so you never need to touch the file format yourself unless you want to. Smaller items travel too: test-fire traces and diagnostic logs upload over the command channel on request, so bench work benefits from the same no-cables convenience as flights.
Uploading by hand
For the site with no usable cellular at all, or simply when you'd rather not wait, there is a manual route: copy the .aclz files off the device over USB, where it appears as an ordinary read-only drive, and drop them into the upload tool at altimetercloud.com/upload. The result is identical to an over-the-air upload, the flight lands in your account, charted, archived without limits. The tool verifies every file's Ed25519 signature before accepting it, so an edited log is rejected outright, and that check makes the tool useful for a second purpose: drop any .aclz in, from anyone, and you have an independent confirmation that the file is bit-for-bit what a real device recorded, unmodified since the moment it was signed.