Addition to Conformance Requirements.
Martin Perlot, as RV-C Administrator, proposes the following addition:
---------
Section 4.3 - General Requirements
The following is a list of general requirements. These are specified elsewhere in the protocol and are repeated here for clarity. This is not an exhaustive list of conformance requirements.
- All messages have eight bytes of data.
Even if a DGN only defines the meaning of seven or fewer bytes, all eight bytes are transmitted, with the undefined bytes filled with 0xFF values. The extra data bytes may be defined in future versions of the protocol, and this practice avoids ambiguity.
- All unused bits are filled with 1 values.
An examination of Table ## shows that, regardless of the type and length of the data field being transmitted, a maximum value (i.e. all bits set to 1) explicitly means that the data item is unavailable and the value should not be parsed. Therefore, filling in unused fields with maximum values (e.g. FFh for a eight-bit field, 11b for a two-bit field) is always safe, and devices shall ignore those fields when parsing the message. In contrast, filling in unused fields with zeroes is rarely safe - zero values usually have specific meanings, and other devices will parse them accordingly.
- Send DMRV's even when nothing is wrong.
The DMRV has several purposes. It serves as a heartbeat to show that the device exists on the network. It gives a rough idea of the type of device, which is often critical for the correct operation of other devices. And it gives an indication of the device's operating status. Therefore, broadcasting the DMRV on schedule is critical. If no faults are active, fill in the SPN and FMI fields with 7FFFFh and 1Fh values, respectively.
- Send DMRVs for every different function.
It is not unusual for a node to have multiple functions - e.g. Generator and AutoGenStart, or Furnace and Thermostat. If so, send a DMRV for each device function. This is essential for diagnostics and in some case, product interoperability.
- Encode values in Little-Endian format.
Be aware whether your microprocessor and its toolchain process 16-bit and 32-bit values in "Big-Endian" or "Little-Endian" form. RV-C uses Little-Endian encoding exclusively, and if your environment is Big-Endian you may need some extra code to convert multi-byte values accordingly.
- Maintain a gap between messages.
It is often the case that a device has a significant number of messages transmitted on the same schedule or in response to the same DGN request - for example, a transfer switch has multiple legs to report upon every 500ms, each requires several messages. If all of these messages are sent in immediate order, with no gap between, other devices may see their CAN buffers overflow and messages get dropped. The general rule is that a device should maintain a 50ms gap between messages. It is acceptable to reduce this gap if the number of messages a device is required to send in a particular interval requires it, but the gap should not be reduced any further than necessary. It is also acceptable to temporarily reduce the gap in a service context, such as a firmware download or diagnostic test.
------
Justification: Simply enough, this is the "Rogues Gallery" of common mistakes that I see in new products. Including this explicitly in the document should save everyone a fair bit of time.