Unknown FIT message types — the numbers the SDK does not name

FIT files contain message types the SDK has no name for. That is normal, it is readable, and refusing the file over it is the wrong response. Here is what actually appears in real files.

Why unnamed messages exist

Every FIT message carries a global message number. The SDK profile maps some of those numbers to names — 20 is record, 18 is session. Manufacturers are free to use numbers the profile does not cover, and the profile itself is revised: our corpus contains 241 distinct profile versions, so "the SDK" is not one thing.

The important structural point: an unnamed message is still fully readable. Its definition message states its field numbers, sizes and types, so a parser knows exactly how to walk it. What it loses is the human-readable name, not the data.

What is actually in real files

Across 68,068 files we see 79 message types that carry data, of which 1 is unnamed by the profile we build against (profile.xlsx:250986b:1407f:126m): message number 69.

That number is lower than you might expect, and the reason is worth stating precisely, because it is the difference between two true statements. We count messages that produced data. A message type that appears in a file but which our mapping does not yet turn into a measurement is invisible to this count — so "79 message types" is a claim about what reaches a user, not about what the format contains.

The full list, most useful as a check against your own file:

69 · aad_accel_features · accelerometer_data · activity · ant_rx · ant_tx · aviation_attitude · barometer_data · beat_intervals · blood_pressure · camera_event · chrono_shot_data · chrono_shot_session · climb_pro · course_point · dev · device_aux_battery_info · device_info · device_settings · dive_settings · dive_summary · event · file_id · goal · gps_metadata · gyroscope_data · hr · hrv_status_summary · hrv_value · hsa_accelerometer_data · hsa_body_battery_data · hsa_configuration_data · hsa_event · hsa_gyroscope_data · hsa_heart_rate_data · hsa_respiration_data · hsa_spo2_data · hsa_step_data · hsa_stress_data · hsa_wrist_temperature_data · jump · lap · length · magnetometer_data · max_met_data · monitoring · monitoring_hr_data · monitoring_info · nap_event · nmea_sentence · obdii_data · ohr_settings · one_d_sensor_calibration · raw_bbi · record · respiration_rate · schedule · segment_lap · session · set · skin_temp_overnight · sleep_disruption_overnight_severity · sleep_disruption_severity_period · sleep_level · split · spo2_data · stress_level · tank_summary · tank_update · three_d_sensor_calibration · time_in_zone · timestamp_correlation · totals · training_file · video_clip · video_frame · weather_alert · weather_conditions · weight_scale

What a parser should do

• Read it anyway. The definition tells you the layout.
• Key the fields by number. fit:288.7 is a perfectly good identifier when there is no name.
• Record that it was unnamed rather than silently discarding it, so the gap is visible and can be closed later.
• Never guess. A field number in an unnamed message means nothing without documentation, and inventing a meaning produces data that looks real.