NMEA 2000 over WiFi ?

[stevead]

Pavel, I fear you may have misunderstood the discusion between Tony & myself. We have been discussing NMEA 0183 encoding of NMEA 2000 by the Chetco Seasmart protocol ($PCDIN) and the Shipmodul protocol ($MSPGN).

Most of the participants in this thread are of the opinion that OpenCPN should not natively support these formats. In the light of this, the suggestion was made that the Javascript plugin could support this scenario, albeit using some indirect mechanism to provide the data to OpenCPN.

Tony & myself have not been discussing the other protocols (ASCII Raw, Actisense Raw, ASCII N2K, Actisense N2K), of which the assumption is that one or more will be natively supported by OpenCPN with the NMEA 2000 data ingested directly.

I hope that provides some clarity.

[nohal]

I perfectly understand what you discuss, what I do not understand is why you keep inventing the bizarre ways to somehow hack the injection of the converted payload into OpenCPN instead of simply accepting the fact that it will be possible to inject into the NMEA2000 over IP pipeline (which will be using one of the raw formats) which is the subject of this thread.

[Scubacat]

Originally Posted by Antipole

Or push decoded data as NME0183 where there is an appropriate sentence. We know that works.

I came on this discussion thinking it was discussing how to send N2000 data over WiFi..

But it appears that the main discussion seems to be about how to get N2000 instrument data into OpenCPN ??

The Questions "How do I send N2000 data over WiFi" and the question "How can I use N2000 instrument data in an application that gets its data via WiFi" are subtly different questions and should not be conflated.

I would like to enlarge my previous comments about $PCDIN format in this light:

• The $PCDIN format is indeed an excellent, transparent, method to send N2000 data (ie the data actually sent over the N2000 canbus) over WIFI.
• There are other methods that may be equally competent at transcribing N2000 (canbus originated) data and reconstructing it as N2000 data after transfer over WiFi. (I happen to prefer $PCDIN)
• However these transcriptions are not an optimal method for getting NMEA2000 instrument data into OpenCPN (or any other application). - they simply make the raw N2000 data available to the application. - Where it must be parsed and converted to get useful data.

I would agree with Antipole that using existing and well documented '0183' messages is a pragmatic and practical approach to getting data into applications. The conversions from N2000 to 0183 are well understood and although strictly proprietary, are sufficiently well documented in web sources to be usable. Most Wifi multiplexers will already convert "N2k" PGN's to familiar '0183' messages. For PGN that are not readily convertible, then $PCDIN is available, and the receiving application will have to attempt to unravel the data and use it. It is also available "in reverse" so that the application can send (any!) PGN and have it appear on the canbus.

[stevead]

OK Pavel, I think the penny has dropped.

Is this what you are suggesting as the Javascript plugin's mechanism for supporting the $PCDIN or $MSPGN NMEA 0183 encapsulation of NMEA 2000?

If so, then I guess we are just waiting for a decision on which of the protocols (Actisense Raw, Actisense N2K, ASCII Raw or ASCII N2K) will be supported.

[nohal]

Basically yes, except that instead of resending the packet payload over IP again in a different format it will be inserted into the pipeline using the API.

[Scubacat]

Originally Posted by stevead

OK Pavel, I think the penny has dropped.

Is this what you are suggesting as the Javascript plugin's mechanism for supporting the $PCDIN or $MSPGN NMEA 0183 encapsulation of NMEA 2000?

If so, then I guess we are just waiting for a decision on which of the protocols (Actisense Raw, Actisense N2K, ASCII Raw or ASCII N2K) will be supported.

Before Pavel /NoHal reply, I happened to see this..
Please I hope this is not as proposed.. !!

IF THE ORIGINAL DATA source is encoded '0183'.. Then it can be sent over whatever transport method you have (serial/WiFi) without alteration.

IF THE ORIGINAL DATA source is 'N2000' (CANBUS) then it MUST to be converted/encapsulated before it can be sent: These "RAW" protocols all have benefits and disadvantages.. but PLEASE just choose one and do not suggest converting between them!.

[nohal]

Originally Posted by Scubacat

Before Pavel /NoHal reply, I happened to see this..
Please I hope this is not as proposed.. !!

IF THE ORIGINAL DATA source is encoded '0183'.. Then it can be sent over whatever transport method you have (serial/WiFi) without alteration.

