Each power-on writes a console log to the device. Older ones are rotated out as new ones arrive.

Flight logs are compressed on the board before they upload. Harder compression makes the file smaller, so it uploads faster and uses less of your data, but the board is busy compressing and cannot send its position for that time. The log itself is identical either way, so this only trades post-landing delay against file size.

The gap the board leaves between each piece of a flight log as it uploads over the mobile network. A longer gap gives the modem time to send each piece before the next, which is more reliable on a weak or congested signal; a shorter gap uploads faster where reception is strong. If uploads on a poor signal need a lot of retries, increase this. Default is 250 ms.

How long we keep this device's position history for the tracking page. This is our database, not the device: the flight log itself is unaffected.

How fast the IMU produces samples, on the gyro, low-g and high-g channels alike, and the rate every sample is kept at in the flight log. Applies at the next power-up. 2000 Hz is the default; the flight loop consumes four samples a pass at 500 Hz (two at 1000 Hz, one at 500 Hz).

What the flight log keeps from each phase. The IMU column is the raw IMU tier (gyro, low-g and high-g, every axis): launch to apogee and the landing window always keep every sample at the IMU rate; descent and the time after landing are where a lower rate saves space, and a rate above the IMU sample rate simply keeps every sample. The magnetometer and the barometer are 100 Hz in every phase.

A significant event is logged at full rate for the event plus the seconds below, whatever the phase table says. An output firing is always an event.