The one-year Loop milestone, how did it perform?


Actually those weren’t my words Mila.

I was quoting someone else…


Have you noticed the changes in the TOS since BT1’s acquisition?


Hola Eddie, not really, some of us even in our jobs as staff or admins use this DIY systems, this is no secret…we are not trading or selling some of what is needed but we are sure giving some legal, non medical and no dangerous advice :slight_smile: we were guided by other members who thought the same. Keeping this info in a drawer does not benefit the diabetes community and friends :wink: We hope our experience using these systems help others


I know. It’s no secret people do it and I am not against it. I just want consistency when someone mentions buying something off eBay.

If a member mentions it and gets their hand slapped for mentioning it, but then an admin posts about it and everything is fine…seems a bit inconsistent.


TOS and some things HAVE changed.


Ok, thanks.


No, you don´t need to worry you’ll see consistency (is that a word in Englis? lol). Some rules have changed and so have TOS … i know you are not against this technology topics. There was a time, yes, when these posts were not allowed but rules have changed (the diabetes tech world changes and so did our communities).


Thanks, I appreciate your forthright response.


Thank-you, @Mila, @Sally7, @Lorraine, and @Mariana11 for commenting on this issue. I support things that help the larger diabetes community and don’t support things that do not.


I think that is great that it is ok to have discussions about this.

With the rules and TOS now changed, would it also be reasonable to allow persons back onto these forums who may have been banned or suspended previously for the rules which are no longer a bannable offense?


I’m not aware of any member whose account has been suspended for a violation of TOU that has changed and therefore would be subject to a review like this, nor am I aware of any changes in TOU that would have singularly resulted in the suspension of a member before the changes were made.

To be specific, if I’m understanding the intent of these most recent comments, if a member made a reference to the sale of medical devices on another site, protocol would be to delete the comment and inform the member why it was deleted. A single posting of this nature would not have resulted in a suspension, and to my knowledge has not unless the member’s account was deemed to be spam.


This is my first post in a long time.
I’m 75 years old, and a retired engineer. 45 days ago I started using Loop with a 522 pump and a Dex4. I haven’t had any difficulty with safety issues, but I wonder if there are changeable parameters in the programming that might make possible a more rapid recovery from high BG without dangerous overshoot to the low side. The only two settings that I know of to control the feedback stability are Insulin Sensitivity and Retrospective Correction.
When I set the insulin sensitivity to a value which seems to give near critical damping, I don’t always get a drop in BG when I need it. If I set the sensitivity so that high BG will normally get corrected, I will sometimes overshoot a bit to the low side.
Keeping the retrospective correction turned off seems to reduce loop gain, and reduce overshoot, but it makes the correction slow.
I have a feeling that I’m asking for something that doesn’t exist because of the body’s normal variation in insulin sensitivity, but thought that people with a lot more experience with Loop might have found answers to this overshoot problem.
I’ve tried to look at it as a negative feedback problem, but I don’t know how to control the damping coefficient of my endocrine system.
Does anyone have any suggestions for reducing my errors in the trial and error process?


Congrats on your Loop start. While I’ve been using Loop for over a year now, my understanding of how the system works is not as complete as I’d like it to be. While there are a few Loop users active on TuD, I suggest that you visit a few other sites to ask your questions.

The first one is a Facebook closed group called Looped. This site helps people not only with Loop but also OpenAPS and AndroidAPS. Just request to join and you’ll soon be posting questions.

The other is called Gitter. You will find people at both sites ready, willing and able to answer your questions. And they’re friendly and excited to share this frontier of diabetes treatment. Good luck!

One TuD member that I’m certain could help you is @Dragan1. My mention of him here should draw his attention.

Good luck with your system. I’d love to read about what you learn going forward.


Hi @DA1958, congrats on your Loop start. As @Terry4 mentioned, you may address your questions to developers and many more users at the Facebook Looped group, or the Loop gitter channel. I’ll try to provide some answers here:

From the control system point of view, (1/ISF) is the proportional gain, while retrospective correction (RC) adds a derivative term. Decreasing ISF increases the gain, which generally results in faster response, at the expense of reduced stability margin, which can be observed as some oscillations in bg responses. Turning RC on generally improves stability, improves response speed, and improves response to unmodeled factors, such as carb miscounts, or incorrect basal rates, so I’d recommend keeping it on. As usual, however, these are just general comments - your experience may vary, our bodies are much more complex than relatively simple models closed-loop systems are based on.

