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.

Leave a Reply

Your email address will not be published.