Loop - a disturbing thing I saw today

Tips, Tech & Gear Treatment
1

Hello my FUD Loop people. I apologize for missing many of you, but I am tagging a few that I know for sure are using Loop.
@TomH
@ClaudnDaye
@Trying
@bkh
Please feel free to add others who are currently using Loop…

Now the problem. A very troubling thing to see.

I set a zero basal in my profile for 7am-8am for this morning. I checked it and double-checked it, and triple checked it. Plain as day, 7am-8am, 0.0 units basal. I synchronized my pod. Again and again, just to make sure.

The night before - new basal rate has been set, pod is synched. All good, right?

Race day. The gun is at 7am.

I am going with open Loop. No phone with me during the race and no Dexcom. I am just using syringes and a BG meter.

The 7am-8am zero basal should work, because that is what my basal profile is set for. I checked it over and over, and the pod has been synched with the new basal profile.

I assume I will have zero basal for the race. That is all I need Loop to do - just honor the basal profile I have set!

Did I miss anything?!?!

So I was surprised to see a 45 on my BG meter right after I finished. Whuh?!?!

I wanted to check into it a bit, so I looked at my Apple Health data. And this is what I saw.

Hugely disappointing and surprising.

image

So as far as I can tell, from 7am-8am it did not give me zero basal, it just kept spitting out the 0.7 units, which happens to be the rate that was set for 5am-7am.

Did I miss anything?

As it stands, the only way I will ever know for sure that I have a zero basal with Loop is if I peel the pod off right before the gun. And I think that sucks.

I mean, I can do it that way. But I should not have to.

8 Likes
2

TL;DR: The solution is don’t schedule a 0-basal ahead of time. Manually start a temp basal of 0 at the time you want all automated delivery to stop.

Setting a zero basal in the schedule doesn’t turn off Loop’s automatic corrections for predicted highs (either via temp basal or microbolus, whichever strategy you have selected.) If you schedule a 0 basal but Loop thinks it sees your BG starting to rise, it will give insulin to bring the BG back down. I could imagine that your basal is so finely tuned that 0.7 is what you would actually need to stay level, so that’s what Loop did despite your scheduled 0-basal.

The reliable way to turn off all automated insulin delivery in Loop is to tap the pod symbol in the upper right, select Set Temporary Basal Rate on the Omnipod DASH page, and set the rate of 0 for whatever amount of time (in half-hour increments) that you want. This can’t be scheduled in advance, it’s something that takes effect immediately. But if you set a 0 basal this way, there will be no automated insulin dosing of any kind, in my experience. It doesn’t prevent a manual bolus that you enter via Loop, and entering a manual bolus doesn’t restart the automated insulin deliveries before their timer expires. (Of course you can navigate to the Omnipod DASH screen to cancel the temp basal, thereby restarting automatic dosing, at any time.)

This is my understanding and also my experience, as of the version of Loop-dev I’ve been using for a while now. I’m guessing it also works in the current Loop-main 3.2.2, but I haven’t checked that. I also don’t know whether or not this feature is present in whatever Loop version you have based your mods on.

6 Likes
3

Wow, scary, Eric! I think the explanation by @bkh helps me understand why this happened. Would Loop provide automated dosing even though Eric had it in Open Loop? I thought Loop would only provide the scheduled basal during Open Loop. I never use Open Loop, so I am not sure. I do use the Overrides all of the time and Loop does continue to process predicted BG and apply the algorithm of choice as you describe using the Override values in its calculations.

I’ve not used the Set Temporary Basal Rate but what you describe does seem to be the safest for no automated dosing. I didn’t know this existed! I’m using the main branch v3.2.2 for OmniPod Eros, and it does exist just as you describe.

I suppose another option would be to use the “Suspend Insulin Delivery” which is a feature also on the OmniPod page but appears to be only for a maximum of 2 hours.

1 Like
4

I am not carrying my phone with me, so I can’t do a zero basal right before the gun.

It was open Loop though, not closed. So it should strictly be following the programmed basal rates, not making adjustments.

On top of that, the phone was not even with me, so it can’t possibly be making changes based on BG.

It’s not that long. :joy: Read it! Please!

Big point though is that I am not running with my phone, so I can’t really do a temp basal right before the gun. I left my phone behind about 45 minutes before the gun.

2 Likes
5

I had forgotten about that kind of override (on the heart symbol at the bottom of the Loop screen) because I don’t use it to prevent insulin delivery because it does continue automated dosing as you describe. I’ve edited my original reply to rectify this.

1 Like
6

Can you start the zero basal a little bit earlier? I thought you usually stopped insulin dosing an hour or two ahead so the IOB would drain out of your system.

Agreed. In that case I have no idea what went wrong. Maybe you could tap on the Insulin Delivery graph to see the table showing the reason for each dose Loop gave. If it says basal, that looks like something went really wrong. If too much time has passed since the incident, the info might still be available in the issue report, but that’s tedious to read.

2 Likes
7

No, for races I do it right at the gun.

8

I was referring to my post, not yours. I put that brief summary at the top of my post when I re-read it and got the feeling I had been rambling as I tend to do.

1 Like
9

Hope you had a great race, @Eric, despite the insulin dosing mishap! I know you are always prepared and hopefully had extra carbs on you!

1 Like
10

Can you tell me how to get to that? I’m not sure where it’s located.

11

@Eric It would be a real pain to pull off a pod and would inhibit proper training unless you did it pull it off constantly.

That’s really scary, I use temp basal all the time. I can’t imagine programming something and it deciding to give a dose anyways while I’m giving myself a shot to cope with it. Is it something new that was in an upgrade or do you think it has been doing it before? If you have been using the system before and it hasn’t done it before, why this time? And if it’s arbitrarily randomly done, that’s even scarier.

