Fine-Tuning settings

It is totally true that there is no one place to read How To Adjust Your Settings in any looping documents.  The reason being…the answers are basically the same as other non-looping situations…test basals, test carb ratios, test insulin sensitivities.  The difficulty is that once people are already looping, nobody wants to turn off their loop to go and test settings again.  Everyone just wants to adjust settings on the fly while also keeping a closed loop.  So…I’ll try to explain a little of both methods.

Before we start, let me say this in case it isn’t obvious…I’m not your medical professional, nor anyone else’s medical professional.  Don’t take my words as a substitution for conversations with your doctor.

Ok…that warning provided…Think Like a Pancreas is a great reference for understanding some of the guiding principles in pump therapy.  Let me summarize the important parts:

  • Basal rates should keep your BGs steady in the absence of other influences (such as food, medications, etc).
  • Boluses should return your BGs to target after a meal.
  • ISF should be the amount one unit of insulin drops your BGs without other influences.

If you are new to looping, I recommend planning for a time to retest/reset all your assumptions about your diabetes settings.  Keep an open mind if you want to keep a closed loop. (how’s that for a catch phrase?)

It is absolutely possible to have two wrong settings look like a right setting when they balance out.  The problem is that those wrong settings won’t balance out in all situations.  Example:  Too low of basals can be offset by regular eating of meals with too strong of a carb ratio.  If you stop eating though, you’ll start going high because that extra insulin from the meal boluses won’t be there to help the lack of basals.  Taking the time to validate your settings by truly testing them is really good practice.

1st: Insulin Duration

New loopers’ number one settings issue will likely be too short of a duration of insulin action (DIA).  Almost all of us have cut our DIA at about 3 hours on traditional pump therapy.  There’s a reason for that.  In traditional pump use, DIA is only used to calculate the remaining IOB at any given time after a bolus.  That’s it.  And when do we use remaining IOB in traditional pump therapy?  Usually when we want to give a correction because a BG is stuck high or going low…in other words, DIA is used as a rough approximation to correct off-target BGs.  It doesn’t have to be rocket science then…we’re making an approximation because some other numbers (carb count, basals, etc) weren’t behaving the way we were expecting either and therefore leading to an off-target BG.

But in looping, DIA (and its related IOB) plays a HUGE part in how the loop is anticipating and evaluating your BG movement.  IOB is used literally every single minute for every single loop calculation for where to go next in setting a temp basal or providing a bolus recommendation.

Not only that, but the STRENGTH of the insulin at any given time is also being used.  Closed-loops know and care about whether your insulin was given recently and is due to peak soon (like between 60-90 minutes with novolog/humalog), or if it is in the slow tail portion hours later where BG impacts are going to be way less dramatic.  So, DIA means a lot in your closed-looping world.

What will happen if you use too short of a DIA in closed-looping?  You’ll see it in a variety of ways, but too short a DIA will give the equivalent of insulin-stacking.  The loops will be assuming insulin is disappearing faster than it actually is.  If you are getting steady BGs while closed looping with a short DIA, it’s likely that your basals are being set too low to compensate.  If instead you have your basals correctly set and use a short DIA in closed-looping, you will likely find yourself going low from corrections.  One good indication of this is going lower than target carrying negative IOB from previous loop low/zero temp basals.

General recommendation:  Set your DIA to 5 or 6 hours for novolog/humalog, do not keep using your old, short DIA from traditional pump therapy days.  If you are using the newest versions of Loop or OpenAPS, the code is defaulted for 6 hours.  Test your basals (see below) with the new longer DIA and make sure that you can get steady BGs with the new basals.

2nd: Basals

Now that you have a reasonable DIA set, make sure to test your basals.  Personally, we find testing basals can be pretty painless and doesn’t require days of fasting.  Instead, we look for easy opportunities.  If you are willing to open-loop test, that is going to give the most accurate information in the quickest way.

It’s a pretty easy test.  Turn off your loop.  Don’t eat food, don’t do crazy exercise, don’t sit in a hot tub.  Just have a relaxing average time period and see if your basals are able to hold you roughly steady.  Doesn’t matter if you are at target or not…the idea is to simply have zero extra insulin on board from any boluses or corrections and watch what happens during those hours.  Typically we like to see about two hours of BGs without the influence of food boluses.

Believe me when I say that Anna is not enthusiastic about fasting basal testing…so I look for opportunities to make it less cumbersome.  For example, use a meal that I know like the back of my hand how to bolus for it and that generally needs no corrections.  For us…that’s two extra large scrambled eggs (or three small ones) with cheese bolused at 8g.  If she eats that meal, the BG response is slow and measured and by 3 hours after that meal…the bolus and food effects are really muted and we can start watching to see if BGs stay pretty steady for the next two hours.

For example, here’s some of a recent open-loop basal testing we did with Anna…confirmed that the BGs could stay pretty steady without the involvement of temp basal help from looping.  The 8g of eggs at the end of almost 3 hours…looks like she went a little lower (and may have deceased even more if she hadn’t started the next meal) than she had started.  Since basals appeared to be keeping her pretty steady, I made a mental note that carb ratio might be just a touch too strong, but didn’t adjust right away.  I waited to see how the next meal was going to behave.


If you absolutely don’t want to turn off your closed loop to test this…see if you can find a time where BGs are steady, you are at/close to target, and you are not carrying positive or negative IOB.  If you can’t find a time like that, chances are you may need to adjust settings.  Nighttime is usually the easiest to find that…but having well-set nighttime basals does not mean that daytime is also necessarily well-set.  That needs to be tested as well.

3rd: Insulin sensitivity factor

Insulin sensitivity factor (ISF) is the next logical setting to test.  If you’ve just done the basal test and gotten steady BGs with an open loop…try taking a glucose tab or two.  Wait for your BGs to be steady at the higher BG, and give a safe correction that you think will get you close to target.  Watch the resulting BG drop over the next 2-3 hours.  You should see BGs come to a steady level again.  How much did the BG drop?  How many units of insulin did you use?  Divide the two numbers and you will have your ISF.  If your BG dropped 15 mg/dl with half unit of insulin, your ISF is approximately 30 mg/dl/unit.

If your ISF is too weak (in other words the actual number is too low compared to reality of how strong the insulin is) in closed-looping, one of the most common symptoms you’ll see is a roller coaster of BGs where the temp basals are cycling between zero and high temping.  I’m going to borrow a couple of example graphs from Looped group.  These are examples where too weak of ISF is more than likely a large factor in the roller-coaster (doesn’t mean it is the only culprit, and is more difficult to ferret out when food is involved like the second graph).  But, lightning bolt high temp basals followed by very quick BG drops and zero temps is usually too weak of ISF…raise the ISF number to help looping know that each unit of insulin is actually doing more BG dropping.



Screen Shot 2017-10-28 at 12.20.02 PM

4th: Carb Ratios

Now that you have basals, ISF, and DIA all set-up…here’s where it gets really tempting to close loop and move on.  And, truthfully, it’s not that hard to test carb ratios on a closed loop vs an open loop if you’ve solidly tested all these other factors.

A good carb ratio will bring your BGs back to the starting point of the meal within about 3 hours or so.

A bad carb ratio will leave you higher or lower than the starting point of the meal.

For example, these are two examples of carb ratios being too strong.  In this first example, there’s 2.27 units of IOB and BGs are at 103 and headed down at a pretty good clip at about 2 hours after the meal.  If the next meal hadn’t been eaten then, low treatment certainly would’ve been needed.


This next graph also shows too aggressive of a carb ratio.  Three hours after the meal, there’s nearly 0.50 units IOB, BG is well below where the meal started, and definitely low treatments needed.


If you are finding that a correct carb ratio is yielding good BGs 3 hours later, but you aren’t happy with the peak BGs during the meal…then it may be time to explore increasing or adding prebolusing time to your meal or implementing “eating soon” targets an hour before meals to help control the post-meal BG spike.  Artificially strengthening carb ratios to help control post-meal BG spike will likely yield lows 2-3 hours after a meal.

But what about diabetes?

Of course, as soon as you test and dial-in all these things, diabetes will throw you a curve ball and change your insulin needs.  That’s the way it works.  It’s not just YDMV (your diabetes may vary), it’s actually YDWV (your diabetes will vary).  So how do you adjust settings without needing to open loop every time?  Short answer: it takes practice.

For us personally, hormones play the largest variable in settings.  If we estimate average basal rate of about 1 u/hr for Anna, hormones can make her range from 0.55 to 3 u/hr.  Illness or heat can make her ISF change from typical 35 to a range between 30-45.  We have gotten used to changing settings (basal rates mostly) to accommodate hormone fluctuations.  Illness and heat we tend to use shorter-term fixes like temp targets to help rather than changing settings.

One of the easiest tells we have that basals need to change is hanging out above/below target with positive/negative IOB.  Here’s one recent example.  During the day before this screenshot, Anna was busy with some stressful things at school…like being front and center during the school’s pep rally for Homecoming around noon to 2pm.  So, the unusual red spot on her graph didn’t immediately make me think anything was “wrong”.  Then she went to Homecoming dance that night, hung a little higher than target, but nothing too bad and she wasn’t looping during dance (her choice).  She came home around midnight, and at about 5am I noticed that she was hanging out steady at about 130s and carrying positive IOB.  Fingerstick showed she was at 195 (thanks Dexcom).  Gave a correction and started to wonder if may her basals were too low, because she shouldn’t have been that high under normal operations (but maybe homecoming dance was to blame?).  I didn’t make any changes to her settings at this point, but did start to watch for signs.


In the morning, Anna had a typical breakfast with some toast and fruit.  With fiasp, she hasn’t really been going above 150 (and usually not above 130)…so when she hit nearly 180 for the meal, I definitely started to think basals may indeed be low…but I waited to see how the meal would land.


As you can see above, about 2.5 hours after her meal of fairly quick carbs, she started to rise.  And she started to rise with about 0.75 units IOB.  This is odd for her.  Ideally, we wouldn’t be seeing sharp, steady rises with a good amount of IOB.  Additionally, this meal didn’t have protein or fat involved so I knew the rise wasn’t a late food contribution (even if Loop had some cob still on board).

So, once it looked like (1) the rise really wasn’t slowing down even like Loop thought it should, (2) she was climing with fiasp for nearly an hour of high temping with (3) positive IOB…then I finally decided to adjust basals.  I moved her basals from 0.85 to 1.2 u/hr.  Why that number?  A guess based on basal rates she tends to move between during her regular variations.  Trial and error have shown us that a rate slightly above 1 u/hour is usually needed sometimes.


One of the things I like to watch is the IOB pill when we make a basal change.  Ideally, I like to get the IOB back to a number that is roughly how much I think may help get a correction going again.  So, changing the basals from 0.85 to 1.2, Loop recalculated IOB from 0.52 to -0.48.  Which was roughly in line with what I’d expect…Anna was about 27 mg/dl over her 95 mg/dl target with an ISF of 55…meaning she’d need about 0.49 units to correct to target.  Perfect…seemed like a reasonable amount of movement for basals then.  Loop started running a high temp and I wait to see how things look in about 2 hours.


