← All Guides

Where AltosUI stores your .telem files

Every flight AltosUI hears on the radio becomes a .telem file on your phone. That file is the full radio capture for one flight — the thing you replay later, feed to the Flight Report, hand to the desktop workbench, or email to a clubmate. This guide explains exactly where those files live, how to get them on and off your device, and how to read the filename without opening it.

What a .telem file is

A .telem file is a packet-for-packet recording of the telemetry stream AltosUI received from a flight computer during one flight. It is the same stream that drove your live Flight and Recover tabs, saved to disk so you can read it later on the phone, on the desktop, or both.

The file is named by date, serial, flight number, and receiver. A real name looks like 2026-04-18-serial-1243-flight-0007-via-....telem. You can tell at a glance which day the flight happened, which airframe (by serial), the sequential flight number, and which receiver captured it. That means a folder of files sorts chronologically without any extra work.

Where the files live

AltosUI writes every received flight into the app's Documents folder. iOS exposes that folder in two places:

  • The Files app on your iPhone or iPad — open Files, tap Browse, and find AltosUI under On My iPhone (or On My iPad). Every .telem file for every flight the app has received is there.
  • iTunes Document Sharing — plug the device into a Mac or PC, open the Finder (or older iTunes) sidebar, select the device, and AltosUI's documents folder is available for copying files off or onto the device.

Either path gives you the same set of files. Pick whichever is convenient — Files for in-the-field sharing, iTunes Document Sharing for bulk copy at the end of a launch day.

“My telemetry folder is empty”

This is the single most common thing people ask about, and the answer is usually the same: if the flight computer was in Idle mode rather than Flight (pad) mode, it was not transmitting. No packets on the air means no packets captured, which means no .telem file is created. The folder is empty because AltosUI heard nothing worth recording.

Idle mode is a prep-area configuration state — useful at the prep table or trailer for querying the device, reading back settings, or running a continuity-protected igniter test before the rocket goes to the pad — but it is not a flying state and it is not something you do once the airframe is on the rail. Once the flight computer is at the pad, powered up vertical, and in Flight/Pad mode, it transmits, AltosUI records, and the file appears in Documents at the end of the flight.

If you expected a file and do not see one, the FAQ has the full walkthrough for diagnosing this. The short version: check that the flight computer actually transmitted during the flight.

Reading a .telem file without opening the app

AltosUI registers .telem with iOS so the files get a Altus Metrum thumbnail in Files and a rich Quick Look preview. Tap the file once and you see a summary card: date flown, rocket serial, callsign, device type, max altitude, max ground speed — no app launch required.

The preview works for any .telem file, including ones AltosUI has never seen before. That means a file arriving via iCloud Drive, AirDrop, or email previews the same way as a file your own receiver captured. See the telemetry file previews feature page for what the card looks like.

Getting files into AltosUI from outside

AltosUI reads .telem files from anywhere iOS can deliver them. The supported paths include:

  • iCloud Drive — browse to the file in Files, tap to preview.
  • AirDrop — accept an incoming file and it goes to the usual iOS share flow.
  • Email — tap the attachment, preview it, and share into AltosUI.
  • Quick Look — the preview card from any source.
  • Share → Open with AltosUI — from the preview, generate a full Flight Report without importing the file or changing your tracker list.

One honest limitation: AltosUI does not register as an iOS Document Provider, so you will not see it as a browseable location from other apps. Files come in through Quick Look, Share, or Open-in — not through AltosUI reaching out into external providers.

Opening a Flight Report from Files

A practical workflow many fliers use: keep your .telem files in iCloud Drive, tap one to preview, and from the Share sheet choose Open with AltosUI. That generates the on-device Flight Report for the flight without changing your tracker list or re-importing anything. Long-pressing the file in Files and choosing Open with AltosUI works too.

The Flight Report runs entirely on the phone. You can read it on the drive home, export a paginated PDF, and email it — see the flight report PDF guide for the full workflow.

What about .eeprom files?

AltosUI iOS does not read or produce .eeprom files. That is desktop territory by design. An .eeprom file is the onboard log pulled over USB from a recovered flight computer — the lossless, full-rate record that AltosUI desktop reads for records-grade analysis and motor-performance work.

The three-tier progression is worth repeating: tier one is the iOS Flight Report from the .telem capture at the launch site; tier two is AltosUI desktop reading that same .telem file; tier three is AltosUI desktop reading the .eeprom file from the board itself. The iOS app owns tier one, cleanly, and hands off to the desktop for the rest.

A small filename habit that pays off

The default filename encodes everything you need to find a specific flight later: date, serial, flight number, receiver. Do not rename files unless you have to — keeping the pattern means a year of launches still sorts chronologically and stays searchable. If you archive a folder of files to a laptop or a shared drive, the names will still make sense to anyone who touches them.

Using .telem files with Flight Replay

One of the quieter superpowers of the .telem format is that Flight Replay runs any file through the full AltosUI pipeline. That is the same Pad, Flight, Map, and Recover tabs you used during the live flight, driven by the recorded packet stream instead of the radio. State transitions fire, voice announcements speak, displays update — it behaves exactly as it did the first time, because it is playing back the actual packets.

Two timing modes make this practically useful. Actual reproduces the original packet intervals, so a 60-second flight takes 60 seconds to replay — the right choice when you want to study what happened in real time. Fast delivers packets at one-second intervals so you can scan through a flight quickly or verify a file captured all the way to landing. Both modes work with recordings from every supported flight computer.

If your Documents folder is empty when you expected a file, work through the FAQ first. If the answer is not there, support will help you figure out what the receiver actually heard.