Custom Lithium Battery BMS and Inverter Communication Integration

A Protocol Selection and System Validation Case Study

Why a “Working Battery” Is Not the Same as an “Integrated Battery”

A custom lithium battery pack can pass every bench test on the supplier’s side and still fail to ship in the customer’s product. The reason is rarely the cells. It is almost always a gap between what the battery’s BMS reports and what the host inverter, motor controller, or medical device expects to read.

We’ve seen this play out often enough that we now treat protocol selection and system validation as the two halves of the same job, not separate workstreams. The protocol you pick determines the message map, timing, and fault registers the BMS has to expose. The validation process determines whether the pack actually behaves the way the message map claims it does, under the real load and fault conditions the host system creates.

This case study walks through a real DNK Power engagement that covered both halves. The customer was a mid-size medical equipment manufacturer developing a portable diagnostic device, with a secondary AGV fleet program in the pipeline. The lessons generalize well to anyone selecting a custom lithium pack that has to talk to a host system they don’t fully control.

The Customer Situation

The team came to us with a fairly common profile. They had a working prototype enclosure, a host controller that already shipped in a previous product generation, and a timeline pressure tied to a regulatory submission window. Their battery supplier for the previous generation was no longer responsive at the engineering level. They needed someone who could:

• Take a 24 V nominal pack spec and translate it into a LiFePO4 or LiPo configuration

• Build a BMS that exposed the right data over a recognized industrial protocol

• Validate that the BMS data and the host controller’s interpretation of that data actually agreed

• Ship a 100% refund-guaranteed production run on a tight lead time

The interesting part was the protocol question. The host controller in the diagnostic device used RS485 Modbus RTU. The AGV motor controller used CAN Bus. The customer wanted to know whether they should standardize on one protocol for both product lines or accept two BMS variants.

This is the kind of decision that, if made wrong, can lock a customer into six months of firmware rework. So we treated it as a scoping question before it became a design question.

Protocol Selection: CAN Bus vs RS485 Modbus for Industrial Battery Integration

There is no universally “best” battery communication protocol. Each option trades off data rate, cable length, device count, ecosystem maturity, and host-side complexity. The right answer depends on what the host controller can consume, what the rest of the system architecture looks like, and what the regulatory or certification pathway requires.

For a quick reference, here is how the two protocols compare in the context of a custom lithium battery BMS:

The key selection criteria we walk customers through:

1. Host controller capability. If the host already has a CAN peripheral and CAN interrupt handling, CAN Bus is usually the path of least resistance. If the host is a low-cost MCU with one UART, RS485 Modbus is often the only practical option. We have shipped packs where the customer later upgraded the host and had to migrate protocol — which is why we always ask about the next-generation architecture, not just the current one.

2. Data volume and update rate. CAN Bus is the right call when you need 10–100 ms update intervals on multiple data points (cell voltages, temperatures, fault bits) across many devices. RS485 Modbus at 115.2 kbps can handle a reasonable set of polled registers, but the round-trip latency adds up when you have 30 cells, 4 temperature sensors, and a fault register. For battery packs with active balancing or high cell counts, CAN is the more comfortable fit.

3. Cable and EMC environment. Medical cart and AGV applications often have long cable runs, motors, and switching power supplies. CAN’s differential signaling with dominant/recursive bit arbitration is more robust in noisy environments. RS485 is also differential and works well, but it is more sensitive to termination mistakes and ground loops over long runs.

4. Standardized battery profile availability. CANopen defines a battery profile under CiA 418 / CiA 419 that covers the state-of-charge, state-of-health, cell voltages, and fault registers most industrial devices need. J1939 has a similar battery message set. RS485 Modbus has no equivalent universal battery profile — every vendor defines their own register map. This is the single biggest reason a “drop-in replacement” mentality is dangerous on the RS485 side.

For the engagement in this case study, the diagnostic device stayed on RS485 Modbus because the host controller’s firmware was already validated and the medical certification cycle could not absorb a controller-level redesign. The AGV motor controller was already CAN-based, so the AGV program adopted CANopen with a CiA 418-style message map. Two BMS variants, one supplier, one design review process.

Custom Design: From Spec Drawing to Functional Sample

Once the protocol decision was made for each product line, the design work moved fast. The 24 V nominal pack spec translated to a 7S LiFePO4 configuration in the 6–8 Ah range for the medical device (where cycle life and thermal stability were the priority) and a 10S LiPo configuration in the 5 Ah range for the AGV (where energy density and high discharge rate were the priority).

DNK Power’s standard turnaround on a scoped custom design is 24 hours for the design package and 3 days for the first functional sample. That’s not a marketing claim — it’s the working rhythm our engineering team has built around a fixed set of design review steps. The steps look like this for a typical custom BMS pack:

• Mechanical fit review against the customer-supplied 2D or 3D drawing. Cell layout, BMS placement, wiring routing, connector orientation, and thermal management paths are all checked against the enclosure constraints. We push back early if the proposed cell layout creates a hot spot or a wiring path that crosses a structural rib.