About 1.5 hours later, Anna wasn’t quite coming down as fast as I would’ve expected. She was still holding 0.57 IOB and at same BG as she was 80 minutes before.  So…I waited a bit and adjusted again to 1.4 u/hour.  Again, just a guess, but nearly two hours after that adjustment we are sitting just about at target and just about even IOB.  I’ll probably split the baby and use 1.3 u/hr going forward.

So…that’s how I look for and make tweaks to my settings while closed looping.  The basis is knowing what “good” times look like and how foods normally behave.  Open-loop testing really helps with that.  Then, when you find yourself with some of the telltale signs (food going differently than expected, BGs holding steady but not at target, moving up/down without IOB helping, etc) over an extended period of time, you can make small adjustments and watch for the resulting behaviors.  I don’t adjust based on just one meal or one period of above-target BGs.  There’s too often another reason (stress, sensor issues, etc) that could explain a short term high/low BG pattern…but if I notice the trend continuing for a period of time/several meals, I adjust.  Shorter term issues from stress or exercise we deal with using temp targets or just have a little more patience and wait for them to come down when the issue has passed.

Exponential Insulin Curves + Fiasp

One of the new updates that came to both sides (OpenAPS and Loop) quite recently are Exponential Insulin Curves.  I’ll spare you all the detailed history of development and discussion, but there’s several threads of discussion on GitHub regarding the new curve developments like the PR here in OpenAPS, the issue here in OpenAPS, and the issue here in Loop if you want to read up.  What you’ll notice is that there was a lot more cross-communication between the different DIY groups than usually happens…so this particular feature happens to be where OpenAPS and Loop have the greatest degree of similarity right now.  And something must have spurred this sudden cross-system work, right?  Yes…and that something is Fiasp.  The new “faster” insulin.

What’s so special about Fiasp?

Fiasp is like Novolog, except it has an additive that “speeds up” the insulin effect.  To quote from the official paperwork:

Fiasp is a mealtime insulin aspart formulation in which the addition of nicotinamide (vitamin B3) results in a faster initial absorption of insulin compared to NovoRapid.

The onset of action was 5 minutes earlier and time to maximum glucose infusion rate was 11 minutes earlier with Fiasp than with NovoRapid. The maximum glucose-lowering effect of Fiasp occurred between 1 and 3 hours after injection. The glucose–lowering effect during the first 30 minutes (AUCGIR, 0–30 min ) was 51 mg/kg with Fiasp and 29 mg/kg with NovoRapid (Fiasp/NovoRapid ratio: 1.74 [1.47;2.10]95% CI). The total glucose–lowering effect and maximum (GIRmax) glucose–lowering effect were comparable between Fiasp and NovoRapid. Total and maximum glucose–lowering effect of Fiasp increase linearly with increasing dose within the therapeutic dose range.

What is the most important take away for most of us?  Less need for prebolusing in order to control post-prandial spikes in BG.  Translation for Anna…she doesn’t have to wait nearly as long to eat that donut.  So you can see the appeal of the product if it works as they advertise…a 2-minute prebolus or even post-meal bolus?!

Why can’t Fiasp work with the old curves?

As a gross simplification, the insulin curves are made by “drawing” a smooth line through a bunch of individual, discrete data points collected from all the users in insulin study groups.  Mathematician’s version of art could be envisioned as HOW they connect all those data points, because there are many different methods (such as straight-line, bilinear or exponential) they can use, each with pros and cons.  Typically, mathematicians try to pick the method that provides the “best fit” to the data points.  In picking that method they may need to ask themselves…what are the important areas of the dataset?  Do they want those areas to match up best?  This wiki page offers a great overview of the concept of curve fitting.

The old insulin curves (bilinear curve for OpenAPS, Walsh curve for Loop) didn’t fit Fiasp data well.  Our looping community needed a new piece of art (aka curve)…and ideally the new curves could also be slightly individualized for YDMV (your diabetes may vary) and still work for the rapid insulins such as novolog and homolog.

What are the Exponential Insulin Curves?

The new way that the looping systems model insulin impacts in their system is through exponential insulin curves.  The exponential insulin curves have two user-adjustable inputs; peak time (PT) and insulin action duration (DIA).

For Loop, there is one legacy insulin curve (Walsh) and three new exponential curves to choose from when you configure your Loop app.  The first 3 listed below are for rapid-acting insulins (novolog/humalog) and the last one is for Fiasp. (Note: the Loop docs contain the instructions for individualizing the exponential curves’ DIA and PT settings.)

  • Walsh – default DIA =360 min, PT not user-configurable
  • Rapid-acting adult – default DIA = 360 min, PT = 75 min
  • Rapid-acting child – default DIA = 360 min, PT = 65 min
  • Fiasp – default DIA = 360 min, PT = 55 min

For OpenAPS (currently in dev branch, as of this blog date), there are three curves; the legacy curve, and two new exponential curves (one for novolog/humalog and one for fiasp).  The peak times for rapid-acting and ultra-rapid can be set in the preferences, DIA is set in the pump (and must be at least 5 hours for the exponential curves).

  • Bilinear – old OpenAPS curve
  • Rapid-acting – default DIA = 300 min, PT = 75 min
  • Ultra-rapid -default DIA = 300 min, PT = 55 min

For fun, here’s what the math looks like inside the Loop code:

Parameters: td = duration, Ia(td)=0, IOB(td)=0, tp = peak activity time, both expressed in minutes.
Time constant of exp decay: tau = tp*(1-tp/td)/(1-2*tp/td)
Rise time factor: a = 2*tau/td
Auxiliary scale factor: S = 1/(1-a+(1+a)*exp(-td/tau))
Insulin activity curve: Ia(t) = (S/tau^2)*t*(1-t/td)*exp(-t/tau)
IOB curve: IOB(t) = 1-S*(1-a)*((t^2/(tau*td*(1-a)) - t/tau - 1)*exp(-t/tau)+1)

And the math inside the OpenAPS code is pretty similar, too.

IF you take that math and boil it down into pictures (because don’t most of us like pictures better?), you get curves kind of like these based on what DIA and what PT you select (thanks Sulka Haro):


Looking at the chart above, you can see the grey and blue lines would roughly represent Fiasp, while the orange and yellow lines would represent slower Novolog.

So this default curve will work for me, right?

Most of us are so excited when something new is released for our loop, and we think it will be as simple as just turning on the new feature and looping gets even easier.  The developers do a great job of reminding us YDMV, test these features for yourself…but somehow we all get so darned excited we forget that warning soon after we enable the new feature.

The new insulin curves are no different.  There are a lot of assumptions that go into these curves, not the least of which is that they represent a consolidation of data from THOUSANDS of insulin users in study groups.  They are not derived from data gathered from YOU in a study group.

My personal understanding of insulin curves has grown a lot since beginning to loop, and it still has a long ways to go.  When I started, I’d swear on a stack of bibles that our insulin duration was 3 hours.  Then, after looping for a bit, I’d sheepishly admitted that 5 hours was indeed actually a smoother ride once my settings adjusted.  Finally, I even moved it out to 5.5 and 6 hours and still had a smooth ride (the difference between the two durations was not enough for me to readily notice in my data).  I would say that if there’s one bit of consensus in the looping community development group, it is that your DIA should not be less than 5 hours.  If you aren’t at 5 hours DIA yet, you should take the time to fine-tune your settings.  If you are using less than 5 hours DIA, you are probably relying on a loop-induced insulin stacking to make up for basals that are too low.  (Ahem, looking at you 670G users who are using 2 hour DIA in order to trick those loops into providing more aggressive BG control…but alas, that’s the only variable they have to control their loop.  Lucky us, Loop and OpenAPS give us options.)

But, since Anna started on Fiasp October 11th, my whole head exploded and I had to rethink my insulin curves all over again.  In fact, if you read those discussion threads linked at the beginning of this post…people have been having success at lots of different settings while trying fiasp (2 hours, 5 hours, 7 hours DIA and various peak times as well).  How could the same person be having “success” at such varied settings?  The answer is multi-faceted.

What are the impacts of DIA and PT?

This is a great set of graphics (thanks Dragan Maksimovic) illustrating the effects on the curves at varying settings.  This first set is the insulin activity where you are only varying the PT, and keeping the same DIA.  Notice, as the peak time increases, more of the insulin’s strength to bring down insulin is used up earlier.  You’d expect to see BGs drop sooner with a quicker PT and slow up more as the insulin wears off.


This next set of curves shows what happens when you keep the same PT, but vary the DIA.  If the peak time is the same, the shorter the DIA then the stronger the insulin will impact the user at the same time post-prandial.


Keep these curves in mind, as they may provide good reference in later discussions about fine-tuning your insulin settings.

Actually, this is probably a good place to end this post.  We can carry over the discussion about Fiasp and insulin curves to the next post, where I’ll share how the first 6 days of Fiasp led me to actually stop looping, go full manual mode for 2 days to recalibrate all my settings and search deeper about where my problems with Fiasp and looping were coming from.  Don’t worry…so far it has a happy ending.

Moving between DIY closed loop systems

A year ago, I chose to build our first DIY closed loop system based purely on size of the device Anna would have to carry and my ability to get the dang thing built.  (no easy feat for the first venture, lol)

Now though, there’s so much support for building and the device sizes are nearly identical…the choice involves a lot more variables now.

We’ve moved interchangeably between both systems several times over the last year…so I thought I might write up a blog post from the perspective of someone thinking about moving between systems and what to expect.  I get this question a lot from people, not just about kid considerations, so I’ll log my thoughts on the topic here.


In Loop, you only use the Loop app to enter your meals and boluses.  Loop calculates the bolus recommendation based on the total carbs of the meal and the carb absorption time (as well as a component of BG momentum if you are trending up or down at the time of bolusing).  Meaning, your Loop is dynamically prepping your bolus recommendation based on meal type and current trends.  If you (or your kid) mistakenly bolus for a meal using the pump bolus wizard, you will simply need to enter the carbs into the Loop app as soon as you can remember or notice, backdating the carbs to the time that they were eaten.  The bolus itself will be read by Loop app when it reads the change in reservoir volume, so nothing special needs to be done for the insulin portion.

In OpenAPS, all bolusing is done on the pump itself using the pump’s bolus wizard.  This means that your bolus wizard pump settings will be used to calculate a bolus for the amount of carbs you enter.  You should NOT enter a BG value into the bolus wizard because the pump will not know your active IOB correctly.  Your bolus recommendation will be based purely on carb ratio as a result of switching to OpenAPS.  The bolus will not automatically be adjusted by the system for any active IOB or current BG trends.

Split Bolus/Extended Bolus meals

On Loop, you can use the carb absorption time of the meal to help with split-bolusing.  If your meal is heavy carbs and/or long absorption, Loop will recommend an initial bolus to keep you from going low while the first part of the meal slowly absorbs, and then Loop will cover the rest of the “missing” bolus as soon as the possibility of going low passes.  To help with this action, increasing your max basal rate may help so that Loop can deliver enough insulin in a timely manner to cover the “missing” bolus later.  You can read about that behavior in my other blog post about Why DIA Matters.

