OpenCPN Version 5.2.0 Released

[verkerkbr]

Originally Posted by Wbartoszy

Hi.


I don't know: it's a problem in OpenCPN or in the Dashboard plugin...
After changing the suorce of data about position from "TCP (NMEA0183)" to "SignalK", GNSS data comes in, and openCPN sees it, but the "GPS Status" on "Dashboard" is empty ... (but "Position", "SOG" etc. are correct).

OpenCPN 5.2 on Openplotter 2 on Raspberry Pi 4

BR - Wojtek

If you use SignalK to OpenCPN the number of sats does not show. However it is in the SignalK server. If you use the Tommy Kip SignalK application then you can see the number of sats. You can also see the sats in SignalK diagnostic in OpenPlotter.

[Rasbats]

On the MacOS finally got the 'JavaScript_pi' plugin to compile without needing a modified OpenCPN.

For the MacOS the plugin can have the wxStyledTextCtrl compiled and built in to the 'dylib' without the need for any changes to OpenCPN base code.

Mike

[Hakan]

Originally Posted by Mattzilla

Data is also stopping from multiplexor with OpenCPN running for a few hours - came off watch to all instrument data blank/not updating. Laptop is not sleeping and have disabled USB power management options.

Unplug/replug USB to fix.

Mattzill.. Dave..
On Win10:
I can confirm a similar experience. Two times today a USB port lost connection to O. Unplug-Plug the USB recomposed the data flow in O wo further actions.

If of any relevance this USB is a doubled serials to one USB -> two COM ports. Have been working for years although I've to tweak the registry after every Win10 major update in terms of giving each port a unique name. But since others have seen the same this specialty wouldn't be a relevant cause.
Håkan

[Wbartoszy]

Originally Posted by Hakan

Your observation is correct.
But it's SignalK that not parse the "GSV" sentence to a JSON message. Number of satellites "GPS in View" from GGA are though there.

Originally Posted by verkerkbr

If you use SignalK to OpenCPN the number of sats does not show. However it is in the SignalK server. If you use the Tommy Kip SignalK application then you can see the number of sats. You can also see the sats in SignalK diagnostic in OpenPlotter.

