NMEA 2000 "Fast Packet" protocol and fragment ordering

[e100]

(Originally posted in the network forum)
(Unfortunately the NMEA 2000 spec is hidden behind a pay wall so I don't have a copy.)

My understanding is that the "Fast Packet" protocol is a lightweight alternative to the ISO-TP  (ISO 15765-2) protocol used for transmitting long messages over a CAN bus which has a max payload size of 8 bytes.

Apparently not all CAN controllers have a FIFO mode for Tx. This results in some packets being sent out of order which appears to be a particular problem for a Fast Packet receiver. I could be wrong, but it looks like there is a sequence number field in each packet so in theory you should be able to reorder the fragments. Is this correct and is Fast Packet inherently less robust than ISO-TP?

[andrewi76]

This is a pretty good resource on the format:

https://www.embien.com/automotive-insights/exploring-the-nmea-2000-protocol

TP and BAM messages wrap a longer message in a number of frames, TP requires handshaking (RTS, CTS, N x Data, EOM) and can be addressed to a particular node, on the other hand BAM are broadcast and are sent out as a plain sequence of frames but also require a small inter-fame delay.  NMEA2000 treats some PGN's as single frame and some as multi-frame.  Some messages are variable length (eg PGN 129540 Sats in View) and if there are zero sats the length would fit in a single frame, but it must always be transmitted as a multi-frame message because in NMEA2000 the decision about single or multi frame is based on the PGN, not the actual length of the data.  Unused bytes should probably be padded as non-dominant (0xFF).  Also NMEA2000 multi-frame message do not require any inter-frame delay.

The NMEA2000 spec specifies for each standard PGN if it's a single or multi-frame message.  For proprietary PGN's this can be specified by the vendor.

There shouldn't be any issue with order of transmission as long as the priority is consistent, other higher priority frames could be transmitted in between frames in the multi-frame session, but they can be filtered out and would not change the order of the multi-frame message transmission.

[IDEngineer]

It's funny that the Embien reference suggests that Fast Packet "optimizes the delivery of large data sets by reducing the overhead associated with individual message transactions". Not hardly! It still forces the larger message to be broken down into 8 (really 7) byte messages and consumes 12.5% of CAN's eight data bytes with Fast Packet overhead (sequence and frame numbers). Granted, this eight byte limitation is baked into CAN but still, I wouldn't describe it as optimal or having reduced overhead.

If they wanted it to be more efficient, define new PGN's so the sequence and frame numbers could be embedded in the 29 bit header (e.g. part of the addressing) and all eight bytes could be used for, you know, actual data. That would be immediately 12.5% more efficient than Fast Packet while still conforming to CAN specs.

There is another "fast protocol" scheme I've seen somewhere that temporarily increases the transmission speed to actually burst data on the network. I suspect that hasn't become more popular because not all CAN controllers support it, and not all PHY's can handle the reduced bit times.