On OpenAPS, the options are a little different.  Since OpenAPS is ignorant of the type of food you are eating, you will have to manually adjust for split bolus situations.  You can do this by simply entering part of the carbs at one time, and the remainder of the carbs later, in the pump’s bolus wizard.  Or you can manually enter the total amount of carbs in the first entry, decrease the initial bolus manually, and let OpenAPS determine how to apply high temps/single microboluses to cover the remaining “missing” bolus as the meal goes forward.


In Loop, you change the timestamp on the carbs using the time scroll wheel to a time in the future to indicate a prebolus.  You can edit the time if the meal ends up being eaten sooner or later than originally planned.

In OpenAPS, prebolusing is not quite as straight-forward, if you want to have the carbs and bolus timestamped at their real times.  Since OpenAPS uses the pump’s bolus wizard, typically the insulin bolus and carbs will share a timestamp.  For prebolusing using the pump’s bolus wizard, you can’t tell the pump that the carbs are actually going to be eaten 20 minutes from now.

If you want the system to know you really ate the carbs 20 minutes (for example) after you actually bolused for them, you can manually calculate the bolus you’d need/want, use the manual bolus function of the pump (or easy bolus button), and then use Nightscout’s careportal to enter the carbs 20 minutes later, when they are actually consumed (you can’t record a carb entry on the pump without having a corresponding bolus…therefore the NS careportal entry would be used to record the carb entry alone).

As a practical consideration, OpenAPS has a bolus snooze feature which in essence covers the loop’s actions during the time immediately after a bolus.  The rig won’t recommend a low temp basal immediately after a bolus unless your BGs are really dropping.  Bolus snooze, basically, pauses the loop from making any drastic actions immediately after a bolus.  So, practically speaking, most prebolusing OpenAPS users just enter the carbs using the bolus wizard when the initial bolus is given (say, 20 minutes ahead of eating).  While not precisely correct, the incorrect, early time-stamped carb entry doesn’t affect the actions of the OpenAPS logic too much during that time.

Active IOB

Both systems can use the SkyLoop Pebble watchface to see IOB.

On Loop, you can see your active IOB (aka net IOB) on your main screen of Loop.  It also appears in your Loop and IOB pills on Nightscout.

For OpenAPS, active IOB appears in Nightscout on the OpenAPS and IOB pills, or on Papertrail online.  There is nowhere locally on the pump to see the same information, so you’ll have to have internet access to via IOB (* offline IOB using Pancreabble pebble watch is possible, but documentation is not completed yet for setting that up.  I had a terrible time trying to get that setup on my last attempt.).

Carb Editing

On Loop, you can always go back at any time and edit the carbs for a meal entry.  Even after the meal has been bolused for, you can edit the carbs.  The system won’t be able to suck back any insulin already delivered…but it can more aggressively suspend insulin deliveries if fewer carbs ended up being consumed than originally bolused for.  Additionally, if a meal is digesting slower than anticipated you can extend the carb absorption time and Loop will know more carbs are still on-board and provide better high temp basals to treat.

On OpenAPS, you cannot edit carb entries once they are entered in the pump bolus wizard.  You can edit carb entries only if they were made using the Nightscout careportal (either through website or IFTTT).  If fewer carbs ended up being consumed than had been bolused for, you can use a higher temporary BG target to prevent the loop from providing as much insulin via basal deliveries in the near future.

Predicted BGs

Loop generates a single predicted BG curve.  Always a single curve.  When the predicted BG dips below 55 mg/dl, your Loop will suspend.  When your predicted BG dips below your low-suspend target, but eventual predicted BG is above target, you’ll get your scheduled basal until the dip comes above target.  When you are above target for the entire predicted BG curve, you’ll be high temped.  There’s more to the algorithm for bolusing…but the basics are pretty straight-forward for how basals are set in Loop.

OpenAPS generates four predicted BG curves that will be displayed in Nightscout when carbs are on-board (otherwise a single prediction curve will be present).  One based on insulin-only (as if no carbs existed), one based on slower carb impacts, one based on faster carb impacts, and one based on current trends without as much limit on carb entries (e.g., UAM curve).  Which curve OpenAPS chooses to use for setting basal rates will be based on the logic decisions in the determine-basal file.  It’s fairly complex, but that blog post linked will provide a good summary idea and links to more in-depth reading if you are interested.  At any given time, the logic being used by the OpenAPS rig will be displayed in the OpenAPS pill on Nightscout.  For that reason, the OpenAPS pill is tremendously more wordy and filled out than the Loop pill in Nightscout.

Temp BG Targets

Both Loop and OpenAPS have temporary BG targets as features.

On Loop, setting of temp targets is local only…meaning the targets must be started and stopped by the Loop app on the iPhone itself.   Loop has both pre-meal (a.k.a. eating soon) and workout targets that you can set.  Pre-meal target will end after one hour, or whenever the next carb entry is saved, whichever comes sooner.  Workout targets will expire based on the time initially set by the user, unless cancelled manually earlier.

On OpenAPS, setting temp targets is done remotely through Nightscout.  (Technically, you could edit your targets in your pump’s bolus wizard settings and that would eventually be read by the rig…but this solution is cumbersome and clumsy compared to using Nightscout…so I’m just mentioning it as a possibility for completeness’ sake.)   You can enact a temp target in Nightscout by either using the website’s careportal directly, or by setting up IFTTT quick buttons on your phone that will log the temp target in careportal.  You can manually cancel temp targets using either option as well.

OpenAPS does have a preference settings too that will allow for the automatic setting of a lower temp target, if enabled. This setting will automatically set an eating-soon type target, as low as 80-80, during periods of detected insulin resistance (high BGs and high predicted BG).  You can read more about that setting here.

Internet dependence

First, let’s clarify what internet dependence means.  Internet-dependent means that the device needs to have either a wifi or connection to a cell phone that has cell reception, in order to work.  This could also be termed on-line use.  Off-line use means using the system where no wifi or cell reception is available…aka the Amazon jungle, most airplane flights, or in busy El Segundo right next to LAX airport (as I discovered on May 6, 2017 at my cousin’s wedding).

Loop can function completely offline, without any internet connection.  Loop will grab BG data straight from the Dexcom devices.  This does mean that the iPhone with Loop app will need to have the Dexcom G4 or G5 Share app also installed and paired to the Dexcom device (G4/G5 Share receiver or G5 transmitter).  This works on the BT of the iPhone…not using cell data or wifi connection.  So, when you board the airplane and put your iPhone in airplane mode…you just simply toggle the BT back on and you’re good to go.

OpenAPS, while not technically internet-dependent, is really much more useable when internet connection is available.  Without internet connection, your rig is not able to fetch BGs from Nightscout, nor will you have the ability to view your rig’s actions (on Nightscout).  There’s two parts to this discussion, I suppose…how to setup the internet connections, and how to deal with offline times.

To setup OpenAPS rig’s internet connections, you basically pre-setup wifi network names and passwords into the rig’s files ahead of time.  You also pre-setup your rig’s ability to BT tether to your cell phone to use cell data when wifi is unavailable.  This is where things get a little technical with a bunch of caveats like:

  • Not all wifi networks will allow the rig to work properly, it is up to the settings the IT dept may have imposed.  Especially at schools and work.
  • Since wifi networks must be setup in the rig’s files (i.e., accessing inside your rig with a computer), some thought has to be given to traveling in advance for things like using hotel wifi or potentially using a mobile router like a HooToo. You can’t just simply press a button and connect to a new wifi network for the rig.
  • Not all android phones have BT-tethering capabilities, some have it better than others.
  • Not all cell phone plan providers offer mobile hotspot plans without extra cost or data limits, and may depend on device itself.
  • Rigs transition off/on some phones better than others.
  • iPhone seem to BT-tether pretty reliably, but not always.  And iPhones cannot use wifi while the rig is tethered to the iPhone’s hotspot.  So, make sure your iPhone’s cell data plan is ready for that.

So, what do you do when wifi networks are unavailable and you happen to be in a cell dead spot?  For most users (*exceptions below), you need to pack an OTG cable, your Dexcom receiver, and a USB battery pack.  Your rig will get BGs direct from receiver and looping will continue.  You just won’t be able to see the details of your looping on Nightscout…you’ll be “flying blind” except for being able to see that a temp basal is still being set on the pump.  When you get back into cell range or a known wifi network, your system will go back to normal operations.

*notable exception for medtronic sensor users…offline is easier because BGs flow directly from the pump read.

*some android users can choose to pre-setup offline visuals of rig because android users can connect their rig/phones even when no cell data is available.  iPhone users do not have the same ability because the rig will not connect to the iPhone unless cell data is available.

Computer dependence

Loop is pretty much computer independent until you decide you want to upgrade your Loop app (as new features might be released).  Troubleshooting Loop issues never involves needing to find a computer to rebuild the app or debug.

OpenAPS will, more than likely, require periodic access to a computer in order to access the files for the rig.  Such as when you want to:

  • Update your OpenAPS code (for new features, similar to Loop above)
  • Add new wifi networks
  • Get a new phone, change your NS URL or API secret, or change CGM systems (G4 to G5 to x-drip to Medtronic)
  • Change pumps
  • Troubleshoot rig issues

There are some work-arounds as you get more comfortable that will let you do much of these tasks using an app on your phone (vs pulling up a chair to a computer), but you will probably need to get used to doing them on a computer first.  Either way, your rig will need to be near you when you access the rig via the computer/app (either on the same wifi network or cabled to the computer you are using).  If your kid is away at school, you will have to wait until you can get back in proximity to the rig to make the changes.


Loop does not currently have any type of auto-adjustments of basals or ISF.

OpenAPS has autotune and autosens.  Autotune will behave sort of like the 670G in that the rig will create a new basal and ISF profile for you based on the previous day(s) data, adjusting your pump settings between 70-120%.  Any changes you make to your pump settings for basal or ISF won’t be used unless the autotune was bumping up against the 70-120% limits of the old settings (the 70-120% range is from the pump’s current setting).  Basically autotune creates a new profile of basals and ISF for your loop to use.  Some people have loved this feature, other people have not…but you should try for yourself to make that decision.  Autotune is available for people to use as a single-time manual run as well…meaning Loop users can test their settings through the autotune algorithm and see what autotune recommends.

Comms Battery

Both systems use rechargeable lipo batteries for their communications system (RileyLink or Explorer Board), and with both systems the users typically charge the batteries overnight.

Loop uses a smaller battery, but the battery lasts longer due to RileyLink’s low power consumption.  The lipo for Loop users charges in about 2 hours, and lasts over 24 hours.

OpenAPS uses a larger battery.  The lipo charges over about 8 hours (depending on the size of battery you are using) and lasts about 14-16 hours (for a 2500 mAh capacity lipo).

Pump Battery

The Loop communicates with the pump less often than the OpenAPS rigs do, so pump batteries will last longer on Loop systems.   Using Loop and a 723 pump, we have reliably gotten 16+ days on a single lithium battery.  Using OpenAPS and a 723 pump, we have reliably gotten just over 8 days on a single lithium battery.


Loop users should buy an extra RileyLink.

OpenAPS users should keep an extra rig (consisting of an Explorer board and an Edison together).  Recently, Intel announced they would no longer be selling or producing Edisons…so the end of 2017 will bring about the end of that type of OpenAPS rig.  Possibly the OpenAPS community will transition back to raspberryPi setups?  Unknown now what the transition device will look like.  BUT, if you love the Explorer board/Edison setup…you might want to pre-order your redundancy rigs now.

What if the system fails?

In either system…if the system goes down and is not working…all your pump settings will be used to deliver basals, make bolus recommendations through the pump’s bolus wizard, etc.  The fallback for each system is normal pump operations, once the currently enacted temp basal is completed.  On Loop, the maximum temp basal duration is 30 minutes (for both high or low temp basals).  On OpenAPS, the maximum low temp basal is 120 minutes of suspended basals (a.k.a., zero temp basal) or 30 minutes of high temp basals.

Notification of failure for Loop users comes locally on the iPhone via notification message pop-up at 20 minutes (and regular intervals up to 120 minutes if the system fails to resume on its own).  Nightscout can be setup to have Loop pushover alerts for remote caregivers/parents.

Notification of failure for OpenAPS would have to be setup manually via Nightscout pushover alerts (similar to Loop pushover alerts).  Additionally, if the OpenAPS user is using Papertrail, some more complex alerts (such as email or text messages) could be customized through that system.  Currently there is no documentation of that process, but it is not too hard to do from within the Papertrail integrations.

What pump settings are used?

Loop reads the reservoir volumes from the pump to confirm boluses and determine IOB.  Pump events are read and used (if Event History is selected in app settings) such as pump prime, pump bolusing status, pump suspend, pump resume.  Notes will appear on Nightscout for those pump events, as well as carb and insulin boluses, if Event History is selected and NS URL/API secret has been entered in settings.  However, Loop uses all the app settings (not the pump settings) for DIA, ISF, basal schedule, carb ratio, BG target range, maximum bolus, and maximum basal rate (* for safety, the pump setting for maximum bolus and maximum basal rate must be at least as much as the Loop setting in order for Loop to enact the maximum amounts).

The only time your pump settings are used is if your Loop decides to cancel a temp basal because the scheduled basal in the Loop settings is appropriate.  Loop will cancel the temp basal and the pump will turn on the scheduled basal from the pump settings.  If your pump settings and Loop settings don’t match for basal rates…in those instances…the pump basal rate will be enacted.  Loop will eventually “see” the mismatch because the insulin delivery through reservoir readings will show more/less insulin delivered than expected, and Loop will try to compensate going forward.

OpenAPS uses all the settings directly from the pump.  The limited exception to this are temp BG targets set through Nightscout careportal or if you have autotune/autosens enabled as part of your rig’s setup (those are discussed in the earlier sections).  OpenAPS can supplement carbs-on-board through Nightscout careportal entries as well.

What gear is supported?

Pumps:  Loop and OpenAPS use pretty much the same suite of old Medtronic pumps.  OpenAPS can use the 512/712 pumps, whereas Loop cannot.  However, the x12 model pumps require a bit of extra setup in OpenAPS and changing the pump settings is a manual file change instead of simply updating the pump itself.

Phones:  Loop requires an iPhone.  OpenAPS can work with either Android or iPhone (and technically it can work without a phone in offline mode, but you won’t have access to detailed information about the loop functions/status).

CGM:  Loop and OpenAPS both can use Dexcom G4/G5 or Medtronic sensors.  I am admittedly not the most savvy on Libre integration, but I’ve seen it for both systems as a custom setup by inventive users.  Also have seen x-drip users on both systems…but Loop would require more customization for x-drip users than OpenAPS does.  And Loop x-drip users would need only be able to run their Loops as internet-dependent.  Gitter would be a good area to ask about non-standard type setups.

Computers:  Loop requires you to build on a computer running Sierra macOS.  OpenAPS can be on Windows, linux, macOS…a variety of computer platforms.


Nightscout supports both systems.  All the important information for each system will be displayed in the various pills and graphs.

Loop does not require Nightscout as part of Loop use, it is optional since Loop does not read or use any data stored in the Nightscout site.  Mostly, Nightscout is used for remote parents or caregivers to track Loop status.  Loop requires the dev branch of Nightscout (updated since at least June 29, 2017) if you want the extra new features of Loop v1.4 (i.e., food emojis and carb absorption times) displayed on the Nightscout graph.

Nightscout is pretty much mandatory for OpenAPS users, as it is the easy display of OpenAPS status and actions (analogous to the Loop app’s main screen display locally).  OpenAPS will read AND USE the following information from Nightscout; carbs and temp BG targets entered through careportal/IFTTT, and BG values.

Neither system uses the information in your Nightscout profile for looping such as basal schedule, carb absorption, carb ratio, etc. All that Nightscout Profile information is UNUSED by either DIY closed loop systems (except for setting your timezone appropriately).  The basal schedule in your NS profile is only used as a relative indicator for NS to draw your loop’s temp basals above/below from.


For Loop app, changing the time for travel is really straight-forward.  You will use the RileyLink command within the app to “set pump time” for the timezone you are in when you are ready.  Everything will continue to work smoothly, even if you do not immediately update the time.

For OpenAPS, typically the timezone travel recommendation is to leave pump and rig times unchanged if the trip is short.  For longer trips, you’ll need to login to the rig to change the rig’s timezone, and possibly wait some time to clear out future data entries.

Loop vs OpenAPS update

Jumping into the DIY closed loop arena can be tough.  Feels like a big commitment and huge change (and it is).  Choosing which system you want to use can be overwhelming.  Worrying about whether you get “the right” system for your needs?  Awhile ago, I posted a comparison of Loop and OpenAPS systems from the perspective of a parent of a t1d kiddo.  Since that original posting, lots of improvements have happened in both systems and I’ve had more time on each system, so it’s time to update the comparison.  🙂

My evaluations have always been colored by our particular situation…my almost 15-year-old daughter has type 1.  She’s in public high school, pretty darned independent at school and only uses the school nurse as a means of storing backup supplies.  BUT, I’m also exposed to many other families who use DIY closed loops for their smaller kiddos at schools that are less-than-friendly to looping.  So, I’ll try to keep the full spectrum of parent/kid users in mind.

By way of short background, we started using Loop from September 2016-December 2016, OpenAPS from January 2017-June 2017, and back to Loop from July 2017-current.  So, quite a bit of time using each of the systems.

My  comparison focuses on these aspects:

  1. Size
  2. Cost
  3. Durability
  4. Ease of build
  5. Ease for caregivers/school nurses
  6. Troubleshooting
  7. Reliability
  8. Portability
  9. Ease of use
  10. Kid-specific features

I intentionally left BG control off the list is because either system is capable of achieving great BG results.  BUT, the ease/difficulty in the WAY you have to adjust your thinking, actions, or lifestyle to achieve the desired control was important to me.  And I’ll get to that shortly.

Size, Cost (Advantage: Even)

These factors are virtually the same between the systems.  Both systems can be easily put in a small box about the size of a tic-tac box for pretty much the same cost.

  • OpenAPS: Each rig costs about $163 for the parts, most people tend to want to build two rigs once they get the system setup with their first rig.  Papertrail service, to remotely view the loop’s detailed logs and help with troubleshooting, is about $5 per month.  Not required, but is very helpful.
  • Loop: Costs $99 annually (for Apple developer program enrollment) and the RileyLink costs $135.

Both systems consist of a small circuit board and a rechargeable lipo battery…so the same care and durability should be expected between the systems.  We plug both systems in for recharge nightly and they last the whole day on the one charge.

  • OpenAPS: we had to use a 2500 mAh battery and got approximately 14-16 hours of use, but took all night to charge (about 8 hours).  The 2000 mAh battery would get about 12 hours of use…and we found it tended to need recharging just about as we sat down for dinner or homework.  Bigger battery kept us from having that interruption.
  • Loop: RileyLink takes about 2 hours to charge and lasts at least 36 hours (we haven’t tested it longer than that, but I think about 2 days would be the limit)

OpenAPS Rig on the left, RileyLink on the right.


Durability (Advantage: slight advantage to Loop)

After months on each system, I’d give the slight nod to Loop for this category.  We’ve had four rigs setup while we were using the OpenAPS system and had two explorer boards stop working randomly during that time.  The radio system just stopped working.  I’ve also seen several other families deal with bad explorer boards, too.  So, it’s not the OpenAPS code that is the issue…but rather the board that provides the communications with the pump had problems.  The company that makes the boards replaced them free-of-charge and was very helpful, but it does take some frustration and attention to diagnosis when the boards fail and deal with the fix.  The company recently started to make the boards thicker to help with the radio issues…those boards have only been released about a month ago so time will tell if it helps with the issue.

We’ve used four RileyLinks without issue (typically we only use one at a time, but we’ve rotated through which one we use because I like to test gear a lot).

Ease of build (Advantage: Loop)

For first time builders, there’s a big difference in this area.  Loop will be an easier initial build.  I’d say the average first-time builder takes a couple hours to build Loop and a few days to build OpenAPS.  If you’re familiar with both systems and want to build a new system from scratch again, the times shorten significantly.  Time to build a new Loop app is about 15 minutes and OpenAPS is about 2 hours, if you’re already comfy with the documents and guides.

The building guides for both systems have been updated a lot over the last year.  Both systems have very helpful groups on Gitter where people will help you through the setup process…Loop and OpenAPS.  And the Facebook group Looped is infinitely helpful and I’m on there all the time.

That said, Loop can initially seem like a more relaxing build for the people who are uncomfortable with “code” since much of it is done through the Apple interface (pictures and symbols, points & clicks).  OpenAPS is done through linux commands and scripts.  HOWEVER, do not let this deter you.  Both systems will take you into places on your computer you have likely never been before (Loop to Xcode, OpenAPS to Terminal), and you will live to tell the story.

I’m here to say…don’t let your intimidation stop you from trying either or both systems.  Let the features you want drive which system you choose…not fear of the building process.

Ease for Caregivers/Small Kids (Advantage: Loop, depending)

Here’s one that adult t1ds probably don’t have to worry about.  Can a school staff member reliably dose your kid with insulin through the closed loop system?  On my previous evaluation, the advantage to this category went to OpenAPS.  HOWEVER, Loop has been updated significantly since then and a lot of the stumbling blocks to safe caregiver use have been eliminated.

One difference to keep in mind if you’ve never used either system, Loop uses the app on the iPhone to enter meal carbs and calculate/administer boluses; whereas OpenAPS uses the pump.

