Rick Gleason added that edit to the wiki as a result of my experiences with the SD128, which were detailed on the page you linked to.
I'm no expert on either NMEA0183 or SeaTalk, so I only had my own practical experience with the device onboard to use as well as the online resources like Knauf's SeaTalk document. I'm also very much only an amateur coder and don't have the skills to dive into a larger codebase to start making edits.
My experience was pretty straightforward: my boat
has older ST60 instruments and an ST1000+ autopilot
, all on a SeaTalk v1 network along with the RC520 chartplotter
. The chartplotter
displays the correct COG and heading (in either magnetic or true degrees). Once the data on the SeaTalk network had gone through the SD128, translated to NMEA0183, and onwards to OpenCPN
on my laptop
, the COG and heading info were no longer correct. I would see the wrong COG predictor line and my heading would also be wrong, and it always seemed to be wrong by exactly my magnetic declination (16E here near Vancouver
Canada). Additionally, my track in OpenCPN was always very jagged - it seemed to jump around in ~20 m increments instead of smoothly updating every few metres.
The wiki page you linked to accurately describes my experiences and my thoughts on what the causes were. There were a few more minor issues (also described on the wiki page). As I said, however, I'm no expert so would likewise welcome a more experienced person to look over my post on the wiki page and chime in.
My main issues with the SD128 Bridge were:
1) its code doesn't allocate more than 1 byte for latitude and for longitude, which means it is limited to 0.01 min resolution (i.e. ~18 m), not sufficient for modern navigation
chartplotters or OpenCPN display. It makes the boat
jump around in 18 metre increments, making a jagged track of straight 18 m east-west or north-south segments. The Bridge appears to pull its lat/long info from SeaTalk datagrams 50 and 51 which according to Knauf's document only provide 0.01 min resolution. The fix would be to implement lat/long with datatypes of sufficient size to store 0.001 min resolution and pull this from datagram 58, which also gives lat/long with this higher precision (~1.8 m).
2) I think you're reading datagram 53 wrong. My reading of Knauf's reference is that COG (i.e. the track of the boat, calculated directly from sequential lat/long position data) is output in degrees magnetic in this datagram, so it needs to be corrected for magnetic declination at your location to give COG in degrees true. My understanding of your code is that you are using this datagram's data directly as-is in RMC sentences, so it gives the wrong COG predictor arrow in OpenCPN, off by the amount of local magnetic declination - in areas with low magnetic deviation like Germany
, you probably don't even notice the mismatch, but here on the west coast
where it's around 16 degrees east, it makes a big difference.
3) I think you're also inserting datagram 53 into the VHW sentence, which would also be wrong, as this requires heading data, not COG (track) data. From our correspondence, it seemed to me that you might be sometimes mixing up heading and track. The RMC sentence provides COG i.e. based on the movement of the boat and not its heading, whereas VHW gives the heading i.e. which way boat is pointing, not the direction it's going (as well as the speed through water). Compass heading in SeaTalk comes from a couple different datagrams (9C, 84, 89).
It seems to me like the raw heading and COG data on the SeaTalk network is always given in degrees magnetic, and the magnetic declination is available via datagram 99. You need to correct the COG for this declination before using it in an RMC sentence, and you need to ensure that the VHW sentence is constructed from heading data, not from COG.
I'm open to being wrong about any or all of this, but I did spend a fair bit of time trying to understand how the Bridge was displaying erroneous data, and I think the wiki page gives a good summary of my conclusions. At the end, I decided that the output of the SD128 wasn't correct, and I pulled it from the boat pending fixes.
I'm happy to help troubleshoot further as time permits, and hopefully someone who knows SeaTalk a lot better than me will also chime in.