Reset G5 Transmitter

First, let me preface by saying that I adore, love, respect, and covet my Dexcom system.  It gives us a stability with type 1 diabetes that we would never be able to do without now.  But what I’m about to tell you is a bit of a hack on their system.

There’s been one thing I really have not enjoyed about moving from the G4 to the G5 system about four months ago.  The G4 transmitters were warrantied for 6 months, but usually the battery in those would go for a year…meaning we had the opportunity for much of the transmitter’s useful life to have a backup on the shelf at all times.  If the G4 transmitter failed for any reason, we could pick one off our shelf and not stress about how long it would take to get a new one.  Overseas travel and 2-week long diabetic summer camps were not a big deal…we could pack a backup.

Then we switched to the G5 system at the beginning of this year so that Anna didn’t have to carry a receiver while she did track team workouts.  This dramatically improved the likelihood that she would stay in good BG range during workout because our DIY loop system would have BGs available the entire workout to help her insulin needs.  If Anna had to carry a receiver during track workouts, that would’ve been the straw that broke the camel’s back in terms of diabetes gear she was willing to manage.

So, we’ve loved the G5.  It has worked well; not really having any problems with signal loss, BGs are accurate, we have enjoyed Clarity reports.  All good EXCEPT those G5 transmitters being shut-off by Dexcom  at 112 days.  At 90 days, you get a warning and your warranty is up.  At 112 days, your transmitter is artificially shut-off even though the batteries have some useful life left.  How much life?  Well, that depends, but for most users it is about a couple more months of life.

The problem with this system is that my insurance covers 2 transmitters in one order every 6 months.  So, for the first 90 days (3 months) after a transmitter order, I will nicely have a backup sitting on the shelf in case things go wrong.  BUT, for the next 3 months, I will have no backups on the shelf.  If that second transmitter dies early, I would have to wait for Dexcom to send us a new one.  If we were overseas or traveling, this could be very inconvenient.  I definitely won’t have one to send with Anna to her 2 weeks of summer camp based on how I can forecast our insurance refills already.

And here’s the really great news.  You can now reset the clock on that 112 day shut-off by building your own iPhone app.  This doesn’t buy you heaps of extra time…as the battery will only go for about 2 more months (maybe even less?) past 112 days…but that could be just enough time to start to be able to keep a backup transmitter on the shelf for longer between orders.

Another really good plus?  You can use this reset on G5 transmitters that have had their batteries replaced AND still use the Dexcom official app…you won’t have to try to use a different app (like Spike-App or X-drip+).


What you will need:

  • iPhone (iOS 11.0 minimum)
  • (this may also work on iPod…but I haven’t tested it yet)
  • Apple computer (macOS 10.13.2 High Sierra minimum)
  • Xcode 9.3
  • Apple ID email

Check to see if you need to update your macOS based on the version of iOS you have.  You can check your macOS by clicking the apple logo in your computer display’s upper left corner and selecting About this Mac.   If you are due for an update, click the Software Update button.

Download and install the app called Xcode from the App Store on your computer.  When the installation is finished, open Xcode by double-clicking on it from your Applications list.

Note: If this is the first time you are opening Xcode, you may get an initial message telling you that Xcode is installing command line tools.  Please let that run and complete the installation.  Command Line tools are a needed installation.

Go to the Xcode menu on the top of your screen, and click on Xcode and then Preferences...

Within Preferences, click on the Accounts tab and then the + button in the bottom left corner to add an account.  You are going to add an Apple ID type account.

Enter in your Apple ID email and password.  This process automatically makes a free Apple Developer account associated with your Apple ID email.  The account will show up in your Xcode preferences now with your name and (personal team) as a suffix in the name.  Once your account is added, close the Preferences screen by clicking on the red circle in the upper left corner.

Download the code for the ResetTransmitter app that we are going to build by clicking HERE

Open your downloads folder and navigate to the CGMBLEKit-master folder and then find the file CGMBLEKit.xcodeproj folder.  Double-click on that file and the project will open in Xcode automatically.

Click on the open button when the message appears asking:

“CGMBLEKit” is a project downloaded from the Internet. Are you sure you want to open it?

{Take the time now while the project opens to plug in your iPhone to the computer using your lightning cable.  Please accept any prompts about trusting your computer and unlock your phone so that it stays awake through the build process of the app that we are about to finish.}