If you have a resistant-to-change school district, they may perceive Loop to be “too different” than normal pump therapy and ask for special training or a note from Endo authorizing the use.  OpenAPS generally could fly under the radar since the bolusing looks more normal…BUT, there is a caveat on that as discussed in the Meal Entry bullet below.

  • Failed boluses  – How does the system handle when a bolus fails to be delivered by the pump?

Loop: Every once in awhile, for whatever reason, a bolus command in the Loop app will not go through.  A notification will appear almost immediately on the iPhone saying “Bolus may have failed, safe to try again”.  Our experience has been that the bolus failures aren’t very often.  We’ve had two bolus failure notifications in the last two months of use.  Only one of them was unnoticed by my kid.  It was a 60g croissant sausage sandwich from Jack-n-Box.  By the time we noticed the missed bolus, Loop had already provided sufficient high temps quickly to cover the missed bolus and we didn’t suffer any high BGs as a result.  How was this possible?  Well, with Loop when you enter a carb to start the bolus wizard, that carb entry is saved in the system…whether or not the bolus is administered.  So, Loop knew the 60g was coming and safely provided the necessary insulin through those high temp basals.  Pretty nice feature.

OpenAPS: Since the boluses are entered from the pump, generally speaking you won’t miss a bolus unless the bolus fails midway through and the caregiver had already stopped looking at the pump.  Likely this would be because of a site issue, so hopefully you’d hear a no-delivery alarm to help with that. (Advantage OpenAPS)

  • Low BG bolusing – How does your school deal with bolusing when the kid has a low BG?  Do they wait to bolus until later and let them eat immediately?  Do they still give the bolus but just shorten a pre-bolus time?  Each school handles these situations differently so it’s a little hard to compare Loop and OpenAPS evenly.

Loop has a minimum BG guard which will prevent a bolus from being administered while the BG is below that user-set level.  That level used to be buried in the code for Loop app, but now it is a simple editable setting in the Loop app itself.  Much easier. For example, the parent can set that “minimum BG guard” value at 60 mg/dl and now Loop app will not provide a bolus recommendation if the kiddo is below (or predicted to go below 60 mg/dl).  You will have to make the caregiver aware of Loop’s minimum BG guard in advance so that they are not caught by surprise if a bolus is not recommended when BGs are lower than the guard.  The carbs will be saved, and insulin will be provided (A) through high temp basals as BGs recover or (B) careprovider can go back to the Loop app when BGs are above 60 mg/dl and press the bolus tool on the app to deliver whatever remaining bolus is needed at any time.  If going with option B, the Loop app will automatically subtract out from any recommended bolus any insulin that’s been delivered by high temp basals since the meal was eaten so that the caregiver will not over bolus in those situations.

For OpenAPS users at school, likely the school will operate more traditionally and simply wait to bolus until they confirm the kid’s BGs have recovered before entering in the carbs and bolusing using the pump.  The downside is the traditional low BG bolusing means sometimes kids are either over-carbed for the low (so that school nurse can hurry them out of their office) or the bolus is completely forgotten about unintentionally.  If the nurse waits “too” long to come back and administer the bolus, it’s possible that the OpenAPS loop will have delivered extra insulin via high temps while BGs climbed from the initially unbolused meal.  If the school nurse doesn’t decrease the bolus by any amount (to account for the insulin delivered by OpenAPS high temps), it could lead to low BGs later if the delay in bolusing was long enough.

Depending on the skill and attention of the school nurse, the advantage in this scenario now may lie slightly to Loop users.  Since any bolusing for Loop is done through the app, Loop ALWAYS knows about any insulin on board and will adjust any recommended boluses accordingly.  But, since OpenAPS is through the pump’s bolus wizard (which does not know about insulin on board from loop actions), the results could be dependent on the whether the school nurse understands/pays attention to the fact that insulin may have already been delivered by the OpenAPS system.  But again, it would depend on the caregivers and how aggressively the school tends to deal with low BGs before meals.

Personally, I like the Loop in low BG bolusing situations.  If I’m not sure why my kid is low (could be from recent strenuous PE class? could be from yet-undetected illness?), I tend to prefer how Loop can administer the bolus incrementally via high temp basals (using that Option A above)…so in essence, she will be more likely to get a (lower total) bolus that reflects the recent increased insulin sensitivity that may be causing her to be low at that time.  She will enter her carbs in the Loop app and hold off on a bolus.  If her BGs recover normally, Loop will cover her normally via high temps.  If her BGs continue to stay low, Loop will not bolus her as much (default to scheduled basals at most) and wait until BGs recover before safely providing any additional bolus. (Advantage depends)

  • Double Carb Entry – When a carb entry is entered in the Loop app, there is a “save” button to move you onto the bolus recommendation part (just like a pump’s bolus wizard).  In both Loop and OpenAPS, an entered carb is saved by default.  Backing out of a bolus wizard does not cancel the carb entry.  In Loop, the caregiver/kid can go into the app and cancel/edit the unwanted carb entry.  However, in OpenAPS you cannot edit the entry.  So both systems require a consistent method of carb entry to prevent unintentional double entries.

Also does your kid ever say they are hungry for a muffin and carrots?  You bolus for both, but then he only eats the muffin?  Leaving you with carrots and ranch sauce bolused for, but uneaten?  In Loop, you can edit OUT carbs that your kid may have decided not to eat.  While this doesn’t have the ability to suck out the insulin already delivered for the carbs not eaten…by editing the carbs lower, you are able to tell Loop to more aggressively reduce basals in the near future.  Depending on the amount of carbs not consumed (yet already bolused for), you may be able to simply have Loop suspend enough basals to recover without needing any additional interventions later.  (Advantage Loop for the ability to edit/delete carbs already entered)

Experience note:  I am unsure of the reasons why, but there were instances in OpenAPS where the system perceived double carb entries even when the bolus wizard had not been backed out of. I never nailed down the source of the double carb entries, and I only noticed them because I had been watching Nightscout at meal times.  In those instances, we would set a high temp target and wait for the extra carbs to decay in order to prevent the OpenAPS loop from overtreating carbs that weren’t really there.  It would have been nice to edit out those carbs, but there never was a way.  This occasional error was a bit disconcerting because there was not a way to be alerted to the error except by noticing it on Nightscout.  I know they (the OpenAPS dev team) are actively working on how carb entries are read and uploaded, and making sure that those duplicate carb errors are minimized.  There’s also been a few reports more recently about errant carb decay (carbs not decaying fast enough)…I’m not sure the status on those.  I’m certain that issue is also being actively evaluated.

  • Meal entry – Originally, I called this category “carb absorption time” but really it’s probably better to call this “meal entry”. This category has changed significantly since this comparison was originally done.  In the original comparison, the advantage in this area went heavily to OpenAPS, but now that Loop has been updated with dynamic carb absorption…I’d call this even between the systems. The new versions of Loop have nifty food icons that a caregiver can use to enter in the carb absorption times of the meals.  They no longer need to diligently follow notes from mom or be inherently talented at estimating food types (and neither do YOU!  woohoo!).  The Loop app is much better now dealing with carb absorption times for foods.  While having to enter a carb absorption time does add one complexity to Loop over OpenAPS (you don’t have to enter carb absorption time in the pump bolus wizard after all), it also now bring with it a big advantage…which is more fully discussed in the Ease of Use section below.

One note about OpenAPS meal entries for caregivers/school nurses is that you’ll have to train them to NOT enter a BG reading in the pump’s bolus wizard to enter a meal.  If you enter a BG in the pump’s bolus wizard and the BG is higher than target, the pump will offer additional insulin as part of the meal bolus to help “treat” the high BG.  HOWEVER, if your OpenAPS rig has been looping, the loop has already provided additional insulin via high temps to treat that high BG.  Your pump is unaware of that extra insulin.  By using BG entries in the bolus wizard, your caregiver will likely administer more insulin than needed.  So, while OpenAPS looks more traditional and may be more comfortable for loop-resistant school nurses, you will need to make sure they are complying with instructions to NOT enter BGs in the bolus wizard for treating high BGs. (Advantage even, both require a short school nurse discussion now)

  • Emergency tubing/reservoir changes – In older versions of Loop (and in the first comparison post), this area was a significant advantage to OpenAPS.  Loop users used to need to do a special set of procedures if they were priming out air bubbles or changing tubing in the middle of the day (without a reservoir change).  Those issues have since been eliminated in Loop updates and now the systems are no different between Loop and OpenAPS.  No more special procedures needed.  (Advantage even)
  • Net IOB – The Loop app tracks net IOB (IOB from both boluses and basals). As such every Loop bolus and correction is automatically consider net IOB. However, Medtronic pumps do not track IOB from temp basals. In OpenAPS, since there is no app, netIOB is usually seen in Nightscout (in fact, the IOB pill will even break down the basal IOB contribution). Caregivers/kids will need to be aware that the usual “take BG before a meal and add a correction adjustment to meal bolus using pump’s bolus wizard” should not happen. Most OpenAPS users will only bolus for their meals using straight carb ratio, and not use the pump to suggest a +/- correction bolus.

Caregivers can use Loop’s main screen or Nightscout to view current net IOB.  For OpenAPS, caregivers will have to use Nightscout to obtain net IOB.  (Advantage Loop, simply for ease of access to the information)

  • Corrections – Corrections under both systems are about even now.  In both systems, corrections during stubborn highs should be applied very conservatively by any caregivers and only with consultation with parents.  (Advantage even)

Troubleshooting (Advantage Loop)

Loop relies on the RileyLink for communications, OpenAPS relies on the explorer board.  Both feed information into Nightscout about the status of those communications and looping.  A remote parent can receive information about potential problems that may be causing the loop to stop running.  OpenAPS users can use Papertrail to give even further detailed information about the rig’s errors, but that is optional and costs $5 per month.  Papertrail will require internet connection in order to log the error messages as well (so if the error involves a failure to get internet connection…papertrail won’t work).

Originally, I had this category Advantage OpenAPS, but I’m going to have to revise this based on watching more and more users come online for OpenAPS over the last half year or so.

When I first started OpenAPS (and through most of my OpenAPS use), all my troubleshooting steps pretty much only had to involve restarting the rig.  HOWEVER, there’s been more instances as time went on of errors that required a rebuild of the OpenAPS loop.  Which means, the OpenAPS rig wouldn’t work until you can find time to login to the rig with a computer connection.  Luckily, we had pretty smooth sailing for our rigs…but admittedly, others that I’ve been helping have not had the same experience.  Some people had flaky wifi routers or wifi dead spots (those issues have been very frustrating for some people).  Some rigs suddenly have files that corrupted and needed to have the files removed before the loop would work again (git lock errors).  A lot of the issues seem to happen when the rig moves in and out of wifi areas or when the battery dies.  That said, when you have time to reach a computer, you can either spend time trying to fix the specific issue or simply erase and rebuild the loop.  An erase and rebuild of the loop, once you get used to it, can be done in about 20 minutes…but does require finding time in front of a computer.

