I am working on an Arduino library that reads data from wheels, using some of this excellent code as a reference for my c++ code.
I personally have a new (late 2022) MTen3, and the raw data stream that I see from my device is slightly different from that in the comments at the bottom of the Gotway Adapter.
Frames now come in varying lengths.
Frame A is sometimes longer with 4 additional data bytes (?) from buffer[20..22].
Frame B is sometimes longer, but just with additional filler bytes in the footer.
It looks like the data is backwards compatible, because buffer[00..18] are the same as before. However, the WheelLog code will discard the longer Frame A packets completely because of the footer check.
Not sure if it makes a difference, but data is received in alternating packets of 20 and then 8 bytes (20, 8, 20, 8, 20, 8, 20, 8 etc)
Here are the different frames (with markup for visibility):
Hi there,
I am working on an Arduino library that reads data from wheels, using some of this excellent code as a reference for my c++ code.
I personally have a new (late 2022) MTen3, and the raw data stream that I see from my device is slightly different from that in the comments at the bottom of the Gotway Adapter.
Frames now come in varying lengths.
buffer[20..22]
.It looks like the data is backwards compatible, because
buffer[00..18]
are the same as before. However, the WheelLog code will discard the longer Frame A packets completely because of the footer check.Not sure if it makes a difference, but data is received in alternating packets of 20 and then 8 bytes (20, 8, 20, 8, 20, 8, 20, 8 etc)
Here are the different frames (with markup for visibility):
Once I have my code in a better state, I will help decode what the additional data might be! But in the meantime, just a heads-up :)
Some raw data from my wheel (just sitting still beside my desk):
Here is some raw data, but in the 20/8 format that is is actually received: