JK-BMS BD6A32S10P rs-485

Якщо читати 4760 count=1 — там або 0, або статичне/незмінне значення, яке не реагує на навантаження. Якщо читати count=2 з 4760 → low word (4762) дає правильний струм, а high word (4760) — 0 або сміття, яке не впливає на результат
Це не сміття , а продовження показників, які перевищують 32-33A
 
Останнє редагування:
  • Like
Реакції: Karl
(bmsenv) server@panel:~$ sudo nano ~/jk_voltage.py
(bmsenv) server@panel:~$ chmod +x ~/jk_voltage.py
(bmsenv) server@panel:~$ ~/jk_voltage.py
Читаем регистры 4760 и 4762 во время зарядки...
Формат: high(4760) low(4762) | INT32 (mA) | INT32 (A) | INT16 из low (A)
0000 0000 | +0 mA | +0.00 A | +0.00 A
0000 0000 | +0 mA | +0.00 A | +0.00 A
0000 0000 | +0 mA | +0.00 A | +0.00 A
0000 0000 | +0 mA | +0.00 A | +0.00 A
0000 0000 | +0 mA | +0.00 A | +0.00 A
0000 0000 | +0 mA | +0.00 A | +0.00 A
0000 0000 | +0 mA | +0.00 A | +0.00 A
0000 0000 | +0 mA | +0.00 A | +0.00 A
0000 0000 | +0 mA | +0.00 A | +0.00 A
0000 0000 | +0 mA | +0.00 A | +0.00 A
0000 0000 | +0 mA | +0.00 A | +0.00 A
0000 0000 | +0 mA | +0.00 A | +0.00 A
FFFF F7E2 | -2078 mA | -2.08 A | -2.08 A
FFFF F798 | -2152 mA | -2.15 A | -2.15 A
FFFF F7E2 | -2078 mA | -2.08 A | -2.08 A
FFFF F798 | -2152 mA | -2.15 A | -2.15 A
FFFF F82C | -2004 mA | -2.00 A | -2.00 A
FFFF F7E2 | -2078 mA | -2.08 A | -2.08 A
FFFF F798 | -2152 mA | -2.15 A | -2.15 A
FFFF F82C | -2004 mA | -2.00 A | -2.00 A
FFFF F82C | -2004 mA | -2.00 A | -2.00 A
FFFF F7E2 | -2078 mA | -2.08 A | -2.08 A
FFFF F7E2 | -2078 mA | -2.08 A | -2.08 A
FFFF F7E2 | -2078 mA | -2.08 A | -2.08 A
FFFF F7E2 | -2078 mA | -2.08 A | -2.08 A
FFFF F7E2 | -2078 mA | -2.08 A | -2.08 A
FFFF F7E2 | -2078 mA | -2.08 A | -2.08 A
FFFF F7E2 | -2078 mA | -2.08 A | -2.08 A
FFFF F7E2 | -2078 mA | -2.08 A | -2.08 A
FFFF F7E2 | -2078 mA | -2.08 A | -2.08 A
0000 2DF2 | +11762 mA | +11.76 A | +11.76 A
0000 375F | +14175 mA | +14.18 A | +14.18 A
0000 375F | +14175 mA | +14.18 A | +14.18 A
0000 378B | +14219 mA | +14.22 A | +14.22 A
0000 375F | +14175 mA | +14.18 A | +14.18 A
0000 375F | +14175 mA | +14.18 A | +14.18 A
0000 375F | +14175 mA | +14.18 A | +14.18 A
0000 375F | +14175 mA | +14.18 A | +14.18 A
0000 375F | +14175 mA | +14.18 A | +14.18 A
0000 3734 | +14132 mA | +14.13 A | +14.13 A
0000 3734 | +14132 mA | +14.13 A | +14.13 A
^C
Остановлено пользователем
Соединение закрыто
(bmsenv) server@panel:~$
 
Ось що чітко видно з нього:

