OpenCPN Version 5.7.1 Release Candidate 1 (RC1)

[bdbcat]

Dirk....
LoL helped decode the corrupted files. Nohal pointed out the root of the complaint. The solution was clear enough, in github now.
Thanks for the info
Dave

[hoolie]

Windows 11; I also get checksum error message loading the JavaScript plug-in

[Mattzilla]

Hi, just installed 5.7.1

Have noticed the AIS icons for other vessels are green triangle, but have no border and are hard to dicern against the chart. They had a black border in previous version.
Is this by design and can it be changed or is it customizable?

[Sailoog]

Originally Posted by Hakan

Saillog..
On Win I could reproduce once while restarting O. The following five time of restart all works.
What I saw was all instruments getting data direct from SK-data via "dashboard_pi::ParseSignalK()" | "dashboard_pi::updateSKItem()" didn't get data.

While data direct from O via: "dashboard_pi::SetPositionFixEx()" , like position, heading, are working all time.
I'll check my RPis as well..

What about an issue?

After testing again I can see that this is somehow a random issue, but for me 95% of it failed and only worked a few times after closing/opening opencpn.

[Hakan]

Sailoog..
I do agree that it's random. Also more frequent failures on RPi than Win.
D and I tried to narrow it yesterday but still no obvious reason so not an easy fix.
Apart from your mentioned methods to reinitialize the data, restart SK or OCPN, also disable and enable the SK connection works all time.

To be continued..

[stevead]

How does a plugin developer determine the NMEA 2000 source address for OpenCPN, other than reviewing the OpenCPN source code ?

#define DEFAULT_N2K_SOURCE_ADDRESS 72

There appears to be an API in comm_drv_n2k.cpp

std::shared_ptr<NavAddr> CommDriverN2K::GetAddress(const N2kName& name)

but it does not appear to be accessible by a plugin.

Some autopilots require the address of the controller to be included in the NMEA 2000 message sent to control the autopilot. Enabling support for NMEA 2000 autopilots was a raison d'etre for the inclusion of NMEA 2000 support in this new release.

A few other observations, possibly an edge case for the SocketCAN interface, and I have no way to test/confirm on the smart adapters such as the NGT-1.

OpenCPN does not perform the address claim dance. If another device with a lower NAME claims the same address, OpenCPN does not claim another address. Possibly unlikely, but with the increased number of NMEA 2000 devices being installed in vessels and the mechanism in which addresses are claimed, this may be problematic.

OpenCPN does not respond to PGN 59904 ISO Requests. Other devices on the network often request PGN 60928 (address claim) as a form of heartbeat, others request PGN 126996 (Product Information) to understand what devices are present. There does seem to be a PGN 59904 event listener buried in comm_drv_n2k_socket.cpp and some code in ProcessRxMessages

if(n2k_msg->PGN.pgn == 59904 ){
  }

, which doesn't actually do anything..

I can confirm that writing NMEA 2000 fast messages onto the network seems to work correctly.

[gallatin1988]

I have installed RC1 via FlatPak. What is the correct plugin catalog? I am currently using master catalog of flatpak-x86_64:22.08.


Thanks,
Sam

[verkerkbr]

Most of the plugins are available. Update plugins and the plugins appear.

[bdbcat]

SteveAd...
1. "Some autopilots require the address of the controller to be included in the NMEA 2000 message sent to control the autopilot."
How does that work? The address, I mean. How is it carried in the message.


2. About address claim: Been waiting for an N2K savvy user to test this functionality. Not terribly surprised there are troubles. I'll take another look.


Thanks
Dave

[verkerkbr]

Originally Posted by verkerkbr

Hi Dave,

just tested the the flatpak 273 version on several systems like the RPI4 with different Operating S. and the Linuxmint AMD64.

The former beta worked well, but the RC1 version gives errors with the movement of the charts and some chart do not appear. Not yet tried the Oesenc charts. But this is my first impression.


Bram

With the latest updates the ..273 RC1 version works very well on the RPI4 with:
Debian Bullseye, Debian Bookworm (works better then Bullseye), Fedora Rawhide and
Ubuntu Lunar Lobster. All running now on the Linux kernel version 6....


Bram

[Antipole]

Originally Posted by Gilletarom

Hello,

Windows 10 :
With Javascript plugin, I have this message. So impossible to install it.

Log file :
18:55:26.467 MESSAGE update_mgr.cpp:218 Selected update: javascript
18:55:26.514 MESSAGE pluginmanager.cpp:572 Installing javascript
18:55:27.186 MESSAGE downloader.cpp:119 filesize https://dl.cloudsmith.io/public/open...-win32.tar.gz: 331572 bytes

Will take this up as a plugin issue here. Please monitor there.

[stevead]

How does that work? The address, I mean. How is it carried in the message

The value is simply a field of a proprietary pgn.

2. About address claim

In my limited testing on Linux using SocketCAN, I have transmitted a PGN 60928 Address Claim message with the same CAN address (72) on the NMEA 2000 network, but did not observe any reply from OpenCPN.

Similarly sending PGN 59904 (ISO Request) for PGN 60928 does not cause OpenCPN to transmit an Address Claim.

[bdbcat]

Stevead....
"The value is simply a field of a proprietary pgn."
That is truly strange. The source address is already in the payload header. Why duplicate? A bit like sending a source ip address as part of a TCP/IP packet payload, just to be sure the receiver understands where the message comes from.


Do you have any reference on this?
Dave
.

[sanner]

In somewhat related question though maybe better for another thread I've been working on a PR to add Attitude(PGN127257) to the Communication Priorities screen. I realized that some PGNs are handled directly by plugins and others (position/heading) through this more central routing. (If I've got that right)


My PR has Attitude alongside pos/heading comms but now I'm wondering if there are other plans for all PGNs/0183/SK to be centralized to the priority screen? (I guess things had been prioritized through the src priority on the connections screen but that obviously has issues w/ n2k bus).

Is there a plan on how to prioritize these other PGN's overall or will that be left to plugin side? Migrate them overtime? Diving into this area of the code for the first time so I may be missing something. Thx.

[bdbcat]

Sanner...
You probably will be better to add some prioritization logic (and maybe GUI) to the plugin that ultimately handles the 127257 message, whatever that is or may be.

I would not be inclined to accept a PR that adds arbitrary PGNs to the existing core N2K priority logic. This logic is reserved for basic navigation information that every N2K net is likely to have, and drives the core navigational needs.
It is possible in some future vision of N2K management to imagine a global N2K message priority scheme in OCPN, with GUI. But I don't think we can get there by patching the current model. Next major version?


Thanks
Dave