NMEA 2000 over WiFi ?

[Scubacat]

EDIT.. It does accept UDP "RAW" - I wil try to find out why my previous UDP test failed.. Possibly because I was trying to use UDP in/out.
But I still cannot get a "N2000" response in RAW suitable for wifi out of the Raymarine AP plugin!

ALSO.. is there an edit post capability in this forum! Most frustrating to post and see an error and not be able to correct it!

[wholybee]

Originally Posted by Scubacat

I missed the alpha tests, but needed today to check (V5.10) out and note that the TCP network works fine with both "N2KASCII" RAW and "$PCDIN" RAW input formats. However, neither format are accepted via UDP.

I presume this failure to accept (raw) 'N2000' UDP is a bug ?? Or are there some subtle settings hidden I have missed?

Slight rant.. it would be very nice if the "port connections" identified which RAW format the "N2000" protocol can accept (or is trying to send!!).

Also some clarity about what OpenCPN can transmit wirelessly in the "N2000" mode would be appreciated. I could not see any "sent" data in the debug window - but would have expected to see a N2KASCII or PCDIN transliteration of sent pgns for eg GOTO or AP button pressing.

Thanks
Dagnall

I don't think the debug window currently displays n2k pgns that are transmitted. But, the Autotrack Raymarine plugin does successfully control my autopilot. It causes opencpn to crash after 5 minutes, but it definitely sends the pgns to the AP until then.

I would be interested in your results, as no one else con duplicate the crashes, even though they happen to me on 3 different setups. This weekend I hope to test on a raspberry pi, just as another data point.

[Scubacat]

Originally Posted by wholybee

I don't think the debug window currently displays n2k pgns that are transmitted. But, the Autotrack Raymarine plugin does successfully control my autopilot. It causes opencpn to crash after 5 minutes, but it definitely sends the pgns to the AP until then.

I would be interested in your results, as no one else con duplicate the crashes, even though they happen to me on 3 different setups. This weekend I hope to test on a raspberry pi, just as another data point.

Warren, I think I also saw some crash on PC. So I will try hard to see if I can get some data. I need to repeat my tests with separate comms channels for UDP TX and UDP RX as I think for some reason OpenCPN has issues if it tries to do In/OUT on a single port (and it would be good to definitely confirm this.

The key help for me would be to see some evidence of PGNS being sent in the OpenCPN debug window..
Also some setting that would define which RAW format the Wifi “N2000” is being sent with!
My gateway can accept multiple formats, but need to know which ione is expected.. N2KASCII and $PCDIN are by far the easiest to deal with. The Binary RAW that actisense use for Serial gave me headaches! And I worry that this may be the default OpenCPN “output RAW” format.

Raw format autodetect for incoming is helpful, but what RAW format did the developers try to use to “send” out PGNS.. One would hope the same format that they detected.. but who knows..

On the Raymarine AP - Are you using that in the N2000 (EVO?) mode or the “$Stalk sending” mode.. (The latter works fine — the former is supposed to send PGNS.. and is where I am having issues seeing any PGNS at all!)

Is there any chance you could capture (ideally using N2kASCII or $PCDIN) some autopilot communications so I can simulate the AP presence and see if that makes a difference? The plugin may want to send the PGN to the “seen” Autopilot, and without ine in my test bench, it may just be ‘waiting’.

Having said that - I also have issues with (none seen!) PGN for Goto waypoints etc.. so it could be a much bigger OpenCPN “not sending PGN” issue.

Cheers

[stevead]

Having said that - I also have issues with (none seen!) PGN for Goto waypoints etc.. so it could be a much bigger OpenCPN “not sending PGN” issue.

OpenCPN doesn't send any NMEA 2000 navigation data (PGN's 129284, 129285) when navigating to a waypoint or following a route.

What confuses many is that Douwe's Autotrack Raymarine plugin when following a route or navigating to waypoint, doesn't put the EVO into Nav mode, it simply puts the EVO into heading mode and the plugin sends heading corrections. The plugin does not send nor care about the NMEA 2000 Navigation PGN's.

[wholybee]

Originally Posted by stevead

OpenCPN doesn't send any NMEA 2000 navigation data (PGN's 129284, 129285) when navigating to a waypoint or following a route.

What confuses many is that Douwe's Autotrack Raymarine plugin when following a route or navigating to waypoint, doesn't put the EVO into Nav mode, it simply puts the EVO into heading mode and the plugin sends heading corrections. The plugin does not send nor care about the NMEA 2000 Navigation PGN's.

Nonetheless, heading corrections are not shown in the NMEA debug window either. If you trust the NMEA debug window, N2K data is received, but not sent. But the plugin does control the AP, so some N2K data is being sent.

[stevead]

Nonetheless, heading corrections are not shown in the NMEA debug window either.

The heading corrections are calculated by the plugin which then generates and transmits the proprietary NMEA 2000 PGN's to the EVO.

I don't believe the debug window shows transmitted PGN's, only those received.

[Scubacat]

Originally Posted by stevead

I don't believe the debug window shows transmitted PGN's, only those received.

I think this is demonstrating inconsistent behaviour (?) of the debug UI for N2000 relative to 0183 data.

The debug window definitely shows transmitted 0183 messages?
Is this something that is planned to be corrected?

[stevead]

Originally Posted by Scubacat

I think this is demonstrating inconsistent behaviour (?) of the debug UI for N2000 relative to 0183 data.

The debug window definitely shows transmitted 0183 messages?
Is this something that is planned to be corrected?

Beyond my pay grade, a question better asked of Dave at al.

However with respect to NMEA 2000 autopilots, which at the moment support is provided by plugins, due to the use of proprietary PGN's it is kind of difficult for core OpenCPN to decode them into anything meaningful.

[bdbcat]

Scubacat...
This:
"due to the use of proprietary PGN's it is kind of difficult for core OpenCPN to decode them into anything meaningful."


According to our research, there are no generally defined PGNs that will reliably control any known N2K autopilot. So OCPN delegates control of modern N2K autopilots to vendor specific plugins.


Of course, we do not have access to all possible network configurations and autopilot devices. So we base our claim on anecdotal references. We sure would not mind being proven wrong on this claim, if you can help.


And if there are other use cases for OCPN core to transmit one or more common PGNs, we would like to talk about that in specifics.


Thanks
Dave

[wholybee]

Originally Posted by bdbcat

Scubacat...
This:
"due to the use of proprietary PGN's it is kind of difficult for core OpenCPN to decode them into anything meaningful."


According to our research, there are no generally defined PGNs that will reliably control any known N2K autopilot. So OCPN delegates control of modern N2K autopilots to vendor specific plugins.


Of course, we do not have access to all possible network configurations and autopilot devices. So we base our claim on anecdotal references. We sure would not mind being proven wrong on this claim, if you can help.


And if there are other use cases for OCPN core to transmit one or more common PGNs, we would like to talk about that in specifics.


Thanks
Dave

I would like to suggest the following PGNs. I believe that none of these are proprietary, and while they will not control any autopilot, would probably work with many/most autopilots once activated from the autopilot head. This would basically mirror the functionality of what OCPN does with NMEA0183. Any plugin would then only need to deal with the proprietary PGNs to activate the pilot and change modes.


129283 Cross track error
129284 Navigational Data (sent 2x with true and magnetic bearings)
129285 Active Waypoint Data

And maybe 127258 Magnetic Variation, unless a GNSS device normally sends that?

My source on those is the Raymarine EV-1 manual, pg 123
https://raymarine.app.box.com/s/j9ua...e/119763483197

And Yacht Devices YDWG-02 manual, page 57
https://www.yachtd.com/downloads/ydwg02.pdf

Also, in the debug window. It would be helpful to show the PGNs being sent, even if the payload was not decoded. Perhaps the PGN and some hex data?

[Scubacat]

Originally Posted by wholybee

I would like to suggest the following PGNs.
129283 Cross track error
129284 Navigational Data (sent 2x with true and magnetic bearings)
129285 Active Waypoint Data

I thought I had sent a longer response, but seem to have managed to lose it!..
I note that https://opencpn.org/wiki/dokuwiki/do...ions:autopilot defines:

1. Engaging the autopilot. This means to turn on the autopilot, change the mode from Standby to Heading (follow a compass bearing), Wind (steer to a wind angle) or Navigation (steer towards a waypoint).
2. Controlling the autopilot. When the autopilot is in Navigation mode, this means sending navigation data to the autopilot to ensure it stays on course.

So the plugins Engage - and need to use proprietary commands.

OCPN should be capable of "Controlling" the AP using PGN or 0183 messages and that is not proprietary.

IMHO the communications debug window MUST show all messages sent.. the PGN should at least identify source and destination and PGN number. but for some reason the sent PGN are currently not shown (?)

I referenced the manual above and believe that it demonstrates the confusion about N2000 AP and 0183 AP that was appropriate when OPCN could not send N2K messages out.
Now that we are beginning to have proper N2000 support, the method to "control" AP is (should be) near identical. OCPN (should!) send XTE/waypoint etc data in N2k or 0183 messages that the AP will use to steer towards a waypoint.

[stevead]

To control a NMEA 2000 autopilot when in navigation mode, it should be possible for OpenCPN to generate and transmit PGN's 129283 and 129284 just as it does today sending NMEA 0183 XTE, APB & RMB sentences.

BTW, already done today in an unreleased version of TwoCan.

However two things to note. As I said before, Douwe's Raymarine Plugin does not engage the autopilot in Nav mode, it simply engages the autopilot in heading mode and the plugin adjusts the heading using its own algorithms using xte etc. In this case no PGN's 129283 or 129284 are required.

Secondly, and I can't comment on Raymarine or Garmin but for B&G NAC-3 the navigation data sources must be selected during dockside commissioning, which may be problematic for many OpenCPN users who are not network savvy.

Also I can't recall if OPENCPN displays its NMEA Network address anywhere.