I have a GNSS receiver connected (via USB -> Serial (NMEA0183) to the SignalK server. Then the SignalK plugin ("signalk-to-nmea0183") makes data conversations to NMEA0183 format and sends it to port 10110 (if the plugin is deactivated there is NO DATA on port 101110).

Is the GSV sequence sent directly from NMEA0183 GNSS to port 10110 (bypassing SignalK)?

I checked, there is really no (explicit) GSV sequence in the plugin...
But the GSV sequences on the 10110 port after conversion exist...

I have only this one connection 192.168.1.185:10110 in OpenCPN...
I tried OpenCPN on a Raspberry and on an external PC - same effect.

[Hakan]

The O-Dashboard instrument "GPS Status" info comes from NMEA "GSV". SignalK NMEA parser don't use GSV so this info is not available as a SignalK JSON message. https://github.com/SignalK/signalk-p...e/master/hooks


The O Dashboard instrument "GPS in view" info comes from NMEA "GGA". SignalK NMEA parser do use GGA so this info is available as a SignalK JSON message; "navigation.gnss.satellites". It's also used by O Dashboard when you have a Signal K protocol connection.


If you feed SignalK with a NMEA0183 GSV message you can of course read it out from a SignalK server as a NMEA0183 message on a TCP/UDP connection since it's only reflected out. On a Signal K protocol connection this info is not available though.
Use the instrument "GPS in view" instead of "GPS status" and you'll see the number of satellites used as long the (GP)GGA message is transferred to SignalK.


Håkan

[Wbartoszy]

Originally Posted by Hakan

If you feed SignalK with a NMEA0183 GSV message you can of course read it out from a SignalK server as a NMEA0183 message on a TCP/UDP connection since it's only reflected out. On a Signal K protocol connection this info is not available though.

Thanks for explain.

My mistake, I assumed the "conversion" SignalK-> NMEA is a real conversion (not a bypass in this case). I should connect two SignalK servers via SignalK protocol and convert to mnea on the secend one...

This means: NMEA 0183 is "better" than SignalK (in this particular case of course)...

[Hakan]

re: "This means: NMEA 0183 is "better" than SignalK (in this particular case of course)"

If you have only NMEA0183 data there's no need to use SignalK if you don't want it. Then you can connect direct to OCPN instead. That's true. But the advantages of SignalK is you can mix different types of connections and collect it as a single source to OCPN. Some sources are not available for OCPN e.g. 1-wire termoelement, I2C compass, NMEA2000 messages from new instruments and so on. Most are conversed to the specific SignalK messages and can be used by OCPN via the Signal K protocol.

If the SignalK team decide to implement the NMEA0183 GSV message and we adapt our Dashboard also GPS status will be read out.

Håkan

[verkerkbr]

Originally Posted by verkerkbr

Oesenc plugin is not in the latest plugin list. The usb sg-lock key shows in usbview.

Perhaps I need a later version of OpenCPn for arm64.

Bram

Looking for the 4.2.10 oesenc plugin. But no find. The Plugin management in the 5.2 Focal version does not yet work. Is there a separate download possible of this plugin ?

Everything is working in the latest 64 bits Ubuntu Focal for the rpi, except the Oesenc plugin.


Bram

[Wbartoszy]

Originally Posted by Hakan

re: "This means: NMEA 0183 is "better" than SignalK (in this particular case of course)"If the SignalK team decide to implement the NMEA0183 GSV message and we adapt our Dashboard also GPS status will be read out.

And that would be IMHO best solution.
BTW: Or should SignalK use (contain, convert) all NMEA sentences?

[bdbcat]

Bram...
What is your environment? rPi4? RaspiOS, or something different?
Any more information?


Thanks
Dave

[verkerkbr]

Originally Posted by bdbcat

Bram...
What is your environment? rPi4? RaspiOS, or something different?
Any more information?


Thanks
Dave

Hi Dave,

the Raspian 64 Raspi OS works very with the 5.2 version. But I always like to try new software.

Ubuntu has just official released the 64 bits Focal ARM64 version for the Raspberry Pi.

This version works very well with the OpenPlotter 5.2 Focal version. The SignalK server is also running.

What is missing the plugin manager to install the Oesenc plug (dongle) for the arm64.

Is it the 4.2.10 version ?

The NMEA2000 input in SignalK with the Canable or NGT-1 is also working.

Regards from a hot Zeeland,


Bram

[verkerkbr]

Originally Posted by verkerkbr

Hi Dave,

the Raspian 64 Raspi OS works very with the 5.2 version. But I always like to try new software.

Ubuntu has just official released the 64 bits Focal ARM64 version for the Raspberry Pi.

This version works very well with the OpenPlotter 5.2 Focal version. The SignalK server is also running.

What is missing the plugin manager to install the Oesenc plug (dongle) for the arm64.

Is it the 4.2.10 version ?

The NMEA2000 input in SignalK with the Canable or NGT-1 is also working.

Regards from a hot Zeeland,


Bram

Hi Dave,

Reuver had available a compiled version of the oesenc plugin version 4.2.14-0.

At first it does not seem to work. Usb dongle not recognised was the message.

This was because libusb-0.1 was missing. After installing this item. Oesenc chart also works on the Ubunto Focal version in combination with the oesenc dongle.


Bram

[bdbcat]

Bram...
So, all working now?


Dave

[verkerkbr]

Originally Posted by bdbcat

Bram...
So, all working now?


Dave

Yes, everything is running fine in Focal 64 bits. Especially OpenCPN version 5.2 in combination with the SignalK server. OpenCPN as the chartplotter and the SignalK server as the mainstay for marine data processing..

Thanks for this great software.


Bram

[aboon]

Congratulations to the development team on V5.2, great work as always!
I have just loaded V5.2 and the latest base map and updates for my AusENC (S63) charts. I subscribe to the charts direct from the Aust Hydrographic Office.
I have noticed two issues with the new version.
1. The boundary of an obstruction area around groups of rocks, shoals etc. is often broken up into many segments, not always meeting, rather than a continuous line. Not all obstruction boundaries are affected, but with those that are, the effect does not seem to change with any settings (Vector Chart Display or User Standard Objects). I've attached two images of the same area, same data files, one from V5.0 (S63 pi V1.12) and the second from V5.2 (S63 pi V1.16.725).
2. Something is happening with the Harbour Area (administrative) setting. With the setting on, to display the Port Limits, I see many lines close to the shoreline, of the same line-type as the actual administrative boundary. These were not evident with V5.0. The direction of the 'tick marks' is not consistently pointing in to the area bounded (and in one case, the direction changes with chart scale).
I'm running on Windows 10 Pro.

Andrew