Home / Knowledge Base / Battery & Energy Storage

How to Fix JK/JBD BMS RS485 CRC Errors in Solar Assistant

PROTOCOL: MODBUS RTU Applies to: Solar Assistant, JK BMS, JBD BMS, Server Rack Batteries
⚡ TL;DR Diagnostic Quick-Card
Symptom:
One battery fits perfectly. As soon as you daisy-chain 2 or more batteries to the same USB-to-RS485 adapter, the connection drops at random.
Diagnostic Log:
CRC check failed | Corrupt data frame received
Root Cause:
1. Logical Conflict: Multiple BMS boards sharing the exact same Modbus Slave ID.
2. Physical Noise: Ground loops between server racks or missing 120Ω termination resistors causing signal reflection.
↓ Step 1: Software/DIP Switch Fix ↓ Step 2: Physical Layer Check ↓ Step 3: Hub Isolation for Noise & Topology

A single DIY server rack battery (equipped with a JK or JBD BMS) usually communicates flawlessly with Solar Assistant via RS485. But once you daisy-chain two or more batteries in parallel to the same USB-to-RS485 adapter, the connection turns unstable, drops often, and fills the logs with CRC Errors.

Solar Assistant / MQTT Broker Log
2026-06-15 08:12:04 [INFO] Sending Read Holding Registers to Slave ID: 1
2026-06-15 08:12:04 [WARN] Error: CRC check failed. Expected 0x4A, received 0x00.
2026-06-15 08:12:05 [WARN] Corrupt data frame received. Connection dropped.
2026-06-15 08:12:10 [INFO] Attempting reconnection...

When we’re talking about Modbus RTU, a CRC (Cyclic Redundancy Check) error is when the data packet was received but the math doesn’t add up. The CRC bytes added at the end of the frame do not match the checksum calculated by the Raspberry Pi. While cheap USB adapters can cause this, when dealing with multiple BMS units, the issue is almost always a physical bus collision.

The Root Cause: Hardcoded Slave IDs

Modbus is a strict Master/Slave protocol. The Master (Solar Assistant) calls a specific Slave ID, and only that ID is allowed to answer. The problem is that many BMS manufacturers ship their units with a hardcoded, default Modbus Slave ID (usually ID: 1 or ID: 3).

The Electrical Collision Trap

If you have 3 batteries all with “ID: 1” on the same RS485 bus, Solar Assistant will send out a request for “ID: 1” and all 3 batteries will respond. All three BMS boards will believe the message is for it and reply simultaneously. Their electrical signals overlap and crash into each other on the copper wires. Solar Assistant receives a garbled mess of voltages, which fails the CRC check.

Step 1: The DIY Software Fix (Changing Slave IDs)

The solution is to handle each battery individually in the RS485 daisy-chain. Before buying any more hardware try the following:

  • Use the Bluetooth App: Connect to each battery individually using the official JK or JBD mobile app. Go to the communication setting and look for “Device Address” or “Modbus ID”. Change battery #1 to ID 1, #2 to ID 2, etc.
  • DIP Switch Configuration: If your server rack battery has physical DIP switches on the front of the unit, use the manual to set each unit to a unique binary address.

Note: Some older or specific firmware versions of JK/JBD BMS boards don’t allow changing the Modbus ID or they revert back to the default ID upon reboot. If you cannot provide unique ids then you have a hardware problem.

Step 2: Physical Layer Checklist (The 120Ω Resistor)

If you have assigned unique Modbus IDs to all batteries and are still seeing CRC errors, the issue is physical. RS485 requires a strict daisy-chain topology. Ensure you are using shielded twisted-pair cables. Most importantly, verify that a 120Ω termination resistor is installed at the very first and last devices on your RS485 bus to prevent signal reflection—a primary cause of corrupted data frames.

Step 3: The Hardware Fix (Physical Isolation & Star Topology)

If you’ve resolved ID conflicts but still experience drops, or if you must wire your batteries in a star topology (running individual cables from each battery to a central point instead of a strict daisy-chain), standard RS485 will fail. Furthermore, connecting multiple metal server racks often creates ground loops (Ground Potential Differences) that introduce severe electrical noise onto the bus.

To resolve physical layer instability and topology limits, engineers use an active Isolated RS485 Hub. Instead of daisy-chaining, each battery connects to a dedicated, optically isolated channel. This completely blocks ground loop currents, protects against surges, and ensures a clean signal back to Solar Assistant.

✅ Active Isolated RS485 Hub
  • Star Wiring Support: Expand 1 main port to 4/8 ports, no strict daisy-chain limitation.
  • Optocoupler Isolation: Provides physical isolation of noise, static electricity and ground loop currents between the battery chassis.
  • Signal Relay: Amplifies the RS485 signal for longer and more stable transmission distance.
✅ Active RS485 Smart Hub
  • Each battery receives a dedicated, physically isolated RS485 port.
  • Virtual ID Mapping: The Hub reads “ID: 1” from all ports but dynamically translates them to ID: 1, 2, 3 for Solar Assistant.
  • Optocouplers physically block noise and ground loops.

Dealing with unstable daisy-chains or ground loops?

Stop fighting dropped connections. Keep your ESS telemetry rock solid with physical channel separation, optical isolation, and flexible star-wiring topologies using Valtoris Isolated RS485 Hubs.

View Isolated Hubs Ask an Engineer

Troubleshooting knowledge base provided by Valtoris Engineering.
Feel free to bookmark and share. If republishing this diagnostic guide externally, please attribute with a link back to Valtoris.com.