Analysing UART Signal From E-Scooter Controller

[avarafoods]

I'm currently working on a project with an electric scooter, I intend to install a larger battery into the scooter and also replace the stock 300W controller for a VESC. BUT I want to keep the original screen as it looks nice and also has built-in Bluetooth to connect to an app, also it'll be a learning curve for logic analysing, as I haven't dabbled in that arena unit now. I plan on using an Arduino to communicate between the new VESC and translate to the old screen.

I have a Xiaomi M365 CLONE!, its called an Iezway m365.

So far as my understanding goes, the scooter has the screen (BLE) containing TX RX pins connected to the motor speed controller, the screen has the throttle/brake inputs, then talks to the controller (presumably communicating throttle/brake/errors/faults/scooter speed between each other)

using a logic analyzer, I have interpreted signals sent between the 2 devices (screen/motor controller) and I have absolutely no idea what these signals represent or mean... I'm not even sure if I have the appropriate settings in Sigrok pulseview software, (i have found that baud of 9600/ and 8-bit data bits looks correct and throws up no errors.

I have taken several readings when the scooter's telemetry was at different states to try and find an obvious correlation between the readings and the telemetry. I have set the data format to HEX, for no specific reason other than seeing other people on youtube using HEX to read UART. the first data package (leftmost) is the TX from the screen to the controller and the last data package(rightmost) is RX from the motor speed controller to the screen.

if anyone could explain what these signals could mean or how best to find out, it'll be much appreciated. please feel free to give me a dummies explanation of the basic operation of the UART protocol.

Thank you

for reading, Arran.

[johnwasser]

It's easier to work with digits than with pictures of digits

FFAA00 2A 017530 81 FA    FFAA21 A2F6 0000 A4 06  Brake Off, Battery Full
FFAA00 32 017530 A1 22    FFAA21 A32F 0000 A6 42  Brake On, Battery Full
FFAA00 DA 017530 89 B2    FFAA21 A34E 0177 C4 F7  9 MPH, Battery Full
FFAA00 D9 017530 8B B3    FFAA21 A34E 0278 C4 F9  15 MPH, Battery Full

Looks like every message starts with FFAA. The next byte might be an address since it is different for send and receive.

I think the last byte in each message is a checksum. The last two sent messages have these differences:
DA 89 B2
D9 8B B3
Note that D9 is 1 lower than DA and 8B is two higher than 89. Add them together and you get B3 being one greater than B2.

The received 0000, 0000, 0177, and 0278 might be speed. In decimal, they are 375 and 632. Divide by 9 and 15 respectively and you get values of 41.66 and 42.13. Call it 42. Divide that number by 42 to get speed in MPH.

Looks like the 6th bit in the last byte before the send checksum might be the brakes.

Compare the values you have with messages with other conditions to see if you can figure out what the other data bytes are doing.