-
• #2
For one, you're trying to manually handle endian conversion, and you've ended up tying yourself in knots. Funnily enough, I'm pretty sure your checksum routine is getting the right answer!
First: the CASIC packet format is 0xBA,0xCE,2-byte payload length,class,id,payload,uint32 checksum. All little-endian. The example packet you have in the comment right above your test() function has this backwards.
So for your example packet (class=5, id=1, payload=[6,0,0,0]) it should look like BA,CE,04,00,05,01,06,00,00,00. The checksum bytes at the end are 0A,00,05,01. And that is 0x0105000A.
function casic_checksum(id, cl, payload) { let buf = new Uint8Array(4+payload.length); // Varying field sizes is what DataView is for let dv = new DataView(buf.buffer); dv.setUint16(0,payload.length,true); dv.setUint8(2,cl); dv.setUint8(3,id); buf.set(Uint8Array(payload),4); // jazz hands return Uint32Array(buf.buffer).reduce((a,b) => a+b, 0); } function test() { let c; c = casic_checksum(1, 5, [6, 0, 0, 0]); print("test1 - expecting 0x0105000A"); print(c.toString(16).padStart(8,'0')); print(""); print(""); print(""); c = casic_checksum(0, 6, [1, 7, 192, 8, 0, 194, 1, 0]); print("test2 - expecting 0x08c7c909"); print(c.toString(16).padStart(8,'0')); }
Hi All,
I am trying to write a checksum function for the Bangle 2 GPS but getting a bit confused over byte orders.
What we have on Bangle 1 - is a function called writeGPScm() where you pass in the command payload and it works out the checksum.
See below.
The checksum calculation for the Bangle 2 - AT6558 is a bit different (see screenshot of spec below).
@Mark_M has managed to parse a couple of CASIC commands from the GPS and collect the checksum values that the chip is sending - so these make good test cases.
This is how far I have so far.
And the output of the tests are:
As can be seen the output for the checksums is coming out reversed.
But this maybe because the least significant byte of the checksum is being sent first by the chip.
In the spec there is the statement:
(the one received first is in the low order)
So it could be that when we parsed the cip output we needed to take the first byte received of the checksum as byte0.
Wondering if anyone else has looked at this and can see a better way of doing it.
I tried converting the payload into Uint32Array but inside its basically still a list of bytes 0 they are not guaranteed to work the way C uint32s work in terms of overflows etc.
1 Attachment