Category: Uncategorized

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.

Bolusing

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.

Prebolus

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.

Auto-adjustments

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.

Redundancy

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

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.

Timezones/Travel

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.

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?!

 

I’m super excited to share Loop’s latest development…it’s a big one! Dynamic Carb Absorption.

So, one of the things that has been most difficult for most new (or little kid) users of Loop app has been how to enter carb absorption times for meals. There’s lots of different strategies I’ve seen employed…breaking meals down into several different carb entries for a single meal, changing carb ratio/ISF settings, or using “fake carbs”. My personal experience was that we had used the default carb absorption times and found we had some significant post-prandial lows due to early high temping.

In the old Loop app, if you entered a longer carb absorption time and had earlier/stronger than expected increase in BGs…Loop would early high temp to cover the “unexpected” spike. Loop also assumed that the later carbs you’d entered were still coming. Basically, Loop was unable to assume that perhaps the carbs were simply acting quicker, and therefore decay them quicker. Conversely the same was true…if you entered a short carb absorption time, but the carbs were actually taking longer, you would likely see some early suspensions and have a BG spike later in the meal.

We figured out that, for us, a default carb absorption time of 90 minutes was working pretty well for our average meals. Fatty and higher carb meals needed some extra attention. We split-bolused a lot and it involved a fair degree of attention to how we entered the carbs (time of entry and carb absorption time) in order to make sure the suggested boluses were also reasonable.

We also had to keep the max basal rate fairly low (about 2.5-3 times the highest basal rate), just in case we had a situation where the carbs absorbed quicker than we’d expected. Didn’t want to let Loop overly correct in those situations.

After a bit of testing and tweaking, we got into a groove…but it wasn’t what I’d call an easy hand-off for a care giver or kid to operate. We still had a lot of “hey mom, how should I bolus for this pizza?” and “Mom, what time do I enter for the carbs?” So, while Anna was good at estimating total carbs for a meal…her actual entry of carbs into Loop app was still difficult by herself.

This difficulty led me to try OpenAPS, especially because of friends who were having troubles with school nurses and caregivers having difficulty in properly entering carbs. OpenAPS was more forgiving of a carb entry and more straight-forward (familiar) for school nurses. They seemed used to “normal” pump bolus wizard entries.

Enter Pete Schwamb. He took on the carb absorption challenge and came up with Dynamic Carb Absorption. You can read more about the idea behind it in Github here. A really good read…highly recommended.

Basically, what Pete’s done is allowed Loop to look at how BGs are responding based on a term called InsulinCounteractionEffect (ICE for short). To quote Pete:

To make an attempt to see how carb absorption is actually progressing, we can take the observed changes in glucose, subtract changes modeled from insulin delivery, and look at the resulting difference, called insulin counteraction effect.

The effects represented by this term are more than just carb effects. It includes exercise, sensitivity changes, and even errors in insulin settings such as basal rate, ISF, etc. However, since the effect of consuming carbohydrates is relatively large, we can still make some useful adjustments to Loop’s carb model by assuming that the effect is mainly carb absorption in the period following recorded meal entries.

What does this mean for us in plain English?  A more forgiving Loop if you get your carb absorption estimate wrong.

---

Dynamic Carb Absorption version of Loop has been available for development testing since July 1st.  We tried to use it when it was first released, but we were in the midst of trying to cram for how to deal with diabetes camp July 13-19th.  We were trying to figure out if Anna was going to loop, and if so how much and with which system.  She used Loop from September-December 2016 and OpenAPS from January-July 2017.  She’s not keen on change…so trying out a new system right before camp was just not happening.

However, once she came home from camp, we decided to give it a try.  We had a couple days of tweaking her settings after camp, which is typical.  She is quite active and at high altitude for camp, so basals and ISF need a couple days to settle down again.  About 5 days ago, we finally had things dialed in again and I could fairly confidently say that any errors in looping behavior would’ve “not been the fault of bad settings”.  So, it was time to really test.

TWO DONUTS

First test was two large donuts; one chocolate bar and one maple bar.  Typically we have split this bolus up into at least two, sometimes three, boluses.  Not my favorite thing to do.  I keep hoping for the day that Anna will know how to split her boluses herself, but we aren’t there yet.  She still asks for help on about 80% of her higher carb meals that need splits.  Sometimes I get distracted about the timing of the bolus or the eating, and she will go low early after the donuts are eaten because we’ve given too long of a pre-bolus.

So, I did something I thought I’d never do.  I told Anna just to enter 110g of carbs @ carb absorption time of 4 hours, postdate it for 20 minutes for her prebolus time, and give whatever the Loop app recommended for bolus.  It recommended bolusing for 60g of the 110g.  AND THAT WAS THE ONLY BOLUS WE GAVE.

I knew there was some inaccuracy in this entry upfront.  Obviously there are quicker carbs in there as some fraction of the overall carb count…so I knew there was going to be somewhat of a spike after eating.

But, my goal here was more than just BG control.  My goal was “How much can Loop simplify my daughter’s interaction with difficult meals and still maintain decent BGs?”  In other words, can I finally be less involved with my teen’s t1d without risking poor bolusing effects?

SUPER PLEASED with results.  Short version, she did not go above 180 mg/dl and landed after the meal around 100 mg/dl (target is 90 mg/dl).