IF THE ORIGINAL DATA source is 'N2000' (CANBUS) then it MUST to be converted/encapsulated before it can be sent: These "RAW" protocols all have benefits and disadvantages.. but PLEASE just choose one and do not suggest converting between them!.

The issue is that at some point in the pipeline all the NMEA2000 data, regardless of how transported (over IP in any format, SocketCAN, Actisense serial or whatever else) must converge and produce the same data structure, so call it conversion or something else, it must happen.

Later yet, another level of complexity is added when the information must be merged with other datasources (NMEA0183, Signal K) and evaluated based on the user's preference as the information from various sources obviously may and does overlap.

And then another complex task arises where the data available has to be transmitted over output connections, which are possibly physically unable to transfer the amount of data available and require filtering.

[stevead]

Basically yes, except that instead of resending the packet payload over IP again in a different format it will be inserted into the pipeline using the API.

I shall look forward to seeing the speciification of the API and its parameters. Remember that API's last forever.....

[nohal]

APIs have versions as everything else. But of course even the first version is somewhat better when reviewed by knowledgeable people while being designed rather than commented as braindead crap after being released.

[Tehani]

Frustrated watching so much confusion.

a) A virtual port has nothing to do with NMEA0183. They are diametrically different things: One corresponds to the physical layer and the other to a data format.
b) Any data packet (ASCII or binary) can be transmitted through any physical media: USB virtual port, WiFi or Ethernet, among many others.
c) The structure of NMEA2000 messages is not standard in all PGNs. Therefore, the receiver must recognize the PGN number to know if it corresponds to a single message or a fastpacket.
d) Any N2k gateway that processes and assembles fastpackets will impose limitations, since none recognizes all possible PGNs. If we talk about proprietary PGN, even less so.

For all this, I think that talking about $PCDIN, javascript and things like that is like talking about the sex of angels, as we say around here. They are NOT applicable to resolve these issues. I say that ideally the gateway does nothing more than transport simple CAN packets to and from any other physical media available on a PC or Raspberry (USB, WiFi and Ethetnet), and then the API does the work of filtering and assembly of the PGN's that interest.

[rgleason]

I wonder if this could be considered "OneNet" wifi?

[Tehani]

Originally Posted by rgleason

I wonder if this could be considered "OneNet" wifi?

Hello Rick,
OneNet aims to unify numerical data (depht, wind, heading, navigation, etc.) with images and video (radar, sonar and surveillance cameras, for example) in a single network. All through the same Ethernet cable or WiFi equivalent under IPv6.
This may seem like progress, but personally I do not agree, since a failure in a network of these characteristics can endanger the integrity of very sensitive data.
For this same reason, a long time ago, some manufacturers were reluctant to integrate the data exchanged by the pilot, compass and keypad with the rest of the information through the same network.

I believe that this OneNet concept will be an equivalent to SignalK, where the communication between the navigation players will continue to be NMEA2000, and will only be used to link them with an "external world", logically blocking certain sensitive data and commands.

[bdbcat]

Hello all...

Thanks for the robust discussion about the various N2K encoding options available.
It is now time to winnow this down a bit.

To refresh, here is the OCPN N2K device support today, in OpenCPN v5.8.4. The "encoding format" description refers to data on the USB wire, as received by OCPN drivers.
1. Canbus, bi-directional, hardware interface to PC is variable, Raw CAN format.
2. Actisense NGT-1, bi-directional, USB interface, Actisense encoding format.
3. YDNU-02, bi-directional, USB interface, near-Actisense compatible encoding format.

All of these devices connect directly to the N2K bus.

Where are we going next?
There are currently on market a number of devices that connect to N2K physical network on one side, and ethernet on the other side. They may be hardwired to ethernet, or use WiFi as tranport medium. Wifi devices typically establish themselves as Wifi AP's, and the PC connects as a client.

We would like to support one or more of these devices.
We have at least two pathways in which to proceed:

First premise: We are talking only about N2K data. Most of the devices available also offer some sort of conversion to/from N2K<->NMEA0183. To the extent that a user configures this gateway conversion, our existing NMEA0183 network protocol handlers will interface as required.

Choices:
1. Choose one or more devices, and support whatever method of encoding N2K data onto ethernet that the devices employ by default, or configurable by device's web page interface.
a. For example, the YDEN-02, or YDWG-02. For N2K interfacing, these devices use the Yacht Devices ASCII Raw protocol.

 00:34:02.718 R 15FD0800 FF 00 01 CA 6F FF FF FF

b. Actisense (Model?)...unknown RAW data format.

2. Alternatively, we may chose one or more protocols, thus gaining compatibility with devices from several vendors that support, or can be configured to support, our selected protocols.
Here we are discussing only what comes in to OCPN, or is transmitted by OCPN, over the configured network port.

Reasonable choices to consider might be:
a. Yacht Devices ASCII raw.
b. N0183 wrapping of ASCII PGN encoding.
c. Actisense RAW?

My instinct is that the more robust long term solution is #2. Specific hardware devices come and go. On the other hand, the implementation details for #2 may be more complex, with many edge cases to consider.

Note that in above discussion, there is no mention of OCPN internal data structures. But it should be understood that such structures will be exposed as necessary in order to support N2K transmit functions by plugin API, as is done today by the various autopilot plugins, as well as Tony's javascript plugin.


Finally, lets discuss how a user might interface with all this.
1. Somehow, the user must have pre-knowledge of the ip address/port of the device, both in the wired or Wifi scenarios.
2. Using OCPN connections dialog, user makes a network connection to the device. Might be TCP, or UDP, depending on the configuration of the device.
3. User selects Protocol->NMEA2000

And that should be it.
The OCPN drivers hopefully can grok the data streaming in, in whatever format it is, and just "do the right thing". If there is ambiguity, we may possibly need to implement a "sub-Protocol" selection option presented to the user. User may need to try/error to find the one that works.

I note again: If the user selects Protocol->NMEA0183, then the device is assumed to be acting as a N2K->NMEA0183 gateway. NMEA0183 decoding is used.

Stopping here.
Thoughts?

Dave

[Scubacat]

Dave, Thanks.

Can I comment a little about the YD format. This is indeed "Open", but is limited to non fastpacket PGN. Other ASCII based encoding formats can and do accomodate PGN with more than 8 data fields, and may offer a more universal solution for OpenCPN.



$PCDIN / Chectco / SeaSmart format:
See (http://www.seasmart.net/pdf/SeaSmart...evG_043012.pdf)

Short message example: $PCDIN,01F802,00075BFA,7F,00FCFFFF0000FFFF*2E
Long message example : $PCDIN,01FA04,00076634,7F,00FF0B053919718CF8110000 0000F20D7F344439B80B00000000F20E0B20A22BAC0D000000 00F20FF32A87CCC40900000000F211DC084448F00A00000000 F21268039FC1C40900000000F2147405147C3C0F00000000F2 16E728673F600900000000F217A20DCDD8B00400000000F218 2E17ABB4A00F00000000F21E0B115C2E540B00000000F2*2B

YD format message.
Defined in Appendix E of this document https://www.yachtd.com/downloads/ydnr02.pdf

Message example: 00:01:03.565 R 19F11320 00 A6 BC 00 00 00 FF FF

Actisense ASCII format Is simple to understand and decode, (but I have no reference to the specification, and it may be proprietary?).
also, there may be some confusion over names for this (these?) format(s?).. I am not certain, but I believe I have also seen it referred to as ASCII N2K. Actisence themselves talk about "ASCII RAW; Actisense RAW; ASCII N2K; Actisense N2K; and Actisense NGT".

Short message example: 44850 : Pri:6 PGN127251 Source:33 Dest:255 Len:8 Data:0,79,56,FD,FF,0,FF,FF
Long message example: 44963 : Pri:6 PGN129029 Source:33 Dest:255 Len:43 Data:0,1A,4D,10,2D,87,13,0,16,AD,91,71,D7,56,6,AC, F8,7C,A1,4E,26,6B,0,10,28,A7,34,0,0,0,0,10,FC,0,5A ,0,96,0,10,13,0,0,0

I would personally suggest using the SeaSmart format, as it is "more" NMEA0183 like, and so existing NMEA0183 decoder structures and transport methods should be able to accomodate decoding this from the datastream. The SeaSmart format sends all as two bytes but without a delimiter potentially making smaller messages than when the "," delimiter is used. But this depends on how many fields can be sent as single bytes. Once you have the PGN and its data inside the application, you will then - of course- need a further NMEA2000 decoder to actually get any usable data for OpenCPN to work with.

[nohal]

Being almost NMEA0183 (It violates the standard which limits the maximum message length) is not an advantage, it actually is the biggest disadvantage of the SeaSmart format. And using the NMEA0183 pipeline to process NMEA2000 would be a huge mistake that would keep kicking back at us forever.