SOG 0.3kts but I am not moving!

[LifePart2]

Thanks Dave,
I will try that. The challenge is that 'a few minutes' does not seem to be enough to cause the issues.

Today went sailing. So far no spontaneous shutdowns since I removed the dashboard plugin. I did have the o-charts plugin and Explorer raster charts activated. It does seem to suggest that the Dashboard plugin is causing instability.

However, at on point I decided to zoom all the way out to CM93 and then back in again. The system froze and I had to hard-reboot it. I then tried a number of times to zoom out and zoom in again. No problems. So I left it as we sailed another half hour.

Then, just as we were about to approach the entrance to Adderly Cut I zoomed to look at it better. The system froze again, so I turned around and waited while I hard-rebooted the system. Then I proceeded through the cut with no navigational nor RPI issues.

After that I again tried some in and out zooming with no problems.

Regards and thanks again for your help.
Noel

[bdbcat]

Noel...
The occasional crash and freeze:
I know that you have read about this, and that you thought hard about it. But I have to ask...
Are you absolutely sure that your power supply to the rPi is bulletproof? Any way of trying a different power supply? Likewise for SDCard.


Think about this: adding plugins, add ing multiple data sources, and zooming/panning around, all add to the CPU load of the rPI. If the power supply is at all marginal, one can see erratic behavior, and crashes.



Also, I really would like to hear the results from successive filtering steps. OCPN will run just fine with only RMC for input, at least while underway.


Dave

[LifePart2]

Another night with no spontaneous shut down. That is good. Tonight I will enable the desktop plugin again and see what happens.

