© RVIA RV-C 18
n+4 - DSA extension uint8 - FFh — No DSA extension defined for product
3.2.6 Proprietary messages
RV-C supports proprietary messages. The proprietary message is defined in Table 3.2.6.
Table 3.2.6: Proprietary message
Attribute Value definition
DGN EF00h
DGN-High EFh
DGN-Low Destination address, global messages (FFh) are not allowed
Priority 6, RV-C node may increase priority if appropriate.
Broadcast rate As needed
Data 0 to 7 Manufacturer-specific
There are two main applications for this DGN: for advanced configuration (usually via a service tool), and for adding features to
the protocol without publishing. Both should be handled with care. It is particularly important that the RV-C nodes involved
properly identify each other and use the destination address properly to prevent other RV-C nodes from trying to parse their
messages. (Consider that your message to calibrate a sensor may also be another manufacturer's message to run a slide room
in).
NOTE 1 There is a complete lack of controls on this DGN. There is nothing in the protocol to protect RV-C nodes from
incompatible messages. Therefore this DGN should be used very sparingly and carefully.
NOTE 2 A safe technique for using this method for advanced configuration is to begin any sequence with a
"password" from the configuration tool. The RV-C node should ignore all proprietary messages until it receives the desired
password. The password should "expire" eventually, so the when the configuration process ends the RV-C node stops parsing.
Although it is possible to use this message to implement functionality without publishing the method, this technique is to be used
only when the desired function is not supported in the published protocol.
3.2.7 Multi packet message
Data groups longer than eight bytes shall be sent using the multi-packet message protocol, which allows messages up to 1785
bytes. Each 'long message' is identified with a particular DGN, but the DGN definition is no longer limited to 8 data bytes. The
method uses an initial packet to set up the transfer, followed by up to 255 data packets.
This technique has several severe limitations. There are no provisions for flow control. The receiving nodes do not communicate
their readiness to receive data. The transmitter has no assurance that the data is being processed. There is no method for a
receiver to request a specific packet. If the entire DGN is not received correctly the receiving node shall request the entire DGN
again. A node shall only transmit one long message at a time, since data packets are not specifically identified in any way other
than the packet number. And long messages are relatively slow, because of the 50 ms gap between data packets. Therefore long
messages shall not be used for control and instrumentation purposes.
Long messages are implicitly required for the PRODUCT_ID, and are optionally used for the DM_RV DGN when multiple faults
are active. They are used rarely in the Application profile; generally for configuration purposes where substantial tables have to
be downloaded or uploaded.
3.2.7.1 Initial packet message
Table 3.2.7.1a defines the DG definition and Table 3.2.7.1b defines the signal and parameter definition for the initial packet
message.
Table 3.2.7.1a - DG definition
December 17, 2015 3.2.7.1 - Initial packet message