Now click on the CGMBLEKit at the top of the left column, and then click on the small box as shown on the screenshot below to show the list of “Targets” below it.  Select the “ResetTransmitter” target.

Now, look at the screenshot above.  See that part highlighted in blue? You will need to change the loopkit part of the Bundle Identifier to a unique-to-you word.  Make sure that when you make the edit, you do not delete the period before and after.

Once you have the name edited, then go down to the Team section and select your (personal team) signing name from the drop down menu selection.  [Note: if you have a paid developer account, you can use that signing name instead.]

After you finish signing, a Provisional Profile will automatically be created and you’re close to done.

If you see a prompt under the status area below the Team about your device not being registered, please click on the Register Device button provided there to register the iPhone to your developer account (see screenshot below).

Now, navigate up to the top of your window and select two things; one from the left side of the box you’re going to select ResetTransmitter and from the pop-out, you’re going to select your phone’s name from the very top of the device list (not just your phone model…you want to go all the way to the top of the list for your phone’s name).

If your phone/device name has (untrusted) after the name (see screenshot below), please open the phone and click on the Trust button that should appear on the main screen.  If the (untrusted) tag hasn’t disappeared after that, just unplug and replug the phone into the computer.  That should get rid of the (untrusted) tag.  If you try to build an app onto an “untrusted” device, you’ll get an error message reminding you to do the steps above.

When you’re done, the screen should look like the screenshot below; ResetTransmitter on the left, your phone’s name on the right, and no red error messages under the signing team area.  If your screen looks correct, then go ahead and press the build/play button.

Depending on if this is the first time you’ve built on Xcode, you may get prompts for codesign access and keychain access.  If those prompts appear, please enter your computer’s password and click on the always allow button to confirm.

Also, if this is your first time building with this developer account onto your iPhone, you may get another warning that the app could not launch because an issue with trust on your Developer Account on your phone.

Follow the directions on the warning.  Open your iPhone Settings >> General >> Device Management and then select your Developer App certificate and trust it.

Once you click the Trust on your iPhone, go back to Xcode, click on the blue OK button for the warning and then press the build/play button one more time.  This will finish the build of the app onto your phone.  Success!  You can unplug your phone from the computer and use the app now.



There is some warning messages in there about the use of this app.  When the app was first written, the code writers were uncertain how Dexcom Share and Clarity servers would treat information coming from a clock-reset transmitter (i.e., would data still be uploaded properly). The app has been in-use by many people now and the Share and Clarity services are, thankfully, not impacted by the reset transmitters.

You cannot reset a transmitter that is currently in a session and/or paired with Dexcom or Spike, or any other device/app.  So, quit those pairings and sessions first.  Forget the transmitter from your iPhone’s bluetooth list.  Re-open the ResetTransmitter app, enter your Transmitter ID and press the red Reset button.  Within 5 minutes you should get a pairing request.

If you do not get a pairing request and instead see a message “Unable to parse auth challenge: timeout” that means your transmitter is still busy with another app.  Double-click the iPhone’s home button and scroll through the open apps.  Upswipe on the Dexcom and the Reset apps to close them.  Re-open the Reset app, enter in the transmitter ID again and press the red Reset button again.  Within 5 min you should now see a pairing request.

If you STILL don’t see a pairing request, some users have reported that turning off Dexcom’s cell data within the iPhone Settings >> Dexcom G5 app can also help release the transmitter from Dexcom app’s influence.  If that fails…you can try deleting the Dexcom app and reinstalling it at the end of the reset process.

If you still don’t get a pairing request, make sure the transmitter is within pairing range of the iPhone (but not in active session).  The Reset app needs the transmitter close enough to be able to pair with it in order to reset the clock.

Once you press the pairing request, the reset command is immediately issued and you should get a confirmation screen like below:

You can now close the Reset app (double-click phone’s home button and upswipe Reset app) and forget the transmitter in the iPhone’s bt list again.  Reopen your Dexcom app and you’ll be able to use your transmitter for another 112 days or until the battery gives out…whichever comes first.

The free developer account that you signed the Reset app with only allows the app to be used for 7 days.  After 7 days, the app will simply produce a quick white screen and self-close if you try to open it.  You can rebuild the app anytime after the 7 days to use it again.  Simply double-click on the file in your CGMBLEKit folder download to open the project in Xcode again, plug in your iPhone, and press the build/play button.  All your previous changes will have been saved, so the rebuild is quite easy.

You can reset any amount of transmitters.  The app does not know transmitter ownership, nor does it have a limit on how many times you can use the app to reset transmitters.