So this is a tough category.  For myself, looking at logs provided a lot of insight into the troubles that my OpenAPS rig was having.  BUT, for other many other users, the logs are confusing and overwhelming.  The OpenAPS docs have had a lot of updates to help with troubleshooting aspects of the system…and that has helped a lot of people.  But, the requirement to login to rig in order to fix some of those errors has been a pain for some people.

Loop app, when it has stopped looping, has never taken more than a reboot of the dexcom and/or Loop apps, and sometimes a BT toggle on/off.  The app has never suddenly stopped working to the point of requiring getting to a computer to rebuild the app.

Reliability (Advantage Loop)

How often does each system go down?  How do you find out the system has failed?  The answer is “it depends”.

The original post gave the advantage in this area to OpenAPS.  Our original Loop app had frequent communication failures and we’d regularly go 15-20 minutes without looping about 2-3 times a day.  We’d retune the RileyLink, get communications working again, but it was a bit of a pain.  In fact, Anna’s love of OpenAPS initially was that she no longer fussed as much with keeping gear working during school day.  Well, I’m happy to report there were some code improvements since we’ve come back to Loop use, and they are most definitely noticeable.  We’ve now only had one period of time with poor Loop communication (fixed in 5 minutes) and Anna no longer has to interrupt her day with any Loop troubleshooting.  We’ve traveled in car, on planes, all over school campus, and such…no connection problems.

Since updating, we’ve had only three instances of Loop failures.  The single time where restarting the Loop app fixed the problem (as described above).  The other two times both were the result of the iPhone being shut down completely and therefore the dexcom app and Loop apps being turned off. If you have your iPhone setup to update iOS automatically…the reboot at the end of the update will mean your Share app is off until you specifically restart it.  Which means you won’t be looping until you do that.  Or if your teen lets her iPhone battery die, she will need to remember to restart the dexcom app when the iPhone restarts.

Our OpenAPS system was quite reliable for us.  But, we did have some periods of downtime; typically when she was switching from a known wifi network and the rig would try to connect to her iPhone’s hotspot.  Usually the rig would automatically switch, but sometimes she would have to restart the rig to get it to work.  The restart isn’t such a big deal (unless your rig is in a case that makes it hard for the kid/caregiver to access the power button).  HOWEVER, the issue is whether or not the kid/caregiver will NOTICE there’s a failure in the rig and whether they can do something about it.  That’s been our biggest Achilles heel with OpenAPS and a kid.

Anna doesn’t check Nightscout.  She also doesn’t check her pump to see if temp basals are enacting.  She just keeps moving about her day…never checking if her loop is looping.  We’ve tried pebble watches to alert her to loop failures (but inevitably she just hasn’t gotten in the habit of keeping the watch even reliably going…9 times out of 10, the pebble has been disconnected and she doesn’t even notice).  So with OpenAPS, she would never notice if the rig stopped working.  This bit us in the butt a few times.  Murphy’s Law is that the rig always fails at the times when it will be most inconvenient (and in ways you hadn’t planned for).

Situation 1: Most notably, one time she’d gone out with friends to eat sushi (new food for her), didn’t want to be interrupted by mom (mom texts are ignored), and was nowhere near known wifi networks. Just after leaving the house, her rig didn’t successfully connect to her iPhone’s hotspot, which meant the rig couldn’t loop.  Unfortunately, the rig had also set a 120 min temp basal of zero (temp suspend) as she headed out the door.  Meaning she went to eat sushi, without a loop to help, without checking phone for mom texts, and on a 120 min zero basal setting.  Needless to say, that didn’t end pretty.

Situation 2:  We went to the end-of-track-season banquet.  The banquet was held at a building NEAR the school’s bus barn.  I never even gave this a second thought.  HOWEVER, the way our school’s IT department has configured their wifi network…all the networks across all campuses and buildings have the same wifi name and password.  BUT, her rig is only specifically cleared on certain locations (the high school and middle school…not the bus barn).  So when we got to the banquet, her rig connected (without us realizing it) to the bus barn’s wifi network.  However, since it was not cleared on that location, the rig could not actually loop using that connection.  Further complicating things, the cell reception there was incredibly slow and spotty, so Nightscout and Papertrail wouldn’t load on my phone.  I was in the dark about what was going on.  Anna (being the independent teen), didn’t want to sit near us so we didn’t have her receiver to look at or hear (and it was a little noisy in there).  Turns out that with the nerves of the banquet, her BGs took off and there was no looping going on to stop it.  We walked out of the banquet and could finally hear her receiver alerting to a BG of 280 mg/dl.  So yeah…that sucked.

Situation 3:  School redid entire wifi network, but forgot to add Anna’s rig back on the “all clear” list.  No OpenAPS all day while I tried to get them to resolve that.

At least with Loop, she’s regularly seeing the screen that indicates if Loop is looping during the day.  She can’t avoid seeing if the Loop circle is red or green every time she goes to bolus.  So, this visual provides a nice opportunity for not-so-invested-people (aka not parents) to periodically check if the loop is working as opposed to depending on Nightscout check-ins.  Also, the Loop sends notifications that appear on her iPhone screen proactively at 20, 60, 80, and 120 minutes if the Loop isn’t going.  So…for a kid who isn’t habituated to paying attention (or wanting to pay attention) to loop status…those notifications and visuals help.  Especially since she doesn’t keep her Pebble functioning.

For my teen, cultivating independence is a big deal right now.  This may not be the case for parents of little kiddos, but for Anna and me, the Loop app setup is providing a little easier opportunity for her to be responsible for looping with fewer mom interruptions.  I know she will see a notification locally from her Loop app if she needs to restart the app.

Plus, not being dependent on cell reception and wifi has been beneficial.  I never anticipated some of the wifi/cell issues with OpenAPS like I’ve described…but they do happen occasionally and seemingly when you haven’t got a backup plan in place.  Murphy.

Portability (Advantage Loop)

There’s been no significant changes in this area since the last comparison.  The portability of Loop is pretty great.  You could take it to the middle of nowhere and still be able to run a closed-loop…no internet, wifi or cell needed.  The Loop user will be able to see all the important looping information like IOB, current temp basals, COB, and such.  Loop needs internet connection (aka cell phone reception or wifi network for iPhone) for the parent to remote monitor things on Nightscout still.  (If I were reviewing portability as an adult t1d, Loop would be an easy advantage.)

There are options for running OpenAPS without internet like Loop (aka “camping mode”).  The disadvantage is that your rig gets bigger and you need to preplan for offline use (because you’ll need to carry the OTG cable and spare USB battery).  You’ll need to directly plug-in the dexcom receiver to the rig and a USB portable battery.  You also won’t be able to monitor what the loop is doing really when operating offline.  (Android phone users have some better options for offline use and visualization.  See the OpenAPS docs for the info.)

One thing that we noticed with Loop vs OpenAPS in terms of portability would be a factor I’ll call accessibility.  We hadn’t really run into this until we attended a wedding a few months ago.  Anna was on OpenAPS at the time.  She was wearing a dress, and had a pair of booty shorts that she tucked her pump into for the evening.  I asked her “Are you sure you don’t want to use Loop tonight?  You’re going to have to dig up your dress to bolus for the evening if you stay on OpenAPS.  Might be a pain.  Maybe wear the pump on the outside of dress?”  She swore up one side and down the other that she had no problems just going to the bathroom to dig for the pump when needed.  So, off we went to the wedding…but I had that nagging parent-feeling that tells you “You know better, Katie.  She’s not going to do what she says she’s going to do.”  You know where this story is headed, right?

The pump was apparently NOT pulled out to bolus.  Food was eaten, BGs climbed.  And when I went to check on Nightscout to keep an eye on things…turned out the wedding was in the only cell dead spot in the middle of Los Angeles.  So…not only did she not bolus, we also didn’t have looping.  It was a really rough night.  Would’ve been nice that she had one less obstacle to bolusing that night…because sometimes teen brain stops at the very first obstacle it encounters.  And if that’s a hidden pump, that may just be enough.

Also worth noting, the OpenAPS rig has longer communications reach than the RileyLink.  We found that one OpenAPS rig could still reach Anna from 2-3 rooms away in our house…whereas the RileyLink is more like 1, maybe 2 rooms reach.  Anna has adapted, as I imagine most kids do, to carrying their gear with them in a pack…meter, receiver, phone, and rig/RileyLink.  She is equally likely to walk away from rigs/RileyLinks as she is to walk away from a receiver/phone…so the gear grouping/toting has proven to be less of an issue than I originally expected.  Each system has had equal instances of being left behind. 😉

Finally, one quick note about portability that we learned…the OpenAPS rig gets a little too hot to be kept in a pocket.  The RileyLink stays a lot cooler than the OpenAPS rig and can still comfortably sit in a pants pocket.  Anna has kept both her OpenAPS rig and RileyLink in her purse, which then gets stuffed into her backpack for the school day.  Both maintained connection just fine being transported like that.  But, I suppose if you are thinking about OpenAPS in pockets, it is worth mentioning that you’d want to consider an alternative to pockets due to heat.

Ease of Use (Advantage Loop? OpenAPS?)

This category originally went to OpenAPS because the carb absorption times were so difficult for many people.  It was just too hard to trust caregivers or kids to estimate the carb absorption of new foods on their own with Loop.  Now, I think that gap is gone and there’s actually some really cool features that have been added to both systems since the original post:

Loop: dynamic carb absorption, food icons, and temporary “pre-meal” target (coming very soon)

OpenAPS: single microbolus and unannounced meals

There’s a good deal of personal preference about the physical use of each system to bolus.  Anna has gone back and forth about which system she prefers to bolus from.  When she’s actively using the Loop, she loves the ease of bolusing from the iPhone. (Perhaps in time, she may even decide to wear an Apple watch and use the bolusing from watch part of Loop…but she isn’t interested in that yet.)  When she’s actively using OpenAPS, she likes how easy it is to just pull the pump out and bolus.  None of her teacher give any side eye to her using her pump…but some teachers have to be reminded at the beginning of each school year that her iPhone is how she boluses when using Loop.  So, she likes that OpenAPS doesn’t catch the teachers eye as much if she pre-boluses in the class before lunch.  Basically, Anna seems to physically like whichever system she is currently using fairly equally.  I think she’s an oddity for that.  Probably most people have more solid, unchanging personal preferences on whether they prefer pulling out a phone vs pulling out a pump.

BUT, here’s where Loop has been TREMENDOUSLY upgraded since we had originally used it.  The dynamic carb absorption update now makes it so easy for Anna to bolus herself completely independently…even for hard food like pasta, pizza, Chinese food, and quesadillas.  On old Loop, we would have to split the boluses up, splitting the carb entries up, and sometimes editing the entries to better match the carb absorption we were observing.  It was not super easy, but I got used to it.  Anna, however, never got used to the more complex boluses and I would always have to narrate how to split up the carbs, carb absorption times, and bolus for the bigger meals.  When she was at school, I couldn’t see what she had entered for the carb absorption times, and would have to hope she (or a caregiver) had gotten it correct.