I don’t loop yet. But the potential problem is pretty big. I aim for higher blood sugars for certain things and would not want something overriding my decision without reprogramming the entire thing.

But that brings me to the next question. How easy would it be to set a new much higher BG goal at the start of race time, so essentially you are turning off your basal insulin? You know how you can set a different goal for a different time? Would that work? Then you just have to remember to turn it back.

1 Like
12

Thanks @Trying!

It was okay. I don’t know if the low BG impacted me at the end, but I felt okay. Just tired. But I expect to be tired at the end, so I don’t know if it was a big deal.

2 Likes
13

I’m not familiar with Loop. I used AndroidAPS which is genetically the same code but is maybe now a different species.

It strikes me that AAPS is too complicated by far to be failsafe. So, yes, open loop in AAPS should defer to the programmed (profile) basal which should have given you zero in this case, but that’s a lot of settings to go wrong.

In AAPS the answer may be to turn off the loop, “Disable Loop”, big red circle with X in the middle.

My approach is to always carry my 'phone and when the shebang explodes (normally because my 'pod lobs off) go back to Lantus (eewhu) and Fiasp.

1 Like
14

I don’t have my phone with me. And I am open loop, not closed. So there is really no loop responding to a BG reading, it is just giving me the pre-programmed basal rate. Which in this case was supposed to be zero!

Which brings me to my complaint. I mean, with all the bells and whistles Loop has, is it too much to ask that if I have a pre-programmed basal setting and I am in open loop, it should just give me the basal amounts that are programmed?

Like that is the very basic lowest expectation for a pump, isn’t it?!? If I say X units per hour for this particular time, that should be what I get. No CGM, no closed loop, just give me this certain amount for this hour. That should be very basic functionality.

I dunno, sometimes it seems like I am the only one who ever runs the thing in open mode. :man_shrugging:

1 Like
15

@Eric Do you usually run closed loop at night? I am wondering if you switched to closed loop whether it would work. I just don’t know about loop enough.

You wouldn’t need your phone with you if it lets you do it. In my eros pdm in settings, you go to target BG level and it lets you set the target level you want at the time frames you want. So you would be able to change the goal BG level at any time during the day. In this case only between 7-8 am. And then change it back after. So I am wondering if in closed loop you could set a high BG level goal at a specific time frame?

That’s if you can do that with loop. But if you set your target level up to 200. It might virtually turn off your basal rate? I’ve never used loop so I might be dreaming lol. And I don’t know if using closed loop brings other issues into the mix.

1 Like
16

I am Looping with Dash pods. You would need your phone to do it that way. There is no direct CGM reading between the pod and the sensor like there is with the Omnipod 5 pods.

Yes, the only time I run closed loop is at night. When I am awake, it’s open!

1 Like
17

The issue report is in Settings (the gear icon lower right) > Support > Issue Report

The Issue Report is an enormous text file containing logs of all the settings, software versions, and basically everything that Loop saw and did. You should be able to save it in the phone files, or export it via email to yourself or something suitable. I think the timestamps are GMT, so you’ll have to adjust by I think 4 hours for Eastern time. Anyway, somewhere in there I’d guess you should be able to see Loop receiving the new basal schedule from you, and sending the new basal schedule to the pod.

2 Likes
18

Your programmed basal should have been employed. This is a great question to ask on the developer thread in Zulip.

3 Likes
19

@Eric I don’t do what I consider a lot of changes of the type you mention. And to determine the potential reasons would need to know the type (Dev/Releaseed and version number you’re using. What I recall is that if you separate the phone from the pod for an extended period, the pod reverts to the programmed basal rates, i.e. any temps you had set go away. @bkh may have it better than I do.

As usual, if you want the expert rationale, post on GitHub forum. Depending on when the event was, they may want a sysdiagnose from your phone in addition to the issue report @bkh mentions, to run it to ground (no pun intended).

Sorry you had the issue.

2 Likes
20

This is more “catharsis” than asking for help…but if you’ve got ideas I’d gladly listen…

Something odd happened last night, not quite sure why or what I should have done. I had what for me is a normal meal, albeit I had breakfast for dinner. Triple-zero yogurt, oz of blackberries, oz of raspberries, oz of strawberries, and an “Egg McMommy” (what we call it - English muffin, fried egg, 2% cheese slice, thin ham); 34 carbs all in, 20 is the muffin. As I’m terrible at pre-bolusing (shy of 10 minutes), I’d normally go up to 150 (I blame the muffin, the fruit doesn’t impact that much). About 45 min later, I notice Loop had me at 3.4 IOB and wanting to add to it; I was headed down for the count per my G6 and Loop! I turned insulin off, took two glutabs with almost no effect 15 mins later, was at 71 still headed down. Had three swallows of my wife’s 100% grape juice, again almost no effect 15 mins later. After an hour I came up to 126, expected it to climb do to the extra carbs took, instead it curved back down to 85, back up to 108 an hour, back down to 70 straight down arrow, abruptly back up to 127, then back down to the mid-upper 70s in another 2 hrs and skidded across there until 6am this morning. Alerts (set below 80 so I can treat if warranted) went off regularly until 2am; to avoid further disruption to “she who must be obeyed” (I love her dearly!), I moved to “sleep” in a chair downstairs, though sleep was fitful at best. Finally crept up to 100 from 4:30 to 6, got actual sleep until 7:15am. I’ve no idea what caused it, hope not to repeat the night in future. This morning I had my regular breakfast (yep…yougurt, fruit, eggs); normally would go up to 140-150, I’ve been over 200 for an hour+ trying to get down without causing a low. Not at all sure the two are connected. Will be a while before I do breakfast for dinner again (ok, probably not that long, but…)! T1…gotta luv me!

3 Likes