The transmitter does not have to be on a sensor in order to be reset, just needs to have battery life left and not be paired already with another app.

Fiasp Day 17 update

Our Fiasp experience started October 11th.  Here’s what I was expecting:

  • increased insulin resistance
  • fast insulin

Optimistically, we gave our first Fiasp bolus.  Full of excitement.


After 24 hours, here’s how I summarized our experiences:


1. If Anna started to rise with pretty significant IOB, I adjusted basals up. The last adjustment was leveling out beautiful, then started to climb for three consecutive readings about +3 or +4 each time, but the important part is that it was happening with 1.8 u IOB. That means she was really short on basals since it was nearly 3 hours after she had last eaten.

2. Also, she climbed more than 150 mg/dl from eating one single uncooked spaghetti noodle. Do I really think that was all noodle? NOPE. Definitely another sign that basals were too low. Shouldn’t be spiking that bad from small food.

3. Only one adjustment was to lower basals…when she had dropped significantly and had negative IOB. That was the adjustment right before the steady line at night. I had apparently gone too far with the earlier basal increase.

4. We prebolused the first meal by about 8 minutes I’d say. A peanut butter sandwich that she overcounted carbs on. That’s the only low we corrected on this graph. (Fiasp rebounds quickly from inadequate basals). Tonight’s sandwich is the same meal, but bolused with a stronger carb ratio, and no prebolus. Looking better.

In short, an awful lot more insulin needed almost right away. Like A LOT more. BUT, the no prebolus thing is real. And Loop’s fiasp curve is working better and better as I get my settings better fleshed out.

We had a couple good days, but then things started to get a little worse for wear around day 4.  We were having an awful time of:

  • volatile BGs, more lows to treat/more highs to stare at and wonder
  • fast insulin
  • insulin sensitivity
  • frustration with looping
  • distrust of looping (both Loop and OpenAPS, I tried both)

Our days just got progressively worse.


Then on the evening of October 18th, we just had a lot of stubborn lows and I was sick of spending so much time on diabetes again.  We were treating a lot of lows in advance on those graphs.  I had a choice between throwing the Fiasp into the trash (considered mailing it to a friend but wondered if that would even be considered “nice”) or *gasp* suck it up and go back-to-basics.  I opted for back-to-basics…aka open loop test all our settings.


It didn’t take long to find my first problem on open loop.  Notice on the screenshot above, the low near midnight after a manual correction?  WOW, that correction brought her down over twice as much as I’d expected and I needed to treat a low.  Basals were too strong and I suspected my ISF was way off, too.  I lowered basals as I treated the low but didn’t adjust ISF at the time (after all, I was still open looping so ISF wasn’t actively being used other than by my brain if I wanted to do a correction).

For two days, I opened my loop so that I was in control.  I tested basals, tested ISF, tested carb ratios, watched my IOB, and watched Loop predictions during all of this.  Things got better pretty fast.  After a day and a half, things had smoothed out quite a bit with a lot of adjustments.


The screenshot above shows a few things I learned.  That dip at middle near noon…Anna’s PE class.  She is very sensitive to her lunch bolus since PE comes right after.  We are still working on that.  It’s not a fiasp issue, per se.

But, the more subtle observation?  See the Loop prediction?  Loop was predicting that she would start coming back up around 12:30pm.  But instead, she was still heading down.  This started me wondering if either my carb ratio was still too strong, and/or if I needed to maybe shorten our default carb absorption times.

It became pretty obvious that my carb ratio was still too strong in the next few meals.


Basically after two days of open loop use, I learned that my basals had been too high, my ISF had been too weak, my default carb absorption times needed to be lowered, and my carb ratio was too strong.

The odd part to me was that you’d think that with all those indicating that I would need less insulin…we would’ve only been battling lows while closed looping the week before.  But, we weren’t.  We were fighting lows and highs.  I think that all the suspends to keep us from going low were leading to some strange rebounds with fiasp.  It was really hard to see through all the looping noise to figure it out though.

In the end our average numbers by comparison have ended up as:

  • Novolog: ISF = 40, Basal = 1.0, Carb ratio = 7.5
  • Fiasp: ISF = 58, Basal = 0.85, Carb ratio = 10.5

Our settings now are working much better.  We closed loop again and are happily looping on Loop.


