SOG 0.3kts but I am not moving!

[LifePart2]

Summary of issues I have identified, in order of importance of their effect on real world navigation:

1) Zooming in on raster charts in a new location causes the system to freeze. Probably only happens on the RPI and maybe only on the RPI 3 as the 4 has higher specs. Happens just when you need it most, ie you are trying to look in detail at some navigational issue.

2) The dashboard plugin causes spontaneous closure of the program when it is left unattended for a periods of time. Both RPI and laptop - but seems to have been happening less on the laptop since we filtered out the NMEA sentences.

3) SOG is only displayed correctly if the RMC sentence contains a non-zero value for speed. If the value is zero, then the previous non-zero is displayed until a new non-zero value arrives. When the speed is actually zero, then SOG should display 0.0 (not ---) and the COG should display as '---' and the course predictor line should be absent.

4) Boat heading - I think this is maybe the same basic problem. Occasionally the heading gets stuck pointing in the wrong direction and remains there for minutes and then suddenly reverts to correct. Seems to have been resolved by filtering out the IIVHW sentences, so I suspect that this is caused by malformed sentences being used. Impossible to estimate leeway or side current under these circumstances.

5) Malformed RMC (and perhaps other) sentences result in unexpected behaviours. Error trapping should filter out sentences with missing data and (my suggestion) they should also filter out sentences with latitude and/or longitude of EXACTLY zero.

8) Would be nice to be able to delete individual points from a recorded track. Maybe right-clicking on the track would give the option of deleting that particular segment.


Thanks, Dave and other developers for the work you do on this. It is a great program. I am hopeful that the next version will have some solutions to these issues. In the meantime I am going to experiment with using the Status Bar plugin instead of the Dashboard so that the system doesn't keep shutting down on me. And I will just have to be careful about when I zoom in on the charts.

[rick bertram]

You should be able to manually adjust that in settings. My new Raymarine electronics showed my sog to slow so I adjusted it in settings. Just guessing you might be able to zero it.

[In The Mood]

There is a key issue here. GPS gets position and time data only. Everything else is calculated. The slower you go and the more random the path Walking or drifting at anchorJ the less accurate GPS outputs of COG and SOG are. Anything less than about 3 knots of progress will start to introduce errors. This is exacerbated but GPS systems that have slower update rates. Your system is fine.

[bdbcat]

Noel...
re:
"3) SOG is only displayed correctly if the RMC sentence contains a non-zero value for speed."


If you can capture a VDR recording where this happens, we may be able to diagnose.
What I mean is, we need a recording where the value is correctly displayed, then somewhere contains an RMC message with speed "0", but the displayed statusbar SOG remains at a non-zero value.


FWIW, I suspect that this all relates to your specific NMEA message interface. You are the only user reporting this effect, and no-one else has been able to reproduce it.


Thanks
Dave

[bdbcat]

Noel...


Re:
5/9, "occasional track jump to 0,0"


This is evidence of a faulty RMC message from the GPS receiver. Has been seen elsewhere. There is an undocumented config file setting to work around this malformed sentence. Rarely used, so not available in the GUI.

[Settings]
FilterTrackDropLargeJump=10

The units for the value (10 in this case) are "nautical miles". It works like you might expect. Avoid adding track points when two successive points are more than "n" miles apart.



Good Luck
Dave

[Info Express]

You are suffering from what is known as multi-pathing. More likely to happen on a glassy sea as it will act like a mirror. You will have one GSP packet arriving directly at you antenna, and the same packet arriving a moment later off the sea surface. When GPS first came on the scene it was almost impossible to use it to navigate through a city, for example, because the GPS signals would mutlipath off all the high rise buildings. Manufacturers developed antennas that masked signals coming it at dubious angles, i.e. not from overhead and the software of nav sets was developed to filter the signal to give a smooth course. Helped evenmore when you tell the system that you must be on a road and not in the middle of a field. Unfortunately, at sea you can go just about anywhere, nav hazards allowing, so the GPS software won't be linked to the map (chart) per se, however the filters willl look at what is reasonable direction and speed for a vessel and filter out any "spikes" caused by GPS wobbles.

Your heading will not be true, if it is GPS from which heading is being derived, unless you have a twin GPS antenna setup. With a single GPS antenna heading is not actually heading but course .i.e. heading is derived as the bearing between one position and the next when the vessel is moving.

Dual GPS antenna setups give good TRUE heading by simultaneously acquiring position and then calculating the bearing between the two positions. And, whilst GPS signal does have its inaccuracies due to troposheric and ionospheric affects, such as refraction, the dual antennas will be affected by the same effects and be true to eachother.

