no VMG, HDG, COG on Dashboard (plus other issues)

[rgleason]

Moo thanks for following this. It would be very good to know if there is some issue with Dashboard.

[LifePart2]

ok, been doing some more investigation. Sorry about the delays - it is hard to get internet connections around here.

When I save the nmea stream through the VDR from my RPI and windows I get the attached files. As you can see, they both include those $EC sentences. These files were recorded at the same time.

However, I do NOT see those $EC sentences in any of the following places:
on the NMEW degub window in OpenCPN on the RPI or Windows
on my Ship Modul config program

The RPI is connected to the ship modul mulitplexer through USB. The windows is connected by bluetooth. The multiplex config is set to send the same data to both outputs. There are no settings I can see that are adding $EC sentences. I believe that $EC means it is being generated by a chartplotter.

So I have no idea where that $EC data is coming from, but it does show a different time stamp on it - different to both the $GP sentences AND different for the two files, RPI and windows.

If I play the RPI VDR output on my windows machine, I do get the wrong time showing, but it does not flash back and forth like it does on the RPI. If I play the windows VDR file it does not show the wrong time. When I look at the two files, I see that the $EC time stamp it different on them both, suggesting to me that the $EC is being added by the VDR program or at least somewhere in OpenCPN, and that the timestamp on it is being taken from the local CPU. I thought that maybe it was from the speed filtering option, but I have turned that off and that makes no difference.

So, I guess the question at this point is where is that $EC coming from and how do I get rid of it?

nmea_RPI.pdf

nmea_windows.pdf

[Moo]

Originally Posted by LifePart2

ok, been doing some more investigation. Sorry about the delays - it is hard to get internet connections around here.

When I save the nmea stream through the VDR from my RPI and windows I get the attached files. As you can see, they both include those $EC sentences. These files were recorded at the same time.

However, I do NOT see those $EC sentences in any of the following places:
on the NMEW degub window in OpenCPN on the RPI or Windows
on my Ship Modul config program

The RPI is connected to the ship modul mulitplexer through USB. The windows is connected by bluetooth. The multiplex config is set to send the same data to both outputs. There are no settings I can see that are adding $EC sentences. I believe that $EC means it is being generated by a chartplotter.

So I have no idea where that $EC data is coming from, but it does show a different time stamp on it - different to both the $GP sentences AND different for the two files, RPI and windows.

If I play the RPI VDR output on my windows machine, I do get the wrong time showing, but it does not flash back and forth like it does on the RPI. If I play the windows VDR file it does not show the wrong time. When I look at the two files, I see that the $EC time stamp it different on them both, suggesting to me that the $EC is being added by the VDR program or at least somewhere in OpenCPN, and that the timestamp on it is being taken from the local CPU. I thought that maybe it was from the speed filtering option, but I have turned that off and that makes no difference.

So, I guess the question at this point is where is that $EC coming from and how do I get rid of it?

Attachment 192464

Attachment 192465

Can you sketch a network diagram showing everything connected and how please?


Can you let us have the exact comms configuration on both machines ... screenshots of each connections settings.


Or attach your config files from both machines. You can can find the location by clicking on the ? symbol in the OCPN toolbar.


The EC files could well be coming from OCPN itself so I suspect that you have configured some sort of loop. Not sure why the time is offset at this stage. What are the local times on both your windows machine and the RPi?


PLEASE: attach your files as text files, or .vdr, etc... just change the extension to .pdf if the files are too big to upload here. Actually making a PDF file makes it cumbersome to extract the data and recreated the text file at this end.


Chris

[Moo]

What is the time set to on your RPi.. is it the same as the dodgy EC timestamps in the RPi file?

[rgleason]

Just a suggestion here, I agree that diagrams are needed. Some other information might be helpful, please review this FAQ post
How to request support and report problems if I cannot find the answer in resources listed above?

Another thing that should done, is strip the hardward connections down to what is essential to get it going. Solve the problems then. Then add hardware back in one step at a time.

[LifePart2]

Thank you for your patience as we unravel this. I have new information.

I just testing things out on my Windows 10 machine, using OCPN 5.0 and a GPS USB dongle, So this time the computer is not connected in any way to my multiplexer, other chartplotter, or any other device. Just the laptop and the dongle.

With the set up like that I then changed the local time on my laptop. No errors. Still the dashboard correctly displays the local time based on GPS not on my local (wrong) cpu time. So far so good.

