RV-C Lithium Battery Integration: A Guide for RV Builders and Upfitters

Most new motorhomes and many towables now run a multiplex system: a touch panel or app that shows tank levels, controls lights and slides, and reports the house battery. In North America that system usually talks RV-C. If you are sourcing a private-label lithium battery for an RV build, the question is no longer only capacity and size, but also whether your panel can read the battery and how a bank of several batteries appears on the network. This guide explains the parts of RV-C that matter for batteries and what to ask a battery supplier.

Third-party products named below are typical market examples, not LJY products. RV-C support on an LJY-supplied battery is arranged per project with the manufacturer and has to be verified on your own panel.

Short answer

• RV-C is the CAN-based network standard for RVs, developed and published by the RV Industry Association (RVIA).
• Bank-level battery data travels in the DC_SOURCE_STATUS messages; most panels read the house bank from there.
• Per-battery data for smart lithium batteries was added as BATTERY_STATUS_1 to BATTERY_STATUS_11, plus BATTERY_COMMAND.
• Your options: a battery with native RV-C, a battery plus a gateway, or an OEM multiplex platform that handles both.

Why RV builders care

A multiplex system replaces many separate switch and gauge wires with one data bus. That only pays off if every major device, including the battery, reports on that bus. With RV-C battery data, the panel can show state of charge and alarms, an automatic generator start function can react to battery state, and charging sources can be coordinated. Without it, you are back to a separate battery monitor and a second display.

RV-C basics

The RV-C specification is published by RVIA. Its scope section describes RV-C as “a CAN-based communication network for recreation vehicles”. A few rules from the full layer document that affect battery integration:

• Bitrate: all transmitters run at 250 kbit/s.
• Frames: CAN extended frame format with 8 data bytes. Each message is identified by a 17-bit Data Group Number (DGN).
• Termination: both ends of the trunk are terminated with a 120 Ω resistor, and those are the only terminators on the bus.
• Instances: devices that can appear more than once carry an Instance as the first data byte, separate from the node’s source address. This is how two battery banks or several batteries are told apart.
• J1939 roots: RV-C keeps a measure of compatibility with SAE J1939, and Victron describes it as built upon SAE J1939. If you also build equipment on J1939 or CANopen, see our BMS CAN protocol guide.

RVIA’s specification page shows a last update of 20 February 2026 and links the full layer document; the copy we reviewed was dated 31 July 2025. Always design to the current RVIA document.

Battery messages: DC source vs per-battery DGNs

DGN name (from RVIA documents)	What it is used for
DC_SOURCE_STATUS_1, DC_SOURCE_STATUS_2 and further DC_SOURCE messages	Status of a DC source or battery bank, such as the house or chassis bank. In Victron’s implementation, DC_SOURCE_STATUS_1 carries voltage and current and DC_SOURCE_STATUS_2 carries temperature, SOC and time remaining.
BATTERY_STATUS_1 to BATTERY_STATUS_11	Per-battery status for smart batteries, added so each battery can be monitored while the DC source status still reports the bank
BATTERY_COMMAND	Commands to a battery, for example to request a snapshot of cell status

We list names only. Byte layouts, scaling and update rates are in the RVIA document; take them from there, not from summaries.

Multi-battery banks: who reports the bank?

When several lithium batteries form one house bank, someone has to report the bank total. RVIA’s 2019 submission for the battery DGNs notes that most devices look to DC_SOURCE_STATUS for the aggregate of the house (or chassis) battery system, while the new BATTERY_STATUS messages report each battery. Victron’s manual adds a practical rule: according to the RV-C specification, only one node may broadcast DC source messages for the same instance, and each device type has a priority that decides which one does. In Victron’s example, a battery monitor outranks the inverter/charger, solar charger and AC charger for instance 1.

So decide early whether the bank total comes from a master BMS, a battery monitor or a gateway, and make sure only one device reports each DC source instance.

Typical architectures in the market

Option (typical market examples, not LJY products)	Pros	Cons
Battery with native RV-C, e.g. Lithionics, which uses CAN RV-C for data and integration with inverters and chargers	Battery data appears directly on the RV-C panel; the BMS can control charging values in real time with compatible equipment	Ties you to batteries whose RV-C implementation has been proven on your panel
Battery plus gateway, e.g. a Victron GX device with the RV-C profile (Venus OS v2.90 and later)	Victron devices and supported batteries can be read and controlled from an RV-C panel	A VE.Can port runs either VE.Can or RV-C, not both; some GX models have only one fully functional VE.Can port. Victron lists Lithionics and Battle Born as the supported RV-C batteries.
OEM multiplex platform, e.g. Firefly Integrations’ Spark, built on RV-C	One supplier for panel, app and wiring; one data bus replaces many copper runs	The platform decides which battery messages it reads

Spec checklist for your battery supplier

1. Your platform: name the multiplex panel or GX device and its firmware version.
2. Messages: which DC_SOURCE_STATUS and BATTERY_STATUS DGNs the battery must send, and which instance numbers.
3. Bank reporting: which device reports the bank total, and how multiple batteries are instanced.
4. Charge control: whether the BMS must send charge limits to inverter/chargers and solar controllers.
5. Wiring: connector, drop length and where the bus terminators sit.
6. Proof: the battery’s RV-C message list and a CAN log captured on your own panel before the pilot build.

For the electrical side of the house system (bank sizing, charging sources and protection), see our RV converter LiFePO4 charging guide, the RV lithium battery system design guide and the RV battery solutions page. Private-label terms are on the 12.8V RV and marine private-label program, and customisation on our OEM/ODM page.

FAQ

What is RV-C?

A CAN-based communication network standard for recreation vehicles, developed and published by the RV Industry Association. It runs at 250 kbit/s and defines messages (DGNs) for RV devices, including batteries and DC sources.

Do I need RV-C batteries if I have a Victron system?

Not necessarily. A Victron GX device with the RV-C profile can publish data from Victron battery monitors and BMSs onto the RV-C network. Check what your multiplex panel reads and which batteries Victron supports over RV-C.

Is RV-C the same as J1939?

No. RV-C is based on CAN and keeps a measure of compatibility with SAE J1939, but it uses its own RV-specific DGNs, instances and rules.

How are multiple batteries shown?

Each battery can report through BATTERY_STATUS messages with its own instance, while one device reports the bank through DC_SOURCE_STATUS for that DC source instance.

Can a private-label RV battery have RV-C?

It depends on the BMS. Ask for it to be arranged per project and verify it on your own panel before production.

Sources (checked 30 October 2026)

• RVIA: RV-C specification document (full layer document download)
• RVIA RV-C submission: New DGNs – Battery Status
• Victron Cerbo GX manual: RV-C support
• Victron Cerbo GX manual: appendix (RV-C DGNs)
• Lithionics: RV-C integration with Victron Cerbo GX
• Firefly Integrations: Spark