Do I know that we could do better if I’d manually added a second bolus earlier?  Or if I’d added quicker carbs in addition to the slower carbs?  Sure.  But this accomplished something that I’ve been wanting to see for a long time…a very simplified, safe way my teen could bolus a sugary/fatty meal without danger independently and still get reasonably good (or better) BG results.  She’s not always home.  She’s not always wanting my input on bolusing.  Independence is an important aspect we are trying to nurture.  This experiment gets a big WIN checkmark from me.

NEW SCREEN

Now you’re probably wondering what that new screen is above?  That’s the new carbohydrates effect graph that pops up when you click on the carbs graph.  The graph shows, basically, the expected ICE (insulin counteraction effects) compared to carb absorption effects in grey.  Pete does a great job of explaining the graph in the earlier link, so I won’t repeat it all here.  Suffice to say, I’ve actually found quite a bit of utility in this graph for non-carb stuff too.  For example, the first two days back from camp, Anna’s basals were still too low and our ICE was leading to additional carbs being “counted” at the end of each meal.  These were for meals we had been pretty certain of the carb amounts for.  It was pretty easy to see that we weren’t coming back to target after meal AND that the BG-resistence was being picked up as “additional carbs”.  Knowing that the carb counts were correct, it was pretty easy to hone in on lack of basals as our problem still.  Once we got basals dialed in a little better, the carb counts have been fairly close again between what we enter and what ends up being counted in the ICE at the end of the meal.

IN-N-OUT Cheeseburger

Another favorite meal that we’d previously split and prebolused for.  This time we did all 60g upfront @ carb absorption of 2 hours, and let Loop do the rest.  We started the meal at 115 mg/dl so I figured the lack of split would be ok this time…Loop agreed and provided the whole bolus upfront (vs giving a portion like in the donuts scenario).

About 2 hours after eating, we hit the high point.  Finger sticks showed a max of about 145 mg/dl.  Clearly the meal wasn’t done at the 2 hours we’d initially estimated.  In previous Loop versions, this would’ve meant a need to manually correct to come back to range easier.

By the time the meal ended (over an hour after I’d estimated the meal would take), we settled nice back to target range and didn’t have to manually intervene at all.  All off a single bolus entry.

Breakfast

How about a mixed meal?  Fruit cup, spoonfuls of peanut butter, and leftover fajitas meat.  Yum…the things that teenagers eat on their own while left alone during summer mornings.  Anna estimated 25g @ 90 minutes for this meal.  Peanut butter has always been a favorite of hers, but not so much for me.  Makes the carb absorption times kind of variable.  Some of the quick carbs make it through, but then we get a later rise too.

The dynamic carbs version somehow knew that all those carbs hadn’t ended when Anna had suggested.  By keeping them in the queue, the Loop was more responsive, even while BGs were dropping with IOB, and picked up the later BG rise quite well.  Left us in perfect shape after the meal.

So after 6 days of use, and 4 or 5 of those with our basals fairly well set, here’s how we are looking on Loop DCA version.  We’ve done zero spilt boluses, and only one manual correction (last night her basals doubled in middle of night from hormones).

Anna and I are both really loving the Loop DCA.  She’s enjoying bolusing from phone.  We are still using IFTTT that we’d setup from OpenAPS in order to track site and sensor changes.  I’d say I miss the range of the edison/explorer board that could get us several rooms away…but Anna has easily picked up her old habits of stashing the RileyLink in a pocket again.  We are going to test out tonight how well using multiple RileyLinks in the house may help if she walks around with phone/receiver only.

After testing this out, we’ve felt safe to give our max basal rate room to run a little more for boluses like the two donuts.  We have made our carb ratios just a touch stronger, but I think that’s unrelated to Loop DCA, but rather some hormonal changes that we saw even before we started this system.

All in all, I think this update is going to get a lot of deserved attention and appreciation.  Makes use for kids a heck of a lot easier and safer.  School nurses won’t have nearly the same ability to mess up your kid’s day by a careless carb absorption entry.

Post-lunch BG climbs to 195, which I knew was unusual given what she’d packed for lunch.  Didn’t notice anything with a crazy carb count on her NS.  But those SMBs were really such a nice visual that my loop and I were on the same page about what to do about it.

I ventured a quick text to check in.  I hate doing that, but she was home from school and I wouldn’t be interrupting class…so I did.  I asked.

Woah.  Wasn’t expecting that one.  We are still a little variable on when that pesky thing is coming…so this caught me off guard.  Three weeks…not four.  Ok.

Things had been so steady for the last several days (*except on beach party with cupcakes, teenagers, and suspended pumps for extended times a couple days ago).  I mean, look…so steady, right?  That was yesterday.

And then today….with the same food basically.  But that red arrow was The Change.

If I could offer a hug to an inanimate object, it may be going to autosens.  I took a peek to see if things really had been *that steady* or if we had actually been getting a lot of help that I wasn’t aware of.

My suspicions were correct.  What had looked like a calm day, was actually the result of increasing ISF and Basal adjustments, as well as auto lower temp targets, behind the scenes.  From yesterday to today…basals went from 0.8 to 1.05. ISF went from 40 to 30.3.  The storm was held at bay until this afternoon when the big hormones hit just after lunch.

We adjusted her basals to 1.3 (based on where we had to adjust them to last month) and autosens is predicting we may need more…we will let it sit here for a little bit if we need to nudge in that direction in a few hours.

I can’t say how nice it is to take what is normally a horrible time (hormone swings) and make it limited to just a few hours of pain-in-the-butt.  The old way (non-autosens and non-looping) was days of pain.