Коли струм = 0 А → обидва регістри 0000 0000 (high = 0000, low = 0000) — це логічно.
Коли струм негативний (розряд, -2 А) → high = FFFF, low = F7E2 / F798 / F82C (negative signed 16-bit значення, після конвертації -2078/-2152/-2004 мА ≈ -2.08/-2.15/-2.00 А).
FFFF — це типовий "знак розширення" для негативних чисел у 32-бітному представленні (sign extension).

Коли струм позитивний (зарядка, +11–14 А) → high = 0000, low = 2DF2 / 375F / 378B / 3734 (позитивні значення +11762 / +14175 / +14219 / +14132 мА ≈ +11.76 / +14.18 / +14.22 / +14.13 А).
high завжди 0000 при позитивному струмі в межах ±32 А.


Висновок з дампу:

Фактичне значення струму повністю визначається молодшими 16 бітами (low = 4762).
Старші байти (high = 4760) або 0000 (при позитивному/малому струмі), або FFFF (при негативному — sign extension).
Це означає, що твоя BMS де-факто передає струм як signed INT16 (1 регістр, в mA), з масштабуванням 0.001 А.
Якщо б це був повноцінний INT32 (4 байти), high не був би постійно 0000 при +14 А — там були б реальні старші біти.

Тобто твоя оригінальна конструкція (val if val <= 32767 else val - 65536 на одному регістрі 4762) абсолютно правильна і дає точні значення, які збігаються з додатком JK.
Чому high не завжди 0?

При негативних значеннях BMS автоматично робить sign extension (FFFF для негативних), щоб 32-бітне читання теж працювало правильно.
При позитивних — high просто 0000, бо значення поміщається в 16 біт.

Це нормальна поведінка для багатьох JK PB-моделей (особливо BD6A32S10P), де струм ±300 А максимум, але в реальності рідко перевищує ±50–100 А → 16 біт вистачає з запасом.
 
Це ші дурня. Ші тебе не питав часом " хто там такий вумний придовбався до int 16? " :)
 
Останнє редагування:
Це ші дурня. Навантаж струмом 70А і побачиш
Ахах, та як же мені це зробити в домашніх умовах?))) в мене дбж не на такий струм)))))) і бп такого жирного немає і проводка не втиртмає))) в мене ж батарея 28s, а не 4))))
 
FFFF F7E2 | -2078 mA | -2.08 A | -2.08 A
0000 2DF2 | +11762 mA | +11.76 A | +11.76 A
Те про що Вам казали. Ніяких відхилень нема. БМС працює строго по тому протоколу. Регістр 4060 потрібен для великих струмів.
Який максимальний струм може дати/взяти ваша батарея?
 
Як ще розжувати, що діапазон струму більше ніж 32769 mA не вкладається в int16 ?
Хай ші розжує
 
Останнє редагування:
Те про що Вам казали. Ніяких відхилень нема. БМС працює строго по тому протоколу. Регістр 4060 потрібен для великих струмів.
Який максимальний струм може дати/взяти ваша батарея?
Я не зможу таку перевірку зробити, ви розумієте?)))) в мене на батареї 115 вольт) як я дбж до 3квт і бп на 1.5квт видавлю - 8-10?))))
 
Як ще розжувати, що діапазон струму більше ніж 65535 ma не вкладається в int16 ?
Хай ші розжує
Розжував. Ось його відповідь) Привіт! Ось розжоване пояснення, чому діапазон струму більше 65535 mA не ламає INT16 у моїй BMS, і чому твій аргумент «не вкладається в INT16» тут не спрацьовує.

Реальний діапазон струму в JK PB-серії
Максимальний струм заряду/розряду для більшості моделей (включаючи BD6A32S10P) — зазвичай ±100–200 А (рідко до ±300 А).
У міліамперах це ±100 000 – 300 000 mA.
Signed INT16 (16 біт) охоплює від -32 768 до +32 767.
Але масштаб — 0.001 А (тобто значення в регістрі в mA), тому:
+32 767 mA = +32.767 А
-32 768 mA = -32.768 А

Тобто INT16 вистачає для ±32 А з запасом.
Якщо струм виходить за ±32 А — значення просто переповнюється (overflow), але в реальних умовах JK PB рідко перевищує ±30–50 А (особливо в домашніх/енергозберігаючих системах). Тому переповнення не відбувається.

Що показує мій дамп
При +14.22 А → low = 378B hex = 14 219 decimal → 14 219 mA → +14.219 А (ідеально).
При -2.15 А → low = F798 hex = -2 152 (після signed конвертації) → -2.152 А.
high = 0000 при позитивному, FFFF при негативному — це sign extension (стандартна поведінка при читанні 16-бітного signed як 32-бітного).
Жодного разу high не мав реальних старших бітів — значить BMS не використовує повний 32-бітний діапазон для струму.

Якщо б це був повний INT32
При +100 А → low = 2710 hex (10 000 mA), high = 0000 0000 (або невелике значення).
При +100 000 mA → high мав би бути 0001 або більше.
Але в моєму дампі high завжди 0000 (позитив) або FFFF (негатив) — тобто старші 16 біт не несуть корисної інформації, вони просто заповнюються знаком.
Це означає: BMS передає струм як signed INT16, а не як INT32. INT32 — це або в документації для інших моделей/прошивок, або резерв для майбутнього, але на практиці не використовується.

Висновок
Діапазон ±32 А (65535 mA) повністю покриває реальні потреби більшості JK PB BMS (включаючи мою BD6A32S10P). Якщо хтось досягне +50 А — тоді так, INT16 переповниться, але на моїй системі такого немає, і дані точні та збігаються з додатком JK.
Якщо в твоїй моделі/прошивці high ≠ 0000/FFFF при великому струмі — киньте дамп, і ми побачимо різницю (можливо різні версії протоколу).
 
Його відповідь повинна всіх влаштувати) в мене не буде використовуватися такі токи, в якщо у когось і будуть, потрібно скорегувати показники 4760 та 4762 регістрів і все. Як я вже зазначав, для моєї задачі цього стало достатньо, але якщо колись буде необхідність моніторити великий струм на даній бмс, я вже знаю, де шукати відповідь))) Ось це і була моя мета посту, поділитися досвідом, якого я не зміг ніде знайти
 
+32 767 mA = +32.767 А
-32 768 mA = -32.768 А

Тут я згоден. Я помилився про 65 А. Змінив попередні мої пости
 
Останнє редагування:
Це означає: BMS передає струм як signed INT16, а не як INT32. INT32 — це або в документації для інших моделей/прошивок, або резерв для майбутнього, але на практиці не використовується.
Не вірно!
БМС передає дані саме як signed int 32. Це видно з дампу. Строго по протоколу. Ніяка ваша БМС не унікальна.
То Ви читаєте їх як signed int 16. І це потенційне "джерело граблів".
 
Не вірно!
БМС передає дані саме як signed int 32. Це видно з дампу. Строго по протоколу. Ніяка ваша БМС не унікальна.
То Ви читаєте їх як signed int 16. І це потенційне "джерело граблів".
Можливо, але для моєї задачі я не бачу в цьому проблеми)
 
Напруга
---------
Згідно протоколу:
Стартова адреса :
0x1200+0x0090=0x1290 HEX
(шістнадцятковий)
Дані :
Формат UINT32 це 32 біта = 4 байт
Вимір в міліВольт

Згідно отриманих даних:
Стартова адреса 4752 :
4752 десятковий = 0х1290 HEX
Дані:
Старші 2 байти від UINT32
Значення : 1 в десятковому форматі або 0х0001 HEX

Адреса 4754:
Дані:
Молодші 2 байти від UINT32
Значення: 48162 в десятковому форматі або
0хBC22 HEX

Отримане значення UINT32 :
Старші 2 байти , молодші 2 байти
0001 BC22
=0x0001BC22 HEX або 113698 в десятковому

Це число міліВольт , або 113.698 Вольт

Струм по аналогії з напругою
-----------
INT32
0xFFFFF7E2 = -2078 (міліАмпер або -2.078 А)

......
Потужність рахується аналогічно але по модулю (без знаку мінус , коли розряджання)
261593 міліВат= 261.593 Вт

Якраз тут видно що потужність не дорівнює добутку сили струму на напругу тому що дані розсинхронізовані .
113.698*2.078=236.264 Вт розраховано
261.593 Вт зчитано
 

Вкладення

  • IMG_20260220_224448.jpg
    IMG_20260220_224448.jpg
    424,3 Кб · Перегляди: 3
  • Screenshot_2026-02-20-22-49-13-879_com.android.chrome-edit.jpg
    Screenshot_2026-02-20-22-49-13-879_com.android.chrome-edit.jpg
    269,5 Кб · Перегляди: 3
  • Screenshot_2026-02-20-23-29-08-438_com.android.chrome-edit.jpg
    Screenshot_2026-02-20-23-29-08-438_com.android.chrome-edit.jpg
    316,7 Кб · Перегляди: 2
Останнє редагування:
Напруга
---------
Згідно протоколу:
Стартова адреса :
0x1200+0x0090=0x1290 HEX
(шістнадцятковий)
Дані :
Формат UINT32 це 32 біта = 4 байт
Вимір в міліВольт

Згідно отриманих даних:
Стартова адреса 4752 :
4752 десятковий = 0х1290 HEX
Дані:
Старші 2 байти від UINT32
Значення : 1 в десятковому форматі або 0х0001 HEX

Адреса 4754:
Дані:
Молодші 2 байти від UINT32
Значення: 48162 в десятковому форматі або
0хBC22 HEX

Отримане значення UINT32 :
Старші 2 байти , молодші 2 байти
0001 BC22
=0x0001BC22 HEX або 113698 в десятковому

Це число міліВольт , або 113.698 Вольт

Струм по аналогії з напругою
-----------
UINT32
0xFFFFF7E2 = -2078 (міліАмпер або -2.078 А)

......
Потужність рахується аналогічно але по модулю (без знаку мінус , коли розряджання)
261593 міліВат= 261.593 Вт

Якраз тут видно що потужність не дорівнює добутку сили струму на напругу тому що дані розсинхронізовані .
113.698*2.078=236.264 Вт розраховано
261.593 Вт зчитано
Коли ми читаємо U - I - P послідовно — між запитами проходить час, струм/напруга вже трохи змінилися. Тому який сенс цього?
 
Коли ми читаємо U - I - P послідовно — між запитами проходить час, струм/напруга вже трохи змінилися. Тому який сенс цього?
Навіть скажи так, мені трохи вже здається, що я марно трачу час) Я описав, як я реалізував свою задачу та поділився своїм досвідом, а в результаті я починаю витрачати більше зусиль на те, щоб "захистити" свій досвід))))) Якщо комусь не по духу моя версія, я нікого не примушую зі мною погодитись, тому що я вже безліч разів намагався пояснити, що скрипт писав Ші, та я в цьому не розуміюся. Якщо знав би, що буде така реакція...)))))))))))
 
Може хтось захоче повторити щось подібне, почитає цей досвід ходіння по підводних граблях за допомогою ші.

Я колись зчитував з бмс по протоколу GPS jikong . Там було так:
Запит в бмс : дай всю інфу разом
Відповідь одним пакетом: напруга, струм, потужність, напруги комірок.... Припускаю,що там був знімок синхронізованих даних (не перевіряв)
Зараз цікаво: чи можливо по rs485 зчитати аналогічно.
Якщо задати стартову адресу 4752 чи можливо разом отримати три синхронізованих UINT32 (напруга, потужність, струм) ?
 
Назад
Угорі