Designing a protocol for an entire industry is a difficult task. The RVIA committee responsible for RV-C's genesis spent two years debating a variety of concepts before the first PGN was ever defined. These concepts grew from the unique demands of the RV industry. Wherever possible the committee shamelessly plagiarized existing protocols, but in a few key areas we struck out on our own to create novel solutions to our unique problems.
This series of short articles explains the key factors that motivated these design decisions. It is intended for engineers that are already familiar with such protocols as SAE J1939 or NMEA 2000. It outlines how RV-C is different from these protocols, and the motivations for the differences.
The overarching principle that drives almost all other design considerations was simple. It has to be cheap. The full benefits of RV-C comes when the network extends to every nook and cranny of the RV, including low-cost items such as water heaters and light switches. RV-C is not intended just for high-end motorhomes, but for RV's of all types and prices.
This principle drove the initial decision to work with CAN as the base protocol. Almost all microprocessor suppliers include products with built-in CAN controllers, making CAN the cheapest protocol to implement at the hardware level. The net additional cost of implementing RV-C in a microprocessor-controlled product can be as little as a dollar.
Cost was also the driving factor in another key decision. Whereas many other CAN protocols require shielding, the RV-C committee was skeptical of the benefits of shielding in light of the costs. Shielding requires more expensive cable, and connectors have to be attached by hand in most cases. Thus it drives up the cost of wiring considerably. The committee was reluctant to require this expensive step.
The debate included both theoretical considerations and lab testing. The conclusions obtained were that while shielding theoretically can reduce interference, in practice it usually has little or no benefit. And in some situations it can actually create or exacerbate problems. The committee unanimously agreed that shielding would not be required by the protocol. RV-C does not prohibit the use of shielded cable, but it is neither required nor recommended.
Not surprisingly, the trend among other industry groups has been in this same direction.
A novel concept in RV-C is deceptively simple. Every data packet contains all the information needed to interpret its contents. A device never needs to look at any other data packet to decide how to parse the message.
There are a few exceptions, all of which are directed towards service tools and configuration or troubleshooting, rather than normal operation.
The motivation is simple. This concept means that microprocessors never have to keep large buffers or tables of information on other devices in order to function. This allows RV-C to be implemented on microprocessors with very little memory. This makes it possible to create extremely low-cost circuits that are fully RV-C compliant.
It also hugely simplifies the programmer's task. The parsing routines for an RV-C device are extremely simple to program - many products require just a couple of pages of straightforward code. This simplicity reduces development time dramatically, and makes for robust products.
One of the fundamental issues RV-C had to address is the plethora of devices in an RV that have multiple installations. An RV may have seven or more awnings, four climate control zones, two or more inverters, and dozens of lights, keypads, and the ilk. This factor had to be addressed in a simple, direct manner. The means the committee devised is called "Instancing".
Devices in RV-C are defined as either single-instance or multiple-instance. Frankly, there are very few of the former items - generator and chassis being the most obvious. Data packets for these devices have no special provisions for identifying the source or target of the packet. But data packets involving multiple-instance devices always have as the first data byte the "Instance" for the source or target device.
The Instance is completely distinct from the Source Address - in fact, the SA is irrelevant to parsing the data packet. The Instance is always a single data byte, usually with a value from 1 to 250. (Some devices have limitations on the range of values, and some devices have more complicated schemes.) In most cases the value is arbitrary, though for some devices RV-C assigns a specific meaning to certain numbers. In almost all cases, zero is not a valid Instance.
For example, for an Awning Instance 1 is defined as the Main Patio Awning. A large RV may have several smaller awnings assigned Instances 2 and higher. Any command to the patio awning would have a first data byte of 1, and any status information about that awning would also have the same first data byte. The same would be true for the other awnings, with the appropriate Instance put in the first data byte.
RV-C does not specify how the Instance is assigned to a device. A general PGN is provided, but manufacturers may also use dip switches, jumpers, or even hard-coding to establish which physical device is assigned each Instance.
The Instances always refer to the physical device, rather than the microprocessor node. A single microprocessor might handle several device Instances. For example, a wall thermostat may handle several climate control zones. The microprocessor in that thermostat would send and parse messages for each climate control zone Instance independently.
The use of Instances forces RV-C to use a unique scheme for diagnostic messages. This is one of the few ways RV-C differs materially from SAE J1939.
Whereas the "Instance" concept allows multiple nodes on the network to have the same function, another challenge for any protocol is dealing with multiple functions being served by the same node. A simple example is the "inverter/charger", which obviously serves two different functions. But there are far more complex examples, and there are nodes on the market today that serve over a dozen different functions.
RV-C's mechanism for dealing with the identification of a node's function is the Default Source Address, or DSA. Ironically, the least important role of the DSA is determining the node's source address. Whereas some nodes are statically addressed and thus will use the DSA as its source address, there is no particular meaning attached to the source address. In fact, with the exception of proprietary messages and a few related messages, the source address is ignored. The key purpose of the source address is in bus arbitration, not in identifying the node itself.
That's the DSA's role. The DSA is transmitted in DM1-RVC messages, which serve both as a diagnostic warning and an indicator of the general node condition. A device that has multiple functions reports a separate DM1-RVC for each function. Any other device or service tool can simply watch the DM1-RVC messages being broadcast to obtain a "census" of the devices on the network.
If the device has a fault condition, the DSA also helps identify the code within the DM1-RVC. The SPN within the DM1-RVC indicates the "suspect parameter" for the fault. To interpret the SPN requires the DSA. For example, the SPN 260 may mean something completely different if the DSA is 64 (Generator) or 129 (Waste Dump).
To summarize, every device shall send a different DM1-RVC for each function that the device performs. The DM1-RVC is sent at least every five seconds - more often if a fault condition exists. If a device contains multiple instances of a single type - e.g. a tank monitor likely supports three tank instances - only one DM1-RVC is sent unless a fault exists.
With this scheme it is easy to determine the full range of products on the network and obtain general operating information on all of them.
Good programmers know the value of "reusable" code. The RV-C protocol also re-uses ideas whenever possible. This is obvious in the way the committee used very few distinct data scales. By being ruthlessly consistent in the way amps, volts, and degrees are scaled, not only did the committee make the programmer's job easier, but they greatly reduced the chances for error.
But the best example of the committee's dedication to code economy is the AC Point. This is a collection of several different PGNs, all with exactly the same format. There are four distinct AC Point formats, and two AC Fault formats, which are applied identically to AC devices including generators, inverters, chargers, and transfer switches. GENERATOR_AC_STATUS_1 thus has exactly the same format as ATS_AC_STATUS_1, with only the PGN number itself and the Instance byte being different.
Obviously this greatly simplifies the job of writing the code to parse this data, and reduces the chances of a documentation or coding error. But there are a few tricky points. Some devices are purely 120VAC - and report a single "leg" or "line". But some devices handle power that may be 120VAC or 240VAC "split-phase". Shore power, in particular, may be 30A or 50A. In the former case, whereas the power may be distributed to two physical lines, the lines are in the same phase and the total capacity is 30A. In the latter case, the two lines are 180 degrees out of phase, and each separate line has a capacity of 50A (for a total of 100A).
RV-C identifies the phase relationship using the "Complementary Leg" and "Phase Status" fields. In a split-phase scenario, the first field identifies the Instance of the other leg (it must be of the same device type, of course). The Phase Status confirms whether the two legs are in single- or split-phase.
RV-C does not have any general mechanism for associating outputs from one device to inputs for another. "Leg 1" from the generator may or may not be "Leg 1" at the transfer switch - it would likely depend on the installation.
It might be asked, if the AC Point was such a good idea, why isn't there a DC Point. DC is substantially different from AC in one key regard. An AC line always has one specific source. A DC line may have multiple sources. For example, the same DC bus may be fed by a set of batteries, solar panels, a charger, and an alternator, all at the same time. Characterizing DC power is substantially different than AC power, and thus is served by a very different scheme under RV-C.
Watch This Space.
Watch This Space.
Watch This Space.