The same split bolusing technique applied in OpenAPS to a certain extent; we still split bolus the big meals to avoid early lows and try to still catch the later highs.  But, the noticeable improvement was that I didn’t also have to deal with carb absorption time issues. OpenAPS has its own version of a variable carb decay based on observed BG trends…so it was a big improvement in terms of the flexibility of the system.  Not having to tell Anna (or her having to guess) what the carb absorption time on foods was…that was nice.  However, OpenAPS was still not “smart” ahead of time about the meals we were bolusing.  OpenAPS didn’t care or differentiate, ahead of a bolus, whether Anna is eating 60g of fruit or 60g of pizza.  I would still need to adjust the bolus if the food needed an extended/split bolus.

When dynamic carb absorption came to Loop app in July 2017, it turned what used to be Loop’s biggest flaw into Loop’s biggest asset (in my opinion).  NOW, finally, I can reliably tell Loop that a meal will be a long absorption meal…and it does the split bolus FOR ME.  Or rather FOR ANNA.  It’s how I always imagined a true bolus wizard should work.

You can read a detailed description about how Loop boluses here.  A short version of how Anna boluses for a meal like a bowl of pasta now…she roughly knows the amount of carbs in her bowl of spaghetti, usually she eyeballs between 75-90g of pasta when she eats that for dinner.  She goes to the Loop app and selects the food icon that is a depiction of a bowl of pasta, and enters the total grams (and sets time stamp ahead 20 minutes for her pre-bolus).  Loop app knows that pasta takes a long time to digest, so it calculates the amount of bolus that is safe to give up front (including knowing she is being prebolused), and recommends that amount.  Loop then watches Anna’s BGs and when it starts to see that the meal is finally absorping enough that it is safe to provide more insulin…Loop high temps to provide that remaining bolus.  It is much like an automated extended bolus now.  Without me needing to lock it in upfront, and having the flexibility to adapt if BGs come slower or faster, higher or lower than I had expected at the beginning of the meal.

On the OpenAPS side, single microbolus (SMB) and unannounced meal (UAM) features have been released since the original comparison.  These features can allow for faster treatment of rapidly rising BGs.  This is especially advantageous in situations were kids might eat without remembering to enter in the carbs or bolus.  The loop is going to be able to treat a little more aggressively, within reason, for those situations.

Both OpenAPS and Loop have the ability to set a temporary target to help pre-bolus kids easily.  Simply enacting a temporary lower BG target (such as 80-80 mg/dl) an hour before eating will help pre-load some insulin before a meal and help curb post-meal spikes.  With OpenAPS, you can enact this feature using IFTTT and a careportal entry.  With Loop, there’s a new “pre-meal” target button on the app (different that the workout temp target setting) that will set the lower target you specify for up to an hour before the meal or whenever a carb entry is made, whichever is sooner.  (note, this feature hasn’t been merged for release yet, but will be available soon.)

Only OpenAPS will allow you to remotely set a temp BG target (using Nightscout’s careportal).  When my daughter went to track practice using OpenAPS, I could set a temp BG target (while I was at my work desk) to help keep her in a slightly higher target range.  I could also easily cancel the temp target if practice gets out early or situations change.  For kids that are too young (or teens that are too distracted) to know when a temp target is helpful…this remote feature is AWESOME.


Kid-specific features (Advantage OpenAPS)

There are some feature that OpenAPS specifically designed to adapt for kid t1ds.  We haven’t used or tested these, but they may be of interest to some of you reading here.  There’s been no change to these features since the original comparison.

  • Override High Target with Low: “Defaults to false, but can be turned on if you have a situation where you want someone (a school caregiver, for example) to use the bolus wizard for meal boluses. If set to “True”, then the bolus wizard will calculate boluses with the high end of the BG target, but OpenAPS will target the low end of that range. So if you have a target range of 100-120; and set this to true; bolus wizard will adjust to 120 and the loop will target 100. If you have this on, you probably also want a wide range target, rather than a narrow (i.e. 100-100) target.”

Conclusions (Advantage Loop or OpenAPS?)

Which system will work best for your kid and your lifestyle?  I suppose you’d have to answer some upfront questions to decide which aspects are priority for you.  The gap between the systems for kid use has tightened tremendously.

  • If you have a small kid, who would really benefit from being able to set remote temp BG targets while they are at school or a school district who would prefer a more “normal” looking diy closed loop system that wouldn’t attract as much scrutiny/attention…OpenAPS may be the best system because it’s the only one with remote BG targeting and bolusing from a pump is usually something a school nurse is used to.
  • If you have an older kid who wants to keep pump hidden, likes to use their phone, and is more “locally” in charge of their diabetes care…Loop may be the best system.
  • If you have a need to be seamlessly internet-independent because you live in a rural area…Loop would be best, or be prepared to carry a larger rig for OpenAPS and have limited ability to see the rig’s actions while offline.


Some side notes about what we’ve noticed in the last several months, too.

IFTTT:  I never used IFTTT or mentioned it in my original comparison because we hadn’t had it setup at that point.  However, once we were on OpenAPS, we did eventually set up IFTTT to have single button actions.  Because again, trying to eliminate any obstacles from the teen brain doing the right thing.  Turns out that many of the IFTTT buttons from OpenAPS are still super useful on Loop app.  So…I’d recommend that parents of Loop-using kiddos also setup IFTTT buttons for things like dexcom sensor sessions, tracking pump battery life, and infusion site changes.  Probably the best IFTTT button we installed allows Anna to tell me in a single touch “Hey mom, I’m walking away from my phone/rig/receiver for a little bit…don’t worry about it.  Things aren’t broken, this is intentional.”  By seeing the notification on my phone, I can NOT bug her about why her CGM doesn’t have data or whatnot. Sure, she could text me the same thing…but teen brain won’t do that amount of effort and school sometimes moves too fast for texting.  A single button press she will do, however, if it saves her from having a mom-interruption.

No more Loop issues:  When Anna and I discussed which system she would take back to school at the end of summer, she hemmed and hawed.  She liked parts of each.  But, ultimately she said she wanted to use Loop system IF it stayed connected and she didn’t have to fiddle with it.  With the improvements to the app since we last used it, this is finally holding true.  Reliably staying connected now.  She likes how easy the bolusing for ALL the different food types is now with Loop.  Again…finding the theme?  Less mom-involvement.  Like she prioritized all the things that take me out of her life.

Hormones:  With Loop app, we simply manually adjust basal rates when her period comes.  I had hoped that autotune on OpenAPS would be able to completely handle hormone shifts automatically…but the changes were just too large and fast for autotune to keep up with them in the end.  We did keep autosens (different than autotune) enabled for much of our time on OpenAPS and it helped take the edge off of some of her swings, and also with shorter term post-track workout sensitivity.  However, we did have occasional times where autosens went the opposite direction of where we wanted things to go…so a few times we had it disabled on OpenAPS.  I do see that auto-ISF may be a feature coming to Loop later…and if so, I’d be very interested in seeing that feature.  I think auto-adjustments of basals and ISF is where a lot of advancements lie. (After all, it’s what the 670G is supposed to be doing…)

Remote boluses:  This is purely a “Me” issue…but I do love NOT touching Anna’s pump nearly as much while using Loop.  Since she is old enough to bolus herself, it’s not like I was touching her pump all the much to begin with on OpenAPS…but at night if I ever need to make a bolus or a change to a basal rate…it is very nice to just be able to use her phone to make those changes instead of digging under the covers and finding her pump (she tends to hit people who grab for things under the covers when she’s sleeping…a good habit for a teen, one I will cultivate.).  For parents of small kids who are used to giving remote boluses on Animas pumps, you may find that Loop feature still really appealing.

Redundancy issues:  I think about the Murphy’s law parts of our setups a lot.  When we were using OpenAPS, we had two rigs in her room each night to provide automatic redundancy.  That did save us a couple of times that one rig went down unexpectedly in middle of night.  If our Nightscout failed or mlab service stopped, our OpenAPS rig would stop working (unless we’d plugged the receiver directly into the rig and had a power source in other plug on rig).  Loop app is unaffected by any Nightscout failures.  When Anna’s pump died unexpectedly from a button error, I also learned that switching pumps is easier on Loop than OpenAPS.  For OpenAPS, you do need access to login to your rig and change the pump’s serial number within the files on the rig.  For Loop, it’s a setting within the app that you can change without rebuilding anything in the app.  To help with the Murphy’s law prevention, we got in the habit of having a spare OpenAPS rig rubber-banded to the spare pump in the closet, so that it could be grabbed in an instant and put into service if we weren’t around computers.  If you’re a Murphy’s law planner, you might want to consider that in your plans.  I also keep a Loop app built on the other iPhones in our house, in case Anna’s phone gets broken.  At least then she could temporarily use that phone until her’s could be fixed/replaced.

Pump battery life:  Random tidbit and low on priority list, but our lithium AAA batteries last just over 8 days on OpenAPS and just over 16 days on Loop.

My end conclusion from the previous post’s comparison still applies:

“I’m just trying to find ways that we talk less about diabetes and more about everything else.”

With the improvements to Loop and OpenAPS, both systems are pretty amazing for accomplishing that.  Dang, we are lucky.  The ease of bolusing for pasta and pizza have sold me on Loop.  I’ve been waiting for the day that I would have a system capable of keeping us under 150 for pasta, Chinese food, and pizza without needing more than a single communication with the pump/loop.  It’s finally here.  Double bonus that Anna can now do these boluses completely independent because of food icons…who would have ever guessed?!



Why DIA matters

DIA: Duration of Insulin Action

At our first endocrinologist appointment, I distinctly remember the doctor telling us that rapid acting insulins (like humalog and novolog) had insulin durations of about 5 hours.  I remember looking at the insulin curves…and I remember that the curves were distinctly skewed to the left.  Meaning, most of the insulin “action” seemed to be in the first few hours and it peaked around 90 minutes.  I also remember them saying to wait until about 2 hours had passed since the last insulin dose before considering a corrective dose of insulin…to give that insulin its due time to work.  Based on that information, I had concluded that the “tail” of the insulin duration (from hours 3-5) contributed relatively little to the insulin experience.  After all, looking at curves like the one below, it would pretty easy to say that the effect of insulin seems pretty darned small between hours 3-5 compared to hours 0-3.


Back when we were on omnipod, we used a 2 hour DIA.  Basically, we picked that setting because it seemed like after about 2 hours we noticed that insulin seemed to wear off…corrections from high BGs slowed way down after 2 hours, or our BG control of food seemed to falter for big meals around 2 hours and we’d need to give more.  We had pretty great control with 2 hours of DIA.

Our omnipod system basically only used the DIA to calculate the insulin remaining after it had been given…the insulin-on-board (IOB).  So, if BGs were coming down too quickly (have you seen what happens to kids’ BGs on trampolines?), we would look at the IOB and eat an appropriate amount of carbs to try to offset the remaining IOB.

