The Loop is still considered a “hybrid” artificial pancreas system in that it requires user input for meal doses and larger corrections. The Loop excels when it is “in the zone” and makes small insulin nudges to keep the blood sugar in a tight range, like the 3/25 overnight line.
If I wake up and I’m above 140 mg/dL, I will correct. I’ve found that Loop can not pull down a BG when it rises and stays at over 150 mg/dL or so. I’ll often take a dose of Afrezza or a syringe delivered correction in this case. I try to record these “external corrections” by entering them into my Dexcom receiver but sometimes during the night I forget.
I use the Dexcom Clarity program to analyze. But that doesn’t include pump data and I am getting by without using that data for now. In the past I’ve used Diasend, when I was using my Ping pump. I’m thinking about setting up the NightScout system so I can get a fuller picture that uses all my data.
I’m finding this as well. It’s a little frustrating. It’s still new, so I feel like we’re still learning, but it’s helpful to hear that you have this experience.
Thanks for your responses @Terry4. A bit disappointing that it can’t deal with BGs over 150. Is this connected to the rise rate, i.e if it creeps up from a bedtime of say 5.5 to 150/9 over 3 or four hours, will Loop deal with it at the early stages? I often find that my overnight BGs will drift down slightly on the first day of a set and drift up slightly on the second day (I am on a 2 day rotation). It would be nice to deal with this (I suppose I could set a different TB on the two night, but have never bothered).
Clarity would be a problem for me. At present I use the Vibe/G4 which means using Diasend (Clarity is not an option in Europe). If/when I give Loop a try, the plan would be to upgrade my transmitter to the G5, so I still wouldn’t have access to Clarity. I don’t know if Diasend will download from an iPhone yet. If/when they allow this, I would be able to upload pump and CGM data, although I don’t know if Diasend will integrate the reports.
I find that Loop can usually contain the BG within acceptable levels during the night. This is last night’s performance. The blue line is the BG trace while the bottom graph with the orange segments are the varying basal rates set by Loop.
It’s when other factors drive the BG well out of the target zone that the Loop algorithm fails to reel it back in. For me, it works well most nights.
I like the Diasend 14-day ambulatory glucose profile. It gives a great concise picture of your control. I would definitely use Diasend if I didn’t have access to Clarity.
What happened to your BG at 7.00 am.? Looks like it dropped suddenly into hypo-land. Insulin delivery goes to -1 (whatever that means). If it were me and my BG was dropping that fast, I would temp my basal down by 90% for an hour. How much has Loop reduced it by?
It actually bottomed out at 70. The dashed blue line is a prediction that didn’t pan out. Here’s the Clarity chart for that time:
The yellow line is 140 mg/dL (7.8 mmol/L) and the red line is 65 mg/dL (3.6 mmol/L). The zero reference line in Loop is whatever the pump basal rate is at that time. My pump basal rate at that time of day is 0.8 units/hour so Loop can actually go down to a negative 0.8 units/hour, equivalent to a net 0.0 units/hour basal rate.
In this case Loop decided to run with the pump basal rate of 0.8 until the 70 (3.9) appeared and then it completely took away the basal and reduced it to 0.0 for about an hour.
So the dotted line running around 50 until 12 pm is predicted.
I am a bit surprised at the speed of some of your drops. I am using the G4/Vibe (which I believe doesn’t track changes as rapidly), but drops like the one at around 2 AM would be an almost certain indication of a sensor drop-out and not a real change. Maybe the new algorithm works better.
I agree with you. That abrupt change was likely caused by either a sensor site compression while sleeping or the system missed a smoother adjustment to that lower level and it was playing catch-up. Or it might be a combination of those two factors. At this point I’m just guessing as I don’t have any fingerstick-data at that time. I didn’t lose any 5-minute data points; it dropped from 104 to 92 to 89. Dropping 12 mg/dL in five minutes is not likely in this context but I have seen movement like that while exercising.
The length of the dashed is my duration of insulin action setting. The further out along this dashed line the more likely it is to change as actual BG data points overlay the prediction. This predicted line changes every five minutes and it can move quite a bit.
@Lorraine and @Terry4, the cases when Loop seems to not be able to pull the bg down are the cases when Loop does not know of the “carbs” (real carbs, or proteins, or stress, or whatever) that are pushing bg up. For example, if it thinks carbs on board (COB) are zero, and bg is above target, it will issue high temps until it counts enough IOB to predict an eventual in-target bg. It will then stop high-temping. If COB=0 is indeed true, bg will indeed go down, and everything is fine. If bg does not go down, that means COB is not really zero, and bg will continue to hover at a steady high level or could even increase further. In response, Loop will repeat adding some more high-temps, and so on. Depending on how long the unaccounted COB may last, the process of bringing bg back to target may take long time (multiple hours), which is what I believe you are observing. In my experience, the most likely culprit is slow digestion of protein/fat meals. If I realized I had misinformed Loop about the “equivalent carbs” due to protein/fat content, I’d simply enter some extra “fake carbs” and I’d either issue an immediate bolus correction or just let Loop work through the added “carbs” by high temping. For nights after a large complex dinner, I’d just enter some extra long-absorption-time “fake carbs” and go to sleep. This is a way of giving Loop a licence to issue high temps more aggressively. If it happens that bg does not go up, Loop won’t issue those high temps, minimizing any added risks of lows.
Not so, there is nothing special about >150 or whatever bg may be. However, the Loop algorithm does have it’s limitations, especially when parameters or carbs entered are way off - see my comments above. It is hard to tell for sure without knowing all details, but I’d say that in the situations described by @Lorraine and @Terry4 Loop simply did the best it could given the info provided, and it most likely kept bg from creeping up any further
It’s reassuring to hear this is your experience. I still don’t have enough time/experience under my belt to draw conclusions. The times where I’ve struggling with highs have been when dexcom was off (one time 90 points - eek), and overnight seems to be a challenge and I’m not able to figure out why quite yet.
Just this morning I was talking to Caleb about the carb absorption. We haven’t jumped into those large, complicated meals yet, but I said we’re going to have to view inputting carbs differently, and be sure to add only a portion up front and extend the rest over a period of time.
Do you have any advice on this particular issue? The first night he looped, he had pizza. I think we just got lucky with a completely in range overnight. We input and bolused for carbs upfront as we normally do, and to replace an extended bolus over 8 hours that we normally input, he bolused another amount of carbs and input absorption time of 8 hours. What do you think? Is that something that should work, or did we just have beginner’s luck?
That sounds good, although I am not sure what you mean by “bolused”? You probably mean another bolus at a later time? (that would be fine) For complex meals, I prefer to split carbs entered into Loop into two parts, one with short absorption (for which I give a normal pre-bolus), and one with long absorption for which I let Loop high temp up to my max temp basal setting. This amounts to a “smart” extended bolus. Here is an annotated example of what I did for a pretty large dinner I had last night.
At 5pm I entered 40g of future carbs (at 6pm) with 240min absorption time. Note how Loop immediately saturated to 2.5U/h high temp, which is my usual high temp limit. I’ve found that high pre-temp about an hour ahead works wonders (this is similar to “eating soon” technique of Dana Lewis). At 5:30pm, when I also decided I should have some with roasted vegetables, I entered 40g of future carbs (at 5:45pm) and accepted a 3.5U bolus as a standard 15min pre-bolus. I had the dinner between around 5:45pm and 6:15pm. At 6pm, being aware of (too much) stuff I ate, I bumped up my high-temp limit to 3.5U/h to let Loop be veen more aggressive. Around 7:30pm I had some chocolate and wine for dessert. Glancing at bg and IOB, I decided to just enter 20g of carbs to let Loop know about the dessert but I did not bolus for it at all. In response, Loop continued to high temp. At 8:30pm I noticed bg creeping up a bit so I entered another 15g of long-absorption-time “fake carbs” to let Loop know there is apparently more stuff to be digested. The rest is completely automatic Loop action. This may all sound complicated when you look at the graph and read my description. In real life, with some practice, it’s actually pretty effortless - a few seconds to decide what to do and a few taps on the iPhone Loop app.
The following nighttime graph may also be interesting but for a different reason: a large pressure drop around 3am, followed by somewhat noisy sensor recovery. Loop responded by a low-temp followed by a high temp, which triggered couple of small bg waves. Never exceeded 120, and woke up at 89, so all fine.
I think this is where I’m undermining Loop’s ability to better keep my BGs in range. When I came to Loop, I bolused for both my meal carbs using an immediate bolus and for fat/protein with an extended bolus. When I adopted Loop, I bolused for the carb content of the meal and then let it variable temp basal dose for the protein/fat without any announcement from me.
I’m going to try telling Loop about all my meal carbs and carb equivalents (fat/protein) and only let Loop do an immediate dose for the actual carbs. I’ll use Loop as if I’m dosing for two discrete overlapping meals but cancel any immediate insulin dose for the fat/protein dose.
That’s basically what I am doing. Please note that max temp basal rate is another important factor in this approach. Lets suppose you entered long-absorption-time “carbs” to represent protein/fat, If your max temp basal rate setting is very high, Loop will high-temp a lot up front, which would likely result in your bg dropping low.
I should say I’ve seen other Loop users prefer to deal with long-absorption-time meals using multiple meal announcements and multiple boluses - that’s fine as well.
In any case, Loop does work much better when it knows about all factors contributing to upwards bg pressure, be it actual carbs, or protein, or whatever. In my experience, it’s much better to overdo estimates of these factors (because Loop can always abort high temps), than to not Loop know at all (because Loop high-temps are then severely limited)
This is very helpful. Thank you. I really don’t know how we managed to make it work for pizza the first time. I now understand that inputting carbs without an insulin bolus, regardless of the absorption time, will result in Loop effectively bolusing for the carbs via a temp basal in the next 30 minutes. That’s not what I want. I want to increase basal slightly over the next eight hours. I can’t figure out a good way to do this. I could lower his max basal, but that would limit Loop’s ability to correct a high if my estimates are wrong. I could periodically input fake carbs, but my goal is to sleep, and this would be in opposition to that. Letting Loop deal with it without any proactive announcement seems like a recipe for disaster.
I should learn more tonight. We had pizza. But now I have no confidence that we can handle it w Loop.
In the Loop, I have my max basal set to 2.5U/h, which is 4 times my maximum regular basal rate. For me this works really well as an extended bolus level for almost all complex meals (including pizza), and it still provides more than enough room for Loop corrective actions. In the absence of major errors in meal entries, I find that Loop rarely temps above about 3 times my regular basal rate (except when it saturates to 4x in response to long-absorption-time meal entries, which is what I want it to do). Everyone is different, of course - best luck with your adjustments.
I have the same problem with McD’s - the impact on the blood sugar can start 2-4 hours after I’ve finished the meal (talking about high quality foods) so I always have to take insulin with a delay. We should actually just skip that kind of c*ap in our diet.
with roasted vegetables, I entered 40g of future carbs (at 5:45pm) and accepted a 3.5U bolus as a standard 15min pre-bolus. I had the dinner between around 5:45pm and 6:15pm. At 6pm, being aware of (too much) stuff I ate, I bumped up my high-temp limit to 3.5U/h to let Loop be veen more aggressive. Around 7:30pm I had some chocolate and wine for dessert. Glancing at bg and IOB, I decided to just enter 20g of carbs to let Loop know about the dessert but I did not bolus for it at all. In response, Loop continued to high temp. At 8:30pm I noticed bg creeping up a bit so I entered another 15g of long-absorption-time “fake carbs” to let Loop know there is apparently more stuff to be digested. The rest is completely automatic Loop action. This may all sound complicated when you look at the graph and read my description. In real life, with some practice, it’s actually pretty effortless - a few seconds to decide what to do and a few taps on the iPhone Loop app.