I then put in a temporary 'go here' route.

As soon as I did that, the dashboard started to display the incorrect cpu time alternating with the correct GPS time.

I then deactivated the route. Now the dashboard displays the correct GPS time only,

I then activate the route again. Now, once agsin, the dashboard displayd the incorrect local time.

When I record the VDR I see those $EC sentences ONLY when the route is activated.

I then replicated this on the RPI with the same results.

Conclusions:

1) This is nothing to do with the local network, as there isn't one.

2) There is some kind of interaction between the activated route and the dashboard that is resulting in those erroneous $EC sentences, which are then being used by the dashboard to produce incorrect output Incidentally, remember also that the ETA on the activated route uses the local CPU time, not the GPS time, so that is probably connected to the same issue.

I hope that takes us forward. Maybe you can replicate the above?

regards,

Noel

[Moo]

Originally Posted by LifePart2

Thank you for your patience as we unravel this. I have new information.

I just testing things out on my Windows 10 machine, using OCPN 5.0 and a GPS USB dongle, So this time the computer is not connected in any way to my multiplexer, other chartplotter, or any other device. Just the laptop and the dongle.

With the set up like that I then changed the local time on my laptop. No errors. Still the dashboard correctly displays the local time based on GPS not on my local (wrong) cpu time. So far so good.

I then put in a temporary 'go here' route.

As soon as I did that, the dashboard started to display the incorrect cpu time alternating with the correct GPS time.

I then deactivated the route. Now the dashboard displays the correct GPS time only,

I then activate the route again. Now, once agsin, the dashboard displayd the incorrect local time.

When I record the VDR I see those $EC sentences ONLY when the route is activated.

I then replicated this on the RPI with the same results.

Conclusions:

1) This is nothing to do with the local network, as there isn't one.

2) There is some kind of interaction between the activated route and the dashboard that is resulting in those erroneous $EC sentences, which are then being used by the dashboard to produce incorrect output Incidentally, remember also that the ETA on the activated route uses the local CPU time, not the GPS time, so that is probably connected to the same issue.

I hope that takes us forward. Maybe you can replicate the above?

regards,

Noel

Yes. The messages are being generated locally. This is why I keep asking for your comms configuration settings, config file etc.. Please provide so that I and others can help you get to the bottom of it.



If you don't have a local network why are you sending out Autopilot commands?


Please provide the files referenced in the first help window that pops up when you click the [?] icon.



Please provide screen shots of the comms set up windows.. all settings


On windows use the snipping tool. Hit the windows key, type "snipp" and select the tool from the menu that pops up.



Until you provide those items nobody can help because we are getting down to specifics.

[LifePart2]

As I said, the latest info comes from stand alone testing on my windows 10 laptop that was not connected to any network. Just the laptop and the GPS dongle. Nothing else. This is not my normal sailing setup, it was just for testing as suggested above.

The previous VDR outputs were from my normal sailing set up with a local network, which is why they may have autopilot info. Since the new data is not from a network it seemed to me that a network problem has been excluded. Nevertheless I have attached the config file from my windows laptop.

I have also included two new VDR outputs - one with a route that is not activated, and one with an activated route. The difference between them is those $EC sentences which are picking up the time from my cpu instead of from the GPS. Both of these are from my windows laptop.

As I said, I replicated this on my RPI while it was not connected to the windows laptop, so it seems to be repeatable. Did you try replicating it yourself?

Thanks again

Noel

opencpn.ini.pdf

nmeadongle_no_route.txt.pdf

nmeadongle_active_route.txt.pdf

[Moo]

Originally Posted by LifePart2

As I said, the latest info comes from stand alone testing on my windows 10 laptop that was not connected to any network. Just the laptop and the GPS dongle. Nothing else. This is not my normal sailing setup, it was just for testing as suggested above.

The previous VDR outputs were from my normal sailing set up with a local network, which is why they may have autopilot info. Since the new data is not from a network it seemed to me that a network problem has been excluded. Nevertheless I have attached the config file from my windows laptop.

I have also included two new VDR outputs - one with a route that is not activated, and one with an activated route. The difference between them is those $EC sentences which are picking up the time from my cpu instead of from the GPS. Both of these are from my windows laptop.

As I said, I replicated this on my RPI while it was not connected to the windows laptop, so it seems to be repeatable. Did you try replicating it yourself?

Thanks again

Noel

Attachment 192560

Attachment 192561

Attachment 192562

