Didier, we don't know exactly what's causing you trouble even though we're getting closer.
But to serve you as a reference, I myself have put Signal K as the exclusive center of openplotter and it goes to perfection. In my assembly a small rpi- with Moitessier hat collects data from GPS, Ais, the rest of sensors of the moitessier hat and even seatalk data. ALL go directly to Signalk.
In fact in that central rpi with Signal K I have eliminated even applications like openplotter-serial because I do not need it when doing that Signal K work.
As a result everything works to perfection so I can assure you that Signal K is one of the best parts of OpenPlotter.
This little Rpi that collects everything and sends it out using Signal K, does nothing more than that. Then, on the navstation I have the Rpi4, the main one, which collects this data sent by the small rpi3 with hat. In this rpi4 is where OpenCpn runs and works properly. I use OpenCpn exclusively with data type Signal K. Also I could do it with NMEA0183 data and it would work exactly the same.
Sailoog thinks that in your case there might be some lack of GPS signal quality either because of the area you are in or because of some kind of interference. It seems that in such a case OpenCpn does not interpret that situation well, or at least it does not do it as well as when working with NMEA0183 data. That could be the origin of your problems. If so, it is not a problem related to Signal K but to OpenCpn and its way of understanding the Signal K data.
In your case try to replace your opencpn data connection with the classic NMEA 0183 type. That is to say, cancel the Signal K localhost:3000 and change it for the TCP localhost:10110.
Check if using only NMEA 0183 type your problem disappears or changes its behavior.
And don't be obsessed with Signal K, believe me, it's one of the best advances we're expecting. NMEA0183 is quite limited.
I can confirm it Didier. I'm on board and I just did the experiment.
If I use opencpn with Signal K data everything goes perfect. Then I have thought to use the portable VHF and start to broadcast just above the HAT Moitessier. In a few seconds the GPS signal has been distorted and the boat has jumped to world position 0.0 in the Atlantic.
I have repeated the experiment using NMEA0183 data and by cancelling the GPS signal the opencpn boat has changed to grey as I expected but it has NOT moved to 0.0. It is here where OpenCpn must be corrected so that when the GPS signal is lost it behaves in the same way. NOT moving the boat to 0.0 but keeping it in the last known position.
This seems to be a problem related exclusively to OpenCpn and will surely be solved soon.
But to serve you as a reference, I myself have put Signal K as the exclusive center of openplotter and it goes to perfection. In my assembly a small rpi- with Moitessier hat collects data from GPS, Ais, the rest of sensors of the moitessier hat and even seatalk data. ALL go directly to Signalk.
In fact in that central rpi with Signal K I have eliminated even applications like openplotter-serial because I do not need it when doing that Signal K work.
As a result everything works to perfection so I can assure you that Signal K is one of the best parts of OpenPlotter.
This little Rpi that collects everything and sends it out using Signal K, does nothing more than that. Then, on the navstation I have the Rpi4, the main one, which collects this data sent by the small rpi3 with hat. In this rpi4 is where OpenCpn runs and works properly. I use OpenCpn exclusively with data type Signal K. Also I could do it with NMEA0183 data and it would work exactly the same.
Sailoog thinks that in your case there might be some lack of GPS signal quality either because of the area you are in or because of some kind of interference. It seems that in such a case OpenCpn does not interpret that situation well, or at least it does not do it as well as when working with NMEA0183 data. That could be the origin of your problems. If so, it is not a problem related to Signal K but to OpenCpn and its way of understanding the Signal K data.
In your case try to replace your opencpn data connection with the classic NMEA 0183 type. That is to say, cancel the Signal K localhost:3000 and change it for the TCP localhost:10110.
Check if using only NMEA 0183 type your problem disappears or changes its behavior.
And don't be obsessed with Signal K, believe me, it's one of the best advances we're expecting. NMEA0183 is quite limited.
I can confirm it Didier. I'm on board and I just did the experiment.
If I use opencpn with Signal K data everything goes perfect. Then I have thought to use the portable VHF and start to broadcast just above the HAT Moitessier. In a few seconds the GPS signal has been distorted and the boat has jumped to world position 0.0 in the Atlantic.
I have repeated the experiment using NMEA0183 data and by cancelling the GPS signal the opencpn boat has changed to grey as I expected but it has NOT moved to 0.0. It is here where OpenCpn must be corrected so that when the GPS signal is lost it behaves in the same way. NOT moving the boat to 0.0 but keeping it in the last known position.
This seems to be a problem related exclusively to OpenCpn and will surely be solved soon.