However, this morning the SOG was again showing something crazy (32kts or something, don't actually remember). So then I closed and reloaded OpenCPN, activated VDR and Dashboard. It started with SOG 0 and then almost straight away went o0.3kts and stayed there. So I looked at the VDR output and found some IIRMC sentences, although there is no mention in there of that speed. Actually the sentence is
$IIRMC,,A,,N,,E,,,,0.0,W*43


I also found $IIVHW ,,T,,M,0.0,N,,K*7B which is pretty useless.

So maybe those are the ones messing things up. The II talkerID seems to be the conversion of SeaTalk to NMEA by the Quark_Elect

I tried to filter them out using 'ignore sentences' however I am unable to type into that box on either the RPI or Laptop. There is a dropdown option on the right with the three dots, but that only allows me to select the data type (ie RMC) and not the talkerID, so that would filter out both the GPRMC and the IIRMC, so that is not much use.

There is no option to do the filtering on the Quark-Elec multiplexer which seems to be much inferior to the ShipModul. Maybe when I get back home I will order one of the new ShipModuls. Can't remember why I was unable to get one previously. Probably because of COVID supply chain problems.

So, if you can tell me how to filter out those sentences, I will have another go at it all.

And any ideas on the occasional freezing on the zoom function?

Yes, the power supply seems to be good. I have never had any indication of either undervoltage nor overheating.

Thanks

[LifePart2]

Also there is the sentence $STALK which is not even valid NMEA. I have emailed Quark-Elec to see if they have some solutions.

[nohal]

Originally Posted by LifePart2

I tried to filter them out using 'ignore sentences' however I am unable to type into that box on either the RPI or Laptop. There is a dropdown option on the right with the three dots, but that only allows me to select the data type (ie RMC) and not the talkerID, so that would filter out both the GPRMC and the IIRMC, so that is not much use.

To the right of the sentence list there are several buttons, click the one labeled "Add" and add whatever you need to the list of sentences to filter.

[flightlead404]

Originally Posted by BMD21

You are aware that the primary purpose of GPS is military? They added a random noise, which has been scaled down due to public demand. I don't know but what is happening could be noise that the military puts in. That would also explain why we have 3 constellations giving the same information. Those things aren't cheap.


Boris

Are you talking about Selective Availability? I believe that was turned off under Clinton. GPS has limitations, its the 1st gen sat nav after all. WAAS is used to increase precision where needed but is a ground based system afaik for aircraft instrument approach procedures.

[bdbcat]

Noel...
"And any ideas on the occasional freezing on the zoom function?"


Yes. Basic troubleshooting methods. We must determine whether the two problems are related.


So, dIsable all NMEA I/O. Spend 5 or ten minutes playing with the charts, zooming, switching, etc. Try and prove to yourself that if there is no NMEA activity, then the system is stable.


Thanks
Dave

[LifePart2]

Originally Posted by nohal

To the right of the sentence list there are several buttons, click the one labeled "Add" and add whatever you need to the list of sentences to filter.

Ah, didn't realise that was that button was for.

So, I added all the sentences to the IGNORE leaving only GPRMC in green on the Debug window.

So here is what happens.

When I get a sentence like
GPRMC,004859,A,2345.6646,N,07605.3364,W,000.3,328. 8,230322,A*65<0x0D>

The SOG changes to reflect that sentence, in this case 0.3kt

BUT, when the following sentences are:
GPRMC,004859,A,2345.6646,N,07605.3364,W,000.0,328. 8,230322,A*65<0x0D>

(which most of them are, as we are usually not moving around)

Then the SOG does not change. It remains at 0.3kt until the next 'live' sentence provides a non-zero value for the SOG.

I have a video showing this, if you want to see it, and I have attached a photo.

I notice also that when I start up the program from scratch, the SOG shows --- not 0.0 when those zero values come through. Since there is an actual value in the RMC (ie SOG of zero) then it should show zero, not ---. The --- implies that no value has been received, which is not the case. So it should show --- initially, then as it receives live RMC data, it should show 0.0 (or whatever the current SOG value is).

So, I think that explains the SOG problem.

I will tackle the freezes on zooming tomorrow. I did have another such crash today while I was playing with it. I will unplug the USB NMEA input. I suspect that the problem is too much zooming to quickly. When using the + and - buttons on the bottom right the cursor goes to hourglass until it is ready, so one waits (or perhaps the cursor is disabled). But when using the keyboard + and - keys it does not show any hourglass. So as soon as it looks like the next chart is rendered I press it again. But probably it is too soon. Do that a few times and the queue fills up and overwhelms the system. That's my theory, anyway. I will play with it tomorrow without the NMEA input.

In the meantime I will leave it running tonight with the Dashboard active and see what happens.

Thanks again for your help and patience.

Noel

[LifePart2]

Some more observations:

When starting OCN the status bar and dashboard both show SOG --- and COG--- which is correct until the moment that the first live RMC sentence is received. Then it should show the new live data.

Looking at the GPRMC sentences: When the SOG is 000.0 the COG still shows the previous number. e.g.

GPRMC,004859,A,2345.6646,N,07605.3364,W,000.0,328. 8,230322,A*65<0x0D>

With this input (at startup), the status bar shows SOG --- COG --- while the dasbboard plugin shows SOG --- COG 0 deg

Since there is actual real data in the sentence, both the status bar and the dashboard should show SOG 0.0 and COG --- (there is no valid COG if you are not moving. Zero is north, so not appropriate when you are static).

When more data is received, eg
GPRMC,004859,A,2345.6646,N,07605.3364,W,000.3,328. 8,230322,A*65<0x0D>

Then the dashboard shows SOG 0.3 kt whish is as it should be. The Dashboard and status bar, however, round the COG differently: the dashboard rounds it up to 329 deg, while the status bar truncates it to 328 deg.

when the received data reverts to:
GPRMC,004859,A,2345.6646,N,07605.3364,W,000.0,328. 8,230322,A*65<0x0D>

Now both the dashboard and the status bar retain their previous values. SOG stays at 0.3kt, and COG stays at 329 and 328 respectively. It should go back to SOG 0.0 and COG ---

Finally, when a new sentence with new (non-zero SOG) data arrives, then both the dashboard and statusbar get updated and retain the new numbers until the next non-zero datum.

[LifePart2]

Since enabling the dashboard plugin OCN has spontaneously shut down multiple times when left unattended, even for a few minutes. So there is definitely a problem there.

Also, a thought about the very occasional jumps to the equator and back again. I am presuming these probably come from a malformed RMC, probably one of the IIRMC's. I was not able to capture any of these jumps on the VDR, but I am guessing that the coordinates in it were either missing completely, or else where exactly zero - for lat, long, or both.

To prevent this, maybe we need some additional error trapping to ignore malformed sentences and also to ignore sentences with coordinates of EXACTLY zero (either lat or long)?

When you are crossing the Greenwhich Meridian or equator you will be on exactly zero for max one second - then you will have moved a meter or so and your position will no longer be exactly zero, so this would not affect any real-world navigation.

Today I will play with the zooming. will report back.

[rgleason]

Partial Suggestions Summary

1. See bdcat Post #7 "..verify that Settings->Ships->"Calculate SOG and COG from position changes" is disabled (unchecked). Option is only to be used if you have a very old, or defective, GPS receiver that cannot calculate SOG/COG on its own, or does not transmit RMC." Answer: calculate SOG from position.. is unchecked.
2. Bdbcat: Paraphrase: Does the RPI have a good solid power supply?
3. Nohal "Simplify your config to the bare minimum, make sure it works, then keep adding back complexity until it starts causing problems. The last thing added is likely the cause. It is really hard if not impossible to troubleshoot a complex system like yours without having access to it"
4. Tehani "If RMC/VTG show stable SOG values at 0 knots (that is best seen on a 1-2 minute VDR capture), I don't see any other possibility either. This does not contradict the other posts, since it is also normal to see SOG of up to 0.5 knots in AIS messages from moored ships. A simple calculation: 0.5m error between position calculations with 1s intervals means a speed calculation of almost 1 knot. (0.5 * 3600) / (1 * 1851.8) " ...Attach a VDR file for review!
5. Bdbcat: "[to] tackle..use NMEA filters. Start by removing all NMEA sentences except RMC. Test for a while. I'd be very surprised if your speed wanders with only RMC messages coming in. Then add NMEA message types, one by one, testing for some minutes between changes. Sooner or later you will find the offender/conflict."
6. Next Report: Still more crashes and freezeups
7. Bdbcat: "is power supply to the rPi is bulletproof?..trying a different power supply? Likewise for SDCard. Think about this: adding plugins, add ing multiple data sources, and zooming/panning around, all add to the CPU load of the rPI. If the power supply is at all marginal, one can see erratic behavior, and crashes."
8. Report: "SOG was again showing something crazy (32kts). Closed and reloaded Opencpn, activated VDR and Dashboard. It started with SOG 0 and then almost straight away went 0.3kts and stayed there. ..looked at the VDR output, found some IIRMC sentences, although there is no mention of that speed. Actually the sentence is
   $IIRMC,,A,,N,,E,,,,0.0,W*43 I also found $IIVHW ,,T,,M,0.0,N,,K*7B which is pretty useless. ..maybe those are the ones messing things up. The II talkerID seems to be the conversion of SeaTalk to NMEA by the Quark_Elect. I tried to filter them out using 'ignore sentences'" ..how to filter out those sentences?"
9. Report: Also see $STALK which is not even valid NMEA."
10. Nohal: "To the right of the sentence list there are several buttons, click the one labeled "Add" and add whatever you need to the list of sentences to filter"
11. Bdbcat: "Noel..."And any ideas on the occasional freezing on the zoom function?" Response: "Yes. Basic troubleshooting methods. We must determine whether the two problems are related. ..disable all NMEA I/O. Spend 5 or ten minutes playing with the charts, zooming, switching, etc. Try and prove to yourself that if there is no NMEA activity, then the system is stable."
12. Report: "So, I added all the sentences to the IGNORE leaving only GPRMC in green on the Debug window. When I get a sentence like
    GPRMC,004859,A,2345.6646,N,07605.3364,W,000.3,328. 8,230322,A*65<0x0D> [in the Options > Nmea Window] the SOG changes to reflect that sentence, in this case 0.3kt, BUT, when the following sentences are: GPRMC,004859,A,2345.6646,N,07605.3364,W,000.0,328. 8,230322,A*65<0x0D> (most of them are..we are usually not moving around). Then the SOG does not change. It remains at 0.3kt until the next 'live' sentence provides a non-zero value for the SOG.
13. Report: Very good set of observations, see Post #38,39,40

How about providing these experts a good VDR file attached here as a vdr.txt with (.pdf) added or (.doc) added? See FAQ about attaching files and FAQ: Jumping GPS

[bdbcat]

Noel...
Thanks for the detail.
Couple of points:


1. In NMEA RMC messages, a SOG value of "0" is a valid report. It does not mean that speed is invalid, or unreported. It means speed is zero. So, failure to report "0" for SOG is definitely interesting.



2. Probably you hand typed these sentences into your posting?


GPRMC,004859,A,2345.6646,N,07605.3364,W,000.3,328. 8,230322,A*65<0x0D>
GPRMC,004859,A,2345.6646,N,07605.3364,W,000.0,328. 8,230322,A*65<0x0D>



If you did NOT, then one of these RMC messages is invalid, since they both could not have the same checksum value of "*65".
Just checking....


Dave

[LifePart2]

Yes indeed, I just copied and pasted the same RMC sentence and adjusted the speed part of it. The datetime on them is also identical. I was only highlighting the SOG and COG part of the sentence.

[LifePart2]

Stability/Freezing:

This is now reproducible for me:

Plugins: o-charts with explorer raster charts (south Bahamas)
NOT dashboard

NMEA usb unplugged.



Start with the chart zoomed on the raster chart to the boat (ours is at Lee Stocking island) and autofollow turned OFF

Close OpenCPN and the open it up again so it starts with the boat and the zoom at the same point with the same settings.

zoom all the way out to an overview (not necessary to go all the way out to CM93, but it doesn't hurt)

click somewhere else a good distance away from own boat on the overview to bring that location to the middle

zoom all the way in again using the - (minus) key on the keyboard or the bottom right zoom in/out buttons with the mouse. At each keypress wait for the hourglass (if there is one) to go away, and for the display to appear to be settled on the new zoom level. Then keypress again.

At some point the system freezes and becomes completely unresponsive to mouse movements, mouse clicks or keyboard presses. Waiting a number of minutes does not help. Eventually one has to turn off the power and reboot it.

This does not happen on the Windows 10 laptop. Also does not appear to happen with the o-charts plugin disabled.

The move to a different location appears to be part of this. Zooming in and out in the same area is not a problem, perhaps because the images are cached somewhere? As I said, to me it seems to suggest that the re-rendering of the raster image overwhelms the poor little RPI system.

[LifePart2]

Aberration in the Recorded Tracks

Here is a screen shot of the occasional random trip to zero degrees (lat, long or both). In this case we apparently took a quick nip over to the Greenwhich Meridian way down in the southern Atlantic. Odd. In most cases it either goes to 0,0 or else it preserves one or other of the coordinates, ie heading due south to the equator or due east to the zero meridian (assuming we are in the west.)

The other two tracks heading way down south appear to be artifacts - On hovering over them, there is no information about them, and on panning the chart they sometimes disappear and then reappear again. Don't why they show up at all, nor why they go down south (not to any obvious destination.

These are probably coming from some abnormal RMC sentence, generated either erroneously by the GPS itself, or perhaps by the multiplexer. I used to get the same thing previously when using the ShipModul multiplexer.

They are annoying (but not critical to navigation) as there is no easy way to removed them. The simplest is to just delete the whole track. If one wants to preserve the real track, then one has to edit the track, find the entries that have ridiculous speeds, split the track before and after those points, and then delete the new middle segment. There does not appear to be a way to delete individual points from a track. It would be nice if one could right click on the track and have the option of deleting that particular segment.