Selecting RV-C Components
Although RV-C allows products from any vendor to be inter-operable, an RV-C network is not “plug-and-play”. The RV manufacturer has to take certain steps in the design process to ensure that all the components in the network properly work together. In the manufacturing process, the builder may also need to do some special configuration as well.
RV-C defines a standard way for products to talk, but it doesn't guarantee that every product says what needs to be said! For example, it defines a way for the generator to broadcast the amperage that it is generating, but it does not mandate that the generator broadcast that information. After all, the generator may not have any means of measuring that amperage. If another component is depending on that piece of information, it may not function properly.
Thus every component vendor is encouraged to provide as part of their product documentation an “RV-C Application Guide”. The guide documents the information that the product generates, the data it requires from other nodes, and other key facts that might affect how it works with other products. This guide may be just a single page, or it may be a small book, but it is crucial to the design process.
An Application Guide will refer to “PGNs”, or Parameter Group Numbers. A PGN is simply a list of related data items appropriate to the product. A product may have several PGNs associated with it. The PGN structure is determined by the RV-C specification, but the component does not generally have to support every PGN defined for the product, or every data item in a PGN. So although the RV-C specification may define four PGNs and forty data items for, say, a generator, it is quite possible for a particular generator to support just one data item from one PGN.
The designer's first job is to collect the Application Guides for every component intended for the network. For every datum required by a component, the designer must verify that another node is supplying it. The designer must also consider when the datum is needed – different components may have different power sources. For example, if the slide room electronics are only powered up when the ignition key is on, and another component needs the slide room status, there may be a problem.
The designer must also look for pitfalls such as having two sources of the same information. In such cases the designer has to determine which source is the most relevant, and perhaps adjust the configuration of various components to use the proper source. It is possible that two components may be completely incompatible, although this would be a sign of poor design by one or both vendors.
The designer must also look out for problems with multiple items controlling a single device. For example, suppose a radiant tile heat system is installed that can be turned on and off by the main thermostat, or manually by a multifunction touchpad. The problem comes when, say, the manual switch turns it off – and then the thermostat turns it back on! There are several ways of dealing with this type of problem, but it is the designer's responsibility to ensure that some solution is implemented. For major components such as the generator these methods are an explicit part of the RV-C definition.
One final pitfall is easily detected. Every item on an RV-C network has to have a “Source Address” - an assigned number from 0 to 255. Some products may support “dynamic addressing” - that is, they find an unused address when they first power up. But some products use “static addressing” - their address is “hard coded” into their firmware. No two products with the same static address can be installed on the same network. Addresses are assigned by the product type, so this should be a very rare problem.