The JK BMS Sending failure error, "This parameter does not apply to the connected device. (Sending failure)", means the firmware refused one value. It is not a Bluetooth problem. The BMS checks every value against the settings it holds right now, and rejects anything that breaks its internal rules.

Most of the time the cause is one of four things: a broken voltage chain, a bad write order, a value outside the range of your firmware, or a charge timer above 18.2 h. All four can be found in the file before you import it.

Why the JK BMS Sending failure happens

The JK app does not send a whole file at once. It writes settings one by one. Each write is checked against the values the BMS holds at that moment, not against the values in your file. A file can have a perfect final state and still fail halfway.

The error text is generic. It does not name the parameter. That is why people search for "jk bms cell ovp sending failure" or "jk bms settings won't save" and find no clear answer.

Cause 1: the voltage chains are not strict

The firmware wants two ordered chains of cell voltages. Each "less than" is a strict one. Equal values are rejected too.

Chain	Meaning
Cell OVP recovery < SOC-100% voltage < Cell RCV	SOC-100% must sit between the over-voltage recovery and the request charge voltage
Cell UVP < SOC-0% voltage < Cell UVP recovery	SOC-0% must sit between the under-voltage protection and its recovery

Other pairs follow the same strict rule. Cell OVP recovery must be below Cell OVP. Cell UVP recovery must be above Cell UVP. Cell RFV must be below Cell RCV, and Cell RCV below Cell OVP. Temperature recovery values must also sit on the safe side of their protection values.

A common trap is setting SOC-100% voltage equal to Cell RCV, for example both at 3.55 V. That looks harmless, but the firmware rejects it. Move one of them by 0.01 V.

These chain rules were verified on a real JK PB2A16S20P running firmware 19.26. Other models may be stricter or looser, so treat them as the minimum.

Cause 2: the write order crosses an existing value

Say your BMS holds Cell OVP recovery 3.40 V, SOC-100% voltage 3.45 V and Cell RCV 3.50 V. You want OVPR 3.50 V, SOC-100% 3.55 V and RCV 3.60 V. The final set is valid.

If the app writes OVP recovery first, the BMS compares 3.50 V with the SOC-100% voltage it still holds, 3.45 V. The chain is now broken, so the write fails. Raising SOC-100% voltage first would also fail, because it would pass the current RCV of 3.50 V. The only safe way is to split the change into steps.

We do not know the exact order the app uses, so the editor plans steps that are safe in any order. It only puts an edit in the same step as another one when neither can break a rule against the other, whichever goes first.

Writing over Bluetooth from the browser removes the guesswork. The editor sends the steps itself, one setting at a time, reads the BMS back after each step and stops at the first refused value with its name.

Cause 3: a value outside the firmware range

Some fields store different numbers on different firmware. The classic case is the short circuit protection delay. V15 files hold values like 1500 µs. Firmware V19 and newer stores a small number (5 by default) and rejects anything above 50. A PB2A16S20P on 19.26 rejects a file carrying 1500.

If you imported a file exported from an old unit into a new one, check this field first. The safe fix is to keep the delay your device already holds, or to set it in the JK app instead of the file. See JK BMS overcurrent protection settings for the SCP fields.

Cause 4: charge timers above 18.2 h

The RCV time and RFV time fields accept 0 to 18.2 h. They are stored as seconds in a 16-bit value, so a larger number cannot be written. If a preset from a forum uses a longer timer, lower it to 18.2 h or less.

How to fix it step by step

The quickest fix, in Chrome or Edge, is to skip the import: connect to the BMS in the editor, make your changes and press Write to BMS. The editor plans the order, writes and verifies every step. If your browser has no Web Bluetooth, use the file route:

Export the current settings from the BMS in the JK app. This is the file your BMS holds now.
Open it in the JK Preset Studio editor. Nothing is uploaded, the file stays in your browser.
Make your changes, or load the file you tried to import.
Read the validation errors. Each one names the field and the other field it conflicts with. Fix the chain until no error is left.
Open the download dialog. If your changes need more than one write step, it offers a file per step.
Import the step files in order. Each step file includes the changes of the earlier steps, and the last one holds everything. Wait for each import to finish before the next.

The editor only patches the fields you changed and recomputes the checksums, so unknown bytes in your file stay as they were. See export and import of JK BMS settings for the file handling itself.

Common mistakes

Setting two chained values to the same number.
Changing Cell OVP and the SOC points in the same import without checking the order.
Copying a file from another model or firmware and importing it unchanged.
Blaming Bluetooth and moving the phone closer. The BMS answered, it just said no.

The Detail Log shows what the BMS actually enforces. Load the log on the log analysis page to see the voltages where protections tripped, and compare them with the values in your file. If the trip voltages differ from your file, the import did not take. The JK BMS Detail Log guide explains how to read it, and why cell overcharge protection keeps tripping covers the most common trip.

FAQ

Does Sending failure happen on all JK BMS models?

No. It depends on the firmware and on how strict its checks are. The rules in this article are confirmed on a PB2A16S20P with firmware 19.26. Older firmware may accept values that newer ones reject.

Is it a Bluetooth problem?

No. The message comes back from the BMS, so the connection works. A real link problem looks like a timeout or a disconnect, not a clear refusal of one parameter. When the editor writes over Bluetooth it sees the same refusal as a result code and names the setting.

Why does the same file work on another BMS?

The other BMS probably holds different current values, so the same write order does not cross any chain. Its firmware may also accept ranges yours does not, such as the SCP delay.

Why is my JK BMS not saving settings from the file?

If only some settings stay, the import stopped at the first rejected value. Fix the chain, import again, and check the values in the app after each step. For the meaning of each parameter, see the parameter reference and parameters explained.

Connect your BMS or open your .jkcfg in the editor to check the chains and write the changes in a safe order.

JK BMS Sending failure: Causes and Step-by-Step Fix