Software Design

RV-C software can be extremely simple. Most products need only support a handful of messages and can ignore everything else. A few features, however, are mandatory.

One mandatory feature is the addressing procedure. As noted above, every node on the network must use a Source Address to identify all the messages it sends. Nodes may use either “static addressing”, in which case the Source Address is preset and never changes, or “dynamic addressing”, where the address is determined when the node is powered on and it may change as other nodes are added.

Static addressing is very simple – the node simply uses the Default Source Address defined for that product type. It “claims” this address when it starts up, and when another node attempts to claim the same address it responds with a message that informs the other node that it can't change. (It has 250 ms to respond). It's extremely easy to implement, but suffers from one obvious drawback – you can't put two of them on the same network. Perhaps not a problem for a generator, but unforgivable for a control panel.

A node with dynamic addressing starts by claiming an address from a recommended range. If a static node is already there, the dynamic node tries the next lower address. If another dynamic node is using the address a tie-breaking procedure is used, and the loser moves on.

Nodes that implement dynamic addressing also must implement some sort of unique identifier, an embedded serial number that serves as part of the tie-breaker. Dynamic addressing does not require a lot of code – fewer than 100 lines of “C” code can encapsulate the entire process.

Because some nodes may be dynamically addressed, nodes can't assume that another node's Source Address will always stay the same. The Source Address alone does not identify a node – in fact, RV-C has no provision for completely identifying a node and its capabilities. Although this may seem to be an oversight, it isn't. Each packet of data is defined without reference to the source address. When parsing a message the receiving node can ignore the source address – the only exception being for proprietary messages. There is little reason to keep track of the addresses of other nodes.

The source-independence of the messages also means that most data will have just a single source. There is no “battery voltage” PGN, but there are PGNs for chargers, isolators, and other devices that include a battery voltage. Thus a node looking for the current battery voltage must ask for “voltage at the charger” or “voltage at the isolator”. There is an implicit assumption that there is only one battery isolator. In the case of the charger (and many other products) there are specific provisions for identifying multiple units.

The other features that are mandatory for all nodes are the Diagnostic PGN, the Product Identification PGN, and the response to a PGN Request. Any node can query any other node or all nodes on the network for specific information. If a node is specifically asked for a datum, it must respond either with the data, or with a certain negative response.

If a node embeds the functions of more than one product, such as an inverter/charger combination, a generator that includes a genstart module, or a furnace that integrates a thermostat, the programming hardly changes. The node uses a single Source Address for all messages. The only distinction comes with the Diagnostic Message – the node will send one message for each product that it embeds. Each product is distinguished by a different Default Source Address, which is included in the diagnostic packet.