NMEA 2000 over WiFi ?

[Scubacat]

NoHal.
That is a very interesting observation. (for OpenCPN).
The main objective for OpenCpn should presumably be to select a format that is easily generated by available WiFi multiplexers and does not limit OpenCPN capability.
For that I would assume an OPEN standard and ability to transport all PGN would be required.
For OpenCPN I would assume that this would then make the Actisense ASCII format I note preferable ? -- It is very simple to understand, so perhaps does not need a "formal" specification. -- It will not pass (or conflict?) with any NMEA0183 messages on the same medium, so perhaps this would be preferred?

My preference for $PCDIN is based on using it inside a Multiplexer to send commands to a N2000 bus that are not able to be sent via converted NMEA0183 messages. Typically autopilot control codes. (In a similar way to $STALK can be used to send messages to a Seatalk1 autopilot). But I could just as easily accept an Actisense ASCII formatted message and generate the N2000.

[rgleason]

"ability to transport all PGN would be required"

Why? Is there a distinction between "transport" and "interpretation"?
Why can't OpenCPN just transport and process PGN that it uses?

[nohal]

Ability to transport all PGNs of course is a paramount requirement for the format we select as primarily supported by the core application.
The other is that it must be rich enough to allow being constructed from or converted to the other formats by a plugin. So that you, or anybody else, can easily achieve the conversion to and from any other format they like, for example SeaSmart.
The third, and IMHO least important, is that it should have as high a market share as possible while satisfying the first two.

[Scubacat]

Originally Posted by nohal

Ability to transport all PGNs of course is a paramount requirement for the format we select as primarily supported by the core application.
The other is that it must be rich enough to allow being constructed from or converted to the other formats by a plugin. So that you, or anybody else, can easily achieve the conversion to and from any other format they like, for example SeaSmart.
The third, and IMHO least important, is that it should have as high a market share as possible while satisfying the first two.

That is a very good point..
Do you have any market share perspectives for the potential RAW alternatives.?.

[nohal]

I don't, all I have are my own observations and see many more Actisense units where stuff is actually connected to NMEA2000 than anything else. Where I am, of course, where you are the situation may be very different.
Advantage of the Actisense format over others of course is that it is supported by https://ttlappalainen.github.io/NMEA2000/ which is used by pretty much every NMEA2000 related open source project out there, so their life would be easier than with any other format we select.
I am very open to hear why each of the formats is better, but being almost NMEA0183 simply is not that feature that would convince me.

[wholybee]

Originally Posted by nohal

I don't, all I have are my own observations and see many more Actisense units where stuff is actually connected to NMEA2000 than anything else. Where I am, of course, where you are the situation may be very different.
Advantage of the Actisense format over others of course is that it is supported by https://ttlappalainen.github.io/NMEA2000/ which is used by pretty much every NMEA2000 related open source project out there, so their life would be easier than with any other format we select.
I am very open to hear why each of the formats is better, but being almost NMEA0183 simply is not that feature that would convince me.

I agree with this assessment completely. I think the almost NMEA0183 option would create lots of trouble. Not only exceeding the max length, but many MNEA0183 devices are also constrained by at most 38400bps and sometimes 4800bps so if this almost 0183 ever made it to one of those devices, it would fail in undefined ways. My gut is that the Actisence is the best choice, but that is my gut, not an empirical evaluation.

I have only a rudimentary understanding of NMEA2000, and I thought this would be much easier. Why can't a gateway device simply take the data off the NMEA2000 bus, and send it over TCP or UDP byte for byte with no translation? Isn't that what happens in a NMEA2000 to USB device? I thought that was (at least mostly) what the binary/raw protocols did. The text version doing nothing more than converting the data byte for byte to a human readable ascii format, and adding a timestamp for additionally readability and troubleshooting.

If there is more going on, why can't the same protocol that is used over USB serial be used over TCP/UDP? Granted that may be a gateway device question, not a question for OpenCPN devs.

My lack of understanding might be showing, but I don't have a strong preference, and I would lean toward the option that modified and changed the underlying data the least.

Actisence is almost the defacto standard for gateway devices, with Yacht Devices a close second, or maybe having taken it's place recently. So that should work into the equation as well. If the Actisence protocol were chosen by OpenCPN, it is reasonably safe to assume that most of the gateway industry would follow because all of these gateways target OpenCPN as one of the primary uses.

[rgleason]

@wholybee Warren I really like this statement it is a very different perspective.

So that should work into the equation as well. If the Actisence protocol were chosen by OpenCPN, it is reasonably safe to assume that most of the gateway industry would follow because all of these gateways target OpenCPN as one of the primary uses.

[bdbcat]

Whollybee


re:

"Why can't a gateway device simply take the data off the NMEA2000 bus, and send it over TCP or UDP byte for byte with no translation? Isn't that what happens in a NMEA2000 to USB device?"


Nope. The Actisense and YD USB devices use a "mostly verbatim" format for the data on the wire. Some header/wrapper bytes. A time stamp. A checksum. That is the format the OCPN 584 understands, and is pretty well documented.



I'd love to be corrected on this, but so far I have not found documentation on exactly what format the Actisense ethernet devices use.
I have at hand a Yacht Devices ethernet device, and it uses an ASCII short packet format, similar in some ways to CANboat log format. it is NOT the same format as the USB devices, at all.


A thick plot.

Dave

[wholybee]

Originally Posted by bdbcat

Whollybee


re:

"Why can't a gateway device simply take the data off the NMEA2000 bus, and send it over TCP or UDP byte for byte with no translation? Isn't that what happens in a NMEA2000 to USB device?"


Nope. The Actisense and YD USB devices use a "mostly verbatim" format for the data on the wire. Some header/wrapper bytes. A time stamp. A checksum. That is the format the OCPN 584 understands, and is pretty well documented.



I'd love to be corrected on this, but so far I have not found documentation on exactly what format the Actisense ethernet devices use.
I have at hand a Yacht Devices ethernet device, and it uses an ASCII short packet format, similar in some ways to CANboat log format. it is NOT the same format as the USB devices, at all.


A thick plot.

Dave

In your opinion, should the Ethernet device follow the USB protocol? Or is there a technical reason it doesn't?

[nohal]

The exactly same format as the NGT-1 uses over USB is one of the 5 Actisense W2K-1 supports. It is not bidirectional in their own solution, only allows transmission of data from W2K-1 to the application.

More about that in https://actisense.com/wp-content/upl...issue-2.19.pdf on pages 13 and 14.
TLDR, they have newer formats for both transmission of unassembled packets and assembled PGNs, each of them in ASCII and binary version, their documentation talks about the plan to publish the specifications, but as far as we know this plan was still not realized.

[wholybee]

Originally Posted by nohal

The exactly same format as the NGT-1 uses over USB is one of the 5 Actisense W2K-1 supports. It is not bidirectional in their own solution, only allows transmission of data from W2K-1 to the application.

More about that in https://actisense.com/wp-content/upl...issue-2.19.pdf on pages 13 and 14.
TLDR, they have newer formats for both transmission of unassembled packets and assembled PGNs, each of them in ASCII and binary version, their documentation talks about the plan to publish the specifications, but as far as we know this plan was still not realized.

I was just reading this as you posted it. And I also have not been able to find any documentation, only that the manual says it is available. Perhaps contacting support will help.

Maybe some quick discussion on pros and cons of the different protocols Antisense has available, at least based on the limited information in the above document.

Actisense NGT - Same format as the USB NGT uses. Unidirectional, so not a good option IMHO.

Actisense Raw - From the Description, this _could_ be a byte for byte transfer from the can bus to a TCP/UDP stream. Bidirectional.

ASCII Raw - From the description, is like the Actisense Raw, but has been converted to human readable ASCII.

Actisense N2k - Not sure how this differs from the Actisense Raw, but perhaps is formatted similar to what Dave describes the USB devices do, with some header and wrapper bytes, and a timestamp.

ASCII N2k - Like Antisense N2k, but formatted as ASCII.

Given those, it seems there are 2 questions to ask. Do you want a binary protocol, or an ASCII protocol. And do you want a RAW format, or a format with header/wrapper and timing information.

And of course, the published specifications for the chosen protocol would be helpful, but I think those must be able to be obtained.

I wonder if either of the Actisense ASCII protocols match the YD ASCII protocol. I don't think that should be the deciding factor, but useful if one protocol could be chosen that would work with both.

[nohal]

After a bit of searching, the formats are already implemented in https://github.com/aldas/go-nmea-cli...main/actisense so we actually could use them if we decided to.

[bdbcat]

wholybee...


At a high level, I think we probably want something like this:


1. Support one or more of the formats provided by the Actisense W2K-1.
Provisos:

a. Choose formats that actually work (i.e. are fully implemented) on real W2K-1 hardware today.
b. Try to get smart (or lucky), and support the one or two Actisense formats that have some probability of being adopted by other hardware vendors in future. Understand that these may or may not be the technically superior solutions. The strong will survive...



2. Support the RAW format provided by Yacht Devices.
a. Just because. YD have a solid and loyal customer base. Their hardware implementations tend to be more "tidy" than Actisense.



And, to make thus project all the more interesting, we should attempt to build an "auto-detect" parser, so as to insulate the OCPN user from the ugly details and mnemonic confusion.


Dave

[bdbcat]

nohal...
In the github link provided, the .go code is probably not practically usable as written. But sure makes a nice readable reference for implementation.


Thanks
Dave

[nohal]

Exactly. After a bit of study I would say it is usable to build an implementation with pretty much only exception of the timestamps in fromActisenseN2KBinaryMessage - looking at the data sample available the values are around 3826835741 (1D E1 18 E4) - that does not make much sense for anything but maybe uptime of the gateway in milliseconds and even that seems weird.

The good thing is that the data fields available seems to be a clear superset of all the other formats we have seen here, so all of them can be converted to it without any loss of data and created from it without anything missing.