I can't figure this one out.
hoping this jumps out at someone and they know how these check digits are being calculated.
Tried the usual suspects... modulo 256, etc.
I don't have access to anything... reverse engineering this one.
Here are the patterns I have fed it and what I get back:
1111111111111111 = 0x6F
2222222222222222 = 0x7F
3333333333333333 = 0x8F
4444444444444444 = 0x9F
5555555555555554 = 0xAE
5555555555555555 = 0xAF
Anyone have an idea what is being used to calculate the check digit here?
What do you mean by 1111111111111111, is this ASCII string, or a decimal number (in uint64_t, for example), or maybe a hexadecimal number?
Any possibility it's a CRC? Try the few usual CRC8 variants online here:
https://crccalc.com/
Sorry, yes those are ASCII strings.
I actually tried crccalc and a few other sites already.
Nothing matched up.
Attached is an example of 2222222222222222
The first 4 are the command... basically read 16 bytes starting at 0x10 followed by what must be a check digit and an ack.
This is the only value that changes depending on the 16 bytes of data read.
I think I got it, at least it matches the few examples you gave.
It just appears to be a simple 8-bit checksum of the 16 ASCII digits, plus the leading 'W' (0x3F), 0x10 and 0x10. The second character, the question mark, is apparently not part of the checksum.
So:
0x3F+0x10+0x10+16*0x31 = 0x6F (mod 256)
0x3F+0x10+0x10+16*0x32 = 0x7F (mod 256)
...
0x3F+0x10+0x10+15*0x35+0x34 = 0xAE (mod 256)
0x3F+0x10+0x10+16*0x35 = 0xAF (mod 256)
That looks to be it. Thanks mate you spotted it and it works.
It's from the second byte (the question mark) but I got what you were saying.
Cheers.