Bird Scooter battery communication

[stancecoke]

Bird scooters are using Lishui controllers, so it should be quite easy to make them run with the EBiCS firmware.
Is there any information about the communication protocol between the battery and the controller? I've listened to the datastream, it uses a KM5S-like protocol @9600BAUD.
The controller sends a startup sequence and afterwards always the same query. The battery answers with quite long messages, I guess there will be the temperature and the SOC of each cell bank in there, but I was not able to decode the messages yet.

UART communication @ 9600 BAUD, same scheme as KM5S protocol.

Controller to battery:

3A 16 04 00 1A 00 0D 0A
3A 16 05 00 1B 00 0D 0A
3A 16 02 00 18 00 0D 0A
3A 16 02 00 18 00 0D 0A
3A 16 02 00 18 00 0D 0A
3A 16 02 00 18 00 0D 0A
3A 16 02 00 18 00 0D 0A

Battery to controller:

3A 16 04 0E 52 46 30 31 4C 31 39 32 33 33 31 30 31 33 34 03 0D 0A
3A 16 05 02 20 22 5F 00 0D 0A
3A 16 02 10 03 00 00 11 12 1B 9E D7 FF D8 1C CE 28 46 A0 00 AD 05 0D 0A
3A 16 02 10 03 00 00 11 12 1B 9E C8 FF D8 1C CE 28 46 A0 00 9E 05 0D 0A
3A 16 02 10 03 00 00 11 12 1A 9E C8 FF D8 1C CE 28 46 A0 00 9D 05 0D 0A
3A 16 02 10 03 00 00 11 12 18 9E BE FF D8 1C CE 28 46 A0 00 91 05 0D 0A
3A 16 02 10 03 00 00 11 12 1A 9E BE FF D8 1C CE 28 46 A0 00 93 05 0D 0A
3A 16 02 10 03 00 00 11 12 17 9E BE FF D8 1C CE 28 46 A0 00 90 05 0D 0A
3A 16 02 10 03 00 00 11 12 17 9E BE FF D8 1C CE 28 46 A0 00 90 05 0D 0A
3A 16 02 10 03 00 00 11 12 17 9E B9 FF D8 1C CE 28 46 A0 00 8B 05 0D 0A
3A 16 02 10 03 00 00 11 12 17 9E B9 FF D8 1C CE 28 46 A0 00 8B 05 0D 0A
3A 16 02 10 03 00 00 11 12 17 9E B9 FF D8 1C CE 28 46 A0 00 8B 05 0D 0A
3A 16 02 10 03 00 00 11 12 17 9E B9 FF D8 1C CE 28 46 A0 00 8B 05 0D 0A
3A 16 02 10 03 00 00 11 12 17 9E B9 FF D8 1C CE 28 46 A0 00 8B 05 0D 0A
3A 16 02 10 03 00 00 11 12 17 9E B9 FF D8 1C CE 28 46 A0 00 8B 05 0D 0A
3A 16 02 10 03 00 00 11 12 17 9E B9 FF D8 1C CE 28 46 A0 00 8B 05 0D 0A
3A 16 02 10 03 00 00 11 12 17 9E B9 FF D8 1C CE 28 46 A0 00 8B 05 0D 0A
3A 16 02 10 03 00 00 11 12 17 9E B9 FF D8 1C CE 28 46 A0 00 8B 05 0D 0A
3A 16 02 10 03 00 00 11 12 15 9E B9 FF D8 1C CE 28 46 A0 00 89 05 0D 0A
3A 16 02 10 03 00 00 11 12 17 9E B9 FF D8 1C CE 28 46 A0 00 8B 05 0D 0A
3A 16 02 10 03 00 00 11 12 15 9E B9 FF D8 1C CE 28 46 A0 00 89 05 0D 0A
3A 16 02 10 03 00 00 11 12 15 9E B9 FF D8 1C CE 28 46 A0 00 89 05 0D 0A

Any idea, what can be the meaning of each byte?
The meaning of first four and the last four bytes are well known from the KM5S protocol.

regards
stancecoke

 

[amberwolf]

Well, a hex to decimal converter
https://www.atatus.com/tools/hex-to-decimal
gives these results for the segments between the four end bytes, to make it more "human readable". Does anything pop out?

