COG, true HDG, mag COG all wrong

[codger]

Please help me understand whether my problem is with OpenCPN or with the input NMEA stream!

I have ST60 instruments, an ST4000+ autopilot, and an old Raymarine GPS/chartplotter, all talking together on a SeaTalk v1 network. The SeaTalk is fed into a GadgetPool NMEA Bridge128SD. The Bridge translates SeaTalk data into NMEA sentences. My laptop runs OpenCPN on Ubuntu and reads the NMEA stream via a USB port.

The bridge outputs (among other things) GLL, RMC, and HDM. Some examples of data read by OpenCPN (from random logs taken a few months ago... the fluxgate compass may not be calibrated correctly in these data, as I did that later)

$IIRMC,202537,A,4917.78,N,12317.08,W,004.6,079.0,1 50718,019,E*68
$IIGLL,4917.78,N,12317.07,W,202537,A*2B
$IIHDM,062,M*38

RMC is giving a track angle here of 079 T, and a magnetic variation of 19 E (WMM plugin reports 16.2 E at my location; I presume I can probably manually adjust the variation on the chartplotter and will do so next opportunity. But 19 E is close enough for present purpose). HDM reporting heading of 062 M, looks as though heading more or less matches COG.


Attached screenshot shows my problem (again, NMEA data above are from a different sail):


I was following the sector lights into Vancouver's False Creek with an azimuth of 131 T / 115 M (as measured on the chart). Once on the sector light, and with the bow pointing directly at the light, I calibrated the fluxgate compass via the ST60 autopilot to read 115 M. This screenshot taken shortly thereafter.

One can see that my true COG as marked by the blue track, approximately on the path of the sector light, so around 131 T / 115 M. My Mag HDG is about right (111 M) for the purposes of this exercise, as is my heading indicator (thin dashed line) in OpenCPN. However the dashboard gives COG 112,True HDG 112, and Mag COG 93.

Any ideas where to look for the problem? (I realise I should have saved the NMEA stream from this time, but hope that the above sample shows what the data probably looked like).

Thank you!
Dave

[rgleason]

What is your COG dampening factor under preferences > appearance please?
Is it 100? (Slow)
https://opencpn.org/wiki/dokuwiki/do..._cog_ir_filter

[codger]

Both the SOG and COG damping are set to 0 (zero), which I presume is the default value, since I have not made any changes to this since installation. (Should they be set to something different? The manual suggests 10.)


I was out today recalibrating the fluxgate compass deviation (hence the circles on my track) and on the way back in to mooring followed the same sector light but this time grabbed the NMEA stream in VDR recorder as well.

See the two attached screenshots (from the VDR replay).

One screenshot shows the dashboard as well as my track. The heading predictor appears correct i.e. it points right at the sector light, which is what the bow points to. The COG predictor line doesn't match with my actual COG. On the dashboard, Mag HDG is correct (~117M), COG is incorrect (116 T; should be 131T), Mag COG is incorrect as well (100M; appears to be off by exactly the mag variation here (16) in the wrong direction).

The other screenshot shows a sample NMEA stream from approximately that moment in time, within a few seconds anyway.

Thanks for any help.

[rgleason]

Why are your tracks so wobbly? Something is wrong here.

[bdbcat]

Rick. et al...

Tracks are "wobbly" because GPS is sending only 2 digit fractions. Should be set for 3 or 4 digits to allow smooth tracking.

Dave

[codger]

That's.... a different problem? My SeaTalk<->NMEA bridge seems to be cutting off the third decimal place on the decimal degree minutes. There are three decimals on the chartplotter, but only two by the time it gets to OpenCPN. Since only two decimal places only gives me resolution of about 18 m or so, I get a choppy track. I'm trying to fix this.


I found one partial answer to my True HDG issue: When I drop VHW NMEA sentences in OpenCPN, True HDG goes blank in dashboard. On next startup, True HDG is now calculated from HDM plus WMM's variation.

[codger]

I think the bridge is perhaps sending bad VHW sentences... I get data like:

$IIVHW,116.0,T,117,M,004.9,N,009.0,K*4E
$IIHDM,117,M*3B

[rgleason]

Interesting. I have the Tiny seatalk from gadgetpoole. Have been getting occasional spurious gps positions 1000 of miles away. This spring I removed a old and unnecessary or unused seatalk wiring thinking that might help.

I am now thinking that the power source might not be good on mine. The devices are fully programable so maybe you can set the decimals.

Also tell the bridge to not send VHW sentences.

[did-g]

Originally Posted by codger

I think the bridge is perhaps sending bad VHW sentences... I get data like:

$IIVHW,116.0,T,117,M,004.9,N,009.0,K*4E
$IIHDM,117,M*3B

Likely, on the other hand OpenCPN should do a better job with conflicting data, at least in the debug window.

[codger]

I can't blame OpenCPN for getting confused with conflicting data. Although certainly if it detected clearly incompatible data, in an ideal world it might pass on a message to the user that conflicting NMEA data are appearing.

In my case, I suspect there is a problem with the NMEA bridge and the way it constructs NMEA sentences from the underlying SeaTalk datagrams (currently in conversation with its creator to try to get to the bottom of it).

For example, I get (from the same data stream as my screenshot)

