This blog post is about my new found appreciation for cortisol:

“Cortisol is a steroid hormone also secreted from the adrenal gland. It makes fat and muscle cells resistant to the action of insulin, and enhances the production of glucose by the liver. Under normal circumstances, cortisol counterbalances the action of insulin. Under stress or if a synthetic cortisol is given as a medication (such as with prednisone therapy or cortisone injection), cortisol levels become elevated and you become insulin resistant.”

One of the large frustrations we were facing during this school year has been a wicked spike during school mornings…but not every morning. But, many mornings I’d be seeing her spike to 200+ without food and invariably starting around 9:30-9:40am. The spikes were so fast and aggressive that they have outpaced any looping algo despite the settings we’d have. How many diabetes frustrations start with “I spike when _____, but not every time. I wish I knew the pattern. If there is a pattern. Oh damn, hand me a diet coke, my head hurts. This sucks.” We were there.

I knew it wasn’t food. Anna is a really diligent food boluser and was actively doing manual actions (on top of looping) to try to blunt the spikes in the mornings. It was just stumping us. LUCKILY for me, as I’ve been discussing algorithms with my friend Ken, I bemoaned that looping is not very effective against this school spike thing. He mentioned that this was looking like a cortisol issue and it suddenly lit a lot of lightbulbs in my head. Here’s what I was FINALLY able to put together:

(Note: I am [un]lucky to have a kid that doesn’t really eat breakfast on school mornings…so the data was uncomplicated by food/boluses for most days.) Mondays are way worse than Fridays..and these Monday graphs include extra insulin from looping and manual corrections. Weekends were zero issue. Here’s the data…

What was happening for months now? Weekends were great. I’d send her to school on Monday. We’d see a huge spike starting at 9:30am (school starts at 8am), but get there too late to prevent going above 200. (and even while Looping…we never avoided the spikes above 200) Loop wasn’t enough and why would we be late? Well, dosing 3 units of insulin proactively at 90 mg/dL is a bit daunting without food involved. Especially if you aren’t seeing it every day. Some days that spike wouldn’t materialize. So we wouldn’t really correct with “extra” until she got to 180 mg/dL and climbing still aggressively. By the time we’d corrected for the spike, we’d have a problem usually fighting a low between 2-4pm.

So, after seeing that big spike on a day, I’d increase basals and adjust ISF and try to account for what we’d seen the day before. The day after a spike would be a little better. Then the next day might have not so much of a spike. Then suddenly I’d be pulling back on the morning basal adjustments because the spike seemed gone, and still overshooting the adjustments and having lows 2-4pm.

Here’s the problem though…my brain never realized this was happening on a Monday-Friday pattern. I just wasn’t realizing it until Ken mentioned cortisol and sleep patterns. So until I realized that, it just seemed like we were chasing a semi-random spike and I was very hesitant to give large corrective actions without knowing exactly what was going to cause them.

Addressing this spike meant near constant basal/profile adjustments and this was destroying our relationship. “Anna, can I see your phone again?” or “Anna can you change your 8am basal to 9am and make it 2.7 instead of 2.5?”…either one of those texts is NOT how I wanted to spend my time. I didn’t want to hound her to pay attention to the spike either. I was utterly SUPER frustrated with Loop’s interface to make these adjustments (hourly changes to basals and ISF on back-to-back days are NOT Loop’s strong point in terms of quick actions). I desperately wanted an easier way to make these changes faster with multiple profiles…because I definitely knew that weekends vs weekdays were one of the underlying needs to address.

Frustrations were at an all time high until cortisol understanding came along.

So, armed with the new info…I watched for patterns. I realized Anna’s spike is like clock work…I just hadn’t been recognizing the clock! DOH! Worse on Monday…decreasing day-to-day until Friday when it is minimal. Non-existent on weekends when she sleeps in about 3 hours later than a school day.

Reading the cortisol/sleep cycle literature and research…Anna’s experiencing insulin resistance tied to her morning spike of cortisol upon waking up. I hadn’t realized that a 2 hour delay from getting up out of bed was still possibly a cortisol issue. I’d always thought of it only tied to feet hitting the ground getting out of bed…but turns out there’s quite a bit of research showing that cortisol-related blood glucose spikes can be at play 2 hours after wake up. The phenomenon is worse on Mondays since (1) her sleep pattern is most disturbed suddenly that day (3 hours shift from the previous day) and (2) highest stress as it is the first day back at school. By Friday, she has acclimated to the wake up time and stressors of school…and the cortisol impact is less pronounced.

Armed with this knowledge, Anna has a better chance of avoiding lows/highs in this scenario.

Option 1: She could choose to wake up early on weekends and therefore avoid the extra cortisol response from the inconsistent sleep schedule…but she’s opted to not use that option lol.

Option 2: She can now more confidently choose to keep a moderate school vs. weekend profile and just manually correct on Monday and Tuesday at 9:40am-ish when she sees a spike building. We know Mondays are an early 3 unit correction, Tuesdays are an early 2 unit correction and Wednesdays are 1 unit correction, with Thursdays/Fridays can be handled pretty well by a looping option with a school profile with increasing time-in-range as those days go.

Option 3: She can choose to accept that Mondays and Tuesdays will be spikes over 200 for an hour or more if she doesn’t want to manually correct…that’s her choice too.

No matter which option she chooses, at least now we have a much safer operation for the 2-4pm timeframes now that we know what’s happening earlier. That’s the most important part. And we have been having increasing success with Mondays and Tuesdays spikes too…which is also nice.

Cortisol. What a beast.

If you want interesting reading on cortisol to start down your rabbit hole of research:

Cortisol and the menstrual cycle

Cortisol on weekdays vs weekends

If you want to really amp up the reading, add some reading about the effect on cortisol from disruption of natural sleep cycles/circadian rhythms. There’s a lot to unpack in the research, but I sure learned a lot and it’s made a tangible difference for us now.


Why Control-IQ?

The overwhelming response when I posted our first 6 days results on Control-IQ was “Why are you trying Control-IQ?” and “Does this mean you are giving up Loop?”

The second question is an easy answer: We have always been a family willing to try new things to see what works best for Anna. We haven’t always used Loop…we tried OpenAPS before as well for 6 months. Anna has used pods and Medtronic pumps. From pumps to CGMs to algorithms…we believe that trying new things is usually worth while. We don’t try everything (*cough* *cough* that 670G never tempted us…we like Dexcom’s CGM much better than Medtronic’s), but we do try to keep an open mind if something has a potential to lessen Anna’s diabetes burden. So are we giving up Loop? Not necessarily. If Control-IQ and the t:slim x2 pump don’t prove to be a better experience in Anna’s evaluation, she can easily go back to Loop use.  We usually give things a full month before concluding anything about BG control of any system…but if the overall experience doesn’t work on an everyday-living basis before then, we would quit before a month.

The first question though is a little longer of a response and there are several layers to that onion 😉 Probably to start with, I need to go into a little bit of history.

CGM data provided lessons

When we first got a Dexcom, we were only one month into diabetes. The benefits were instant. Fewer finger sticks. Alarms to help me know when to check on her. Probably most significant to me was that it shortened our diabetes learning curve tremendously. We were able to see connections between our food choices and boluses like we would never have been able to see on finger sticks alone. I quickly learned how to make settings adjustments based on blood glucose trends.

The lessons from having CGM data access saved us years of effort in learning diabetes management.

Loop data saved relationship

About a year after getting a CGM, we started Loop. And you know what that added to our data stream? EVERYTHING. We now had automatic uploading of every carb entry and bolus. Every temp basal. We could log site changes more easily, I could see her cell phone’s battery level, and I could see the remaining units in her pump reservoir.  It was every little bit of diabetes information.

At the time we started Looping, Anna was starting her freshman year of high school and was 14 years old. Before Loop, I would often text her during the day with instructions about how to treat BGs that were trending up or down. I would ask questions about “I see a rise, did you just eat? Did you prebolus? Or maybe your site is bad? We just changed it this morning.” When she was at school, I wasn’t sure whether or not she was doing things the same way as she was at home (which she was doing very well). I just felt such a burden to try to keep her BGs in range and not burden her with needing to make all those decisions. As a result, I interrupted her school day a lot, asking a lot of questions first so that I could make the best decision for the situation once I understood it.

When Loop brought us carbs, boluses, and temp basals…I didn’t need to ask all those questions anymore. Glorious!!! It literally healed a lot of relationship issues between us because I didn’t interrupt as much. Hands down that was my favorite part of Looping for a very long time. I could see that my kid was doing things fine, and it was a positive feedback loop that gave me comfort.

Loop allowed me to see my kid grow into her diabetes management like a true diabadass.

Therapist Jenny

Around our second year of Loop use, Anna and I started seeing a therapist, Jenny, together. I just really wanted to make sure our relationship could survive the “teen years” and especially wanted help through the challenges of diabetes responsibilities. How long should I continue to make adjustments for her? Does Anna want to take the duties over? Was she capable of it? What level of “give” should I expect as she took over her own management?

We started the discussions, but admittedly we didn’t get far on some of the homework. But, the two most important take-aways from therapy for me were:

  1. Anna does not view my stepping back from such an interactive diabetes management as a “burden” thrust on her. Instead, she welcomed the shift. She WANTED to be more in charge and have me involved less. It wouldn’t be a burden, it would be a blessing. Those conversations were invaluable. I recommend every parent of a teen with t1d start those conversations. Find out if your kid will want to be sharing their health data, and if so…how/what data they are comfortable with sharing. I have a kid that doesn’t want to share unless she’s asking for help. And that is a decision I intend to respect. Closed looping certainly makes that an easier option because the health impacts don’t necessarily have to suffer as they take on more responsibilities. 🙂
  2. Setting up that transition is challenging. Teen brain is real. Parental overstep is real. Sitting on your hands and watching things NOT happen is hard when you are finally ready for her to start doing things. “Why isn’t she doing _______? Look at that data…she doesn’t see this?” was a frequent thought during these efforts to shift responsibilities to her.

So therapy helped us start down the path, but it would take a couple more lessons before I finally identified that the data that previously healed us, was instead now getting in our way.

Anna is growing up

I was having a hard time defining short- and medium-term changes we could implement for this transition of care. As a result, I just kind of ignored it for the most part. I tried simple things like making her take over the overnight low treatments when needed, as opposed to ME having the alarms in my room…we moved the LOUD alarms to her room to wake her up (she sleeps like the dead).

It was easier to see my long-term goal for how I fit in based on Anna’s discussions in therapy…I want to only be there as a fail-safe for low blood sugar alarms. Said another way, I want her to have healthy boundaries of privacy around how she chooses to manage her diabetes. But, I was not close to that long term goal. I see too much of the details of her diabetes management with all the data that Loop provides. I’m like a data addict. If it’s served up, I look. And if I look, it’s really, really hard not to judge or second-guess her actions. And by and large her actions are just fine…and I just need to chill. Really, I’ve had years of seeing her work and it’s really good. But the data just sucks me in to look at it regardless.

Two things happened to really help me change the long-term vision into more actionable medium and short term actions. The first change came as a result of living with adults with type 1. The second big change came from talking to two close parent-friends who had recently sent their t1D kiddos off to college (they are sophomores now).

What adults with t1D taught me: As part of my Tidepool work last year, I lived for a week with about 17 adults with type 1. I watched them so quickly estimate their carbs, give their boluses and then resume our conversations in the blink of an eye. I also realized that they had ZERO parents watching that entry. No mom on the other side looking that her son had just entered 65g and 8.5 units. And the adults had no desire for their parents to be seeing that kind of detail. They’d all grown up without CGMs and Loops, so it was never an option for their parents to be that involved. Yet for me, it was MY normal because of how quickly we’d started CGM and Looping. It’s this current generation’s normal now with Nightscout access and Loop data.

I asked them if any of them shared carb and bolus info with their parents or a significant other. They all said no, it was private. They did say that they had a couple trusted people that were trusted with access to CGM data. They shared that data with ground rules, like “don’t call me unless you see I’m under 55 for more than 15 minutes”.

Like a light-bulb, I realized just how good that will feel from a mental health perspective FOR MYSELF. To not know every time Anna eats and boluses. To just let a meal entry be a private thing she was doing for herself. Even if she is already doing that work herself now…there’s something about always SEEING those carbs and boluses that sucks me into a place that I ultimately am not comfortable having access to when she’s an adult. That should be part of her private personal “life habits” that she gets total control over. I won’t know that food minutia about my non-T1D daughter…so why would I have that info for Anna? If Anna wanted me to be a part of that data as an adult, we could do that…but we’ve already talked in therapy about how much she wants me pretty much as only a low-BG backup alarm.

Long-term, I know that I want to give adult Anna the same kind of privacy and non-judgmental space that I will provide to my other daughter (that does not have t1D). If I have access to her carbs and boluses info, I won’t be building that privacy. It will open the door to spaces that it should be private and only opened by her IF she wants to. So, I recognize that at some point…I will need to make sure I cut off that flow of information and only see blood sugars.

What the college kids’ parents taught me: Luckily, I have two great friends who have recently sent their kiddos off to college with t1D. They’ve been brutally honest about how difficult is has been. These are smart, good kids. These are smart, good parents.  And yet, it’s just a tremendously hard adjustment.

One of the common themes between their two sets of advices has been to (1) prepare earlier than you expect for this transition, and (2) expect a decrease in time in range/increase in A1C. The advice is good. In fact, if you look at any clinical trials the late teens to early/mid-20s is statistically the time of life where the time in range is the lowest of any age range. The total insulin use per day is raging for that group compared to other ages. Hormones are starting to make things really difficult. College and social commitments make life more variable and diabetes is harder to balance.

The good news is that the statistics improve after this age. They recover. Their lives settle in. Their biology settles down. It all gets better. So that made me think that really my goals for the college years needed to flex a bit if our relationship were to come out unscathed. Above all, I want to make sure that we find a way to continue to have a great relationship through this incredibly difficult time coming up.

ACTIon items for change

So that brings me to why we are trying Control-IQ. The reasons are pretty straight-forward. I’ve covered a lot of the background about this move being part of the intentional transition of care. The t:slim x2 pump offers some things that Loop doesn’t do well for Anna.

  1. Multiple saved profiles. Loop lacks the ability to save multiple profiles and this has been a very difficult reprogramming of settings every Friday and Sunday nights to prepare for the differences between school and weekend needs. As well, we were having difficulties dealing with the insulin resistance that happens as the result of hormone cycles every month. Put simply, it was just too time consuming of a process for either of us to do so much. We both grew quite frustrated with that. The t:slim x2 lets us save 6 profiles and she can (and DOES) switch between them with just a couple buttons clicks. A huge problem has been alleviated by switching to t:slim x2.
  2. Simplicity of gear. Anna doesn’t have to carry a RileyLink anymore. She also doesn’t need to have a phone with her to get automated basal changes. While she didn’t have much of an issue with those things with Loop, I know that there were many times it was an issue…seemingly always happened at a time when you’d really want to be looping. Like she’d walk across campus to hang posters and be trending low…but she left her RileyLink behind in class because “it was only going to be for an hour”. Or at the beach, she would leave range of her phone/RL to go play smash ball…then no looping could go on. Plainly said, by not NEEDING extra gear, we’ve eliminated another potential failure point.
  3. Eliminating Red Loops. We have been lucky and not badly afflicted with red loops…but I’m not naive. I know they can happen suddenly and could require quite a bit of attention to resolve if not readily fixed with a reboot of phone/RileyLink. So eliminating this potential stress for Anna is probably a good idea as she moves out. I could easily see her choosing to ignore a red loop for a long time when she is on her own, and especially at night. Dorms are notorious for having a lot of wireless interference and overnights in dorms aren’t necessarily a “loop friendly” experience for some.
  4. Eliminating my need to follow Loop developments. The other nice thing about this is that I no longer would have to stay super current on bugs or issues in Loop. I don’t have to watch for bugs in displays or behaviors. There’s been a recent increase in bugs that I find particularly kind of confusing for kids since they are display related and kind of hard to identify if you aren’t spending a lot of time deeply understanding Loop.
  5. Eliminate worries about building Loop. Let’s face it…when Anna is in college, she will not be building her own Loop. She won’t be stopping to deal with Loop rebuilds if it needs to be done at an inconvenient time. Using the Tandem system eliminates the worry for both of us about iPhone/RileyLink failures or replacements. It also eliminates the worries that comes with every iOS update about whether it will cause an issue for Loop.
  6. Infusion site changes have built-in reminders. Oh lordy, site change reminders have been hard. I desperately want to not nag about them, so we set up really cool little IFTTT actions while Looping, so that if she pushes a button in an app, she would get a text 72 hours later to remind her that it was time to change the site again. But, if she doesn’t press that button…nothing reminds her to change a site except high blood sugars or site irritation. The t:slim x2 has a reminder built-in for every three days after each site change. It’s been working gloriously. Like night and day difference. This was one of the “parental nags” that I was really looking to eliminate prior to college. We needed a system that she could use to reliably keep track of site changes without a personal nag from me.
  7. Lack of data. This was one of the hardest things to put on the positives of trying Control-IQ, but one that I knew I needed. For Anna’s age and soon to be “grown and flown” to college, the data flow needs to pair down to just CGM data now as discussed above. I don’t want to be looking at her food. Quite simply, it is just not necessary and only tempts me to question what doesn’t need questioning. Ironically, this is the opposite of how I felt when she was 12-15 years old. That data then was very valuable for me to learn about diabetes and become comfortable with how she was managing herself. Now the utility of the data is gone. It is not serving to make her diabetes any easier, and is only a potential stress point in our relationship. I just need to be there as back-up for low blood sugar issues for safety. Of course, I expect Tandem will eventually have live data uploading to the cloud and it will be available again…but hopefully by then my cold-turkey efforts will have weaned me off of looking at it anymore.
  8. Bolus from phone still. While it’s not here yet (planned later this year), Tandem does have plans for releasing an app that will allow Anna to bolus from her iPhone (similar to how Loop works). I’m glad she will have that option, but she didn’t cite that in her reasons for liking Loop previously so I can’t really say that is a big influence one way or another for us. For other people, it may be a big deal.
  9. Algorithm differences. This one is going to be expanded on later, I’m sure. But for now I’ll summarize one part of Loop’s algorithm that I am most frustrated by…stuck on highs. Anna knew how to edit her carbs while she was stuck on a high BG or to add carbs…but this still seems a bit cumbersome for a kid. She find it easier to just give a small correction. With Loop, a small correction in those “stuck on high” situations will often result in Loop suspending basals and basically reversing the correction you applied. Control-IQ does not automatically drop you to low basals. Instead, since Control-IQ is looking at a 30-minute prediction (as opposed to a 6-hour prediction) for actions, you tend to get more “trust” from the system that your actions are reasonable for a time. Now I’ll undo a little bit of that and say that overall, we are experiencing far fewer times of being stuck on high.
  10. In-warranty pump. This hasn’t been a huge deal for me…but I do feel slightly better having an in-warranty pump that can be swapped out easily if it breaks. I feel better sending her to camp with a system that I’m sure the medical staff understands well. Again, not my biggest concern, but still was a factor in the decision as Anna goes to college.
  11. Rechargeable pump battery. I can just imagine college years that she will not have a AAA battery near her when she needs one at some point. The rechargeable battery on the t:slim x2 means that we have eliminated a likely failure point. She will be far more likely to be near or carrying a mini-usb charging cord than near a spare AAA battery these days in an emergency. I’m sure adults do a great job at placing AAA batteries around for themselves as needed…but college kids that could prove quite challenging.

So, in summary, that’s why we are trying Control-IQ. I believe it will help us transition into the next phase of her life better than we could do with Loop. I think there’s a bunch of us parents that are “growing up” with lots of data flowing from our kids constantly. I worry about how much that data is affecting their eventual privacy rights. I worry about how much that data is unknowingly able to negatively impact my relationship with Anna as she grows more independent and moves out of the house. She is at the age where her desired level of “control” is going to be driving the boat. Control-IQ allows her more autonomy and me to take a graceful step backwards. I won’t feel the need to make sure her or I are Loop current. We eliminate more diabetes conversations this way. She’s already shown me that those conversations aren’t needed nearly as often as I initiate them. If we can achieve a smaller diabetes footprint in our lives at very little/no detriment to time-in-range…why not give it a try?

So far…the results are super promising. Anna has reported the following negatives after a couple weeks on Control-IQ:

  1. The screen doesn’t auto-dim when you are in a dark room. It’s bright and kind of obvious in a movie theater or dark classroom.
  2. The pump clip sucks.
  3. The cartridge fill process is more clumsy than filling a Medtronic reservoir.

But, for the positives…she has NOTICED that we are talking less about diabetes. And that means the world. She is doing profile switching herself. She is doing all of it with less talking between us. That’s exactly what I was aiming for. Added benefit, she’s achieving better BG metrics than with Loop…but that wasn’t our aim to start with.

I challenge you all to start communicating and make sure that you are planning long term for your own kid’s transition. Find out if you are on the same page as them about data sharing. Start thinking about what you both need to do to get there. You hopefully have some time…but it goes by quicker than you’d imagine. I have spent a year trying to wrap my brain around this transition, identifying data addiction was part of the problem, and find a way to unhook myself from data addiction. I’m fine with just BGs…but I needed to rip the bandaid off and make it happen. Control-IQ is letting me do that plus addressing some things that Loop wasn’t doing well for us (especially that multiple profiles problem).

At one month or so…I’ll do a post showing the BG results comparison. We need to go through a full month before the comparison is very useful, but so far the results are showing that we aren’t doing any worse on Control-IQ. Standard deviation is down, average is only a tiny bit higher, % lows is cut in half, and time in range is improved. And, I’m learning a bit more about the algorithm to know which knobs do what.  Will we switch full-time to Control-IQ? I don’t know…that’s up to Anna. I’ll support whichever she wants to do. If she wants to go back to Loop, I know I will disable Nightscout as my primary viewing/alarm platform and instead use Sugarmate app so that I’m limited to just BGs. As of now, I’m thinking she may want to stay on Control-IQ, but she needs to use it longer to know. This weekend she is going on an school-related overnight wilderness camping trip with Control-IQ and I think that will help her decide, too.

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.