• Electrical spec alignment. Nominal voltage, capacity, continuous discharge, peak discharge, charge profile, low-voltage cutoff, and high-voltage cutoff. For the medical pack, the customer specified a continuous 3C discharge for an internal pump motor with a 5C peak for 10 seconds. For the AGV, the requirement was 5C continuous with 10C peaks during acceleration.

• BMS configuration and firmware scoping. Protection thresholds, balancing strategy, communication protocol, message map, fault register definition, and any vendor-specific extensions. This is where the protocol decision translates into actual registers and message IDs.

• Documentation scoping. Which safety and transport documents are needed (UN38.3, IEC 62133, MSDS, UL 2054, etc.) and on what timeline they need to arrive relative to the customer’s regulatory submission. For the medical device, IEC 62133 cell-level reports and UN38.3 transport certification were the gating items.

Within 24 hours of receiving the finalized spec, we returned the design package. Within 3 days, the first functional sample was assembled with prototype BMS firmware loaded. The medical device sample was a 7S2P LiFePO4 pack in a flat rectangular enclosure with an M8 discharge connector and a 4-pin JST for the RS485 bus. The AGV sample was a 10S1P LiPo pack with an XT60 discharge connector and a 5-pin JST for the CAN bus.

For teams looking at similar custom pack builds, our custom lithium battery pack design service follows the same scoping, design, and validation workflow we used here.

The Validation Checklist Most Suppliers Skip

This is where the engagement either pays off or falls apart. A battery that powers up and reports a plausible state-of-charge is not the same as a battery that survives integration. The validation steps we run before declaring a sample “ready for customer integration testing” are the ones that most often get skipped in the industry. They are also the ones that catch the real problems.

1. Protocol Conformance Test

We connect the BMS to a reference host simulator (either a real host controller or a USB-to-CAN / USB-to-RS485 adapter running on a test PC) and confirm that every register or message ID we declared in the spec actually exists, returns the expected data type, and updates at the expected rate. This sounds obvious, but we have caught multiple cases where the firmware team marked a register as “reserved” or off-by-one, or where the byte order was wrong (big-endian vs little-endian). The cost of catching this before shipment is minutes. The cost of catching it after the customer has integrated the pack is days of debugging.

2. Fault Injection Test

We deliberately trigger the conditions that should produce a fault response and confirm the fault bits, error codes, and host notification behavior are correct. The minimum fault set we test for any custom pack:

• Cell over-voltage (simulated by setting the threshold lower on a test BMS firmware)

• Pack under-voltage

• Over-current discharge (continuous and peak)

• Short circuit (through a calibrated test rig, never directly)

• Over-temperature (both pack-level and cell-level sensors)

• Communication loss (the host stops polling or the bus is physically disconnected)

For CAN Bus, we also verify the EMCON (emergency) message behavior. For RS485 Modbus, we verify the exception response codes. Neither is standard behavior — both have to be implemented deliberately in the BMS firmware.

3. Cell-Level Voltage and Temperature Accuracy

We compare the BMS-reported cell voltages against a calibrated reference multimeter on every cell, at multiple state-of-charge points (typically 90%, 50%, 20%, 5%). The tolerance is usually ±20 mV per cell. Anything outside that range means either a calibration issue in the BMS or a balancing issue in the pack. Pack temperature sensors are checked against a calibrated reference at 0°C, 25°C, and 45°C.

4. Firmware Version Lock and Update Path

The sample ships with a documented firmware version. The customer knows exactly what version is on the bench. We also document the bootloader and update path so that any future firmware change can be reproduced identically across production units. This is a small step that becomes a big one the first time a customer’s regulatory submission needs to reference the firmware version that was on the validated sample.

5. Mechanical and Environmental Pre-Screen

The sample is checked against the original 2D or 3D drawing for fit, connector alignment, and clearance to nearby features. For the medical pack, this included confirming the connector standoff would not interfere with a PCB the customer had placed 3 mm from the battery edge. We also run a vibration and shock pre-screen if the target application is AGV, mobile medical cart, or any environment with mechanical stress. The full IEC 62133 and UN38.3 tests happen at certified labs on the production-representative sample, not on the engineering sample.

6. Documentation Package Pre-Check

The IEC 62133 cell reports, UN38.3 summary, MSDS, and BMS message map are compiled and reviewed against the customer’s regulatory submission checklist before the sample ships. We have learned the hard way that shipping the hardware and the documents on different timelines creates expensive follow-up cycles.

The diagnostic device sample cleared all six steps. The AGV sample cleared steps 1–5 and was held at step 6 pending the UN38.3 transport test, which is standard for new pack configurations.

Common Integration Pitfalls (and How We Handle Them)

Even with a clean validation pass on our side, integration with the customer’s host system can surface issues that did not appear on our test bench. Here are the ones we see most often, and how we handle them.

Firmware definition drift between vendors. This is the single most common RS485 Modbus issue. A customer’s host firmware team has a register map documented in their code. Our BMS firmware team has a register map documented in our spec sheet. If the two maps are off by one register, or use different units (mV vs V, °C vs °F), or use different byte orders, the host reads garbage and integration stalls. The fix is a shared register map document signed off by both engineering teams before firmware is frozen. We do not start BMS firmware on a custom RS485 project until that document is in place.

Message timing assumptions on CAN Bus. A customer’s host firmware may poll the BMS message map at 100 ms intervals, or it may expect the BMS to broadcast certain messages at a fixed cadence. The CAN Bus message timing has to be matched exactly. If the BMS broadcasts at 250 ms and the host times out at 200 ms, the host will flag a communication fault even though the bus is healthy. We always confirm the expected message cadence in writing and configure the BMS to match.

Ground loops and bus termination on RS485. RS485 requires termination resistors at both ends of the bus and proper grounding. If the customer adds a third device to the bus without re-evaluating termination, signal integrity degrades and intermittent communication errors appear. We provide a bus topology reference in the integration guide and recommend termination resistor values based on cable length and baud rate.

Cell voltage drift after long storage. A pack that sits on a shelf for six months can develop small cell voltage differences that the balancing circuit needs time to correct. The customer’s host firmware may interpret a brief imbalance on first power-up as a fault. The fix is typically a “balancing in progress” status bit in the message map, which we add when we know the customer’s storage profile in advance.

Connector pinout mismatches. A surprising number of integration delays come from connector pinout differences between the engineering sample and the production sample, or between the customer’s expectation and our documentation. We confirm pinout on the sample datasheet, in the integration guide, and physically on the sample itself with a pinout label. Three places, no ambiguity.

EMC behavior on AGV applications. AGVs combine motor drives, switching power supplies, and long cable runs in a small mechanical envelope. The BMS communication can be sensitive to EMI from the motor controller. We offer ferrite recommendations, shielded cable options, and chassis grounding guidance in the AGV integration guide.

Production Run and the 100% Refund Guarantee

The production run for the medical device was 500 units, with a smaller follow-on run planned once the AGV sample cleared validation. Before production started, the customer asked the question every supply chain team eventually asks: “What happens if the production samples don’t match the validated sample?”

Our answer is a 100% refund guarantee covering any case where production samples do not match the validated sample on form, fit, electrical performance, or safety behavior. The validation sample and the production-representative golden sample are stored in our facility. Every production batch is cross-checked against the golden sample on a defined set of parameters. If a batch fails the cross-check, it does not ship, and the customer has the option of a full refund or a replacement batch at our cost.

The supply chain team folded this clause directly into their supplier qualification checklist. It’s a stronger commitment than most battery suppliers are willing to make, and it reflects how seriously we take the handoff between the sample that the customer validated and the production units that ship to the field.

Follow-Up Support and Continuous Validation

Integration does not end when the production pack ships. The customer’s diagnostic device had a firmware update six months after launch that changed how the host interpreted cell voltage data. We issued a BMS firmware revision that adjusted the cell voltage register scaling to match the new host expectations, and provided a field-update procedure that did not require the pack to be returned to us. The update went out in a routine maintenance release and the customer’s service team handled it in the field.

For the AGV program, we have a standing review every six months. The review covers field failure data, BMS firmware versions in the fleet, balancing behavior, and any protocol-related issues that have surfaced. This is the kind of ongoing engagement that catches the slow-moving issues (cell drift over thousands of cycles, connector wear, firmware version drift across the fleet) before they become warranty events.

When This Approach Fits, and When It Doesn’t

A custom BMS pack with a defined communication protocol and a structured validation process is the right answer when:

• The host system has a fixed firmware architecture that already defines the battery telemetry interface

• The enclosure constraints are frozen or near-frozen

• The regulatory or certification pathway depends on documented cell-level and pack-level safety testing

• The production volume is enough to justify the custom design effort (typically 100+ units, though we have done smaller runs for medical and industrial customers with MOQ flexibility)

It is the wrong answer when:

• The host firmware is still in early concept and the battery telemetry interface is not yet defined

• The enclosure is still being designed and the battery envelope will change

• The application can be served by a configurable off-the-shelf pack with a standard protocol

For teams earlier in the design cycle, starting with a LiFePO4 battery pack or a lithium polymer battery from our catalog and a configurable BMS can shorten the first prototype without locking in geometry that may still change. The migration path to a fully custom pack is straightforward once the spec is stable.

Closing Note

The hardest part of a custom lithium battery project is rarely the cell selection or the BMS hardware. It is the protocol conformance, the fault behavior, the message timing, and the validation pass that proves the pack behaves the way the message map claims it does. The suppliers who treat those as a separate workstream from “building the pack” are the suppliers whose integrations stall on the customer’s bench.

For teams evaluating a custom lithium battery pack that needs to integrate with a specific host controller over a specific protocol, with the documentation package aligned to a specific regulatory submission, the process we walked through here is what the engagement looks like. Send us your enclosure drawing, electrical spec, protocol map, and target timeline, and we will return a scoped design review within 24 hours.

For more on the protocol selection process, the CANopen battery profile specifications from CAN in Automation are a useful reference. The IEC 62133 secondary cell standard governs the cell-level safety testing most portable medical and industrial applications require.