RV-C is based on Controller Area Network, and operates at a bus speed of 250 kbit/s. Data is contained in packets consisting of a header and eight data bytes. The header contains an 8-bit Source Address and a 17-bit Parameter Group Number, as well as a few additional bits. The total bus capacity is approximately 2500 data packets per second, although in practice bus loads are much lower.
RV-C is peer-to-peer. Each CAN transceiver on the network requires a unique source address, which can be assigned either dynamically or statically. Data packets are prioritized based on their contents, not the device.
The Application Layer details the Parameter Group Numbers, which uniquely identifies how the contents of the data packet are to be interpreted. The primary work of the RV-C committee is the creation of new Parameter Groups as new components are introduced in the RV marketplace.
To be considered RV-C-compliant, a device must support certain PGNs. These are
- Address Claiming. This is mandatory even for statically-addressed devices.
- Diagnostics. The DM1-RVC PGN provides essential information on the device capabilities and status.
- Request for PGN. When asked for specific data, the device must respond.
- Product ID. This is text data essential for a service technician to identify the device.
A key concept in RV-C is the instance. In an RV, multiple "instances" of a device are common. RV-C handles this using a unique method in which an instance number is assigned to each physical unit of a certain type.
An idea that underlies much of RV-C's design is that "every data packet stands alone". That is, with very few exceptions, all the information necessary to interpret a data packet is contained within that packet. This greatly reduces the memory and speed required for a microprocessor to implement the protocol. In general, the committee has been intent on keeping the cost of implementation to a minimum.
Read more about this topic: RV-C
Other articles related to "protocol overview, protocols":
... MGCP packets are unlike those generated by many other protocols ... like you would expect to find in TCP protocols ...