-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
parsing BolusWizard records depends on BG units #8
Comments
issue is descripted here https://gitter.im/nightscout/public?at=57ee9c4fc512d9653a5800e7 |
attached treatments for this day by calling |
My 715 (mmol) 2.3 FW has the same error. SVG from NS and temp basals are sent to the pump and displayed at Nightscout. I use units conversion, but notice that the bolus wizard from the pump is doing a double conversion somehow. BG entered was 3.7 mmol, which shows as 37, and is plotted as 37/18= 2.1 in Nightscout. https://dl.dropboxusercontent.com/u/24731481/pump.jpg |
The pump is in mmol - low/high set as 5/6 - pump. pump-history.json converts the low/high incorrectly as well. When I entered 5.1 in boluswizard as SVG it appeares as 51 in pump-hostory.json |
The BG and carb units are already contained in the bytes sent back by the Carelink stick. The key is in the second byte of the message body part. After several tests, I found the following piece of code to be working in order to decode BGs, carbs, BG targets and carbs sensitivities (I can't seem to get the insulin sensitivities right though, since no other byte seems to change when their value surpasses 256 mg/dL/U):
Hopefully this makes sense! :) Might be useful to know I have only tested this on a 722. I don't know what happens when bolus wizard records are larger, as stated in decocare... |
Has anyone still issues with this? @bewest might wanna see this? |
Thanks for working on this. I was able to confirm your findings -- I think it's easier to understand by just saying that the BG units are in bits 7:6 of body[1], and the carb units are in bits 5:4. Both 2-bit fields should hold the value 1 (grams, mg/dL) or 2 (exchanges, mmol); 0 and 3 are illegal. |
Do you have any idea whether BG units are encoded somehow in 0x0A records (CalBGForPH in decocare terminology)? There is a lot of data that we're not using, so I suspect it's in there. |
Never mind, I figured it out. BG units are encoded in bits 6 and 5 of the 4th byte (the same one that has the hour field of the timestamp in the low 5 bits, and bit 9 of the glucose value in the high bit.) |
I'm glad you could confirm this. Have you got any idea how to correctly decode ISF for values higher than 256 mg/dL/U? When set past this point, the corresponding byte just jumps back to 0, and then starts going up again, without any other one indicating the highest value for said byte has been reached (at least, I didn't see any yet...). |
I've found the extra bit for insulin sensitivities > 255: it's bit 6 of the previous byte. For example, here's a bolus wizard setup record in which I change from sensitivity 35 to 400 (the max on my 522 pump): 5A 0F 1C C6 11 01 11 15 21 00 06 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 23 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 78 78 0C 64 64 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 15 21 00 06 00 00 00 00 00 00 00 00 00 00 00 00 00 00 40 90 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 78 78 0C 64 64 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 44 You can see the "00 23" in the "before" section', which changes to "40 90" in the "after" section. When that bit gets set, it breaks my decoding of the sensitivity schedule (since that bit is set in a byte that's used for the start time of that sensitivity and needs to be masked off). It looks like this bug is in decocare too (history.py, line 459) |
A user of a 753 pump is using mg/dL for BG units, so it is possible to change the units on at least some pumps that have MMOL_DEFAULT = True. As a result, his BolusWizard records are being parsed incorrectly, due to
https://github.com/openaps/decocare/blob/master/decocare/records/bolus.py#L141
I think the correct fix is to do a ReadBGUnits call during session initialization, after ReadPumpModel, and to use this dynamic value rather than a static default when decoding records.
The text was updated successfully, but these errors were encountered: