NMEA 2000 over WiFi ?

[stevead]

( PS I was unaware of the ‘chetco’ link, and perhaps someone can educate me please!)

Here's the link:
http://www.seasmart.net/pdf/SeaSmart...evG_043012.pdf

[stevead]

I meant to add my pennies worth.

According to the Actisense W2K-1 (NMEA 2000 to WiFi gateway) user manual, not all of the conversion protocols support send & receive to the CAN bus.

Given that the current version of OpenCPN sends some of the "housekeeping" PGN's onto the network (126996 Product Information etc.), that some existing plugins (such as Douwe's Raymarine Autopilot) control autopilots by sending the appropriate proprietary PGN's onto the network, and in the future other plugins or OpenCPN itself may support autopilot control, then the selection of NMEA 2000 over TCP/IP protocols (either WiFi or Ethernet) needs to ensure it is one that is supported for both send & receive by the gateway device.

I don't think this is a decision that can be taken lightly. All of the gateway vendors seem to be receptive to discussing this perplexing decision. Probably too late now, but it would have been a great opportunity to have met with them all last November at Metstrade in Amsterdam, possibly in a side meeting to the normally scheduled NMEA sessions.

[Tehani]

Originally Posted by stevead

I meant to add my pennies worth.

According to the Actisense W2K-1 (NMEA 2000 to WiFi gateway) user manual, not all of the conversion protocols support send & receive to the CAN bus.

Given that the current version of OpenCPN sends some of the "housekeeping" PGN's onto the network (126996 Product Information etc.), that some existing plugins (such as Douwe's Raymarine Autopilot) control autopilots by sending the appropriate proprietary PGN's onto the network, and in the future other plugins or OpenCPN itself may support autopilot control, then the selection of NMEA 2000 over TCP/IP protocols (either WiFi or Ethernet) needs to ensure it is one that is supported for both send & receive by the gateway device.

I don't think this is a decision that can be taken lightly. All of the gateway vendors seem to be receptive to discussing this perplexing decision. Probably too late now, but it would have been a great opportunity to have met with them all last November at Metstrade in Amsterdam, possibly in a side meeting to the normally scheduled NMEA sessions.

Hello Steve,
Actisense will likely establish filtering to prevent an incorrect or untimely PGN from disrupting the network. (The timings for responses to "Iso Address Claim", and silences for other PGNs of the same ECU are quite strict).

On the other hand, it is impossible to execute the assembly and generation of proprietary fastpackets because the first frame of an N2k message does not contain information whether it is a fastpacket or a single frame. Therefore, any processing software must have a list of PGN numbers that are fastpackets.
In Ocpn this is located in "model / src / comm_drv_n2k_socketcan.cpp / CanHeader::IsFastMessage(), and if someone wants to use that library, they will have to modify that file including the new PGNs they want to process.

It also happens that some proprietary PGN fastpackets contain only 8 bytes of data. Curious, isn't it?

[Tehani]

PS: I'm reading the SeaSmart manual, and they justify limiting processed PGNs due to the overhead that would occur if they were all converted to ASCII messages with $PCDIN headers, separators, and checksums. Furthermore, I see that these NMEA0183 messages already contain the complete fastpackets, and therefore the limitation is twofold: no new ones can be added, and they also have the length limit of NMEA0183 messages, which is 82 bytes. For example, a message as normal as 129029 - GNSS position data has a length of 43 bytes of binary data, it would occupy 115 bytes in NMEA0183.

[cas206]

Originally Posted by Tehani

PS: I'm reading the SeaSmart manual, and they justify limiting processed PGNs due to the overhead that would occur if they were all converted to ASCII messages with $PCDIN headers, separators, and checksums. Furthermore, I see that these NMEA0183 messages already contain the complete fastpackets, and therefore the limitation is twofold: no new ones can be added, and they also have the length limit of NMEA0183 messages, which is 82 bytes. For example, a message as normal as 129029 - GNSS position data has a length of 43 bytes of binary data, it would occupy 115 bytes in NMEA0183.

