Hybrid Closed Loops

First a couple terms as we embark on this discussion:

Hybrid closed loop (HCL): An automated system that modulates a pump’s insulin delivery, based on a connected CGM, to try to keep user at a specified target BG. The “hybrid” part of the description means that the user is still responsible for bolusing food themselves in the traditional sense (carb counting and a carb ratio). The term “artificial pancreas” is often used interchangeably with HCL. For the purposes of this post, I’m going to shorten the term to simply “closed loop”.

Automatic bolus: The first closed loops only modulated insulin delivery by settings temporary decreases/increases in basal insulin deliveries. Some closed loops are also capable of delivering boluses in some situations to help bring high blood sugar back to target a bit quicker than basal modulations usually achieve alone. The term “automatic bolus” does not refer to the bolus involved with meals.

At a recent diabetes conference, there was a lot of buzz around the options for closed loop systems. At this conference, I had the privilege of speaking about my perspective of the JDRF Open Protocol Initiative. If you haven’t heard about it, you can read more about it here. In a nutshell, there’s a shift in the industry leading to potentially more choice for us (the people living with diabetes) in the near future. The shift means that you’d be able to pick your favorite CGM, favorite pump, and favorite looping algorithm/controller to combine together into your own little “customized” closed loop. So, instead of all the pieces being pre-picked for you…you get choice about the individual pieces and they don’t all have to be from the same company. The term describing this mix-and-match idea is “interoperable” components. The Open Protocol Initiative seeks to clear the regulatory, legal, and funding pathways needed get interoperable devices on the market and FDA approved.

Interoperable’s Current Status

There’s three components that make up the necessary part of a closed loop; CGM, insulin pump, and the controller/algorithm. In order for a potential interoperable device to be sold in the US, it will need FDA approval specific to that category…and the nicknames used for these categories early on were iCGM, iPump, and iController. To borrow Tandem’s wording, “This new category of devices will make it easier for separate companies to integrate their products into advanced automated insulin delivery systems without having to resubmit each of the components and their associated clinical data every time. It’s a great move on the behalf of the FDA to make it easier for companies with leading-edge technologies to more quickly develop and deliver innovations for the diabetes community.”

So what’s the status on any devices getting approvals for these new categories?

iCGM: The only iCGM thus far is the Dexcom G6 system. The FreeStyle Libre 2 has been submitted for FDA review for this iCGM designation…and it’s taking a little longer than initially expected.

iPump (ACE pump): Ultimately when the first device was approved, the official name of the iPump category was made “ACE pump” standing for “alternate controller enabled”…rather than iPump. The first ACE pump  was Tandem’s t:slim X2 pump. Insulet’s DASH pod were the next to get ACE approval. (FAQ answer: the Medtronic 670G pump is a pump that does closed loop…but it is NOT an interoperable pump. The pump was approved as part of a defined system, meaning it must be used with the Guardian 3 sensor and the algorithm inside the 670G pump itself in order to access closed loop operations…so the 670G pump is NOT an ACE pump)

iController (iAGC): Ultimately when the first device was approved in this category, the name became “iAGC” standing for “interoperable autmated glycemic controller). The recent approval of Tandem’s Control-IQ as an iController marked the first (and so far only) for the category. Tidepool announced its intention to take a version of Loop app through that same approval process and is hopefully close to submitting to FDA soon.

Development Partnerships

Partnerships have been, and continued to be, announced all the time as part of this industry movement…a signal of which devices may be available in the future. It is nice to see that there are more partnerships that appear to be giving more choices for the pairing of system components.


With all this awesome discussion about choice…some people could be in a little bit of a pickle right now in terms of finding the proper information so that they can choose the best system for their needs/wants. So, let’s take a quick peek at the currently available commercial systems, DIY systems, and upcoming systems in trials now. But, I’m adding some color commentary on the systems based on the feedback I’ve heard from other users, too.


There are two commercial options right now; Medtronic 670G and Tandem’s Control-IQ.

Medtronic 670G

Medtronic 670G overview: This was the first commercially available option, approved in September 2016 by the FDA. The 670G uses the 670G pump and Medtronic’s Guardian 3 CGM. When using the closed loop feature for the 670G, it is called being in “auto mode”. The standard target setting is 120 mg/dL and the target can be set temporarily to 150 mg/dL for exercise and other events. The system has you use it in “manual mode” for at least 2-3 days before you go into auto mode. Although you have a scheduled basal profile that you enter into the pump and will be used in manual mode, things change with auto mode. In auto mode, the 670G uses a basal schedule that it decides is appropriate from the previous 6 day’s experiences, not the one you’ve programmed into your personal profile. You will not be able to have a corrective bolus recommended for a high blood sugar until you are above 150 mg/dL and then the corrective bolus recommendation will only provide a recommendation to reach 150 mg/dL. These recommended corrections are not applied automatically, the user will need to implement them manually.

670G Clinical data: To read up on the pivotal trials data that lead to the approval of the system, diaTribe has an excellent summary article here.

I also found this data from this study of the real-world users of 670G after launch to be particularly interesting. The interesting parts?  Teens have the most trouble, staying in auto mode about 66% of the time and achieving a 62% time in range (70-180 mg/dL).

670G user experiences: There’s a whole world of experience that needs to be considered beyond what a clinical trial would tell a user. Beyond time in range and A1C is an evaluation of how easily you can LIVE with the requirements of using the gear. Here’s some of the most frequent user experiences I’ve seen…

  • You cannot change the 120 mg/dL target. No going lower.
  • You cannot use a different CGM (such as Dexcom) and still use “auto mode”.
  • Users have often reported setting very aggressive settings changes in order to achieve better time-in-range. The only two that you can change in auto mode are the duration of insulin action (DIA) and carb ratio. You do not have the ability to simply adjust basals to make the system more aggressive, because the “auto mode” operations are automatically setting your basal profile based on the previous 6 days of data.
  • You must calibrate the Guardian sensor twice daily, sometimes more often. The sensor will provide additional prompts for calibrations when it is unsure of the accuracy of its readings. This leads to what’s called a “pretty needy sensor” experience. It is often cited as one of the major reasons that the 670G auto mode has drop-out rates from 33-49% of its users in studies…they just don’t like all the work required to stay in auto mode and intentionally choose to stay in manual mode. For those users that try to stay in auto mode, there is still a low percentage of time in actual auto mode consistent with the clinical trial results.
  • There are no “automatic bolus-type” corrections…all corrections are accomplished through basal modulations.
  • If you stay at “too low” or “too high” of a basal rate for too long, you’ll be kicked out of auto mode. Practically speaking this means the times when you’d most want to be in auto mode critically (stuck on lows or stuck on highs), you’ll be kicked back to basals in you entered in your profile settings within 2.5-4 hours (see below) of these limits. *Note, Medtronic does not tell you the value of your “personal minimum delivery rate” and “personal maximum delivery rate”. It’s a black box mystery.
  • You will be forcibly kicked out of auto mode, and placed in a “safe basal” mode for 90 minutes (no automated basal adjustments will happen in safe basal mode) if any of the following issues below occur. If the issue is not resolved during that 90 minute span, the user is dropped back into manual mode and will not be getting automated basal adjustments:
    • CGM is outside of the 40-400 mg/dL range
    • CGM has not been calibrated within 12 hours
    • Auto Mode has been at your personal minimum delivery limit for 2.5 hours
    • Auto Mode has been at your personal maximum delivery limit for 4 hours
    • Auto Mode detects that your sensor might be underreading
    • An entered BG is 35% or more different than your current CGM value
    • No CGM data has been received for more than 5 minutes
Tandem Control-IQ

Tandem Control-IQ overview: The Tandem t:slim x2 pump combined with a Dexcom G6 sensor can be used with Control-IQ algorithm to provide a closed loop. This system has been on the market since early 2020. Previously, many users were using the low-suspend-only version called Basal-IQ. The standard target setting is 112.5-160 mg/dL, but there are two alternate target settings users can implement. Sleep targets are 112.5-120 mg/dL and exercise targets are 140-160 mg/dL. With the standard targets enabled, the behavior of Control-IQ can be summarized as shown based on the predicted CGM in the next 30 minutes:

