# RV-C

RV-C is a communications protocol based on the Controller Area Network bus. The protocol is used in recreation vehicles to allow house and chassis components to communicate. RV-C is used for control, coordination, and diagnostics, in a multi-vendor environment.

## Development History

RV-C was initially developed by the Recreational Vehicle Industry Association. The first formal specification was approved in 2005, and the first RV-C products were marketed at that time. The RVIA has continued to refine and expand the protocol, and in 2008 applied to ISO with the intention of opening the RV-C protocol to the world community.
In 2006 the first RV-C-equipped RVs were sold in America. The leading adopters were Country Coach, Foretravel, Newell Coach, and Western RV. RV-C-compliant components for these RVs were manufactured by Valid Manufacturing Ltd., Automated Engineering Corp, SilverLeaf Electronics, and HWH Corporation.
In 2007, the RVIA hosted a Network Fest at their main industry show. The Fest was an educational event featuring over two dozen RV-C compliant products from 14 exhibitors.

## Protocol Overview

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.

## Relationship to SAE J1939

RV-C draws heavily from the SAE J1939 protocol. The primary differences between J1939 and RV-C are:
* SAE J1939 does not support RV-C's "instancing".
* The main diagnostic message (DM1) has somewhat different formats, due to the need in RV-C for instance identification.
* The SAE J1939 NAME PGN is simplified in RV-C.

## Links

The RVIA web site for RV-C