OpenMarine

Full Version: Work around NMEA window disparition
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Openplotter has moved to  use Signal K between Op and OpenCPN and it works perfectly . Smile
Consequently OpenCPN doesn't receive any more an NMEA flow, (but a Signal K flow), and cannot populate the NMEA debug window we used to check the proper acquisition of GNSS signals. Sad 
We are now limited to check the 'GPS status window' indicator, or the 'Satelite in view' value in the dashboard ...
But I noticed among the possible connections was one called GPSD . GPSD is the utility allowing to share a serial port by multiple users, coming with a number of clients allowing to display, from command line, the GNSS information. Three of those clients are interesting to evaluate the way our GNSS pucks operate :
  • gpsmon   see attached screen captures
  • cgps               "
  • xgps               " 
So how access to this utility ? By creating in openCPN a second connection :
In the picture,both connections are visible :
  1.  : Networt, input, Sigal K, localhost, port 3000, priority 1
  2.  : Network, input, GPSD, localhost, port 2947, priority 0
The priority 0 aims to let the 1st connection do its job, and to avoid any further propagation of the incoming data, so as not to create any loop risk. The hidden bonus is that creating such connection will automatically create a signal  K connection, which can be seen in Signal K.
  • 1st Advantage : the NMEA debiug window is back !
  • 2nd, 3rd & 4th advantages : the GPSD-clients are there to, as close as a command line !

However, to close the hole in the foundation distribution, you have to install the missing dependency of Python 3 :
  • sudo apt install python-gi-cairo
and xgps will display its  sky view, and more : just UN-tick the 'sky view' box in the view menu to access the other gps data...

OK, I admit the ergonomic is quite rustic, and there are some typo (Non instead of Lon) but the information brought by these utilities can be highly precious !

Here below, the connections windows, xgps, cgps, gpsmon :
isn't it much easier just to use nmea on port 10110? Signalk from the server to opencpn is just another option, how it worked before still works.
(2020-12-13, 06:19 PM)PaddyB Wrote: [ -> ]isn't it much easier just to use nmea on port 10110? Signalk from the server to opencpn is just another option, how it worked before still works.
Yes PaddyB (in fact I have a 3rd inactivated connection for that, just in case). 
And we shall always need this way for NMEA to be collected from or distributed to our legacy instruments,

But  thing don't happen by pure Hazard ! The upcoming of Signal K in both Openplotter and OpenCPN show than  both dev teams are going in the same direction, and I could feel a kind guidance to go that way, so I wouldn't be surprised if Signal K became the only way to follow further future developments ...

Therefore, the GPSD path, with its automatic hidden signal K connection, could be the solution as a single connection (with a priority set to >0). Wait and see ...
(2020-12-13, 07:27 PM)Didier B Wrote: [ -> ]
(2020-12-13, 06:19 PM)PaddyB Wrote: [ -> ]isn't it much easier just to use nmea on port 10110? Signalk from the server to opencpn is just another option, how it worked before still works.
Yes PaddyB (in fact I have a 3rd inactivated connection for that, just in case). 
And we shall always need this way for NMEA to be collected from or distributed to our legacy instruments,

But  thing don't happen by pure Hazard ! The upcoming of Signal K in both Openplotter and OpenCPN show than  both dev teams are going in the same direction, and I could feel a kind guidance to go that way, so I wouldn't be surprised if Signal K became the only way to follow further future developments ...

Therefore, the GPSD path, with its automatic hidden  signal K connection, could be the solution as a single connection (with a priority set to >0). Wait and see ...

Just seems like another program with compex setup running for no reason, nmea will always pass straight through.
(2020-12-13, 07:42 PM)PaddyB Wrote: [ -> ]
(2020-12-13, 07:27 PM)Didier B Wrote: [ -> ]
(2020-12-13, 06:19 PM)PaddyB Wrote: [ -> ]isn't it much easier just to use nmea on port 10110? Signalk from the server to opencpn is just another option, how it worked before still works.
Yes PaddyB (in fact I have a 3rd inactivated connection for that, just in case). 
And we shall always need this way for NMEA to be collected from or distributed to our legacy instruments,

But  thing don't happen by pure Hazard ! The upcoming of Signal K in both Openplotter and OpenCPN show than  both dev teams are going in the same direction, and I could feel a kind guidance to go that way, so I wouldn't be surprised if Signal K became the only way to follow further future developments ...

Therefore, the GPSD path, with its automatic hidden  signal K connection, could be the solution as a single connection (with a priority set to >0). Wait and see ...

Just seems like another program with compex setup running for no reason, nmea will always pass straight through.
I noticed that, when disabling the signal k connection, all I²C and pypilot info (boat attitude and environment data) disappeared from OpenCPN dashboard ;
When enabling back the signal K connection they re-appeared ! Makes me think that Signal K connection is a must have !
(2020-12-17, 12:17 AM)Didier . Wrote: [ -> ]I noticed that, when disabling the signal k connection, all I²C and pypilot info (boat attitude and environment data) disappeared from OpenCPN dashboard ;
When enabling back the signal K connection they re-appeared ! Makes me think that Signal K connection is a must have !

If you want to use the logbook (must have imho) then you need to convert some signalk only data to nmea with the sigk - nmea app. Then it appears in the dash as well. Or use both sigk and nmea inputs in opencpn and filter just the nmea data you want as goes in to opencpn.