We are seeking authoritative guidance on Connect IQ SensorLogger FIT export for a fēnix 7X Sapphire Solar.
Our known development toolchain is Connect IQ SDK 9.2.0; the reviewed decoder was garmin-fit-sdk 21.214.0 with FIT Profile 21.214.0Release. These are development/decoder versions, not an established identification of any legacy installed producer. Historical capture-to-build/firmware linkage remains unresolved. We are asking about documented semantics, not asserting a firmware defect or validated physical accuracy.
### 1. SensorLogger-to-FIT calibrated-axis representation
For a `SensorLogging.SensorLogger` supplied through ActivityRecording's `sensorLogger` option, what version-applicable semantics govern:
- `accelerometer_data` (165): `calibrated_accel_x`, `calibrated_accel_y`, `calibrated_accel_z` (fields 5–7, float32, declared g)?
- `gyroscope_data` (164): `calibrated_gyro_x`, `calibrated_gyro_y`, `calibrated_gyro_z` (fields 5–7, float32, declared deg/s)?
Are those exported values already expressed in the declared units for this path? Which transformations, coordinate-frame/sign conventions, gravity treatment and filtering are documented? Please distinguish device-producer work, FIT decoder scaling and application responsibility, including prerequisites for applying additional calibration metadata.
We do not assume that separate live AccelerometerData/GyroscopeData callback interfaces define the [SensorLogger](developer.garmin.com/.../SensorLogger.html) export transformation.
### 2. Motion clocks and correlation applicability
For these motion messages, what are the time bases and subsecond composition rules for `timestamp`, `timestamp_ms` and indexed `sample_time_offset`?
What prerequisites establish whether `timestamp_correlation` (162), including `timestamp`, `system_timestamp` and `local_timestamp`, applies to the motion clock and supports mapping to native `session.start_time`? Please clarify conversion direction, scope, reset/wrap conditions and precision limits when fractional correlation information is unavailable. A generic documented worked example would help.
An applicable motion-to-native-session mapping has not been established. We are not proposing an arbitrary shift or treating matching stored ticks as simultaneous physical acquisition. This is a sensor-export/correlation question, distinct from app/native timer-event UTC rounding.
As resolved background only, the [SensorLoggingStats reference](developer.garmin.com/.../SensorLoggingStats.html) describes `samplePeriod` as accumulated logged seconds, not an inter-sample interval. We are not reopening that terminology.
For both sections, please identify device, firmware, API and FIT/Profile conditions and official definitions or errata. Please distinguish documented guarantees from suggested experiments; current documentation cannot by itself authenticate an unidentified historical producer. No personal recordings, measurements or identifiers are included.