I, personally, "felt" that Option 1, using $PCDIN, should be thrown out because using an old standard for a new format seems like a duck tape solution. But I didn't want to give an empty opinion. But here is a technical point against Option 1). So I'm stating it.


I have a Yacht Devices YDNU-02 which outputs "In N2K mode, messages are encoded in a binary format. This format is based on Data Link Escape encoding partially compatible with ActiSense NGT format". The format is close enough to ActiSense, that I'm able to use the canboat actisense-serial application to dump the data.


It's not clear to me if this is represented as one of the options in stevead's list. But if it is, that's the one I would vote for. However, I just received a PICAN-M for my RPI 4 to connect to my N2K network. So I don't have a strong opinion.

[Antipole]

The JavaScript plugin v3 (forthcoming) can receive and decode or encode and send any pgn for which the Canboat project has a descriptor. This is a much more flexible approach than bloating OCPN with handling off-piste pgns.

Given the wide variety of NMEA0183 encodings of N2K, one approach is to just convert the sentence to the OCPN standard N2K Actisense format.

I have, in a few minutes, knocked up a function to convert $PCDIN to OCPN Actisense format. So, taking the example above, I have run the following script:

pcdin = "$PCDIN,01F802,000C8286,09,3AFC8CCA0500FFFF";

N2k = require("NMEA2000");  // load the N2K object constructor
actisense = pcdinToActisense(pcdin);
myObject = new N2k(actisense.pgn, actisense.data);
print(JSON.stringify(myObject, null, "\t"), "\n");	// pretty print the object as JSON

which outputs

{
	"PGN": 129026,
	"id": "cogSogRapidUpdate",
	"description": "COG & SOG, Rapid Update",
	"priority": 3,
	"desination": 255,
	"origin": 1,
	"sid": 58,
	"cogReference": "True",
	"cog": "5.1852000",
	"sog": "0.0500000"
}

I was not sure how to interpret the 000C8286 of the above and assume it contains priority, source and origin. I have just filled in defaults for this illustration.

It should be possible to do this for the other NMEA0183 encodings of N2K data.

[Scubacat]

Originally Posted by Tehani

PS: I'm reading the SeaSmart manual, and they justify limiting processed PGNs due to the overhead that would occur if they were all converted to ASCII messages with $PCDIN headers, separators, and checksums. Furthermore, I see that these NMEA0183 messages already contain the complete fastpackets, and therefore the limitation is twofold: no new ones can be added, and they also have the length limit of NMEA0183 messages, which is 82 bytes. For example, a message as normal as 129029 - GNSS position data has a length of 43 bytes of binary data, it would occupy 115 bytes in NMEA0183.

That is very interesting.
We have encoded (bidirectional) $PCDIN conversions in the Vela Naviga "N2K0183 multiplexer", but (largely through ignorance!) have not (artificially) limited it to the 83 characters.
I can definitely say that it is possible (and easy) to send very long fastpackets over UDP/TCP as $PCDIN and then reconstruct them on receipt.
I have, for example, reconstructed PGN 129540 (sats in view) that builds a "$PCDIN" that is over 250 characters long. I have also sent AIS messages this way, and they can be nearly as long. GNSS Position data is short in comparison!

I will happily admit that when we first tried sending fastpackets this way we failed, as we had limited the message buffers to 83 characters. But this was (IMHO) an unnecessary limit. I might argue that $PCDIN is not actually a "FORMAL NMEA0183" message to my knowledge, so why should it be limited to 83 characters??
The coding to convert to $PCDIN and back to N2K is straightforward, and gives access to any and all PGN without limitations. - Ideal I would have thought for the transparent data conversion needed to convert from the CanBus layer to something (/anything?) else.

I do concur that transcribing everything to $PCDIN could result in congestion. But data filtering in the multiplexer could sort this if it was a problem.

If anyone wants to "play" try this example $PCDIN...
$PCDIN,01FA04,0031357E,7F,00FF0805510EFCD1FC080000 0000F2067314668ACC1000000000F207B92F4448B80B000000 00F209A21C5C2E340800000000F20B0B20ABA5F81100000000 F20D8B0936AF5C1200000000F214392836CD1C0C00000000F2 1E7F25CF7E301100000000F2*2A

[stevead]

Given the wide variety of NMEA0183 encodings of N2K, one approach is to just convert the sentence to the OCPN standard N2K Actisense format.

For the NMEA 0183 encodings of NMEA 2000 messages ($PCDIN and $MXPGN), I think the Javascript plugin solution has merit.

That's why I suggested it previously, albeit converting to valid NMEA 0183 sentences rather than simply repackaging as a different NMEA 2000 format such as Actisense EBL, ASCII Raw, Actisenste N2K etc.

My reasoning for that suggestion is that the problem is how to "insert" the resulting data into OpenCPN. Unlike NMEA 0183 which has the "PushNMEABuffer" API, I don't think there is an equivalent function for either NMEA 2000 or SignalK.

You could do some funky stuff with virtual comm ports, sending Actisense EBL data but I don't know if the Java script plugin gives you access to a serial port (COMn on Windows, or a tty device on Linux or Mac).

I was not sure how to interpret the 000C8286 of the above and assume it contains priority, source and origin. I have just filled in defaults for this illustration.

"$PCDIN,01F802,000C8286,09,3AFC8CCA0500FFFF"

The 000C8286 is a time stamp. Unfortunately, the Chetco Seasmart protocol only includes the PGN and the source address, it omits the destination and priority, although in the grand scheme of things, most NMEA 2000 messages are broadcast (eg. destination address is the Global Address 255), so no biggie.

I agree with cas206 that OpenCPN natively supporting NMEA 0183 encoding of NMEA 2000 is undesirable, rather one of the formats used by both Actisense & Yacht Devices that supprts send and receive should be supported

[nohal]

Abusing NME0183 for transfer of NMEA2000 data is a bad idea in general and especially as a native way to do it as it will put yet more pressure on the NMEA0183 pipeline which simply should handle something completely different - data at very low (4800) and low (38400) speeds. The fact that it has to violate the standard re message length to even be able to work just confirms that.

Filtering in scenarios like this would become an absolute nightmare, even bigger than it is already by simply being able to receive data at speeds higher than the standard was designed for and the hardware conforming to it supports.

[nohal]

Originally Posted by stevead

My reasoning for that suggestion is that the problem is how to "insert" the resulting data into OpenCPN. Unlike NMEA 0183 which has the "PushNMEABuffer" API, I don't think there is an equivalent function for either NMEA 2000 or SignalK.

You could do some funky stuff with virtual comm ports, sending Actisense EBL data but I don't know if the Java script plugin gives you access to a serial port (COMn on Windows, or a tty device on Linux or Mac).

This is a non-issue, there are APIs for sending NMEA2000 and SignalK is just a specialization of a general JSON message sent through the respective API. If we need more, they simply can be implemented together with the actual functionality we discuss here.

[Tehani]

Steven, look at the comm_drv_n2k_socketcan.cpp API. As Nohal says, that's done.

Summarizing:
- Of course, converting NMEA2000 messages into ASCII messages, whether in NMEA0183 format or not, is not a good solution. Passing through ASCII is inefficient and the resulting messages will be huge.
- If the gateway is in charge of assembling the fastpackets, it will be necessary to tell it which fastpackets will be required by the user, and in the same way, which N2k fastpackets are intended to be sent and received. I don't think that then the O API would be useless.
- The performance of the process has not been discussed at any time. Some PGN are transmitted at 100mS intervals. We have also not talked about throughput, which will be very bad if the connection between O and the gateway is made by USART (RS422, RS232), which is why in many cases a prescaler is established.
- USB 2.0 has a faster speed than N2k, but it has the small drawback of being an isochronous communication with times between packets of 1mS. USB packets can contain a few CAN frames, but I think spacing the frames 1mS apart when transmitting fastpackets can be disastrous. I mean a virtual serial port but without USART, which looks like Comxx, but has no speed limitations.
- The USB connection allows it to be used on both Windows PC and Raspberry Pi. (At the moment I have found problems with iOS).

- In this post I put some links to the hardware designs of an economical multifunction gateway with "Open source" hardware:

https://www.cruisersforum.com/forums...ml#post3587309

- This gateway has already been installed on many ships for almost two years. Therefore, the same hardware can serve as a basis for a prototype of an equivalent to an NGT-01, for example. If it is accepted, it is easy to simplify the PCB and improve it for a specific N2k <-> USB use, with galvanic isolation between them (this is where I have found problems when using inverters to power PCs).

- In this project it is quite simple to change the N2k processing to transfer raw PGNs to and from USB, grouping them without processing fastpackets, and with a timeout of, for example, 10-20 mS to avoid delays. The procedure consists of filling two fifos (circular buffers), one for the N2k -> USB transfer, and another for USB -> N2k, so that the N2k PGN's will accumulate until the buffer is full or until timeout expires, whichever occurs first. This improves isochronous USB transmission performance without significant delays. The speed of the virtual serial port is irrelevant, it will always work at USB 2.0 speed. All this is the good thing about programming in "bare metal".

- With a little tuning, it is possible to reduce the processing load on the Ocpn side if the app sends PGN 126464 "PGN List (Transmit and Receive)" to the gateway during startup. - This list contains all required PGNs, both single and fastpackets.

- Can you tell me if you find it interesting that I do it? I can modify the design and share it because it would also be "Open". A WiFi version can also be made with similar features. (now the development of the gyro/autopilot is ending and it is leaving me a little time...).
I also listen for proposals, of course.

[Antipole]

Originally Posted by stevead

You could do some funky stuff with virtual comm ports, sending Actisense EBL data but I don't know if the Java script plugin gives you access to a serial port (COMn on Windows, or a tty device on Linux or Mac).

JavaScript plugin v3 already has the alternative

OCPNpushNMEA0183(sentence, driverHandle)

which pushes the data to the specified port. I want to implement

OCPNpushData(sentence, driverHandle)

which differs only in omitting the check it is an NMEA0183 string and addition of the checksum.
You need to know the driverHandle for your serial port. Unfortunately, the Options>Connections panel does not show the handles. I have asked that it do so.
Meanwhile, you have to search for the desired port. NMEA2000.push() looks for the port thus:

handles = OCPNgetActiveDriverHandles();
var handlesFound = [];
for (h = 0; h < handles.length; h++){
	attributes = OCPNgetDriverAttributes(handles[h]);
	if (attributes.protocol == "nmea2000") handlesFound.push(handles[h]);
	}
print(handlesFound, "\n");

which on my system reveals the handle as nmea2000!@!/dev/cu.usbserial-1B0D4
I don't have any serial port on my Mac at home so am unable to test this.
Happy to work with someone with the hardware.

[stevead]

I thought that the WriteCommDriverN2K API only allowed a plugin to send a NMEA 2000 message onto the Network. From first hand experience, I know this works.

Are you suggesting that if for example I send PGN 129025 using WriteCommDriverN2K that it not only transmits the message onto the network, but that also OpenCPN decodes it and updates its own position ?

If that is what it is meant to do, that scenario does not appear to work.

Tony's approach "should" work, but it would require some crafty network configuration and the use of virtual ports:

[Antipole]

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

[nohal]

We will certainly not use virtual serial ports or NMEA0183 for this, but natively consume whichever binary protocol we select as "native".