If you experience longer periods of time when Loop seems to be unable to bring bg down in spite of high temping, here is what you may look into: (1) account for protein and fat effects in meal entries - those often require increasing the amount of carbs entered, as well as extending the absorption time; (2) consider adjusting basal rates, (3) consider adjusting ISF.


Thank you @Terry4 and @Dragan1 for responding quickly with suggestions and engineering information.
I did a lot of reading on Looped in Facebook, and concluded that I was trying too rapidly to adjust multiple variables at the same time. So now, it’s one at a time. Looped also seemed to point me to being more careful with my timing. Eating too soon after bolusing produces the spikes in BG that initiate most of the oscillations.
Do the meal type selections in the meal-bolusing window correspond to different dual bolus settings on the pump–a normal bolus and a square bolus with different ratios, with the square implemented with increased basals? Logically, it seems like the same thing.
Loop seems to be a very well-designed, implemented, and explained system. I ran it closed loop during the day, open at night, for two days, then full time.
I really appreciate your help.


With a manually operated pump, one would typically use square-wave bolus to address high-protein/fat meals with long absorption times. With Loop, a similar approach applies but is to large extent automated. Loop meal type selections simply inform Loop about expected absorption time. Loop does not use pump’s square wave in any way. The absorption time affects Loop’s BG forecast, which in turn affects Loop’s suggested boluses and temp corrections. For a high-protein/high-fat meal, one typically only needs to enter the total carbs (including protein/fat effects) and some long absorption time, such as 4, 5 or more hours, accept Loop’s recommended bolus, and let Loop deliver the rest in the form of high temps dynamically adjusted based on observed BG response.

I agree. Loop takes some time to adjust settings and learn how to best work with it, but it is a very powerful and effective closed-loop system.



I am now looping using AndroidAPS which is build on OpenAPS Oref0. Overnights are FLAT. Average BG not much lower than pre-loop but much less variance (now ~90% in range) . The most difficult thing so far for me to adjust to is the inability to give an extended bolus. The idea is to give the upfront part of the bolus only. AndroidAPS is supposed to then dynamically calculate carbs on board using BG change, carbs and bolus entered and enact the extended boluses via TBRs.

At the moment it is typically showing COB decaying way faster than the actual situation (e.g. 90g of carbs as pasta all gone in 3 hours) so some playing around is still required


Congrats on joining the ranks of the DIY loopers!

That’s a big deal. When you wake up and look back at your overnight trace and see 100% or a high time in range, 1/3 of the day has already expired. You’ve started the day right and your chances of BG success for that day increases, a lot. I also notice that my total insulin used overnight is relatively low. These flat and in-range overnights appear that the algorithm doesn’t have to work hard and simply makes nudging moves adding and subtracting insulin.

I faced the same situation when I started Loop. Like you, I had been giving an immediate carb bolus and then an extended protein/fat bolus. For me, Loop naturally picked up the added post-prandial work.

I’m happy to read that you’ve decided to close the loop and use an automated insulin delivery system. I’ve found it to be superior to my old system in that less effort produces much better results. Your taming of BG variability is a big win in my book. I feel better when my standard deviation is under 30 mg/dL (1.7 mmol/L) and I feel best when SD is under 20 mg/dL (1.1 mmol/L).

Welcome to the future of diabetes!


Loop allows you to manually select or change carb absorbance. You cannot do this with OpenAPS (on which AAPS is built). It uses dynamic carb absorbance to try to calculate COB on-the-fly. I am finding that with low GI hi-carb meals it grossly overestimates carb decay. Consequently 4 or 5 hours out it tends not to be aggressive enough to deal with late carbs (or protein/fat). At the moment I am doing a second bolus at 90-120 mins and registering some of the carbs with that bolus. It works, but it seems a bit against the rationale of a closed loop. After all, why buy a dog and bark yourself?


When I calculate “carbs” for my Loop meal dose, I also add in the equivalent carbs comprised of 50% of protein grams and 10% of fat grams to the actual carb grams. I find that this gets me closer to the actual nutritional BG impact of the meal and Loop can temp basal to make up the difference.

Another tactic that I use every day is to set a lower temporary BG target (the blue heart “workout mode” icon at the bottom of the display) until a BG that’s trending higher turns back toward my actual target. I use 80-90 mg/dL (4.4-5.0 mmol/L) for my standard actual BG target range temporarily and then will set a lower target range, like 70-80 mg/dL (3.9-4.4 mmol/L), to turn higher trends around.

I realize that this takes away some of the automatic nature of the Loop but it works nicely for me. I feel like Loop is a versatile tool that I have not fully exploited. I’m sure you will continue to experiment to find tactics that work for you.