The system uses an initial weight and total daily insulin entry, when entering closed loop mode on Control-IQ, to help establish its model and maximum settings. You don’t get dropped out of closed loop automatically by any condition except CGM data not being refreshed within 20 minutes.  If that happens, you’ll be reverted back to your saved profile settings and no automated insulin delivery changes will happen. As soon as CGM data becomes available again, the system will automatically resume Control-IQ operations and you’ll be back to closed loop operations. There are automatic boluses available, if you are using standard targets. You will get 60% of the needed correction to 110 mg/dL as an automated bolus, when BGs are predicted to go above 180 mg/dL in the next 30 minutes. You can get one automated bolus no more frequently than once per 60 minutes since a previous bolus event (either automatic or manual bolus).

Tandem Control-IQ clinical data: To read up on the pivotal trials data that lead to the approval of Control-IQ, diaTribe has an excellent summary article here. One notable take-away when I initially read this article was that all users stayed in the trial and stayed in closed loop mode 92% of the time. This was a significant improvement from the first-to-market 670G’s results. Additionally, Control-IQ achieved an improved time in range from 59% baseline to 70% after using Control-IQ (670G had clinical trial from 67% baseline to 72% after using auto mode, for comparison). So, while the  data looks like it achieved similar time in range ultimately, I’m actually more impressed at the difference in improvement…Control-IQ brought people up from a far more challenging starting point than 670G did.

There aren’t any real-world clinical studies yet of Control-IQ users, but the Basal-IQ system ended up out-performing the pivotal trials data. I’m excited to see how Control-IQ performs.

Tandem Control-IQ user experiences: To be fair, Control-IQ has not been on the market for nearly as long as the 670G has been…so user experiences are still being gathered. Thus far, the results have been very positive. Complaints that I’ve heard include the usual (can’t aim for lower than 112.5-160 mg/dL) and mundane (pump clip sucks). There have been reports of some users keeping sleep targets turned on 24/7 to achieve a lower overall target range throughout the daytime. Users have been requesting to see more data about their Control-IQ status and to have it link to a mobile phone app (and that is in the works, but I don’t know of a launch estimate on that). There are a couple real-world reviews from users here and here.

An interesting “interoperability” note…this platform could conceivably be the first on-market actual interoperable choices since the announcement of a development partnership between Abbott and Tandem in October 2019. If Abbott’s Libre 2 gets approved for iCGM status (currently under review by FDA), then Tandem customers, using the t:slim x2 ACE pump and the Control-IQ iAGC, could have the G6 or Libre 2 as their iCGM choices. There’s still work to be done for sure to make that happen for Tandem, but it’s an exciting pathway to see finally achieved.

My daughter has been using Control-IQ for about 2 weeks now (after nearly 3+ years using Loop and half a year of OpenAPS). The results so far have been very encouraging. I’m going to do a separate blog post about that when we hit the 30-days of use so that I can have more comprehensive data to share. I never trust that diabetes isn’t just playing nice every time she tries a new system, so I am waiting for more data to really believe it. Thus far, it is out-performing our Loop experience though.


There are many DIY closed loop systems, but the most notable three are Loop, OpenAPS, and AndroidAPS (each of those are links to read more about the individual systems). Most of you know me from Loop, but we also used OpenAPS for quite sometime as well. We have never used AndroidAPS because (1) we don’t use android phones and (2) we don’t have access to the pumps that are compatible with AndroidAPS (those are more commonly available in Europe).

DIY systems are not FDA approved, nor do they come “pre-assembled”. You will have to do some work yourself to build the system and understand how to operate it. There’s a great comparison between each of the systems here. But the short summary is that picking which system is right for you will depend on what aspects you value the most. For example if you absolutely won’t use an Android device, then you need Loop or OpenAPS. Pump choice will also make a large difference. For example if you won’t move away from using your Omnipods, then you need to consider Loop (although AndroidAPS is getting close to a stable inclusion for Omnipod). AndroidAPS is the only system that has the ability to remove the use of an in-between device (such as a RileyLink or Edison rig) because it supports some versions of pumps that have built-in bluetooth capability. AndroidAPS also has the ability to send remote boluses through text messages (although that concerns me a bit from a safety aspect, but that’s a larger topic for another discussion).

All of these systems allow for a level of transparency that is currently unavailable in commercial systems. You can see every aspect of the algorithm’s decision making by examining the code itself and the documentation online. As well, they all integrate with Nightscout and upload live-time with CGM, carbs, insulin, temp basals, and predicted BG values. This live-time view gives remote care givers incredible insight into every aspect of the looper’s status.

There’s also some drawbacks of using a DIY system. You won’t be able to just pick up the phone and call customer support if you have a question (although…holler to the Facebook Looped group for always having pretty quick answers). You may find resistance from your health care provider or school system for using a not FDA approved system. You will likely need to rebuild your system periodically as the code or OS systems of devices get updated.


Tidepool Loop: Tidepool is working on developing a version of the DIY Loop system as an iAGC (that will not require a RileyLink). So far, Tidepool has shared that it is partnering with Omnipod and Medtronic for the ACE pump and Dexcom G6 for the iCGM. They have already stated that the initial platform will be on an Apple device (Android devices will follow later). The observational study has been going for 12 months now and is due to collect data through March 31st. Jaeb Center released initial results at the ATTD conference on February 20, 2020. You can download that presentation here or see it in the browser here. The results are encouraging, with time in range increasing from baseline 67% to 73%. However, as noted in the study, the starting user was demographically from an already “above-average” population. The teen population rose from a baseline 63% to 68% time in range. The time in closed loop mode was 79% on average. Generally speaking, Loop does not go out of closed loop mode unless CGM data is missing, RileyLink communications are failing, or the user has chosen to manually end closed loop operations for awhile. It is unclear from the data so far why the time in closed loop mode is relatively low given the simple requirements for staying in closed loop. No word on the timing of when Tidepool Loop will be available, they are working on getting a submittal ready to send to FDA as of the date this was posted. We also don’t know the specifics on what will be different from DIY Loop ultimately, but Tidepool has stated they are trying to stay fairly similar to the app that DIY users have been familiar with so far.

Note: Tidepool has stated often that it wants to partner with more interoperable devices to provide more choice. So far, Tidepool Loop has partnered with Medtronic and Insulet ACE pumps…but if other companies develop ACE pumps, they could conceivably partner with Tidepool Loop, too. Same for iCGMs, currently just Dexcom G6 but they want more partners to promote more choice for users.

Insulet’s Horizon: Insulet filled its enrollment need for pivotal trials recently and that trial is on-going. They previously conducted a 48-72 hour study with 14 participants and a 36-hour in-clinic study with 58 participants.  What do we know about it right now? Well, the algorithm is contained within the pod itself. So if you walk away from the Android device that controls the pod (aka the PDM), the system will still be able to modify your basals while you are away from the PDM. That’s a pretty useful feature. What we don’t know is any details about the algorithm’s strengths or weaknesses in every day use.  As the 670G and control-IQ experiences have demonstrated, the final user experience will be more than just simply what the time in range or A1C is possible.

Note: Insulet’s Horizon appears to be headed to a partial interoperable product since it has announced partnerships for the Horizon system with Abbott and Dexcom CGMs. Users would need the Horizon system to round out the ACE and iAGC approval portions to be able to switch between CGMs on Horizon.

Beta Bionics: The iLet closed loop system being developed by Beta Bionics has a major difference already…they are aiming for dual-hormone closed loop. So in addition to the usual insulin cartridge in a pump, the iLet will have a pump-friendly version of glucagon to help prevent lows. Beta Bionics is about to begin enrollment for a pivotal trial of their Gen 4 iLet in its insulin-only configuration.  Once they complete a pivotal trial, they should be able continue with the next pivotal trials for dual-hormone looping. Beta Bionics has been around for quite sometime now, and this article has a good history and information:

