Analysing variable length serial protocol

Projects Networking, Protocols, and Devices
1

Hi, I have an ebike consisting of a controller unit which regulates power to the motor and a smart LCD which can adjust max speed, power output, pedal assist sensitivity etc as well as displaying the current battery voltage, motor power usage (Watts) and motor speed; LCD PDF Manual can be found here:

The LCD and controller are connected by a 5v rx/tx line. I have connected an arduino mega in series in the middle of the serial lines; controller rx/tx to arduino serial1 tx/rx then arduino serial2 tx/rx to the LCD rx/tx.
Code is currently passing all received data from controller directly to the LCD and vice versa which works perfectly, LCD values are correct.

I wish to analyse the protocol but can't seem to figure out any sort of structure in it. Currently focusing on Controller -> LCD comms to extract motor values. Seems like all commands start with hex 02 (start of text in AsciiTable) and most then contain 0E which I initially suspected to be message length however that does not seem to be the case as evident from the following commands:

.
02 0E 40 40 00 00 03 0B B8 00 00 35 C8
02 0E 01 00 40 00 00 03 0B 98 00 35 C8
02 4E 40 40 00 00 03 0B B8 88 54 42 F7
02 0E 41 00 0A 00 02 03 B8 00 00 35 C8
02 0E 01 00 50 00 D0 0B B8 00 00 05 FE

02 4E 40 40 00 00 03 0B B8 00 35 C8
02 4E 40 20 0A 00 03 0A B8 80 35 C8
02 4E 40 40 00 00 03 0B B8 88 54 42 F7
02 4E 40 08 01 00 03 0B DD 81 A0 93 FE FE FE

Here is the full hexdump from roughly 60 seconds of running, messages come in constant stream: ebike SW-900 HEX Dump - Pastebin.com

That dump will contain values for battery voltage ( 45-52.4V ), motor power usage (0-1000Watts, could also be 0-10Amps ) and possibly wheel speed. Likely some other params in there also.

The Command

02 0E 01 00 40 00 00 03 0B B8 00 00 35 C8

is by far most popular accounting for over half the messages. Could this possibly be a heartbeat?
Here is the same paste without that command for easier reading:

Not found any sort of manual for controller as of yet.

Thank you for any insight provided, i'm still getting my head around this whole reverse engineering thing.

For reference, question also asked on StackExchange:

(side note, anyone know why I can't make my links here clickable?)

2

Unless the manufacturer wants to share its protocol, I doubt you'll get very far.

.

3

At the risk of possibly damaging something your best option would be to one at a time, send a single command sequence line you have captured back to the display and see what happens (what segments light up).
Then once you find a sequence that looks interesting try flipping a bit somewhere in the middle of the sequence to see if any segments change or you get nothing.
If you get nothing then the protocol probably has a checksum you would need to deduce, if you see changes than keep flipping bits and noting what segments light up/ go out until you have them all.