Just like Windows, it will probably take at least three versions before OpenCPN gets its NMEA 2000 support nailed down.

[Scubacat]

Thanks, just two comments to comment on: !

Originally Posted by stevead

BTW, already done today in an unreleased version of TwoCan.

However two things to note. As I said before, Douwe's Raymarine Plugin does not engage the autopilot in Nav mode,

First, What is "TwoCan" ??

Second, I'm mainly discussing Bernd Cirotzki's Raymarine plugin, that works excellently and is ENGAGING the AP (at least in $STALK mode - it just does not work yet with N2K, mainly apparently due to limits in OCPN sending RAW PGN. ?). It does not try to "control" the AP as you describe. (at least in the sense of the OCPN definitions! )

[stevead]

TwoCan is a plugin that integrates NMEA 2000 networks with OpenCPN. It predates OpenCPN's NMEA 2000 support.

I'm mainly discussing Bernd Cirotzki's Raymarine plugin, that works excellently and is ENGAGING the AP (at least in $STALK mode. It just does not work yet with N2K, mainly apparently due to limits in OCPN sending RAW PGN. ?

As stated before, OpenCPN does not generate PGN's 129283 & 129284 however nothing to prevent Bernd from adding that to his plugin.

I don't know what you mean by "RAW PGN", nonetheless there are no restrictions with OpenCPN transmitting any PGN. Any plugin may construct any PGN and transmit it onto the network via OpenCPN's communications framework.

[Scubacat]

Originally Posted by stevead

TwoCan is a plugin that integrates NMEA 2000 networks with OpenCPN. It predates OpenCPN's NMEA 2000 support.

As stated before, OpenCPN does not generate PGN's 129283 & 129284 however nothing to prevent Bernd from adding that to his plugin.

I don't know what you mean by "RAW PGN", nonetheless there are no restrictions with OpenCPN transmitting any PGN. Any plugin may construct any PGN and transmit it onto the network via OpenCPN's communications framework.

Thanks. We certainly seem to be at cross purposes!

I believe that OCPN, if it claims any N2K connectivity, should (natively) SEND the appopriate PGNs for XTE/WP etc, in the same way that it RECEIVES PGN for position, depth etc.
This is not a job for plugins, unless they have to do so to overcome OCPN native shortcomings.

Berndt’s Plugin only “engages” the AP, and does not send the commands to “control” it, as it reasonably assumes OCPN will send the WP/XTE etc ‘PGNs’ if a route is activated. (As would be the case for 0183 comms). To suggest he should do so is rather missing the point of the discussion about OCPN natively sending goto data when a route is activated.

Regarding “RAW” this term is generally used to denote a file / protocol that is are so named because they are not yet processed. Its used in image capture and also in data transfer. For N2K there are a number of different RAW formats in general use that all specify the data content that can become a NMEA2000 pgn datagram on a CANBUS network. Only data on the CANBUS is truly N2000. If an app (OCPN) needs to communicate what a PGN will contain to - for example - a gateway with CANBUS (N2K) hardware, then that data must be sent in one of the RAW formats, so that the gateway can process it into the CANBUS pgn datagram.

The same is true in reverse as the gateway cannot actually send any “n2000 pgn” to OCPN, but must first convert (transliterate without processing) data from the CANBUS datagram to one of the RAW formats, which OCPN can then accept and use internally after extracting the message data. The latest release seems to accept multiple formats, so plaudits for that! The formats I have used are “N2KASCII” and $PCDIN.

The other (older) way that the gateway can operate is to convert PGN to 0183 equivalent messages in the gateway and send those, as the 0183 ASCII format is compatible with serial, UDP and TCP. This approach is adequate where 0183<>PGN conversions are known and understood and in most use cases would be the preferred mode of operation as OCPN is competent with 0183 (and - rather repeating myself- OCPN natively sends 0183 XTE etc when a route is actvated) ;-)

But unfortunately there are a few and possibly growing number of cases where the pgn<>0183 conversions are not possible. Proprietary commands are one of these, and the use of RAW formats allows an app to read/send any and all pgn.
This is why OCPN has added the capability, and why no limits are present, as plugins can eventually send/recieve any pgn. (PROVIDING that OCPN will actually send them out in a known RAW format!!).

You comment on the OCPN framework. I have yet to see ANY ‘n2k’ data sent from OCPN, so I do wonder if the “send” element is not yet functional, or expects and is only usable with canbus hardware?
I would appreciate details of any setup where data out from OCPN has been seen/sent via “the N2k connections”. The ‘recieve’ part of the framework seems to work fine.

My personal belief is that the best solution is to use 0183 data wherever possible, but to allow sending RAW PGN as well, so the Gateway can send / receive messages not translatable to standard 0183. - Exactly the solution used for Seatalk1 where “$STALK” format (essentially a RAW Seatalk1 message) allows sending special proprietary data. (And this IS a case where plugins are appopriate - and exactly what Berndt’s plugin does).


Sorry to be longwinded..
D