$IIRMC,001430,A,4916.94,N,12308.83,W,005.0,115.0,1 30818,016,E*6B
$IIHDM,117,M*3B
$IIVHW,115.0,T,117,M,004.7,N,008.6,K*44

My understanding (and hopefully someone can correct me if I am wrong) is that the RMC sentence transmits COG in degrees true but no heading information. I don't know what SeaTalk data the bridge is putting into the COG field in RMC, but it's not COG. In fact it's the same data it's putting into VHW in the first field. In the sentences above, HDM is correct. Position is correct (although only to two decimal places), magnetic variation is correct. The VHW true HDG is incorrect, and the bridge creator confirmed he is taking that value from the RMC sentence, which matches the data, but would be wrong if RMC only reports COG, as COG != HDG.


So in this example there is a true heading (115), a magnetic heading (117) and a magnetic variation (16E) and by inspection it's clear there's a problem with something! There would certainly be an opportunity for OpenCPN to detect and report the conflicting data. On the other hand, I can see the argument that it's not its job to do this; garbage in, garbage out and all that.

[rgleason]

RMC sentence transmits COG in degrees true but no heading information.

True
https://opencpn.org/wiki/dokuwiki/do...on_information

See item 11
"Bearing to destination in degrees True"

You've gone this far, I wonder if NmeaConverter plugin would be able to fix this, if Frank won't?
Perhaps Dirk has some ideas too.
Also I believe the builtin program for gadgetpoole can modify seatalk.

From the Tiny Seatalk page on the gadgetpoole.de website
This small version of your SeaTalk NMEA Bridge is supposed to be an easy way to connect existing SeaTalk instruments to a computer. It does not provide a NMEA output port, just a USB (or RS232) port. It will not have a display.
The Software will have the same functions, the big SeaTalk NMEA Bridge has.
It comes with a bootloader, that allows you to update the SeaTalk NMEA Bridge software.
Manual

You can find the Users Manual HERE
In the bootstrapLoader there is a seatalk sentence that can be changed to modify how seatalk works.
In the manual we learn "Course over ground" Seatalk Id 53 goes both ways.

Course over ground ST Id=53 Sentence=RMC X=ST>nmea X=nmea>ST

Where is this data actually coming from?
Also maybe your bridge program needs to be updated?

Review this page about Seatalk messaging.
http://www.gadgetpool.de/nuke/module...le_sid_16.html

[codger]

I've written to Frank to ask if it's possible that the RMC sentence in the BridgeSD128 is using the wrong SeaTalk datagram for the COG / track angle parameter, as well as whether the Bridge is receiving three decimal places for lat/long and truncating them to two. I'll update when I hear back.

Another thing I don't understand is that the RMC sentence contains the correct magnetic variation. According to Thomas Knauf's SeaTalk Technical Reference this is SeaTalk datagram 99, but Frank's documentation doesn't indicate that this datagram is used by the Bridge. On the other hand, the RMC sentence correctly gives the variation, so it must be reading the 99 datagram despite the documentation?


Looking into correcting my data stream with NMEAconverter is a good idea, if I can't get the Bridge to output correctly.

[codger]

Sorry, missed your question:

The SeaTalk data is coming from an ST4000+ autopilot, ST60 instruments on the SeaTalk bus. The SeaTalk is fed directly to the BridgeSD128, which translates to NMEA and outputs to my laptop via a USB cable.

[rgleason]

Originally Posted by codger

Sorry, missed your question:

The SeaTalk data is coming from an ST4000+ autopilot, ST60 instruments on the SeaTalk bus. The SeaTalk is fed directly to the BridgeSD128, which translates to NMEA and outputs to my laptop via a USB cable.

I believe the only two differences we have are ST4000, and use of Tiny STLink which outputs to surfacepro3 via RS232 plugged into a USB converter which is plugged into a USB Hub connected to the one USB port of the SurfacePro3. We have a Raymarine Fluxgate with nema0183 wired to the autopilot. Heading data is only available in OpenCPN an on B&G ZeusT12 when autopilot is on.



So where do you think the Course over Ground is coming from in your case. Is it on the Seatalk bus or from your GPS which is plugged into your computer?


If COG comes from your GPS on your computer, why not try disabling the RMC sentence coming back out from SeaTalk. ..perhaps easier said than done, but I think that bootloader would do that.

[codger]

Our setups sound similar. My Raymarine fluxgate compass is also wired to the autopilot, and I only get heading data when the autopilot is on. The GPS is wired to the chartplotter, and I only get position data when the chartplotter is on. There is no other GPS in my system.

I think COG must be calculated by the chartplotter (Raymarine RC520) and sent over SeaTalk. At any rate, whether it's the chartplotter or the autopilot, COG is available on the SeaTalk bus, and gets fed into the BridgeSD128 to be converted to NMEA.

One of the nice things about the SD128 is that many of the NMEA output sentences are user selectable using the config menu right on the bridge itself to determine whether new SeaTalk datagrams are sent out over NMEA. So I can easily turn off VHW, for example. Unfortunately, I can only turn off GLL, not RMC. That said, OpenCPN could filter RMC out.


In the absence of RMC, would OpenCPN use the GLL position fix data to calculate COG/SOG?