“The iLet is different from the current commercially available pumps in a few ways: it does not require any settings (carb ratios, basal rates, and correction factors), nor does it require carb count entries for meal boluses (though you do still have to announce meals).

This is an adaptive system that is constantly fine tuning and adjusting its insulin delivery settings, and uses the user’s weight as the starting point to dose insulin. This means that users may expect the pump to go through learning curve at pump initialization with more volatile blood sugars, as it may take a few days for the pump to learn about your specific diabetes patterns and management needs.”

Bigfoot: Bigfoot was originally on-scene when they purchased Asante pumps around 2015. We do know that the Bigfoot smartloop would utilize an app to control the pump and run the algorithm. Bigfoot also has states they intend to use prefilled cartridges and a streamlined ordering process. Bigfoot announced the first enrollments in a clinical trial back in 2016, but to date has not begun pivotal trials to support an FDA submission. Awhile back, Bigfoot raised capital and stated they had hoped to have pivotal trials in 2018, but that schedule apparently slipped as Bigfoot changed CGM partners from an expected Dexcom to Abbott. Unfortunately, there’s not much else that I know about Bigfoot’s plans as it appears their progress is currently quickest on smart-pens.

Loop branches

**This blog post is for Loop users**

Lots of people are asking for help understanding whether they “need” to update right now and if so which branch.  This answer is best provided with some links and longer explanation, so I’m choosing to do this outside the FB or instagram platform.

What is GitHub?

First step to understanding all of this topic is to know a bit about GitHub. GitHub (in layman’s version) is where developers of programs store their code for open sharing. Kind of like a public lending library of projects.A project in GitHub is called a “repo” or repository in geek-speak.  Loop is a project/repo in that lending library of GitHub.

Loop, the app, is actually a product of several repo’s stored in GitHub. While you only download the one Loop repo, there are several other repos that are brought in as part of the build process. The have names like LoopKit, CGMBLEkit, rileylink_ios, dexcom-share-client-swift, G4ShareSpy, and a few others. I mention this now because those other repos will be discussed later in the post.

What is a branch?

Extending this idea of a lending library…GitHub is a place where programmers are sharing their code. Let’s pretend the programmers are cooks, their codes are actually recipes for how to make favorite dinners, and their repo is a cookbook of various recipes. At some point of time, the cook decides…after a lot of experimenting in the kitchen…that a recipe is great. Perfect. And then after much back and forth, the cookbook is done. Ready for publishing with all those great recipes. That book is published and put on the shelves in the bookstore.

That cookbook is called the “master” branch and the process of putting it on the bookshelf is called a release. The author is saying “HEY EVERYONE…this cookbook is super great shape. Recipes have been tested by a lot of people, editors have proofread for typos, pictures are great…go ahead and use for your next party.”

So…master branch is stable. Known quantity. Well-tested. Identified with a “release” version…similar to when books are published.

But, then the cook gets inspired by some new spices. She goes on a trip to a new country and says “Hey, maybe I could actually improve on that old chicken parm recipe? And I’d love to add that pesto dish I tried in Italy.” So, the cook starts marking up the old master cookbook with a pencil. She makes edits to the master cookbook. The edits aren’t perfect on the first try. They take some tweaking. Some recipe edits might need a couple tries before they work quite well enough.

This marked-up, in-progress version of the cookbook is called the dev branch. It may have bugs and things that aren’t quite working well yet. People using recipes from this cookbook may encounter not-quite-right-yet results. But, if the *right* kind of people are using dev branch and providing the chef quality, detailed feedback, then the chef can get those recipes dialed in a little quicker.

Once the dev branch’s recipe edits and additions are well-tested and stable again, the chef will publish an updated version of the cookbook. When this happens, the master branch get updated and a new “release” is announced.

And then the process starts all over again when the chef has a new recipe in development…iterative process for code development involves this master and dev interaction. Dev is the playground for new features to be worked on…master is where they all merge together after testing is done in dev. Master will be updated infrequently, but dev will have more frequent changes that are almost always unannounced (see the discussion below about commit history to know how to “track” dev changes)

Which branch of Loop to get?

When you download Loop code, you will be downloading a specific branch of Loop code. Often the question is “Which branch should I get then?”

The branch you use will depend on WHEN you are building, and to a certain degree your willingness to use versions that might be glitchy. In other words…the answer to “which branch to use?” will change over time based on where Loop development is. You will need to read Loopdocs to know the current landscape of branches in order to best inform your choice.

For example as of TODAY August 24th (and as described in Loopdocs)

  • Master branch only supports Medtronic looping.
  • Dev branch supports Omnipod and Medtronic looping and has overrides feature merged in and has a fix for the IOB tracking of short temp basal rates for pod users.
  • Omnipod-testing branch supports Omnipod and Medtronic looping but does not have overrides feature merged in nor the IOB tracking fix.

 Why not use dev?

So, most Omnipod loop users right now will be thinking “Well heck, why not update to dev branch right now then?” There’s a few reasons.

Dev branch users should be EXPECTING AND WILLING AND ABLE to update frequently. Do you have access to a computer? Are you willing to update frequently as fixes are pushed? Dev branch will have frequent updates to fix bugs that are revealed during testing of the new code edits…and you will want to grab them.

Finally…let’s be honest about you the user. If you see an error in your Loop app after you decide to install dev branch…will you be the type to HELP with the solution or merely whine about the problem? Dev branch updates are really helped by people who know how to capture Issue Reports and explain what they are seeing. What really slows programmers down is having a bunch of people complaining about bugs but without any accompanying documentation to help log the cause of the bug. Looped group support does not need a bunch of people saying “I’m on dev and it’s not working”. This will not help.

If you are using dev branch, you should also be capable of using Descriptive Language to help report bugs or problems.

If you can’t use descriptive language, you probably shouldn’t use dev branch right now. This is important. Thanks!

In the near future, dev updates will slow down again. Kind of like when you decide to undertake a big decorating project in your house…lots and lots of changes at first and then the pace slows down a bit. Fewer changes and things narrowing down to a final version. How long in the near future? I don’t know. But, in the not distant future (weeks?), omnipod-testing branch will be gone and we will officially start to tell people to use dev branch for omnipod looping because the updates will have slowed and the dev branch’s edits will be stable enough that the average user shouldn’t have too difficult a time with the user experience.

But can you use dev branch now?

Sure. BUT…you have been warned. There may be some bugs and if you want to report them or ask about them…you will need to use DESCRIPTIVE LANGUAGE and capture Issue Reports to help explain what you are seeing/experiencing. And you should expect to want to update to get those bug fixes.

How often are these dev updates happening lately? Dev branch has been updated 13 of the 24 days in August so far.

What are the bugs?

So you want me to list out the bugs so that you can decide if the bugs are “bad enough” that you don’t want to risk it? Or “not so bad” that you want to try dev?

That’s not how this works. When code is changed, there’s no exhaustive list of all the bugs that comes with the code change. The bugs are identified through use and testing. I may be able to tell you that I *think* most of the bugs are display-related right now…but that is absolutely no guarantee that there couldn’t be a bigger bug yet to be identified (similar to the IOB tracking bug that is in omnipod-testing branch right now). Some bugs just take a lot of testing to finally surface and identify.

But what about my JoJo features if I move to dev?

If you want to move to dev, that’s fine. But, you will lose JoJo specific features, that is true. I will not be updating Jojo yet myself to the new dev branch until dev revisions slow down a bit.

Can you edit dev to include your favorite Jojo features now? Sure, but depending on the particular feature…it may be difficult and tedious to keep up the effort right now. For example, the edit for bolusing down to 55 mg/dL is a super easy edit, but the edit for Remote Temp Targets in Nightscout is difficult.

More globally, I’m working with Loop developer Pete to try to get Jojo features (at least most of them) rolled into main Loop branches anyways. So, hopefully main Loop branches would have all the JoJo stuff soon anyways…and if any are left out, those could be left for users to do as easy code customizations.