The above remembered from University in 1993 and the next 30 years positioning survey vessels.

[LifePart2]

Originally Posted by bdbcat

Noel...

[Settings]
FilterTrackDropLargeJump=10

Exactly what I was looking for. Thanks!

Originally Posted by bdbcat

Noel...
re:
"3) SOG is only displayed correctly if the RMC sentence contains a non-zero value for speed."


If you can capture a VDR recording where this happens, we may be able to diagnose.
What I mean is, we need a recording where the value is correctly displayed, then somewhere contains an RMC message with speed "0", but the displayed statusbar SOG remains at a non-zero value.

That is exactly what is shown in the attachment to message 38. The photo shows a live picture of the SOG, the boat's course predictor line, and the NMEA at that time. As you can see, the latest RMC shows SOG zero, but the dashboard and status bar still show 0.3 kts. Everything except the RMC were filtered out.



I have a video taken at the same time that shows it all in real time. It is 64mb but I can upload it to my own website if it would be helpful. On that you can see how the SOG only changes if there is an RMC that is non-zero.

FWIW, I suspect that this all relates to your specific NMEA message interface. You are the only user reporting this effect, and no-one else has been able to reproduce it.

What else can I do here to filter that out? As far as I can see I have a very simple setup. GPS -> multiplexer -> OpenCPN

Your heading will not be true, if it is GPS from which heading is being derived, unless you have a twin GPS antenna setup. With a single GPS antenna heading is not actually heading but course .i.e. heading is derived as the bearing between one position and the next when the vessel is moving.

My heading is provided by a fluxgate compass. The heading in OCN only gets stuck on the RPI, not on the laptop (using the same NMEA stream), so I am presuming it is something about the RPI setup. No idea what, though.

[bdbcat]

Noel...
I can see the photo evidence, and believe the video would confirm. I can see that there is something funny going on here.

Are you familiar with the VDR plugin? The saved output from that plugin is what I need to reproduce the problem locally. It is difficult to work with a photo snapshot....


Thanks
Dave

[Hakan]

Noel..
Since I see from the picture you're on a RPi - Openplotter. O don't happen to be connected by a SignalK connection to the SK server in parallel to the serial connection?

[LifePart2]

Here is what I did (on my laptop, not RPI, as this issue is on both):

First I filtered out ALL NMEA sentences, accepting only GPRMC

Then I started the VDR record.

Then I moved tboat forward a bit, and then stopped the engines.

Then I stopped the VDR record.

Then I disconnected from the NMEA input.

Then I played the VDR output, and observed that the SOG fluctuated between 0.3 and 0.5kts but NEVER went to zero, despite all the zero RMC sentences.

And then I uploaded it all to here (renamed as a PDF).

Signal K input is NOT enabled but, in any case, this was done on the laptop using wifi input only.

[Hakan]

Noel...
If you look into your VDR file you'll see a few messages like this:
$GPRMC,135743,A,2352.8438,N,07615.0533,W,000.5,022 .6,270322,,,A*61
Here's the speed 000.5 knots. There are more examples with 0.2 and 0.3 knots. So this is reported by your GNSS receiver and thus used by OCPN.

The reason why you see a constant speed is there are a new message with a reported speed before the 6 seconds watchdog is "wiping" it out.

The OCPN program logic don't use a SOG reported to be exactly 0.0 but instead await the watchdog to reset COG and SOG in the same time.

[rgleason]

Hakan, Lifepart have added this example to FAQ

https://opencpn.org/wiki/dokuwiki/do...aq#jumping_gps

[bdbcat]

Noel...
I have reproduced your observations on new build of O56 on rPI4, Buster (OpenPlotter), using the VDR file you have provided.
Please stand by for more info.


Thanks
Dave

[bdbcat]

Noel..
Ok, confirmed. This is a legitimate bug.
The bad code crept into the code base in 2016. One of the trusted devs apparently had a GPS receiver at the time that was acting up, so a patch was made to ignore SOG=0.0. Clearly not a generally correct solution.


Easy fix. I'll publish a new O561 Beta with the correction made.
Strange that we have not seen reports of this elsewhere. Also strange that you do not see it on Windows. But whatever....


So, Noel, you may wait for O562 to be published, or load the Beta 561-2, when it is available. Your choice. Personally, I'd like to see you running the Beta, to evaluate any unintended consequences of the correction.


Thanks for your patience on this. Took a while to assemble all the parts to see and understand the effect.


Dave

[rgleason]

Made a note about this improvement in FAQ