No I can't replicate it just by changing my local time.



I notice a couple of things in your .ini file


You have weather routing and the GRIB plugins set to use local time. Try disabling those plugins and see what happens.



If that doesn't change anything disable all plugins and enable one by one until you find the problem occurring again.


The $EC files are being generated internally by the goto waypoint function and you are correct in that they do not appear in the NMEA debug window but are recorded by VDR; which I don't normally use.


Lets see what happens with those plugins disabled.


Chris

[rgleason]

Originally Posted by Moo

You have weather routing and the GRIB plugins set to use local time. Try disabling those plugins and see what happens.

If that doesn't change anything disable all plugins and enable one by one until you find the problem occurring again.

Lets see what happens with those plugins disabled.
Chris

Good points.


I am starting to wonder if a dead simple parallel install would work properly.

[LifePart2]

Hi
I just disabled the grib and weather routing plugins and retested with my dongle. Same result - when I activate a route, the dashboard shows local cpu time. When I deactivate the route I get the correct time.

Noel

[Moo]

Originally Posted by LifePart2

Hi
I just disabled the grib and weather routing plugins and retested with my dongle. Same result - when I activate a route, the dashboard shows local cpu time. When I deactivate the route I get the correct time.

Noel

OK thanks.



OK so now all plugins disabled?


Next step: close OCPN rename your ini file to something safe. and restart with a clean empty configuration. See what happens.. close OCPN report back and copy the new ini file here.

[LifePart2]

I have attached the new ini file. Exact same behaviour using the dongle.


I also just tested it all out on my wife's windows 10 laptop, again using the USB dongle, but this time using OpenCPN version 4.8.0

Same problem - if I change the local cpu time, and then activate a route, I get the wrong time displayed. If I deactivate the route, then the correct time shows.

I also noticed that if I change the local time zone, the dashboard GPS Local Time also changes in tune with that. So OCPN is getting its time zone from the local computer setting, not the geographical location of the boat. That is interesting. I presume that was a design feature decision? I noticed this as my wife has her laptop set to our back-home time zone instead of the Caribbean time zone where we are now.

Well, I should clarify the above statement:

If I have no route, the dashboard shows the correct GPS LCL time adjusted according to the current time zone specified in my laptop setup. If I change the local time zone, the GPS local time changes accordingly, and the GPS UTC time stays the same (and correct).

If I have an active route, the dashboard shows the local cpu time, and then adjusts the GPS UTC time to match the time difference specified by my local time zone setup. So, right now, if I set the local time to 10:30 and the time zone to -4, the dashboard shows 10:30 LCL and 14:30 UTC even though the correct UTC time right now is 15:30. Hope that makes sense.

The same behaviour happens on my other laptop using OCPN 5.0 and on my raspberry Pi, so that is three different machines showing the same behaviour.

To my mind I believe we have tracked this down to some behaviour in the routes management that is picking up its time locally instead of from GPS and then outputting that as $EC sentences with the wrong GPS time attached. And this behaviour has probably been going on back through a number of version. Just that no one spotted it before.

regards

Noel
opencpn.ini.pdf

[rgleason]

Lifepart2 and Moo

If you guys are getting to the point that you've found something amiss,

We are going to need to be able to reproduce this locally using files or something.

I would suggest that, if Moo is willing and does not have another suggestion, that he become the second user to be able to reproduce it.

So LifePart the next task, if Moo agrees or does not have a suggestion to try, is to bundle everything needed to reproduce this problem and upload it here, with some screenshots to explain very clearly what the problem is. Then Moo or someone else can take a good look at it to reproduce the problem.

I'd like to thank you both for your persistence and patience.

[Moo]

Originally Posted by rgleason

Lifepart2 and Moo

If you guys are getting to the point that you've found something amiss,

We are going to need to be able to reproduce this locally using files or something.

I would suggest that, if Moo is willing and does not have another suggestion, that he become the second user to be able to reproduce it.

So LifePart the next task, if Moo agrees or does not have a suggestion to try, is to bundle everything needed to reproduce this problem and upload it here, with some screenshots to explain very clearly what the problem is. Then Moo or someone else can take a good look at it to reproduce the problem.

I'd like to thank you both for your persistence and patience.

Rick, You can suggest all you like but I can't reproduce this here on W10.


I'm going to try later on Linux on an Intel machine and on my Pi setup.



But the fact that I can't reproduce it here so far is odd.


Chris