How do you get Loop code?

The LoopDocs site has you download Loop’s code as a package to your computer. That package is kind of like a xerox copy of the Loop code at a point in time.  That part is important…A POINT IN TIME. The code that sits on your computer, when you download it, does not track updates that might be added to Loop’s code later. If you want updated code, you have to go out and ask GitHub for a new xerox copy…aka download code again.

How do you know what age your Loop code is?

Every change to the code in Loop is tracked as “commits”. These commits are logged individually…every single one of them. That is the great part about GitHub for developers. They can see exactly what lines were changed, by whom, when those were changed, and they usually include a very brief explanation of what the change was for. The analogy for those who aren’t programmers…it’s like seeing your Word document in track-changes mode.

So, the date you download your code is timestamped on your download folder. Select your Loop download folder and press command-i to bring up the folder’s info (or right-click and choose “get info”). The “created on” date is the date that your code that you’ll use for Loop is current to…in other words, the last commit that was made in your downloaded Loop code is that created date.

In the screenshot above, that indicates that the Loop code (dev branch because I can see that in the folder name) is current through any changes up until July 26th.

How can I compare my download vs current branch’s status?

If you want to see what’s happened to any branch since the date you downloaded your Loop code…that’s easy. GitHub has a log of all the commit history sorted by date. A “commit” is an edit to the code.

Loop master branch commit history

Loop dev branch commit history

Loop omnipod-testing branch commit history

Simply look and see if any commits have come in since you downloaded…if there’s been new commits, then you can decide to update your Loop app with a fresh download. Do you *have* to update? Not usually…but sometimes there’s good reason to prioritize an update sooner rather than later. For example, if you get one of those new G6 transmitters…you’d definitely want to have your Loop app updated as those commits came in on July 18th…you can practice looking at the commit log and find the G6 updates in the commit history. Check your download and see if you downloaded before or after that commit was made. If you downloaded your code before July 18th, then you will want to update before you get an updated G6 transmitter style.

So, if you decide to update to dev branch and wonder whether it’s been updated since you built it last…that’s how to check.


Restarting Dexcom G6 sensors – Updated

Awhile ago, I posted a page about how to restart your Dexcom sensors to last beyond 10 days. There’s need for some updated discussion on the topic.

For clarity- let’s take one quick aside to make sure we are clear on TERMINOLOGY before going in deeper.

  • Reset = resetting the clock on the transmitters so that you can use them beyond 110 days that Dexcom officially ends them at. If you reset a transmitter, you get another 110 days to run that battery down to nothing. When the battery dies, no amount of resetting will help. It’s dead.
  • Restart = term for restarting a sensor session to last beyond the 10 days that Dexcom officially ends them at.

So to be clear…sensors can be restarted, transmitters can be reset. BUT…if you say “restarting a transmitter” or “resetting a sensor”…I may think that you are confused about what you are actually trying to accomplish. I will try to be careful to always use reset and restart to help you follow along exactly which parts I’m referring to.

Ok, now that we have that out of the way, let’s talk about some recent developments on the G6 system. First, a quick description of the products available as there are a few new ones out there.

G6 transmitter

Most G6 transmitters, that we are all familiar with from the start of distribution in June 2018, are fairly flat on top, with a small round indent on the fat end of the transmitter. The transmitter IDs start with 80xxxx.

(Quick note about transmitter IDs: the transmitter IDs could be different in different markets/times…it’s not like Dexcom is sending me a pamphlet to let me know their whole scheme. So…if in doubt, go with the visual indicators of how the transmitter looks and is shaped.)

Those transmitters can be reset using the Reset Transmitter app (instructions here), or Spike/X-drip+ apps.

Those transmitters work offline with all versions of Loop app.

G6 “81” transmitters

Dexcom started sending out transmitters with IDs starting with 81xxxx. At first they seemed mostly Outside US, but now they are in US market too. They look very similar to the transmitters described above. The 81xxxx transmitters will not usually restart sensors using the 15 min, no code method. These transmitters have the more aggressive trauma check discussed below.

Those transmitters can be reset using the Reset Transmitter app (instructions here), or Spike/X-drip+ apps.

Those transmitters work offline with all versions of Loop app.

G6 Firefly transmitter

The G6 firefly transmitter is a “new” transmitter that Dexcom has quietly started to ship out in the US. There’s no formal announcement from Dexcom about this new transmitter. The transmitter ID for G6 firefly starts with 8Gxxxx and the transmitter is visually different than the old ones. There is (1) a kind of bump/hump running along the top of the transmitter’s length where the word “DexcomG6” is printed, (2) bigger, bolder writing for the transmitter ID on the underside, (3) lack of “FCC ID” printed on the transmitter’s underside, (4) a little oval indent surrounding the metal contact points on the underside of the transmitter, and (5) a little groove surrounding the perimeter of the transmitter (like where top-half and bottom-half join). There’s a photo below of the G6+ transmitter which looks very similar to the G6 firefly. The good news is that the new transmitter does seem to have a longer range and pretty strong connection. The changes to the design also probably mean quicker manufacturing for Dexcom…so maybe Canada might finally be able to get the G6 system, too?

The bad news? This is not yet direct-to-watch.

These transmitters cannot currently be reset.

These transmitters cannot currently work with Spike or Xdrip+ apps (to my knowledge…and I will update this when someone does make them compatible).

These transmitters can be used with Loop offline, so long as you built/updated your Loop app after July 18, 2019.

G6+ transmitter

In South Africa, Dexcom is rolling out a new G6+ system…as part of that system, there’s the G6+ transmitter. It has all the same features of the G6 firefly transmitter described above but says “DexcomG6+” on the top. The transmitter IDs for the G6+ start with 22xxxx.

(side note about the G6+ system overall: 14 day sensor sessions and one hour warmup are also part of the new system they are getting in South Africa)

These transmitters cannot currently be reset.

These transmitters cannot currently work with Spike or Xdrip+ apps (to my knowledge…and I will update this when someone does make them compatible).

These transmitters can be used with Loop offline, so long as you built/updated your Loop app after July 18, 2019.

Restarting Sensors: that 15-min, no code thing

So all that talk about transmitters is to let you know that some of the restarting options may need to change for you. The G6 firefly, the 81xxxx, and G6+ seem to have new more aggressive check(s) for “insertion trauma” signs of a new sensor to prevent restarts.

I know the internet had a lot of users that used the “stop sensor, do 15 minutes of no-code, stop sensor, do old code for 2 hours” method of warmup. That 15-min, no code method is prone to failure, and will have even more failures with the new transmitters especially.

Why? Dexcom is looking for signs during warm-up that show that your sensor is new. With new sensors, you’d expect to see some jumpiness in the BG data as the new sensor wire gets acclimated to the new in-body environment. The data during warmup is not the quiet, calm BGs that a settled-in sensor has. Occasionally, an insertion can go so smoothly and BGs happen to also super stable for 2 hours…that Dexcom’s algorithm perceives that the user was restarting because the trauma signals aren’t strong enough. We’ve all probably had that happen once or so…”But wait…I wasn’t restarting”. Congrats, you had a smooth insertion, with stable BGs. Your potential reward? Get another new sensor and show some real trauma this time.

The sure way around “no restarts”: Bluetooth Unpaired method

The only way for sure around this trauma check that I have found on both new and old transmitters alike is to use the old Option 2 method from my original post. Let’s call it the “Bluetooth Unpaired” method from now on.

HUGE IMPORTANT POINT: You must start and finish this process before your current sensor session is scheduled to end. In other words, if you see you have 2 hours left on your session, you’re too late.

The detailed procedure for the “Bluetooth Unpaired” method:

(Start AND finish the whole process before your existing session was due to end!)

1. Wait for new BG to come in and then wait about one minute. Doesn’t have to be exactly one minute…just enough of a little pause to make sure the transmitter is done talking to the app. If you session already expired, just start with step 2…no big deal.