Other than the standard things we learned on open loop regarding basals, ISF, and carb ratio…we also decided to shorten the 1.5x carb absorption multiplier that is default in dynamic carb absorption.  Basically, we shortened our default carb absorption buttons to 1, 2, and 3 hours for lollipop, taco, and pizza.  Other than that we are using the standard Loop settings.

Why did I adjust the default carb times?  Because of the way Loop calculates bolus recommendations, the quicker peak time of Fiasp will predict an early low after eating meals compared to a similar meal with Novolog.  So, even if everything else is equal, a meal bolused with Fiasp will tend to get less of a bolus typically for an average meal than a bolus with novolog in Loop, and this effect gets more pronounced the longer the carb absorption is entered.  Therefore, that 1.5 multiplier will tend to lower the recommended bolus even more.  What we found happening was a smaller upfront bolus would be followed by a high temp/high BG, and then we would crash later as the later carbs (from the rest of the 1.5 multiplier area) wouldn’t be there to support the earlier high temps.  So the upfront and later parts of the meal were being affected by the multiplier. (*screenshot from a pizza meal below and part of this screenshot was also affected by our settings still not being tuned, so take it with a grain of salt.)


On novolog, we never had this issue I suspect because the peak time of novolog was so slow that dynamic carbs had enough time to adjust the predictions before the high temps came on and couldn’t be recovered from.  And we prebolused a lot, so the insulin was pretty active by the time she ate to help prevent spikes.

So, in summary, I’m stoked on Fiasp.  It’s been great now.  BUT, it didn’t behave like others had experienced…so keep your mind open.  Perhaps we will find resistance later, after longer use.  If we do, I’ll be sure to document.  And, if you find yourself slumping into confusion initially with the change from novolog/humalog…don’t be afraid to open loop to get your feeting solidly beneath you again.  A day or two of open looping can save you from wanting to poke eyeballs out.  And, sadly, some meals can still really benefit from a 5-7 min prebolus even on Fiasp.  The really fast carbs are still faster than Fiasp.  Simply announcing those carbs won’t be enough for my teen’s fast digestion.  We are learning which foods need prebolus and for how long…but the list is A LOT SHORTER than with novolog (novolog list included just about everything but water and ice).

Side note (because I also love the not-perfect-examples, too): Fiasp still doesn’t save you completely from a really poor carb count and a busy teen.  Example, she ate 20g uncovered just before I picked her up from karate.  I didn’t know that and she was just distracted.  We almost immediately went to In-n-Out where she scarfed a double-double with a HUGE french fries basket.  We were way off on carb counts (originally this graph only had 80g on it because I didn’t know about the previous 20g and I didn’t know she was getting fries, too).  We adjusted carbs a couple times as I found out about things…and gave the suggested corrections as we adjusted.

But, the recovery from such a bad carb count, no prebolus, and eating 20g without any bolus for that portion…really quite fantastic and quick.  3 hours after that meal was eaten we are recovered…and I don’t think we would look like this with novolog.


(As with all things, don’t take my word as gospel on Fiasp.  I’m still experimenting. YDMV.)

Fine-Tuning settings

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

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

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

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

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

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

1st: Insulin Duration

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

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

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

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

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

2nd: Basals

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

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

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

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


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

3rd: Insulin sensitivity factor

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

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



Screen Shot 2017-10-28 at 12.20.02 PM

4th: Carb Ratios

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

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

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

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


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


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

But what about diabetes?

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

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

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


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


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

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


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


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

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

Exponential Insulin Curves + Fiasp

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

What’s so special about Fiasp?

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

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

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

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

Why can’t Fiasp work with the old curves?

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

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

What are the Exponential Insulin Curves?

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

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

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

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

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

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

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

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

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


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

So this default curve will work for me, right?

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

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

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

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

What are the impacts of DIA and PT?

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


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


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

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

Moving between DIY closed loop systems

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

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

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


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

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

Split Bolus/Extended Bolus meals

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

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


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

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

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

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

Active IOB

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

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

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

Carb Editing

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

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

Predicted BGs

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

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

Temp BG Targets

Both Loop and OpenAPS have temporary BG targets as features.

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

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

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

Internet dependence

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

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

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

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

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

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

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

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

Computer dependence

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

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

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

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


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

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

Comms Battery

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

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

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

Pump Battery

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


Loop users should buy an extra RileyLink.

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

What if the system fails?

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

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

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

What pump settings are used?

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

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

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

What gear is supported?

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

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

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

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


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

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

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

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


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

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