Pod insulin level prevent bolus
A pod can be overfilled. I've been able to get approximately 10 extra units in a pod. Today I tried to bolus & because of the estimated amount of insulin left in my pod, it wouldn't let me bolus & use all the insulin.
Reporting bugs
- Note the precise time the problem occurred and describe the circumstances and steps that caused the problem
- Note the Build version (found in the About dialog in the app, when pressing the three dots in the upper-right corner).
- Obtain the app's log files, which can be found on the phone in /storage/emulated/0/Android/data/info.nightscout.androidaps/ See https://androidaps.readthedocs.io/en/latest/EN/Usage/Accessing-logfiles.html
- Open an issue at https://github.com/nightscout/AndroidAPS/issues/new
@crizz6396
- What Omnipod? DASH or EROS
- does this work with you the standard PDM
- What does the Omnipod manual says about the max fill?
- what error do you get?
- Please share log files, if you need support
I'm using the dash but I have done this with the Eros pods as well. (I've only used dash with aaps)
The max fill listed in the manual is 200. The limitation is only when trying to bolus. It's an actual warning from aaps stating "there isn't enough insulin to bolus".
However, if I wasn't bolusing, the pod would continue until it was empty. There is no way to know exactly how much insulin is in the pod. So aaps needs to be able to take the bolus entered & if the pod empties in the middle of a bolus, then only record that amount.
I've actually put so much insulin in a pod that it started coming out of the canula before it primed. I use a lot of insulin so I always over fill to get my 80 hours.
I have seen this as well with Dash, if remaining amount is less than bolus amount it will prevent bolus. With Eros in 2.8.2 we could definitely bolus out the remaining amount "blindly" to empty the pod, i.e. if remaining amount was 4U and we tried to bolus 10U, it would start delivering, then scream when empty, and the actually bolused amount reported back would be more than 4U, often as much as 8 or 9U. We did not have any issues with highs after those pod changes, so the insulin was there.
I don't remember if I have tried this with Eros on 3.0 version but I suspect this is a Dash issue only, same as the Dash calculating the prime amount into "total delivered".
I think this is less to do with total amount added to pod when filling, and more to do with how AAPS responds to the pod reporting remaining amount. The pod has a "trigger point" where 50U is left, which is where it starts counting down remaining amount, no matter if you initially filled 75U or 220U. Total delivered is an AAPS calculation adding together all the insulin given since last pod change through bolus and basal.
So when pod tells AAPS that "remaining amount in reservoir is 4U", then AAPS decides what to do with that information. For Dash it appears to calculate against this and prevent bolusing a larger amount, but not for Eros I think. I've asked in the discord group to see if anyone else knows whether it's possible for Eros.
This check is on purpose. If the pod reports that it does not have enough insulin, bolus is not started.
The amount of insulin reported in the pod isn't accurate, until the internal mechanism hits the dead stop it will continue to give insulin.
Yes, I agree, the estimated insulin left is not accurate, there will still be 4-5 units left (at least with Eros that was the case), so that estimate should not be used to qualify the bolus. It would be better if it could be like the Eros logic, to let the bolus start and run until the pod reports that it is truly empty (pod fault reservoir empty), then update the actually delivered amount like it would if we pressed stop during bolus.
I like this idea in theory, But I have some reservation about how accurate the insulin delivery is by the pod when it is reporting below 0 units in the reservoir. I used to do this all the time with my Medtronic pumps, but I have only once or twice let the Dash pod run for hours past zero, and my blood glucose was unusually high at the end when it finally stopped. I haven't done this often enough to really get a gauge of whether that was just a coincidence.