Closed jrventer closed 1 year ago
Wow! You did an amazing job!! I will try to reproduce your findings as soon as possible on different BMS versions. This will take some time but it looks very promising.
Ok thanks. FYI my BMS details: Model: JK_B2A24S15P Hardware Ver: V11.XW Software Ver: V11.26 Mine have CAN customisation as well so ordered model was JK_B2A24S15P-CAN
I am busy discussing with JK to get more info but was lucky to figure this part out before they gave me the final information. I received some new docs but they look mainly the same but will check and compare and share if they are updated.
@syssi just test but I suspect we will need to make the source GPS. I was testing many combinations and then changed back to PC source to confirm but as we do not get any response for the pairing/write activation and it stays active for a while it might have activated with gps source. I will also try do some testing later to confirm.
Thanks for your feedback! The implementation of the first switches is ready but untested. Please verify the request payloads before issuing the commands on your hardware. I don't want to mess up the registers of your BMS.
Do you know the meaning of the 0xb2
register of the password (0x05
) frame?
frame[11] = 0xB2; // register: 0x00 (read all registers), 0x8E...0xBF (holding registers)
Do you know the meaning of the
0xb2
register of the password (0x05
) frame?frame[11] = 0xB2; // register: 0x00 (read all registers), 0x8E...0xBF (holding registers)
It is the 0xB2 "Modify parameter password" as I initially assumed they would require the password to be passed as data but then removed the password from the data payload. I suspect it is ignored so will do some tests to pass 0x00 instead.
also had a quick check and seems like you need to update the CRC frame length: ..... frame[11] = address; // register: 0x00 (read all registers), 0x8E...0xBF (holding registers) frame[12] = value; // data frame[13] = 0x00; // record number frame[14] = 0x00; // record number frame[15] = 0x00; // record number frame[16] = 0x00; // record number frame[17] = 0x68; // end sequence auto crc = chksum(frame, 17); <<<<<< should be 18 ....
Good catch!
Hi
After some extensive trial and error I have managed to figure out how to enable the write requests through the TTL interface. For the testing I just did some lambda code to make it easier for the trial and error so will share that. I could go update your code but would likely be much easier for you to make the changes based on my findings. This will now allow us to switch back to fixed connection instead of the BLE connection that take allot of resources and not that stable.
In order to have a successful write request which is acknowledge by the BMS you have to send a request with the 0x05 (Pairing) command. Then when you do a write request the BMS reply. From my testing I can do one 0x05 command request and do multiple writes thereafter. The BMS does not respond to the 0x05 request but as long as it is structured correctly your following write requests will have responses from the BMS. I assume the pairing request will time out at some stage so might be easier just to always issue the pairing before making changes.
Below the Frame structure I used for my testing: Pairing Command Request
Write request:
Below my debug logs showing the requests and responses from the BMS.
Let me know if this will be enough to make the updates to the jk_modbus and jk_bms components.