2. Forget/delete Dexcom from Bluetooth list in phone’s settings. iPhone users, tap the little “i” next to every Dexcom ID in your bluetooth list and forget the pairing(s).

3. “Stop Sensor”, “New Sensor”, enter code, “Start Sensor”

(If you are a Loop user, delete your CGM in Loop settings here…we will add it back at the end of this process. If you forget to delete your CGM in Loop settings, you won’t see a pairing request in Steps 5-6.)

4. Wait 2 hours and 5 min for the warmup to finish. Do not accept any pairing requests during that time. You’ll probably see “transmitter not found” display on the Dexcom app during this time. You can use your phone as normal during this time, but I advise turning off Dexcom app in the Notifications section of your phone settings so that you don’t keep getting pinged every 5 minutes.

5. After the warmup wait, open Dexcom app and wait for pairing request.

6. Accept pairing request. You may see “signal loss” message for up to 5 min after this setup.

7. BGs and fresh 10-day session should appear after that signal loss clears in five minutes.

(If you are a Loop user, add your transmitter ID back into Loop settings here.)

Microwave/Receiver Method still work?

So far in my experiments, I have not been able to use the old “Option 1” method (the microwave or receiver method) on the newer G6 firefly, 81xxxx, and G6+ transmitters (*UNLESS I FIRST did a restart using the Bluetooth Unpaired method…see SUPER INTERESTING LOOPHOLE SIDE EFFECT paragraph below). I also could not get the 15-min, no code method to work with the new style G6+ or G6 firefly transmitters.

So, if you want to use your receiver restarts again with new transmitter styles…make sure to read below.

Why would you want to do the receiver restarts? Seems like hassle to you? Most people choose this method because you continue to get CGM data during the restart wait.

If you don’t own a receiver or don’t care about the 2 hours without CGM data, then go ahead and stick to the Bluetooth Unpaired method described above.


Once I did that Bluetooth Unpaired method for a restart though, oddly that seemed to disable the trauma checks in the system/app long term. I have been able to use the receiver restarts just fine again, so long as I had already done one restart using the Bluetooth Unpaired method. I can now even simply stop a session and restart it directly…without any deleting of transmitters from BT or 15 min, no code…basically stop/start works just fine on its own.  The app becomes pretty much like the G5 app in terms of simplicity of restarts. <—- that’s a really big deal if you value simple restarts. I’ve had one other person confirm their app behaves the same as I’ve just described using an G6 firefly after she did a Bluetooth Unpaired reset once. SOOOO one confirmed with G6+, and one confirmed with G6 firefly…I am testing this method on the old style G6 transmitters now to see if the same loophole can be created with those…I’ll let you know in a day or so. For some reason, I’d never found this loophole before. Maybe it wasn’t there on the old transmitters, or maybe I never looked hard enough.

(*By the way, once I deleted the Dexcom G6 app and reinstalled it, the trauma checks came back to life, and I had to do the Bluetooth Unpaired method once again to get rid of “no restarts” messages.)

Safety Precautions

As with all things DIY…use COMMON SENSE and SAFETY FIRST. The accuracy of Dexcom sensors will decrease over time and the more you restart, the more this could be a concern.

After you see your CGM readings start again on a restart, make sure to do a several finger checks regularly with your glucometer to check for accuracy.

Don’t extend a sensor session beyond its accuracy…ESPECIALLY IF YOU ARE USING AN AUTOMATED INSULIN DELIVERY SYSTEM. No amount of money savings is worth automated insulin delivery on a sketchy sensor.


Final note, good thing I’m not charged per sensor session by Dexcom. I think I did about 50 sessions on these tests just to make sure of everything.




FDA warning against DIY systems

I’d like to address, in my own opinions, the recent announcement of the FDA warning “against the use of devices for diabetes management not authorized for sale in the United States”.

First, there’s a lot of rumors out there and the headlines from the various places trying to “explain” the situation do little to actually give good information. I just did a search to find the link above and let’s just look at those headlines…how many were misleading ledes or otherwise really not getting the whole message correctly explained.

About the only article that really gets it right is the JDRF statement. But, the average person trying to sift through the information this is a very confusing topic admittedly…so let’s pull out some of the specific quotes from the FDA warning and talk about what they mean in plain terms. This really wasn’t about DIY closed loop systems causing harm (although that could be part of it, depending on the situation)…the underlying cause of the warning was about DIY CGM apps.

“The FDA received a report of a serious adverse event in which a patient used an unauthorized device that receives the electronic signal from an FDA authorized glucose sensor and converts it to a glucose value using an unauthorized algorithm. Glucose values from this unauthorized continuous glucose monitoring system were sent to an unauthorized automated insulin dosing device to drive insulin dosing. The automated insulin dosing system gave too much insulin in response to repeated incorrect high glucose values sent from the [unauthorized] continuous glucose monitoring system (emphasis added). This unauthorized system resulted in an insulin overdose requiring medical intervention. ”

Before we can look at what this means…it would be helpful for many people to have a really basic introduction to continuous glucose monitors (and this is the really layman version).

CGM basics

Glucose sensors don’t actually read a blood glucose reading. Instead they read a “raw signal,” basically an electrical signal from the fluid surrounding the sensor wire. That raw signal is then converted to a “blood glucose reading” by an algorithm. The algorithm that does that job is a HUGE chunk of work by the company that makes the sensor. They do lots of design, testing, clinical trials, and reworking on that algorithm. That algorithm is really, really important for demonstrating that the sensor will be safe for the users in a variety of situations. For example compression lows, poorly timed calibrations, and rapid temperature changes are just some of the difficult situations that an algorithm will need to deal with.

Dexcom sensors showing ??? or “sensor error, wait up to 3 hours”…that is actually a part of the safety algorithm. The sensor wire’s raw signals are either varying wildly, perhaps the calibration entered is way out of its expected bounds, or the temperature suddenly shifted a lot. The sensor algorithm is rightly telling you “Hey, I’m unsure about telling you a number and I don’t want you doing something unsafe with a number I’m not sure about. Give me a chance to see if the raw signals settle down again.”

All sensors on the market have safety checks and sensor failure communications built into their algorithms. They also have enforced end-of-sensor (for example, Dexcom G6 is 10 days) timing in the apps. These features are all part of the safety of using CGMs for diabetes management decisions, and they undergo FDA review.

X-Drip and Spike Apps

Have you ever just wanted to avoid the ??? or enforced end-of-sensor sessions? I know you have because this blog’s post on how to restart a Dexcom G6 is one of the most popular blog posts I’ve ever written.

There’s two DIY CGM apps on the market that avoid those ??? and session ends. The apps (X-drip for Android phones and Spike app for iPhones) are popular in part because they offer the ability to just “always get CGM data”. While nice on the surface, those features can present a problem potentially…and that’s what the FDA warning was all about.

X-drip and Spike use their own algorithms to handle the raw signals. Calibrations, temperature variations, sensor noise, sensor failure notifications and other variables within the algorithm are not clinically-tested for those apps. (note: Generally, X-drip and Spike use the same algorithms between the two apps for several of the supported CGM devices. Therefore, X-drip and Spike are generally going to behave the same when we are discussing the general topic of DIY CGM apps.)

Reported Adverse Event

So what happened to trigger the FDA warning?

Plain and simple…a person was using a Libre sensor on one of these DIY CGM apps. Libre sensors are not continuous glucose monitoring devices. They are flash glucose monitors. In order to make them into continuous glucose monitors, some people have used non-FDA approved devices that sit on top of the Libre sensor to emulate someone “flashing” their Libre for a reading.  Those devices you probably recognize as either the Miao Miao or Blucon readers.

Since these readers are not officially associated with Libre sensors…there’s also no clinically-tested, FDA-approved app to receive the information from these readers. And this is where the warning comes in:

“The FDA received a report of a serious adverse event in which a patient used an unauthorized device that receives the electronic signal from an FDA authorized glucose sensor and converts it to a glucose value using an unauthorized algorithm….repeated incorrect high glucose values [were] sent from the [unauthorized] continuous glucose monitoring system…”

Someone using (1) a Miao Miao reader and (2) a Libre sensor and (3) a DIY CGM app had a situation where the sensor failed. Instead of the sensor failing by then reporting no data (such as ??? or “sensor error” like Dexcom), the DIY CGM app showed incorrectly high BG readings.

What does this look like?

The image above is from another recent report very similar to the one discussed in the FDA warning (minus the need for medical intervention). Details of this event can be found in the OpenAPS Github repository.

The user had Miao Miao + Libre sensor + DIY CGM app. The recently restarted sensor started to fail with a drift. The user, rather than pull the failing sensor, tried to calibrate the sensor to the 16 mmol (about 288 mg/dL) value shown near 10am. The failed sensor took the calibration and remained virtually stuck. The DIY CGM app continued to report nearly 16 mmol for 8 hours…

So, let’s stop there and assess.

  • Are we irritated when sensors stop providing data and instead say ??? or “sensor error”? Yes.
  • Are sensors expensive and we try to get them to work as long as they can? Yes, many people do.

But, if automated insulin dosing is also a part of someone’s DIY CGM app use…those safety factors (and your ability to do without them) may need to be re-evaluated in terms of whether or not you want to continue to make insulin dosing decisions on them. Can commercial CGM algorithms still get data wrong? Yes, but it is far less common these days…and if they do get data wrong, it is very unlikely to be so “off” that an automated insulin delivery system would cause a hypoglycemic event serious enough to cause medical intervention.

Automated Insulin Delivery

The FDA-reported problem of the failed sensor still sending bad CGM readings through the DIY CGM app…it affected the user’s DIY closed-loop automated insulin delivery and caused the system to over-deliver insulin. The user needed hospitalization for the hypoglycemic event that occurred as a result.

The figure above with the 16 mmol? See below the royal blue marks at the bottom of the figure? Those were automated insulin microboluses delivered by the user’s OpenAPS system to try to bring down the 16 mmol. If unnoticed by the user, those insulin deliveries could have caused hypoglycemia.

Is this potential to over-deliver (or under-deliver) insulin unique to DIY closed-loop systems? Nope, absolutely not. And that is the message that all this news coverage is missing. The REAL story. Access to quality CGM devices is the underlying need to be addressed.

Any automated, closed-loop system (commercial or DIY) will only be as good as the CGM data that is feeding the system.

Medtronic’s 670G system will kick users out of automode when their algorithm has sensor issues. All commercial closed loop systems will have safety checks that if the CGM part of the system reports an error…you’ll be kicked back to old-school insulin dosing decisions.

CGM Data is Critical

Now that we’ve addressed the background, it is pretty obvious just how important keeping quality CGM data is if you choose to use any closed-loop system.

Only one iCGM system, the Dexcom G6, is currently FDA-approved for eventual automated insulin dosing across future integrated pump/loop systems (Medtronic’s 670G’s Guardian 3 sensor is approved only for their system in particular). This is the system we use and I love it. I feel very safe with its use and messaging. The first 8-12 hours are a little jumpy and I can choose to open loop if I want to…but otherwise the sensor has proven to be exceptionally accurate for the 10 days we use it. Despite the fact I wrote the blog post about how to restart, we actually don’t restart our G6 sensors. Anna enjoys fresh clean adhesive and the insertion is so easy for her that it isn’t an impediment to change sensors any more.

Unfortunately, many areas outside the USA do not have access to or approval of Dexcom G6. This leaves them either incredibly expensive or entirely unavailable. The Libre sensors are more widely available and/or affordable in those markets…giving rise to this dilemma about DIY CGM apps.

Ideally, the FDA’s warning message hammers home a point that really is sorely true. The access to quality health tools to safely manage T1D is lacking. T1D is so inherently risky. The slowness of the world’s government systems to help with access and affordability of quality CGMs is adding to our community’s collective risk.

Dear FDA…if access and affordability of quality CGM systems were addressed, DIY CGM apps would not be needed. Adverse events can happen on your FDA-approved devices as well. T1D is risky with syringes and finger sticks through the most advanced FDA-approved closed loops. The warning is that diabetes is risky, and we need quicker iteration and better development in the commercial markets.

People might not necessarily want to use a Libre plus a reader plus a DIY app…but in some cases they’ve assessed their risk management baskets and decided that setup IS their best risk mitigation.

To those people, please…

  • be exceedingly careful about not extending sensors to beyond their safe lifespan,
  • make very careful calibration decisions,
  • watch for signs that the sensor wire as even partially pulled out of skin, and
  • if in doubt, change your sensor and take finger stick readings.

For us personally, we are grateful to have an iCGM (Dexcom G6) and that we can afford to change it regularly. We use the official Dexcom app because those times of “sensor error” or “???” provide a level of safety that I find appropriate, rather than an annoyance, since we are using a closed-loop. We replace sensors when they show any sign of failure, and I don’t feel in the least bit guilty about it. And the use of our DIY Loop app has decreased our overall risk exposure while managing T1D…but I can only say that because our CGM data is reliable. And that’s what the FDA warning was trying to tell you.

Juicebox Method to Loop

To all those who said hi to me from the Juicebox Podcast, thank you! I see you and hear you…(and hello similarly to Sugar Surfers…this post is also for you all…basically for everyone who tends to “know their boluses”.)

You may have heard my jaw drop on the floor just a touch during the podcast when Scott asked if he needed to count carbs and know his carb ratio in order to Loop…and I think it’s time to write up a blog post to help you all transition from what I’ll call the Juicebox method to Loop. Because yes, you need to know your carb ratio and carb estimate. I’ve noticed for many of you this may be quite an adjustment if you don’t have a head’s up about how to make this transition from where you are with insulin surfing.

Why? Because you all have been insulin surfing without settings (and no, I am not typing that in a derogatory fashion). There’s a book called Sugar Surfing that has the same general underpinnings as what Scott his podcast are really good at explaining for the Juicebox method…think dynamically and react according to what you are seeing. Scott’s coined phrase is “Be Bold with Insulin” and it’s allowed a lot of people to transition from feeling like they need a restricted diet to meet A1C goal, and instead eating higher carb meals quite successfully and getting more consistent results. I’m a big proponent to this concept…it is basically the idea of lining up the insulin dosing so that it is most effective against carbs rather than restricting carbs. Even low carbers have also embraced this concept of lining up insulin and carbs appropriately by using R-insulin (slower, longer peak action time) and eating slower foods like proteins and fats…so the concept crosses a lot of user groups similarly.

The rub is that what if someone else was doing the reacting and thinking dynamically for you so that you could take a break? You can’t react while you’re asleep. Your kid doesn’t want to react while taking their math test. And all the button presses you can save?! That’s what Loop does 24/7 even while you sleep.

BUT…to get Loop to react, you need to feed it information about yourself and your diabetes. That information you’re going to feed Loop is your settings; basal rates, carb ratios, insulin sensitivity factor (ISF, sometimes called correction factor). And this is where Juicebox users will perhaps run into trouble because the method approaches diabetes from the end result (how much insulin to give) rather than the beginning (what settings will affect how much insulin to give). So, how can we get you from managing at the end result (insulin) and shift you to the beginning (settings and meal entries)?

Let me give you an example to help illustrate. Enter friend Jane Doe.

I set up a good friend, Jane, on Omnipod Loop before it was publicly released. I’ve known her for a long time and she has a little daughter, Princess Buttercup, with type 1. My intent was to see how the docs would work for Jane and fix places where she told me it was not clear enough to a new user. Also, I wanted feedback on what common pitfalls in the Loop app might be for new Omnipod Loop users and such. She was my canary in a coal mine (thanks Jane!).

