Checksums not always on r[:-1] ?

[brainstorm]

I've noticed that checksum errors are intermittent, mostly on the very first transaction, not very deterministic though, after a few tries it does not complain anymore. But that one caught my eye, it happened in the middle of a large conversation:

<-- ['a4', '03', '40', '00', '01', '05', 'e3']
Receive packet: array('B', [164, 9, 79, 0, 62, 97, 14, 0, 0, 0, 0, 0, 179])
9
Checksum: 179
<-- ['a4', '09', '4f', '00', '3e', '61', '0e', '00', '00', '00', '00', '00', 'b3']
--> ['a4', '09', '50', '00', '3f', '80', '0e', '00', '00', '00', '00', '61', '2d']
--> ['a4', '09', '50', '20', '00', 'c7', 'ea', '4d', '00', '00', '00', '00', 'bd']
--> ['a4', '09', '50', 'c0', 'ff', 'ff', 'fe', 'ff', 'ff', 'ff', '00', '00', '3c']
Receive packet: array('B', [164, 9, 78, 0, 62, 97, 14, 0, 0, 0, 0, 0, 178, 164, 3])
9
Checksum: 164
Traceback (most recent call last):
File "fitbit_client.py", line 132, in
sys.exit(main())
File "fitbit_client.py", line 128, in main
f.run_upload_request()
File "fitbit_client.py", line 113, in run_upload_request
self.info_dict["opResponse[%d]" % op_index] = base64.b64encode(''.join([chr(x) for x in self.fitbit.run_opcode(o["opcode"], o["payload"])]))
File "/home/romanvg/dev/libfitbit/python/fitbit.py", line 233, in run_opcode
data = self.receive_acknowledged_reply()
File "/home/romanvg/dev/libfitbit/python/antprotocol/protocol.py", line 205, in receive_acknowledged_reply
status = self._receive()
File "/home/romanvg/dev/libfitbit/python/antprotocol/libusb.py", line 85, in _receive
raise ANTReceiveException("Checksums for packet do not match received values!")
antprotocol.protocol.ANTReceiveException: Checksums for packet do not match received values!

Oh, btw, I may inadvertedly dumping my steps on your account, since I haven't change the UUID or anything (using the one that comes on the script itself.... sorry :-S).

[qdot]

In terms of the checksums... I think this may be because I'm not clearing things correctly between transactions (runs of fitbit.py or fitbit_client.py), so we get truncated replies or replies from older commands, which don't line up correctly. It's still one of the major bugs that's holding up a more serious release.

And don't worry, you're not dumping steps into my account. The client ID in fitbit_client.py is a random uuid I generated. That identifies the base station that the information was received off of, but doesn't identify the username/tracker to upload data from. You'd need my actual tracker serial to do that, and the tracker serial is only 5 bytes, not a UUID. :)

[brainstorm]

Hi again Kyle, thanks for the explanations... just for the record, I usually get this one on the first run:

; fitbit_client.py
Receive packet: array('B', [1, 111])
Checksum: 1
Traceback (most recent call last):
File "/home/romanvg/.virtualenvs/devel/bin/fitbit_client.py", line 7, in
execfile(file)
File "/home/romanvg/dev/libfitbit/python/fitbit_client.py", line 132, in
sys.exit(main())
File "/home/romanvg/dev/libfitbit/python/fitbit_client.py", line 128, in main
f.run_upload_request()
File "/home/romanvg/dev/libfitbit/python/fitbit_client.py", line 99, in run_upload_request
self.fitbit.init_tracker_for_transfer()
File "/home/romanvg/dev/libfitbit/python/fitbit.py", line 185, in init_tracker_for_transfer
self.init_fitbit()
File "/home/romanvg/dev/libfitbit/python/fitbit.py", line 168, in init_fitbit
self.fitbit_control_init()
File "/home/romanvg/dev/libfitbit/python/fitbit.py", line 163, in fitbit_control_init
self._receive()
File "/home/romanvg/dev/libfitbit/python/antprotocol/libusb.py", line 84, in _receive
raise ANTReceiveException("Checksums for packet do not match received values!")
antprotocol.protocol.ANTReceiveException: Checksums for packet do not match received values!

Then afterwards (usually on the second run) it hangs as described on issue 6 (on that same last packet).

I wonder why the reset() calls on fitbit.py's init is not enough to reach that clean state between runs... are there more opcodes to be reversed to do proper resets/initializations :-?

[lawnjam]

Sometimes you end up with a single ANT message split across two USB packets - could that cause this error?
The ANT checksum is getting checked in protocol.py too, so it should be fine to remove the test from libusb.py (unless I've misunderstood and this is a USB checksum?)
Also, the code in protocol.py checks the ANT message length, so it should always end up doing the checksum with the right data.

[qdot]

Totally could be part of it, yes. I need to make message handling more robust.