I always knew my estimate of DIA was probably a little off.  I knew I was ignoring that little bit of insulin effect from hours 3-5.  Especially because when we had large carb meals…the system would tell me that her insulin had gone to zero, but Anna would still be dropping.  On large carb meals, those “little bits of tail” between hours 3-5 added up to a significant amount because our boluses were proportionately bigger.  The “noise” of everyday diabetes variations were less apt to hide the 3-5 hour insulin on those big meals.  But most of the time 2 hours seemed to work “about right”…so we stuck to it.

Since we’ve started to manage diabetes with closed loop systems (OpenAPS and Loop), the effect of DIA (and especially that late insulin effect tail) has become more apparent and important.  So, I thought it would be good to discuss just how DIA can impact closed loop operations.

I like to visualize carbs and insulin as opposite effects on BGs; one upward and one downward.  I have several visuals that I typically imagine…my favorite two are crowd surfers at concerts and wet paper towels holding coins.

Imagine carbs are the hands below.  Imagine insulin is the weight of the crowd surfer.  If you had a bunch of weak little kids trying to hold up The Rock (an all fat/protein meal bolused upfront entirely)…BGs would get crushed low.  If you had a tiny little baby being held up by rambunctious steroid-filled weight lifters (underbolused slurpee)…that BG might go sailing high.


Or how about the wet paper towel is a meal and the coins are insulin dosing. Can you put too many coins suddenly on that wet paper towel such that it can’t support the weight of the coins?  Yup…low BG.  Give that towel time to dry out, get strong (carbs absorb)…then it would be able to support those coins later.


With those comparisons in mind, we can look at the geeky explanation a bit more.  Simply put, carbs make your BGs go up.  Loop used to predict the “shape” that carbs would absorb as a static value much like shown below.  You’d tell Loop the time for carb absorption, and the model said it would peak halfway through….BG impacts would look much like my hand-drawn sketch below.  (Please keep in mind these are conceptual drawings…not to any scale exactly.)

dia 1

And insulin makes your BGs go down…

dia 2

If you add the up and down effects together…you hope to get a fairly even final BG curve.  We’re all aware of the difficulty in lining all of this up to achieve that…some foods absorb faster than insulin kicks in (so we try to prebolus to help that), some foods absorb so slow that insulin wears off before the food is done (so we do extended boluses to help that).  If the stars aligned, you may get a fairly good match between the downs and ups…to get a fairly flat BG result.

dia 3

If we take a closer look at those downward forces, the insulin effect, we can conceptualize that as an “area under the curve”.  All that drawing is a bunch of little tiny insulin effects added up together.  If that was one unit of insulin with an ISF= 30 and a DIA of 4 hours…you’d expect your BG to drop 30mg/dl over the entire 4 hours (assuming your basals are correct).

dia 4

But, what would happen if you considered DIA of 2 hours?  Like I’d been doing with my omnipod?  Well, all that insulin action (aka “area under the curve”) still needs to be there, so the shape of the curve changes as a result.  Like moving play-doh into a new shape.  Since the length is cut in half, the height of that curve will necessarily get longer.  The curve become more pointy, less like a upside-down bell and more like an upside-down mountain.

dia 5

In effect, BGs will still drop 30 mg/dl in both situations based on the “math” but the BGs will drop MUCH faster and stronger with the shorter DIA.

dia 6

The shape of the curves didn’t make much of a difference to us when we were using omnipod because we typically only were using the omnipod’s DIA setting much later after the bolus had been given…way down near the post-2 hours, post-3 hours after a bolus had been given when the two different curves might start to look more similar again.  We were checking IOB at times well after a meal had been bolused.

Additionally, we weren’t using DIA to calculate boluses ahead of time…all the boluses were based strictly off carb ratios and MY ABILITY to guess whether Anna would go low if I gave all the carb ratio based bolus upfront.    Quick carbs…I gave all the insulin up front.  Slow carbs…ummm, let me think about how much to give now and how much to extend and for how long.  Anyone have a calculator?  My omnipod PDM never suggested  proactively “Hey Katie, if Anna is eating pizza, you may want to give that 10 units broken up as 6 units now and 4 units extended over the next 2 hours or else she’ll be low in an hour.”  Wouldn’t that have been nice?! (hint: that’s what Loop is able to do now!!!)

So why is DIA different with Loop?  Well, it matters a whole bunch now because Loop is calculating what your curve will look like as soon as you enter carbs and a carb absorption time before you bolus.  If your upward effects (carbs) are not able to keep up with the downward effects (insulin), Loop is going worry about you going below your target BG.  It wants you safe.  If you have a short DIA, the chances increase that your Loop will think that the insulin will overpower the carbs early in a meal and you’ll have a low sag in BGs before carbs can catch up. (because hey…all that orange “area under the curve” has been crunched up into the front part!)

dia 7

So, when Loop does its number crunching and sees that low BG sag…Loop’s checking whether that low is “low enough” to take you below your target BG.  If that low is low enough, Loop will shave off some of your recommended bolus upfront from meal.  How much?  JUST ENOUGH to keep your predicted BG from going below your target anytime after you bolus.

dia 8

If you’re starting the meal near your target BG, you’re likely to see a prediction line something like the graph below after you use the recommended bolus from Loop.  And you will scratch your head and say “WHAT THE HECK IS GOING ON?”  Why would Loop SHOW that you’re going to be going high just after giving a meal bolus and not suggest more?  (some people may even take matters into their own hands and say “hey, it shorted me on a bolus…it should’ve been offering 6 units and only  recommended 4 units!”  And you’ll shortly find that if you manually change it to deliver 6 units, you’ll find Loop suspending you quickly afterwards)

BUT, take a pause and think about the situation.  What you aren’t seeing is that Loop is offering that amount of bolus to keep you from going low early…before carbs can catch up.  Based on the meal specs (carbs and carb absorption time) you entered and the DIA you are using, Loop is helping you know that an extended bolus is a good idea!  Don’t worry, Loop still knows about the upward carbs…it hasn’t forgotten about them at all.  In fact, it is literally SHOWING you that it has not forgotten about those carbs that still need insulin.  Loop will make up the remaining bolus needed through high temp basals as soon as the predicted BGs aren’t showing you’ll go below target.

dia 9

Isn’t that awesome?!  In the pre-Loop days, you’d have to recognize the meal needed an extended/dual wave bolus, do some guessing and memory games, watch the CGM to help decide when it was safe to give more insulin.  Now with Loop, you tell it “hey this is a kind of long slow meal” and it does the work of helping you extend the bolus.

The problem comes if you are using too short of a DIA…you’ll regularly get boluses that are lower than you’d expect (or likely want) because Loop is predicting a significant downward insulin effect early in the meal.  Going back to the simple models, you are telling Loop that you have a wet paper towel (slow carb meal with weak upward support) but want to drop a huge stack of coins immediately.  Loop is telling you to “hey, don’t drop an huge stack of coins on that wet paper towel right away…drop a few coins, wait for the towel to dry out a bit and you’ll be able to add more later safely.”

All of this was to demonstrate the not-so-trivial weight that DIA has in your Looping.  If you set that DIA too short, you’re not just going to see it in IOB calculations, you’re also going to be having boluses and predicted BG curves that aren’t realistic.  Looping in those situations will be less than optimal and you’ll likely feel frustrated.  Out of all the variables that are YDMV (your diabetes may vary) such as basal rates, ISF, and carb ratios…DIA is the LEAST person-specific variable and most likely to be uniform across the population.  DIA is more dependent on the type of insulin being used rather than the person using it.

So I encourage you to set your DIA realistic for the insulin type you are using, and check if your other YDMV variables might need tweaking as a result of changing your DIA.  The work you put into getting those variables more realistic will be rewarded with a much easier bolusing experience.

We’ve regularly been using this “fake extended bolus” technique on Loop now for several weeks and it has been nothing short of remarkable.  The new dynamic carbs model is better able to adjust the insulin delivery (downward pressure) to match observed carb absorption (upward pressure) rather than leaving the upward pressure as a fixed curve.  We have had nearly half a dozen meals over 120g carbs each (donuts, Chinese food, spaghetti) and given single boluses upfront.  Just a single bolus.  I did not calculate or guess how much of the 120g I should bolus for vs try to split bolus for later.  I just told Loop that it was a long meal, took the recommended bolus, and then we walked away to let Loop handle the remaining decisions.  The results have been great.  Very large carb meals peaking between 150-180 mg/dl, no lows, and smooth landings.  Something that used to take a lot of effort and attention has been reduced to a reliable, less stress interaction.

On the left, donuts…large maple bar, large chocolate bar.  Single bolus, Loop calculated…high of about 125mg/dl using a carb absorption time of 2 hours.  On the right, big bowl of spaghetti using carb absorption time of 4 hours.  High of 173 mg/dl, single bolus given, Loop calculated…let Loop do the rest.


For meals that are quicker absorption (where DIA is not an issue because the carbs come in fast enough), Loop functions just like it did before…the full bolus is given upfront and Loop picks up the slop around the messy edges of real life.  But for these big, long meals…if you get your DIA well set, the experience can be one of the most significant reliefs to your t1d burden in a long time.

A few side notes:

  • To fully take advantage of the “fake extended bolus” technique, I did have to increase our max basal rate so that the extended bolus could be delivered in a reasonable time to help control BG spikes later in meal.  It took me some time to feel comfortable raising the max basal rate, since the previous carb absorption model was not forgiving at all…we’d kept the max basal rate fairly restricted to prevent unwanted high temping for quickly rising BGs after a meal.  Our previous max basal rate was 3 u/hr, and now it is 10 u/hr.  Anna’s regular basal rate on average is about 1 u/hr.
  • OpenAPS also uses DIA in calculating your predicted BG curves.  So, while the discussion above is mostly Loop specific, there are many parts that apply to OpenAPS as well.  If you are frustrated and wondering “why is my rig suspending basals so much?”, check if OpenAPS is predicting low BGs before your meal would be done…and ask yourself is it possible that the low BG prediction is due to a DIA set too low for the carb absorption being observed?
  • If you prebolus, make sure you forward-timestamp the carbs when you enter them in the Loop.  That helps Loop better line up the upward and downward curve peaks…and therefore you’ll get a better bolus recommendation upfront.
  • Loop’s Dynamic Carb Absorption model takes your entered carb absorption time and multiplies it by 1.5x as a starting point for its model.  This helps Loop be able to anticipate later carbs (past DIA) but not bolus for them upfront where a low would be more likely otherwise.  This multiplier has been working well for us.  Loop’s dynamic absorption has been able to adjust on-the-fly to situations where the carb absorption was not like we originally anticipated (because hey…that’s life with diabetes).
  • When we started on DCA, we were using 4 hours DIA.  We moved up to 4.5 hours and now are finally pretty pleased at 5 hours.  Our landings from the peak of a meal are more predictably coming in at target at 5 hours vs 4.
  • We still have a growing, hormonal teenager.  We still have to adjust basals regularly during the month.  Our good experiences on Loop still require us to be aware that diabetes presents ever-moving YDMV variables that we need to tweak.  But, it’s easier to be less emotional about that work when the meal bolusing has been made suddenly easier.  Diabetes feels a little lighter on our shoulders.