Jane had been using the Bold With Insulin approach for eating for a long time. She knew which foods her daughter ate and how to administer insulin. Meals had a predictable good result. But, she didn’t count carbs much and didn’t know her settings really. Her endo had given her some PDM settings, but they were never really tested because she didn’t use them. Meals didn’t use a carb count and corrections for out-of-range or changing BGs were done by “feel” based on how quickly BGs were changing, not through calculating insulin on board and ISF. If she saw a slight climb in CGM, she’d have a manual bolus “feeling” based on so many times she’d corrected before in the same situations. If the climb was steeper, she’d manually give more insulin, also based on previous experience. The only setting that got any kind of real use was basal rates…but even those were frequently being overrun manually with temp basal rates she’d enact herself.

I asked her how new meals that she’d never tried before would go. Jane described that there would be a first guess at a bolus based roughly on similar other meals with those similar types of ingredients. She’d watch the CGM and adjust insulin manually. She’d track in her head how those adjustments worked out and the next time she bolused for the same meal, Jane would try to use what she’d learned from the meal the previous time. This meant that new foods were kind of a learning experiment, but she’d pretty quickly dial-in a “known dosing” for the new food within a few tries.

A couple days into using Loop, Jane was pretty frustrated but I hadn’t known it. She was trying to figure it out on her own (she is a smart cookie) and something just wasn’t clicking.

In almost a straw-that-broke-the-camel’s-back moment, it was a bagel that finally made her ask what was going on with Loop and why this wasn’t working. And that opened up my eyes to the Bold With Insulin approach she’d been using and where that transition needed help.

Here’s the rough conversation (and it would probably be very, very similar to a convos any one of you could have as you transition):

Jane: I’m so frustrated. I can’t figure out where I’m going wrong. She had a bagel. Prebolused. Typically a food I bolus well for, like never above 150. (And a screenshot of a definitely-well-over-150 dexcom graph.)

Me: How many units would you have bolused for normally for that meal?

Jane: Normally, I would have dosed 1.25 units like I did this time, but I would have doubled her basal for awhile. This time when I gave the 1.25 units, Loop suspended insulin while she was waiting out the prebolus time.

And that conversation gave me a lot of insight into the issue.

  • Carb counts weren’t a big (or even small) part of her method on a regular basis
  • Bolusing was all being done with tools no longer available in Loop (extended boluses and temp basals)
  • Carb ratio wasn’t even used…she just had the boluses memorized for given meals.

So how has Jane turned it around? (Princess Buttercup has had a 0.5% A1C drop in two months of Looping now and Jane’s getting sleep)

Jane rolled up her sleeves and got to work on her settings.

If you are in Jane’s shoes and want to set yourself up for an easier transition, here’s a few tips you can do now.

Settings Testing

To transition successfully to Loop, Juiceboxers and Sugar Surfers alike are going to need to do some settings testing and meal deconstruction. Likely in open loop for a bit if you want to keep your frustrations down to a minimum.

This means not correcting immediately when you are testing basal rates for example. This means doing things in a sequential testing route…basals, carb ratios, insulin sensitivities in an ordered fashion. And also, you’ll need to look at how you’ve been successfully bolusing your meals and translate that to Loop.

It may take a couple weeks to finish the route…but the end result will be that you have decent settings to start with and Loop will be a less frustrating transition. Let’s start…

Work on your Basal Rates

Juiceboxers and Surfers have a lot of manual insulin adjustments running frequently. Temp basals and extended boluses are not at all uncommon.  Unfortunately, this is also a good chance to have difficulty in identifying if basals (especially daytime basals) are truly set correctly. There’s a high likelihood that all parts of your daytime are touched by insulin remaining from an extended or temp basal that ran within the last 6 hours.

When you get into food habits, and have “known boluses” for them, you can basically have two wrongs making a perfectly great right. For example, send kid to school with her favorite lunches every day and those boluses involving extended/temp basals…you might just be covering not only the food in the meal but also some basal needs from the day at school. Same for the breakfast you’ve been sending her out the door with. Or maybe you’re bolusing less for lunch than you’d typically need because she has PE class after lunch. Those are instances where having two compensating factors are showing a good result in BGs outside a Loop…but you may have problems when you go on Loop without truly knowing you were compensating for a settings issue.

Checking basals is a pretty easy starting place. Basals, in the absence of food and exercise, is the amount of insulin that should keep your blood glucose steady and flat.

So…test that. Go without food and exercise for a bit and see how that turns out. Start easy…these are kids and they won’t want to go without food (I get it). Perhaps start with some distractions to breakfast time. See if you can get 2-3 (or even 4 ?!) hours or so without a meal in the morning. Bribery works wonders here. Favorite video games, money, whatever. 😉 Do you notice a drift? Do BGs start to climb/drop without a breakfast bolus involved? If so, you will need to adjust your basals.

Do this check for a few times of day separately (morning, afternoon, night), if possible. Sleeping basals are the easiest to check since there usually isn’t food involved. But, if you can get a good morning basal test in…that will do WONDERS to helping get you off to a good start on settings during your transition. Did I mention the wonders of bribery? Seriously, if I were to invest money…basal testing is a great place to spend some money on your kid. Huge payback.

And hopefully this is obvious, don’t do basal testing if you are on steroids, medication, ill, or otherwise have something that is temporarily affecting your underlying insulin needs. Bad insulin sites and/or illness will not yield useful basal testing.

Personally, Anna has a basal rate that tends to be higher while she is awake vs asleep. Therefore on weekends (not school days), we can shift the start time of her “I’m awake” basal rate in Loop to match her sleeping-in habits. Anticipating your question: If we forget, it isn’t a big deal…Loop accommodates pretty well. Instead of hanging out at her 95 mg/dl target from 7am-10am on a weekend, she might hang out at 85-90 mg/dl if we forget to tell Loop she’s sleeping in. So, I don’t fret too much about telling Loop those kind of details…it’s up to you how you’d want to deal with that kind of details.

Work on your Carb Ratio

A well done meal bolus should bring you back to target BGs within three hours after a meal and not require low treatments as a result of the meal bolus. Pretty simple concept…difficult in execution for many. There’s a couple insights that really help with “successful” meal time BGs:

  • Prebolusing
  • Accounting for fats and proteins in total carb counts
  • Accounting for fats and proteins in the duration you need to bolus for

The good news is as a Juiceboxer and/or Sugar Surfer, you’re already likely doing those things. You have a good feel for bolusing. That’s a great thing. Don’t let that go to waste. What you need to do though is convert that knowledge into a carb ratio and meal entry so Loop can access that knowledge too.

Start as soon as you’ve completed your basal testing. Then try your meals again. When you have a meal…calculate how much TOTAL INSULIN you use on your Bold or Surfing method for the meal, including extended boluses and temp basals. In the bagel example, total bolus was 1.25 units up-front and another 1.5 units over two hours…so a total of 2.75 units for the bagel.

Now estimate the carbs for the amount of bagel you ate. Let’s say you ate 45g of bagel. Take the total grams and divide it by the total units…that is your carb ratio. 45/2.75 = 16 (rounded off). Therefore for every 16g of carbohydrates eaten, you’ll need one unit of insulin.

As a Juiceboxer, you probably have many meals you already know your bolus strategy for. Write out a list of them, look up some carb counts and do a table of calculated carb ratios. Do as many of your meals as you can think of. They should all roughly average out to about the same carb ratio. This would be an excellent place to start your carb ratio setting in Loop.

If you have meals with heavy fats and proteins, don’t forget that those often need some “equivalent carbs” added to the total count of carbs for the meal. For example, a protein bar may say 35g of carbs on the label…but I know that they are very heavy in protein and therefore I need to cover the carbs in that bar more than just 35g. As a juiceboxer, you’ve already done this by having a larger bolus for that bar than the first time you tried it…now you just need to realize it’s actually a larger carb count because of protein. For us, that protein bar really contains the equivalent of 60g carbs because the protein breaks down into sugar in the blood stream too.

So again…it’s a shift from thinking of things in the end result (insulin) to thinking of things from the beginning (settings and carb entries). Take your known insulin boluses and work backwards to your settings. If you have heavy protein meals, add some to your carb counts (perhaps 30-50% of the protein grams will convert to carb grams for estimations).

Work on Insulin Sensitivity Factor