I added line breaks between "similar" sections; looks like the last 13 are identical. Are they 48v 13s packs? (information on them varies from site to site, so not having one I can't tell for sure)

82 70 48 49 76 49 57 50 51 51 49 48 49 51

58 22 5 2 32 34

3 0 0 17 18 27 158 215 255 216 28 206 40 70 160 0

3 0 0 17 18 27 158 200 255 216 28 206 40 70 160 0
3 0 0 17 18 26 158 200 255 216 28 206 40 70 160 0

3 0 0 17 18 24 158 190 255 216 28 206 40 70 160 0
3 0 0 17 18 26 158 190 255 216 28 206 40 70 160 0
3 0 0 17 18 23 158 190 255 216 28 206 40 70 160 0
3 0 0 17 18 23 158 190 255 216 28 206 40 70 160 0

3 0 0 17 18 23 158 185 255 216 28 206 40 70 160 0
3 0 0 17 18 23 158 185 255 216 28 206 40 70 160 0
3 0 0 17 18 23 158 185 255 216 28 206 40 70 160 0
3 0 0 17 18 23 158 185 255 216 28 206 40 70 160 0
3 0 0 17 18 23 158 185 255 216 28 206 40 70 160 0
3 0 0 17 18 23 158 185 255 216 28 206 40 70 160 0
3 0 0 17 18 23 158 185 255 216 28 206 40 70 160 0
3 0 0 17 18 23 158 185 255 216 28 206 40 70 160 0
3 0 0 17 18 23 158 185 255 216 28 206 40 70 160 0
3 0 0 17 18 21 158 185 255 216 28 206 40 70 160 0
3 0 0 17 18 23 158 185 255 216 28 206 40 70 160 0
3 0 0 17 18 21 158 185 255 216 28 206 40 70 160 0
3 0 0 17 18 21 158 185 255 216 28 206 40 70 160 0

 

[sarlmalone]

hi stancecoke, came across this thread investigating the same bms

I came across this document that google cached that has the protocol https://cdck-file-uploads-europe1.s.../b573097b465ab28757d692206a3ee5c867bb8b89.pdf

It looks like it was translated from chinese to english.. then someone translated it to another language.. it has most of the protocol info on this battery, most of the info is there if you translate it back

There are two known revisions of this battery though being sold around the internet, not sure if this api applies to the later variant

been trying myself with python to query the battery with a cheap ttl-usb adapter, (connecting rx/tx/gnd) and getting nothing back. none of the rx/tx pins are 3.3-5v high

also do you know what the red wire is the attached photo? (not sure if its important)

 

[stancecoke]

also do you know what the red wire is the attached photo?

As far as I remember, this is a +5V supply from the controller, maybe to tell the BMS, that the controller is switched on.

regards
stancecoke.

 

[sarlmalone]

As far as I remember, this is a +5V supply from the controller, maybe to tell the BMS, that the controller is switched on.

regards
stancecoke.

thanks, its labeled "CHA", no clue what that means
I tried giving it 5v but still no go with the uart comms, my bms also might be using an entirely different protocol and just not responding (it is not the rev1.2 version)

which revision battery did you get your hands on? (attached are the v1.2 and v2 photos)

 

[stancecoke]

I never opened the battery and I don't plan to open the battery. Do you send the messages in hex mode without an additional CR/LF?

UART communication @ 9600 BAUD, same scheme as KM5S protocol.

Controller to battery:

3A 16 04 00 1A 00 0D 0A

Edit: I just found, that I have a spare BMS, I didn't remember that. It's a rev.2. It's labeled with HY-RDF-S1004UM V04
There is no voltage on the red wire from the controller side, I just checked that. It has about 6kOhm to GND on the Controller. It is labeled as CHA on the controller PCB also. Maybe it's an input on controller side, that tells the controller, that the battery is charging recently. Did you check the voltage on the pin on battery side with and without charging?

regards
stancecoke

 

[sarlmalone]

I never opened the battery and I don't plan to open the battery. Do you send the messages in hex mode without an additional CR/LF?

UART communication @ 9600 BAUD, same scheme as KM5S protocol.

Controller to battery:

3A 16 04 00 1A 00 0D 0A

Edit: I just found, that I have a spare BMS, I didn't remember that. It's a rev.2. It's labeled with HY-RDF-S1004UM V04
There is no voltage on the red wire from the controller side, I just checked that. It has about 6kOhm to GND on the Controller. It is labeled as CHA on the controller PCB also. Maybe it's an input on controller side, that tells the controller, that the battery is charging recently. Did you check the voltage on the pin on battery side with and without charging?

regards
stancecoke

I figured out my mistake after some probing.. I was using the black/GND as labeled in that photo of that Julet connector.. but the stm8 is grounded to B-, so the black wire going into the battery is just not connected (probably grounded through the original controller), now everything makes sense and works with proper grounding

red/CHA idles low around 0-0.5v and goes high to around 25-30v when charging

UART works, the battery is responding exactly according to that document, @ 3-5v 9600baud, 8n1

I wrote a quick C# app with buttons to test sending the varrious commands, and its replying perfect now. I will write code to decode the responses and verify the response checksums later on.

Does your bms have the "anti theft" feature? Where after the discharge current hits a specific level, the bms cuts out power for a few seconds intermediatly. Apparently this came as a later firmware revision for the v04 pcb. There was probably a later documented way to remove this restriction via a serial command, or the battery might just be looking for constant communication with the controller (if so I will probably take a blue/black pill and code it to emulate/communicate with the bms for a quick ebike project). Otherwise it might involve reversing the stm8 firmware a bit or better yet, flashing a previous firmware version without this limitation.

 

[stancecoke]

Does your bms have the "anti theft" feature?

The BMS cuts the output after a few seconds of drawing (higher) current, if there is no UART communication. You have to disconnect the connector to the controller and reconnect it, to reactivate the voltage output. As long as the BMS receives queries from the controller, the battery output keeps active.

I will write code to decode the responses and verify the response checksums later on.

I'm keen to see your code, please make it public at github

regards
stancecoke