OpenCPN Version 5.1.708 RC2 Test

[Hakan]

Mattzilla..
Most instruments now have a watchdog to blank out if incoming data is not updated in about 10 seconds. What is the update rate from your Arduino?
Håkan

[maohls]

Originally Posted by Hakan

Mattzilla..
Most instruments now have a watchdog to blank out if incoming data is not updated in about 10 seconds. What is the update rate from your Arduino?
Håkan

I had exactly the same problem with an Arduino acting as barometer. Changing the update to 5 sec instead of 10 fixed the problem.

/Magnus

[Schnapsy]

Originally Posted by Hakan

Mattzilla..
Most instruments now have a watchdog to blank out if incoming data is not updated in about 10 seconds. What is the update rate from your Arduino?
Håkan

Are you sure ?
This does not seem to be the case for the depth which remains displayed in the dashboard even after a long cut (which can be dangerous !)...

This had been requested in time - FS#2391 - but does not seem to have been taken into account ...

[Hakan]

Originally Posted by Schnapsy

Are you sure ?
This does not seem to be the case for the depth which remains displayed in the dashboard even after a long cut (which can be dangerous !)...

This had been requested in time - FS#2391 - but does not seem to have been taken into account ...

Depth should be supervised by a 10 seconds watchdog as well.

1) Are you using this OCPN-beta?
2) What's your NMEA depth sentence?
It's working for me, see pict where I closed the connection 30 seconds ago.

[Mattzilla]

Originally Posted by maohls

I had exactly the same problem with an Arduino acting as barometer. Changing the update to 5 sec instead of 10 fixed the problem.

/Magnus

It was 10 seconds. I unplugged the USB from nav computer and plugged into my own to change to 5 seconds (Which has resolved it looks like) and then discovered that the instruments were all offline and did not re-connect automatically any more.



With stable release 5 could unpug and reconnect and would pick up straight away - is this related to 10 sec watchdog?
If yes, is there a way to have a button (Like in Expedition) to reconnect instruments - only way I could reconnect was to close and re open Open CPN

[Hakan]

Mattzilla..
I'm not sure I understand the connection problem. Once a valid NMEA sentence is received from any connection it will be used by Dashboard without further actions.
Please check your NMEA Debug window to see what's coming in and maybe publish a shot of the XDR sentences here.

[Mattzilla]

I have resolved the Baro update by altering the arduino to update every 5 seconds as opposed to 10.


I have found another issue - the vessel I am on has a USB multiplexor. If the USB is unplugged, after ~10 seconds all instrument data no longer updates. IF I then reconnect the USB, it fails to reconnect the data.
For this I have to restart, or goto connections, uncheck my COM port connections, apply, then re-check, APPLY then instruments start working.


Suggestion is for a button that can force-reconnect instruments? (Expedition marine has this functions to force reconnect instrument ports) Or if watchdog can check for instruments after a time? I dont know how the watchdog is designed to work.

[Hakan]

Mattzilla--
If data is flowing into OCPN they are also used immediately. The watchdog timer is only checking for new updates. If data is coming in the timer is reset. No need for any re-initialization in OCPN.
Your description of the multiplexer function seems strange though. What about put all USB direct to the PC or use a USB switch instead?

[Mattzilla]

Originally Posted by Hakan

Mattzilla--
If data is flowing into OCPN they are also used immediately. The watchdog timer is only checking for new updates. If data is coming in the timer is reset. No need for any re-initialization in OCPN.
Your description of the multiplexer function seems strange though. What about put all USB direct to the PC or use a USB switch instead?

The USB goes to a USB hub then into the laptop. I have tried direct to laptop and issue persists. But stable version OpenCPN issue is not present.
Is a Shipmodul multiplexor.
It seems with the RC2 version, that a USB com port does not start on its own after watchdog drops it or if removed/reconnected. This is true for the Arduino and/or the Multiplexor by USB



I also just tried switching to ethernet NMEA data in - same thing, if I unplug ethernet, after ~10secs, instruments all drop out, reconnect ethernet - no data started for about 30+ seconds, then came online. SO the Ethernet started on own, but USB needed forcing

[conachair]

Originally Posted by Hakan

Mattzilla--
If data is flowing into OCPN they are also used immediately. The watchdog timer is only checking for new updates. If data is coming in the timer is reset. No need for any re-initialization in OCPN.
Your description of the multiplexer function seems strange though. What about put all USB direct to the PC or use a USB switch instead?

Just recreated the error with an esp32 sending a dummy nmea sentence.
Set connection to com3 in Opencpm 5.0, unplug and replug the USB and the data starts coming in again after a moment.
5.1.7 unplu/replug and no data comes in after the replug. LED flashes on the ESP so should be running ok, the led flash is in the same function as the print nmea .

[Hakan]

So, nothing to do with Dashboard or USB devices then?
I can't do the same test just now.
@Dave.. Anything you can reproduce?
Håkan

[conachair]

Originally Posted by Hakan

So, nothing to do with Dashboard or USB devices then?
I can't do the same test just now.
@Dave.. Anything you can reproduce?
Håkan

Might be just arduino/esp that do this as well, they usually do a reset when the serial connects.
Unplugging/ replugging in v5 doesn't seem to leave anything in the log, the data just appears again in the debug window.

[Schnapsy]

Originally Posted by Hakan

Depth should be supervised by a 10 seconds watchdog as well.

1) Are you using this OCPN-beta?
2) What's your NMEA depth sentence?
It's working for me, see pict where I closed the connection 30 seconds ago.

yes, I test with OCN 5.1.708.
But there may be a bias ...
Indeed, I test with a VDR file which contains multiple nmea sentences including the depth; then I stop this file and I launch a VDR file which contains nmea sentences but not the depth.
And the depth of the previous file remains displayed ...

I will have to do the test in real life, on my boat by turning off the sounder.

Maybe next week....

[bdbcat]

mgrouch...


re:
"Raspberry Pi 4 with Buster with theme called Breeze-Dark."


On very latest RaspiOS/32, buster, available from raspberry pi download, I do not see this "Breeze-dark" theme. pix attached.


Am I looking at the wrong thing?
Thanks
Dave

[bdbcat]

Hakan...


Hmmm...
Seems to be a regression for sure.

My simple setup:
Win10, USB serial adapter to common NMEA0183 data stream containing RMC.
Test procedure:
1. Start O, verify position received OK. (green bars...)

2. unplug the USB cable, wait for red dot in upper right, no position watchdog timeout.
3. Re-plug USB.


Results:
O5: Works as expected. Connection is re-established, all is well.
O5.1.708: Connection is NOT re-established.


Nothing to do directly with dashboard timeouts. Must be in OCPN core.
I will investigate.
Dave