Hi James,
Thanks for publishing this - it was a useful reference while I built an independent SeaTalk-1 library. I validated my codecs against live Raymarine ST60 instruments (a Wind, a Compass, and a Multi as a repeater) and found a few places where this library's byte order does not match what the real bus uses. Flagging them in case it helps anyone who finds the repo.
The root cause is that two_bytes(), and the matching build_* functions, treat every 16-bit field as
big-endian. SeaTalk byte order is actually per-datagram: most 16-bit fields are little-endian, with a couple of big-endian exceptions.
Confirmed on hardware:
- ST_50 / ST_51 latitude and longitude minutes are little-endian. parse_lat_position and parse_lon_position use two_bytes() (big-endian), so a real ST60's position decodes to the wrong minutes (an intended 30.00' reads as ~62.83').
- ST_85 navigation-to-waypoint: the cross-track-error and distance are 12-bit fields packed as (dataByte << 4) | nibble (the data byte is the high 8 bits, the attribute nibble the low 4). build_waypoint_navigation packs them the other way (x = value >> 8, xx = value & 0xff), which an ST60 reads as garbage (2.61 nm shows as 0.81 nm).
- ST_58 is genuinely big-endian, so two_bytes() is correct there. The issue is the blanket assumption, not every field.
For reference, of the datagrams I checked the only big-endian 16-bit fields are ST_10 (apparent wind angle) and ST_58 (combined lat/lon); the rest are little-endian. Thomas Knauf's Technical Reference matched the hardware in every case where it states the byte order explicitly.
Happy to share the validated layouts if useful. Thanks again for the library.
Gerhard Malan
Hi James,
Thanks for publishing this - it was a useful reference while I built an independent SeaTalk-1 library. I validated my codecs against live Raymarine ST60 instruments (a Wind, a Compass, and a Multi as a repeater) and found a few places where this library's byte order does not match what the real bus uses. Flagging them in case it helps anyone who finds the repo.
The root cause is that two_bytes(), and the matching build_* functions, treat every 16-bit field as
big-endian. SeaTalk byte order is actually per-datagram: most 16-bit fields are little-endian, with a couple of big-endian exceptions.
Confirmed on hardware:
For reference, of the datagrams I checked the only big-endian 16-bit fields are ST_10 (apparent wind angle) and ST_58 (combined lat/lon); the rest are little-endian. Thomas Knauf's Technical Reference matched the hardware in every case where it states the byte order explicitly.
Happy to share the validated layouts if useful. Thanks again for the library.
Gerhard Malan