0 253 4 0x86 = 1058128830 1 0 4 0x85 = 378104392 2 1 4 0x85 = -1322736078 3 5 4 0x86 = -1 4 14 4 0x86 = -1 5 15 4 0x86 = -1 6 73 4 0x86 = 120 7 78 4 0x86 = 13556 8 2 2 0x84 = 65535 9 6 2 0x84 = 65535 10 3 1 0x02 = 255 11 4 1 0x02 = 255 12 13 1 0x01 = 27 13 53 1 0x02 = 255So, one of my records has 14 fields. The first number is the "id" (253 is a timestamp). The next number is the data size in bytes. Then we get a hex value that indicates a data type. Finally I show the value for that field in the first record.
The "data type" field is not terribly useful. I decipher it using in
The "id" field is more useful. I decipher it using information in the python profile.py file from the SDK.
First you do a lookup using the global id "20" for "record_mesgs" then look at "fields" for the following.
This is Id, name, type, units, scale/offset
253 timestamp date_time s 1/0 0 position_lat sint32 semi 1/0 1 position_long sint32 semi 1/0 2 altitude uint16 m 1/0 3 heart_rate uint8 bpm 1/0 4 cadence uint8 rpm 1/0 5 distance uint32 m 1/0 (accumulated) 6 speed uint16 m/s 1000/0 13 temperature sint8 C 1/0 14 ? 15 ? 53 fract cadence uint8 rpm 128/0 73 enh speed uint32 m/s 1000/0 78 enh altitude uint32 m 5/500As an example of how scale and offset work, here is how you calculate elevation in feet:
alt = alt/5.0 - 500.0;
alt *= 3.280839895;
The units for lat and long are in what Garmin calls "semicircles".
0x80000000 is 180 degrees (pi radians). Since this is a signed value,
this works out for longitude (which varies from -180 to +180)
as well as for latitude (which varies from 0 to 90).
The timestamp has unique issues as well. Garmin counts seconds from the "Garmin Epoch" which is:
midnight on December 31, 1989 UTCThis is offset from the usual Unix epoch by 631065600 seconds. (The Unix epoch is 1970–01–01T00:00:00Z. Unix time will "rollover" in January 2038. The Garmin count will rollover 19 years later (January, 2057).
Tom's backpacking pages / tom@mmto.org