Visit our Popular Forums

rgleason · 23-05-2019, 13:31

From your vdr file

$GPGGA,185052.000,1820.9337,N,06436.9185,W,1,10,0. 9,-5.0,M,-45.3,M,,0000*4D
Remove the checksum *4D and run the Nmea0183 checksum checker
$$GPGGA,185052.000,1820.9337,N,06436.9185,W,1,10,0 .9,-5.0,M,-45.3,M,,0000*69

Checksum is wrong.

==========

$GPGSA,A,3,01,22,28,17,30,03,11,18,07,19,,,2.3,0.9 ,2.1*32

remove *32

With checksum:$$GPGSA,A,3,01,22,28,17,30,03,11,18,07,19,,,2.3,0. 9,2.1*16

You try some other sentences in your vdr file here

https://nmeachecksum.eqth.net/

Perhaps this is why there are problems?

rgleason · 23-05-2019, 13:36

Noel, and Chris,
I got thinking about this. Can you try something to test Opencpn by running some good VDR_pi files to see if the problem is still there?

I have also asked Fernando to try this. Download some good data and run vdr_pi and see if the data appears in the statusbar. Try the files in the tactics_pi plugin manual if you don't know of any good VDR files.

Turn off all other incoming data.
Check the screens.

PS: BTW you've got an awful lot of plugins enabled. Turn all of them off except vdr_pi while doing this test.
Then after checking the screens and results, turn the plugins on, one at a time and note when there are problems and what they are please. We would very much like to know about this.

Thank you.

Moo · 23-05-2019, 13:39

Quote:

Originally Posted by rgleason

Noel, and Chris,
I got thinking about this. Can you try something to test Opencpn by running some good VDR_pi files to see if the problem is still there?

I have also asked Fernando to try this. Download some good data and run vdr_pi and see if the data appears in the statusbar. Try the files in the tactics_pi plugin manual if you don't know of any good VDR files.

Turn off all other incoming data.

Check the screens.

Rick....

It is deeper than that. just leave it with me for a few minutes. I can now reproduce. Nothing wrong with my data stream.. and as I stated earlier I don't use VDR

rgleason · 23-05-2019, 13:51

Ok, I'll hold the horses, knowing you've got a hold of it!

Moo · 23-05-2019, 14:46

Quote:

Originally Posted by rgleason

Ok, I'll hold the horses, knowing you've got a hold of it!

Rick, Noel,

OK I can now reproduce on all machines. I don't know why it would not reproduce on my windows machine before but I think it was because I was just changing the timezone but the time was still correct.. However I can now not, not, reproduce the issue!

Rick - the checksum thing you noticed is because you had a space in the NMEA sentence that you copy/pasted.

Here are a couple of screenshots illustrating. Noel have you already filed a bug report?

Noel - You had it right all along. I couldn't reproduce. I guess I had never seen it before because my boat computers run on
UTC.

cheers Chris

rgleason · 23-05-2019, 17:23

Quote:

Originally Posted by rgleason

From your vdr file

$GPGGA,185052.000,1820.9337,N,06436.9185,W,1,10,0. 9,-5.0,M,-45.3,M,,0000*4D
Remove the checksum *4D and run the Nmea0183 checksum checker
$$GPGGA,185052.000,1820.9337,N,06436.9185,W,1,10,0 .9,-5.0,M,-45.3,M,,0000*69

Checksum is wrong.

==========

$GPGSA,A,3,01,22,28,17,30,03,11,18,07,19,,,2.3,0.9 ,2.1*32

remove *32

With checksum:$$GPGSA,A,3,01,22,28,17,30,03,11,18,07,19,,,2.3,0. 9,2.1*16

You try some other sentences in your vdr file here

https://nmeachecksum.eqth.net/

Perhaps this is why there are problems?

Chris you are correct about the second example, but the first one has a space and I believe the checksum is wrong.

Do you have a VDR file perchance?

rgleason · 23-05-2019, 17:42

Post #1 fails NMEA Decoder. Using this free tool you can decode (parse) your NMEA log.

Post #24 vdr file passes http://freenmea.net/decoderwith some jitter.

LifePart2 · 23-05-2019, 17:45

Here is the replication procedure:

1) turn on OpenCPN with an active GPS signal

2) Display the dashboard plugin, showing 'Local GPS Clock' and also 'GPS Clock'. It should display the correct local time for the time zone to which you have set your computer, and the correct UTC time (check the internet for the current time).

3) manually change the local time on your computer to something wrong (eg two hours ago). Make sure you turned off the setting to automatically set the time from the internet. The dashboard should still show the correct times as in step 2.

4) now put in a simple 'navigate to here' route. The route panel will be displayed, showing your VMG, ETA etc. Does the dashboard clock now show the wrong time (eg two hours ago) for both local time and UTC time?

4a) If you are actually moving towards the destination, does the ETA correspond to the correct time, or the wrong time (eg two hours too early)? e.g. if TTG is 1 hour, and the correct time is 10am and the wrong time is 8am, does the ETA show 11am (correct) or 9am (wrong)?

5) deactivate that route. Does the dashboard clock go back to showing the correct GPS time as in step 2?

If the answers to 4 & 5 are yes, then you have replicated the problem.

Hope that makes sense. Do you need any screenshots?

Noel

LifePart2 · 23-05-2019, 17:48

Sorry, just realised that you had already figured it out.

No, I have not filed a bug report. Do you need me to do that?

Noel

rgleason · 23-05-2019, 17:51

File in post #17 is an actual pdf file can't run it.

The 2 nema files in post #23

http://www.cruisersforum.com/forums/...ml#post2894142

both pass the checker.

LifePart2 · 23-05-2019, 17:52

Quote:

I guess I had never seen it before because my boat computers run on
UTC.

Exactly - as do most people's computers. It is only now that I am using the RPI and I don't know how to set it to get the time from the NMEA stream that the problem became so obvious.

Thanks for your patience in sticking with me on this. Tell me if you need me to file a report or if you will be doing it. (internet seems to be better here in BVI now)

Noel

LifePart2 · 23-05-2019, 18:15

Just for interest sake, here is a NMEA recording from about 2 years ago. It shows different time stamps for the $EC and $GP sentences - about an hour apart. Don't know what version of OCPN that was. Would have been a windows machine.

Noel

rgleason · 23-05-2019, 18:19

Quote:

Originally Posted by LifePart2

Here is the replication procedure:

1) turn on OpenCPN with an active GPS signal

2) Display the dashboard plugin, showing 'Local GPS Clock' and also 'GPS Clock'. It should display the correct local time for the time zone to which you have set your computer, and the correct UTC time (check the internet for the current time).

3) manually change the local time on your computer to something wrong (eg two hours ago). Make sure you turned off the setting to automatically set the time from the internet. The dashboard should still show the correct times as in step 2.

4) now put in a simple 'navigate to here' route. The route panel will be displayed, showing your VMG, ETA etc. Does the dashboard clock now show the wrong time (eg two hours ago) for both local time and UTC time?

4a) If you are actually moving towards the destination, does the ETA correspond to the correct time, or the wrong time (eg two hours too early)? e.g. if TTG is 1 hour, and the correct time is 10am and the wrong time is 8am, does the ETA show 11am (correct) or 9am (wrong)?

5) deactivate that route. Does the dashboard clock go back to showing the correct GPS time as in step 2?

If the answers to 4 & 5 are yes, then you have replicated the problem.

Hope that makes sense. Do you need any screenshots?

Noel

Yes please, and can you file a tracker item that refers/links to your posts?
Thank you!

The tracker is found on opencpn.org in the menu bar... call it a bug.