Now the above example is really super exciting and an example of how great Loop can be…but that success also depended on one more critical factor you’ve yet to set; Insulin Sensitivity Factor (ISF), also called a Correction Factor in some systems.

Basically, your ISF is the amount of drop in BGs you can expect from one unit of insulin. That’s a pretty important value to Loop if you think about it in those terms. An awful lot of Loop’s decisions (in fact EVERY SINGLE ONE OF THEM) will depend on that setting in its calculations.

This ISF is a pretty simple concept, but also the most difficult to “get right” because experimenting and testing can be really hard if any of your other settings are wrong.

Unfortunately, this setting is also the place most new Loopers start with their adjustments (because they assume previous success means their settings were right…so it must be the ISF that is wrong?)…and they do it while in closed loop. Hint: DO NOT BE THAT NEW LOOPER. You may lose your marbles.

Instead, start in the sequence listed above…nail down those basal rates by testing them first or else messing with ISF will be counter-productive and you’ll go nuts.

Once you get basal rates set, you can test your ISF by taking a glucose tab. Get above target and steady at that higher BG for a bit. Now take an amount of insulin that will safely get you back near range. Wait about 4 hours with super chill lifestyle. Don’t exercise, don’t eat, don’t fight with your siblings and for God’s sake don’t get on the trampoline. See how much you’ve dropped in BGs. Take the drop in BGs and divide it by the amount of insulin you gave. If you dropped 30 mg/dl with a dose of 0.50 units, then your insulin sensitivity would be 60. Meaning one unit of insulin would be expected to drop your BG by 60 mg/dl.

I cannot stress enough how important ISF is, and how misunderstood as well. Let’s do some ISF myth busting/confirming:

  • Dropping the value of your ISF (say going from 100 mg/dl to 80 mg/dl) will be a good solution to a new Looper who is consistently stuck high. WRONG. This indicates more of a problem with lacking adequate basal rates.
  • Spikes after meals can be dealt with best by changing your ISF. WRONG. Meal spikes should be dealt with by meal entries AFTER you’ve done the work to test your settings as described. Prebolus, adjust carb counts, and adjusting your meal duration (lollipop, taco, pizza icon) are the best way to deal with meals that don’t result in desired outcomes once you’ve adjusted/tested your settings.
  • Illness, medications, and hormones can all change your ISF. TRUE. If you notice that settings that previously worked in Loop after all that great testing…you may have a hormonal female teen. Or a sick kiddo. And yes…you’ll need to adjust some settings for that. (Make a mental note to read my upcoming blog post about the new Override features in Loop…that’s coming up and can help with those situations.)
  • Roller-coastering BGs in Loop can be because ISF is set wrong. TRUE. One of the most common issues is impatience in starting Loop…seeing higher numbers than you are used to (blaming them on Loop not being aggressive enough) and therefore lowering your ISF value thinking that will make Loop correct “better”. WRONG. Lowering your ISF value will make Loop lay on more insulin, but unfortunately, it also works in reverse. Every unit Loop suspends is also undercounted as a result of the artificially low ISF value…leading to a rebound BG. You’ll ride a nice wave of high temp basals followed by suspended basals…and your BGs will reflect that same oscillation.

  • So, if you have tested your basals, tested/calculated your carb ratio, and even tried to take a good swag/test at ISF…yet are roller-coastering? Try raising your ISF value just a bit. If you were at 60, try 65. Keep tweaking slowly and watch for your sweet spot. You’ll find it. Eventually you will find it.

Next Level: Adjust your Meal Entries

Now that your settings are nice and solid…we have a really good place to adjust from. (Really…make sure that you did the work in the steps above. Getting some decent understanding of your fundamental settings will help more complex meal boluses go much better.)

You’re probably wondering right about now “So, I’ve done all that work for settings…but I still don’t quite understand how I’ll bolus for my meals now.” All those awesome extended boluses and temp basal work that you’d been doing and had nailed? How do you recreate that experience in Loop? Meals that tend to stick around longer than just an initial bolus that you used to extend bolus for?

Now that basal rates, carb ratios, ISF are pretty well known, let’s make note of the meals that you normally might give less upfront and more of the total insulin later instead. Like pizza anyone? Chinese food. Quesadillas. Rice (omg, the rice) and sushi.

If you gave all that insulin upfront, you’d be going low early and high later…not the best outcome. Think of it like a game of tortoise and the hare (rabbit).

A quick carb meal like a fruit snack is a rabbit…it can out-run any insulin. It is super fast digestion and uses all its energy very quickly.

A slow carb meal like pizza and pasta is a tortoise. If you gave all the insulin up-front, you’d go low low within about an hour of eating and then be high high for hours later.

As a Juiceboxer and Surfer on a tortoise meal, you’ve gotten accustomed to some insulin upfront but using an extended bolus or temp basal to make sure insulin is still around to deal with those late BG climbs. Loop has a way of dealing with those meals too…it’s actually a pizza icon. Literally. You tell it the total grams of carbs for that meal (remember to add “equivalent carbs” to your total meal carb count if there are fats and proteins) and tap a pizza icon…that is equivalent to telling Loop that you are extending a bolus.

Let’s look at an example, Anna has a bowl of pasta for dinner.

If Anna and Loop had bolused based on carb ratios alone, her bolus would have been 6.25 units. Her carb ratio is 8, meal is 50 grams.  50g/8 = 6.25 units.

But, Loop only recommended 4.85 units up-front. Why? Because I told it this was the kind of meal that was a tortoise. It was going to be sneaking slow at first and stick around for a long time. Loop gave an appropriate amount up-front and then waited like a stealth ninja to deliver the rest when the danger of low BGs had passed.

How did that meal go then? Let’s show that in pictures

And how did that meal do hours later while I slept? Pretty freaking fabulous. As that slow tortoise tried to get to the finish line, Loop kept pushing back. Hours later, Loop had won the war and the tortoise had run out of steam (pasta had finished digesting).

Similarities with Juicebox and Sugar Surfing

All of this reading and do you see it now? Where Loop and the other methods are similar with regards to “nailing” a meal?

They all still involve a bit of learning when encountering a new food. And that is a-ok. Getting friendly with a new meal? Here’s the differences in behavior between the two:

  • With Loop: You adjust how you enter carbs to fine tune Loop’s insulin deliveries.
  • With Juicebox or Sugar Surfing: You adjust insulin in reaction to observed BGs. Carb entries are relatively unimportant.

So…in practice these are actually kind of similar, just different where you are adjusting. If you have a meal, you can learn from it in both systems. If you have a meal in Loop and end up stuck on a high later…add some carbs to the meal entry next time (or even edit the carbs mid-meal to help Loop know that perhaps you didn’t quite guesstimate carbs right) and use a longer food icon (move from taco to pizza). How many carbs to add? If your settings homework was done, the Insulin Counteraction Effects screen in Loop can help you TREMENDOUSLY to dial in those meal entries. Loop will help you see just where your carbs impacted you and help you for the next time to estimate total carbs to enter and how long.

If you really want to fine tune, you can do mixed meal carb entries…give a portion of the total carbs to the tortoise and a portion of the total carbs to the rabbit. My teen doesn’t usually go through that much effort, but that’s ok for us. Could we get slightly better results if we were super diligent about telling Loop the exact mix of a meal? Yes…but we’ve decided the effort’s not worth it overall after 2.5 years of Looping…but I’m glad the option is easy to access for those who would want to.

Read the Docs

Don’t forget to read Looptips.org. There are loads of helpful tips about how to deal with situations in Looping. How to do these settings tests. And for Juiceboxers and Surfers especially, work on converting those old bolus techniques into settings and carb techniques. Identify the results-oriented tools you’ve been using (insulin dosing) and back those into settings understandings.

And then recognize that you’ve been doing the work of a closed-loop system for awhile now. Kudos to you. If you can take the time to dial in the settings as described above, you will have successfully developed the tools to let Loop know the needed info so that Loop can take that closed-loop job for you. It can babysit the reactions to BGs now.