The HEX code is from the pdf file in post #1. Knowing the mileage isn’t going to help. The odometer HEX is known and the Checksum is known. What is not known, is what algorithm was used. Below is the odometer reading.
apologies that I didnt go back and read the initial post. can I ask, what is the 01 in position 04 in that line for? I mean, you have calculated the mileage, and say that A9 is the checksum, is the 01 meant for anything?
Look I can make this work if I use the 01 shown in the hex dump. it aligns with 5F.. 5F -> decimal = 21 01 -> decimal = 1 21 + 1 = 22. 22 -> 10110. Take 2s compliment = A BC -> decimal = 23 there is not corresponding number for this. its 00 23 -> 10111. 2s complement = 9 I have no way to verify this, to back test other samples. just making up stuff on the fly, and well, its kinda simple what the engineers might have employed. shifting bits around
This looks promising. Tried 1’s compliment with binary values, Modulo256, CRC-8 and CRC-16 all will failure. I have PM’d you another chip dump to test your theory.
yeah, this is going to take some time. you do know that you can try Mod 8, 16, 32, etc.. it doesnt have to be 256 Not sure how much processing/registers this processor on these displays have, and thinking it cant be too complex an operation that has to be performed, if its just tiny little processor/FPGA etc..
Can you do the following experiment, to work out if the checksum is using all the milage bits in its calculations Can you travel for 1km, and take another reading, to see if the checksum changes. want to work out if all bits are used, MSB, LSB... Not sure if the bike is accessible to do this
