-
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
decoding of insulin sensitivity > 255 is incorrect #21
Comments
I suspect the interpretation of the two bytes is as follows where sx represents bit x in sensitivity and ox represents bit x in time offset from midnight in 30 minute increments. Since the offset ranges from 0 to 47, it only takes 6 bits to represent the offset.
It would be nice to confirm this by seeing a bolus wizard setup that has more than the first (midnight) sensitivity programmed before posting a PR. To accomplish this, I'd insert two lines after line 459 as follows:
|
You're right, the offset needs to be masked by 0x3F, not the 0x1F that I had in my code. Here is such a bolus wizard setup record (from a model 522 pump):
It should decode to this (in my Go code's representation; decocare's is slightly different): {
"Type": "BolusWizardSetup",
"Time": "2017-03-09T12:43:35-05:00",
"Data": "Wg8j6wwJERUhAAYAAAAAAAAAAAAAAAAAAAAjAAAAAAAAAAAAAAAAAAAAeHgMZGQAAAAAAAAAAAAAAAAAAAAAAAAVIwAGAAAAAAAAAAAAAAAAAAAAI2AsbpAAAAAAAAAAAAAAAHh4DGRkAAAAAAAAAAAAAAAAAAAAAAAARA==",
"BolusWizardSetup": {
"Before": {
"Ratios": [
{
"Ratio": 6,
"Start": "00:00",
"Units": "Grams"
}
],
"Sensitivities": [
{
"Start": "00:00",
"Sensitivity": 35,
"Units": "mg/dL"
}
],
"Targets": [
{
"Start": "00:00",
"Low": 120,
"High": 120,
"Units": "mg/dL"
},
{
"Start": "06:00",
"Low": 100,
"High": 100,
"Units": "mg/dL"
}
],
"InsulinAction": "4h0m0s"
},
"After": {
"Ratios": [
{
"Ratio": 6,
"Start": "00:00",
"Units": "Grams"
}
],
"Sensitivities": [
{
"Start": "00:00",
"Sensitivity": 35,
"Units": "mg/dL"
},
{
"Start": "16:00",
"Sensitivity": 300,
"Units": "mg/dL"
},
{
"Start": "23:00",
"Sensitivity": 400,
"Units": "mg/dL"
}
],
"Targets": [
{
"Start": "00:00",
"Low": 120,
"High": 120,
"Units": "mg/dL"
},
{
"Start": "06:00",
"Low": 100,
"High": 100,
"Units": "mg/dL"
}
],
"InsulinAction": "4h0m0s"
}
}
} |
But I don't think the sensitivity uses 10 bits (0..1023); I think it uses only 9 (0..511), namely bit 6 of the first byte as the high-order (9th) bit, and the 8 bits of the second byte as the low-order 8 bits. The x22 pump has a max sensitivity of 400, and the x23 has a max of 500 IIRC. Do any newer pumps allow > 511? |
Yes, the sensitivity schedules returned by the 0x8B pump comand are encoded the same way as in the bolus wizard setup (0x5A) history record. They're handled in 2 different places in decocare, as you noted. |
I suggested including the two bits from offset simply because it seemed odd to only use one of them. Since the time offset in 30 minute intervals can always be handled in 6 bits and there is no theoretical upper limit to insulin sensitivity, it made sense to me to use both spare bits. But I readily admit that it is just guess work. As far as a use case, someone using u500 insulin in the pump would want to program a sensitivity and carb:in that are 5 times higher than for u100 insulin. As far as I know, though, the limit in Medtronic pumps is a sensitivity of 400, which can be encoded with 9 bits. It would be interesting to see what kind of numbers Carelink spits out when the bit in question is set. Unfortunately, I don't have the desktop version of Carelink on any of my current computers, so I can't test it. |
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 the 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). The bug is in history.py, line 459.
The text was updated successfully, but these errors were encountered: