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.
RVs equipped with an RV-C network are likely to feature at least one multi-purpose control panel. This panel – and there may be more than one – will provide the RV owner with a central place to monitor and control all the elements of the system. Thus it may combine the tank level monitor, generator control, inverter panel, and perhaps much more. There may be more than one such panel – perhaps a smaller control in the bedroom, perhaps a combination house and engine monitor in the dash.
Although a simple panel with just a few functions may be available off-the-shelf, the main control panel for almost any RV needs to be customizable. At a bare minimum it must be configurable for the specific components in the network – for example, different generators may support somewhat different features. Ideally it should also be customizable to provide features that are coach-specific.
But there is no single “ideal form” for a control panel. Notepad computers offer a model for a high-end panel – a large color display, perhaps using a touchscreen, with rich graphics. Another concept being pursued by one RV manufacturer is integrating the panel into the ordinary televisions, controlling it with a small joystick. More builders are working with custom-built medium-sized graphic units, typically about 6” to 9” in size. These units are easier to install, and if well designed are simpler to operate.
But some manufacturers will surely opt for even smaller, cheaper units, which can offer the same raw functionality as the most expensive, albeit with less “flash” and a little more effort from the user. And while the main panel needs to have a display with enough flexibility to serve its many functions, there may be one or more special-purpose panels that could be as simple as a set of LEDs. Such simple devices may serve as a tank and power indicator in the service bay, or to control the generator from the bedroom.
Regardless of the type of display, the control panel is crucial to the success of the RV-C implementation. Customers will base their opinion of the entire network on the quality of this single component. Therefore RV designers should pay particular attention to this component, and select a vendor with a quality reputation and known responsiveness.