decocare bolus ack

mmeowlink and Carelink stick do slightly different things:

Carelink always returns a payload, even when no payload exists, apparently to convey error status?
Mmeowlink exposes the acks per frame, but we observe no payload in the RF, therefore we generate a fictitious 64 byte null payload.

I've seen following successful fictious payloads from Carelink usb: 0x00 0x00 0x00 0x0c 0x00 0x0c

I've seen the following unsuccessful failure payloads from Carelink usb (eg exceeding the max bolus limit): 0x09 0x09 0x09

Please do special testing on this, it's related to https://github.com/openaps/decocare/issues/4

Oct 27 '16 23:10 bewest

We should probably test this with SMB.

Apr 17 '17 20:04 scottleibrand

Looks like this will require updating the various bits of oref0 that accommodate the mis-spelling of receive, and general testing that it doesn't break anything. I think we'll probably want to start working on that right after we release oref0 0.5.0.

Jul 11 '17 02:07 scottleibrand

Turns out the "recieve" hack was already removed from oref0.

Created https://github.com/openaps/decocare/tree/0.1.0-dev and https://github.com/openaps/oref0/tree/decocare-0.1.0 to test this.

Jul 17 '17 01:07 scottleibrand