This is one of the biggest reasons I don’t commit to that sort of stuff fully. The fact that my Dex and BG numbers are off by so much, and by such a large number. I normally correct a high or low before Dex has any clue it is happening.
2 Likes
I normally ignore the errors and just use the G6 value, so that’s not exactly the opposite of what you do (since we both do corrections) it’s just that I use the G6 by default and only do a fingerstick when I have doubts about the accuracy. After the first 24 hours I normally get ceil(+/-20mg/dL, +/-20%) so this means I can’t do corrections below 100mg/dL, since I would end up bolusing when my BG is 80mg/dL.
My new sensor is now back in line, after pogoing for about 8 hours (including the 2 hour I-known-nuttin phase).
My hope is that the Insulet engineers, having signed their productive life away in the NDAs, will have some fallback algorithm for the first 24 hours similar to the one you documented. E.g. they could use a standard basal for the first 24 and only correct if there is fingerstick evidence to support it. I’m pretty sure that could be modified over time on a per-person basis because it seems clear that some people get better early G6 than others, indeed some get better later results as well; I start to get dropouts towards the end of the 10 days, restarting a sensor is unattractive for me to say the least.
2 Likes
I think they will leave it to the users to choose to open the loop during the first 24 hours, and then choose to close it after their sensor settles down.
If they have a different algorithm for the first 24 hours, that is implicitly saying that the sensor values are not reliable.
And they can’t admit that they are using something “unreliable” to choose how much insulin to give. Dexcom is always perfect! It is the gold standard for BG measurements. Throw your meter away! Dexcom is always right!
4 Likes
Here’s the user guide and other information:
https://www.omnipod.com/current-podders/resources/omnipod-5
Based only on the QuickStart guide:
It does have a “manual” mode, CGM not required but if present the data is read and stored. In automatic mode manual (not bolus-calculated) boluses are supported. The bolus calculations do take into account the BG trend.
Manual mode has all the goofy Insulet features, e.g. different basal programs (I only ever use that when switching to Lantus.)
No extended boluses in Automatic mode. I know this is a feature that puzzles Loop developers, but I’m currently using it to deliberately slow down bolus delivery. I guess I can just not bolus and wait for the CGM readings to initiate correction boluses.
Switching to manual mode is something that can be done and undone as required, so an extended bolus can be done that way. So far as I can tell “manual” mode is actually open-loop; the “SmartBolus” calculator is always available and that apparently uses the same algos in both modes, in particular the bg trends.
The “activity” feature is not automatic. It just sets the target BG to 150mg/dL - not much use for scuba when the target should at least 180, maybe 200. I don’t think I’d use it for skiing either, that’s a lot more exercise and requires gentle corrections so I might.
“Pause insulin delivery” still pauses for ever. Duh. I trust they kept the Dash ability to set a 0 basal.
The UI seems to have been cleaned up a little; a little clearer. I hope they’ve fixed the oh-so-busy-you-can’t-use-it history screens. (Bullet points are not data, they are marketing.)
3 Likes
Page 279 of the user guide (ooh, I love indices) [slightly reformatted for clarity, caps per authors, emphasis added]:
• SEARCHING FOR CGM: When the CGM is active and connected to the Omnipod 5 Pod but the most recent CGM value was not acquired within the 5-minute window. There may be no valid CGM value available due to a Pod/CGM communication issue or a temporary CGM sensor issue recoverable
without any user action). Tap MORE INFORMATION for recommended action. Review Pod and CGM placement. Pod and CGM should be at least 3 inches (7.62 cm) apart and within line of sight.
• DEXCOM ISSUE DETECTED: When CGM values are not available due to a sensor error (including sensor expiration). See the Dexcom G6 app for details. No action is required within the Omnipod 5 App
• TRANSMITTER ERROR: When the transmitter connected with the Omnipod 5 System has expired or experienced a non-recoverable error. Tap NEED HELP for potential causes and recommended actions. To set up a new transmitter, see “20.3. Connecting the Transmitter” on page 283.
• TRANSMITTER NOT FOUND: When the Pod tried to connect with a transmitter but after 20 minutes was unable to do so. Tap NEED HELP for potential causes and recommended actions. See “26.3. CGM FAQs” on page 332 for additional information.
Seems to cover all the well known bogosities. I agree Insulet is being quite deferential to Dexcom, as one must with one’s partner, but I particularly like “DEXCOM ISSUE DETECTED”. Will they have to issue release 2 of the manual when the Dexcom marketing bods read it? Nope, that manual is 378 pages; no one will read it.
Unfortunately:
Pod and CGM should be at least 3 inches (7.62 cm) apart and within line of sight.
No solution to the Bluetooth Body problem then and since the human body is curiously curved an apparently unmeetable requirement. Hum, CGM on left inner thigh, Pod on right inner thigh; my now departed endo recommended against that.
4 Likes
@Eric feel the TSlim force… I have an extra if you want to road test one
4 Likes
As soon as they take my PDM away…
Seriously, some of this stuff is annoying. An exercise target of 150? Have they read nothing on FUD?!? Your target for exercise should be no higher than 100. Sheesh! 
5 Likes
My latest scraping from the Insulet website:
The SmartAdjust™ Technology is able to respond to high glucose levels by increasing insulin every 5 minutes to bring glucose down to target. Omnipod® 5 delivers a microbolus of insulin every 5 minutes to correct blood glucose using the user’s customized glucose target of 110-150mg/dL.
From the FAQ. Custom range from 110-150. Seems like they should be advertising this more? Would be nice if it were 90 or 100, but I still like variable ranges.
Automated Mode: Limited
• Pod is not receiving CGM values
Implication from the user guide is the CGM is connected to the Pod, not PDM.
Can I use my Omnipod System PDM and Pods with the Omnipod® 5 System?
The Omnipod® System and Omnipod DASH® Pods/PDM are not compatible with the new Omnipod® 5 System. The new Omnipod® 5 Pod includes an algorithm for automated insulin delivery and the controller software is specific to the new Pod. In general, the Omnipod® 5 Automated Insulin Delivery System uses its own Controller and Pods.
From the FAQ, new PDM for 5. Not sure why? Since its just a new program. Its all free anyway.
3 Likes
Omnipod® 5 delivers a microbolus of insulin every 5 minutes to correct blood glucose using the user’s customized glucose target of 110-150mg/dL.
I wonder how much control people have over how much insulin it gives. Certainly that has to be something that is based on an person’s correction factor (CF).
But if it only gives X% of a person’s CF, and that isn’t enough, what will happen? The person will just lie about their CF. Instead of saying 1 unit brings them down 100 points, they will say 1 unit only brings them down 50 points.
So people will end up playing a game of 2 different values - real numbers, and numbers they tell the pump.
The current version of Loop’s FreeAPS is great in that you can put in whatever values you want for correction amounts. As aggressive or conservative as you want it to be, and any target BG you want.
1 Like
I don’t think its that precise. My experience on closed loop is only 670, but this is how medtronic trained patients: Overbolus, either through a slight overestimation or by manually overriding, and let the algorithm take you back to the 120 target. The bolus would take care of the meal (or correction) and basal wouldn’t kick back in until you were pointed near 120.
So you can overcorrect or fake as much as you want, the pump isn’t going to give you any more insulin until you’re back at the target. And in my mind thats what gets me about all these different competing algorithms, excluding exercise the τ is so long that it doesn’t really matter what your control strategy is.
1 Like
It’s section 18 of the user manual, starting on page 254. It’s got an extensive description of all the limits and, yes, the limits have changed from the Dash PDM. The most significant is that the “target” is limited to a low of 110mg/dL in both manual and automatic modes; that compares with a range of 70-200mg/dL. The “correct above” limit is somewhat misleading, since below the target it’s a reverse correction!
These limits also apply to the closed-loop mode; the loop will try to bounce the BG up so the CGM reads 110mg/dL. (In my experience the G6’s sweet point is 120mg/dL, so this is likely to be fairly accurate for me, YMMV.) 110mg/dL corresponds to an HbA1c of 5.5%, which is the upper end of the normal medical range.
I don’t understand what you (@eric) are saying about the correction factor - it’s the amount 1IU lowers the blood glucose and that is what it has always been. All the PDMs calculate a correction bolus based on that. The G5 now adds the BG trend for both negative and positive corrections. Look at the top of page 263 for the correction factor equation (no, it’s flat too - not variable with current BG!)
That is explicitly stated in the marketing materials (see one of my posts above).
Because the old (Dash) one has a really really bad battery management IC? Because the old one tries to connect to a Chinese ad server? This is a known feature of the hardware Insulet are using, not the Insulet software itself so I don’t know if it can be disabled by an upgrade.
The software has to change radically; even though the UI looks familiar the bolus calculators is now on the pod and, therefore, the PDM has to transmit meal glucose values to the pod rather than transmitting up to four contemporary bolus settings (basal, extended basal, extended bolus, instant bolus). One thing the new PDM doesn’t have to do is be compatible with the G6 because it doesn’t read it directly.
So far as I have been able to determine after a few minutes reading the underlying model hasn’t changed - it’s still a linear IOB decay and it’s still not documented how they deal with more than one bolus active (within it’s action time) at the same time. The target glucose permitted range seems to have changed but nothing else apart from the addition of the CGM trend.
The algorithms are still incompletely documented and the algorithm for the trend is missing. I can guess a common sense solution to the multple-bolus conundrum, but it’s an unattractive one for extended boluses.
I find the thing about including basal in IOB really difficult to understand. It’s in the middle of page 256 but isn’t referenced elsewhere (emphasis added):
Insulin on board
Insulin on board (IOB) is the amount of insulin still active in your body from basal insulin delivery and from earlier boluses. IOB from previous correction boluses is referred to as correction IOB. IOB from previous meal boluses is referred to as meal IOB. Additionally, in Manual or Automated Modes, the Omnipod 5 algorithm constantly calculates IOB from your basal delivery.
Weird; does it include a constant meal-on-board calculation to correct for glucagon mediated release of glucose, or is this just a typo (“basal” when it should be “bolus”?)
1 Like
The automated stuff starts on page 291 of the User Guide. It sort-of-by-implication answers the question at the end of my previous post; the basal rate is learned, so by implication the “IOB from basal delivery” above is actually from the change in the “adaptive basal”; a confusingly misnamed delayed/microdosed bolus…
1 Like
What I am saying is that you tell the PDM what your correction factor is.
So if the Dash system is not aggressive enough for your liking, you may lie to it.
For example, suppose your actual CF is 1:100. If your BG is 220, you would need 1 unit to go down to 120. But Dash may not give you a full unit. It may be too “safe” and only give you 1/2 a unit.
So you lie and say your CF is 1:50. 
There is a difference in them telling you how much to bolus, like giving you a recommendation based on a BG you enter, like they are doing now. And them automatically doing it while you are asleep, and based on your CGM, like they would do in closed loop mode.
I don’t think there is anyway they would automatically use the full bolus amount in their algorithm. It will be some super-cautious number, like 20%.
Make sense?
3 Likes
No, it gives you a full unit, less any IOB. The O5 is apparently the same (according to the formulae); in manual mode it will give you a full unit. In closed-loop mode it is less clear; the “preliminary correction bolus” on page 263 is the same calculation as the manual mode one and the one in the Dash, and it is the obvious calculation. It seems that the calculation in question is used when a meal bolus is done and that it results in an immediate bolus of the calculated amount.
The mystery is what exactly happens in closed-loop mode when BG rises above the target. That’s typically going to happen after a meal, but then there is a lot of IOB. Now the pod is in control - the PDM is completely out of the picture - and it isn’t seeing a final value, it’s just seeing a trend (going up, next floor is Women’s Lingerie and an irritable gentleman with high blood sugar).
I doubt very much that the pod will use the correction factor at all. The User Manual talks about learning the basal rate, but I don’t see why it would not learn the correction rate (not factor) at the same time. To get the basal rate it needs us to flat-line after the food is out of our system or (more, perhaps impossibly, complicated) to calculate the food rate-of-insulin-use. To get to a flat line it needs to tweak the correction micro-doses, an operation that inherently contains the information required for the correction factor and, more important, the correction rate.
I don’t think the pod can safely use the correction factor. Rather I think the pod will accept the bolus calculation from the PDM - plausible deniability there - and then use its own internal algorithms to fix up whatever mess results based on rate-of-change rather than absolute BG.
It does make sense to think that a lower correction factor will induce more aggressive behavior, but I don’t think it will. That said if my assumptions are correct a simple manual bolus will produce the same result.
1 Like
I am reluctant to turn my BG over to an algorithm. I make an occasional exception for allowing the homemade version of Loop to do it when I am asleep, because as good as I think I am at 'betes, when I am asleep I am not paying attention to it.
But when it becomes a total blackbox algorithm that I can’t adjust and can’t even see, forget that!
Which leads me back to this image. 
1 Like
I do think Eric that we are in the early part of these algo’s. I suspect (hope?) that the next couple of versions make these black boxes really really good. You may not need it, but there are so many others that do. I know that once they prove they aren’t killing people the FDA doesn’t usually have a problem letting the companies improve the algorithms. And once there is a huge amount of user data in the company, the engineers get to take their crack at solving them. Unless they are in a very large very risk averse company. Which is why it is great to see smaller companies in the game. So much less inertia. But I do think within 5 years you will likely give yourself over to the black box version 3.0. But as is true in my life, I may be wrong.
2 Likes
Can anyone comment on the difference between 670/770/780? We’re seven years into Medtronic closed loop, they’ve had the opportunity to update the black box if they wanted to (fwiw, I don’t think its a black box just a PID algorithm).
Again, I don’t think the black box is as important as the target. If you can change your setpoint, the way it gets there can be fudged.
1 Like
Part of that solution would be faster insulin, to act, then out, like Afrezza from a pump.
2 Likes
I believe the delay is pretty much down to the adsorption time through the skin. Intravenous insulin doesn’t have this problem and is used for people who are critically ill and suffering from elevated blood sugar. Target BG is actually more aggressive than either the Insulet minimum (110mg/dL) or the fixed value used by Medtronic (120mg/dL). See this article and its references.
So far as I can see the only real answer to the delay, in particular the “out” part, is some other delivery site. This is why Afrezza works; straight into the capillaries. That also explains why there can be great variation in adsorption times, as in sticky highs while asleep, intra-muscular injections and my personal experience that my blood sugar goes high when I drive distances.
A full implantable device, like a pace-maker, seems to be one possibility but insulin supply to the device seems likely to be an issue. Maybe 1000IU/mL insulin would help with that. I don’t know if it would be possible to infuse insulin into a part of the body with an abundant capillary supply, working like Afrezza and avoiding the body defenses that a capillary into a vein would probably invoke.
1 Like