Personal News

I also have some personal news to share. Unfortunately, it isn’t the happy kind.

About two months ago, I noticed my left leg was acting “weird”. It just felt different, had a few more stubbed toes than normal and felt kind of unsteady. I honestly thought I was going to be diagnosed with multiple sclerosis…given my family history of autoimmune diseases, this felt logical with my symptoms.

July 4th the symptoms became too obvious to write-off as side effects of exercise, heat or dehydration. I went to the emergency room and they found a 3cm brain mass.

Long story a little shorter, I went in for an awake craniotomy on July 12th to remove as much of the mass as they could. The day after surgery,  we were told the mass is actually an aggressive brain cancer called Stage 4 Glioblastoma.


I’m currently undergoing radiation and chemotherapy to treat the tumor. But, as I’m sure most people do…you’ll probably google “glioblastoma prognosis” and see the same miserable gut-punch that I’m now living with.  Median survival rate is around 12-16 months.

So, yeah…it’s the worst kind of news. I have a husband and two daughters (ages 17 and almost 19). I had a lot of great plans for my retirement…but since I’m currently 48 years old…that looks a little unlikely now that I’ll be able to live out those plans. Instead, I’m focused on making sure I enjoy my family for whatever remaining time that I’m given.

I’ve shaved my head, still have 6 months of chemo treatment ahead, and will also be wearing a ridiculous looking contraption soon called an Optune device. Basically, living 24-7 with an array of transducers covering my head and attached to a power supply in order to disrupt the mitosis phase of cancer cell reproduction. (Good thing I like science?)

Anyways, if you want to read more, I’ve left my facebook posts about this journey set to “public” audience so that everyone can read or send good thoughts and prayers. You can find me here or search for my name (and bald head profile picture) Katie Disimone.

There’s also a GoFundMe campaign setup by my dear friends to help me figure out how to meet the financial constraints of this diagnosis. I will likely need to medically retire soon, and I am the primary breadwinner for my family. We are working on figuring out how this all will work out…but there’s a lot of unknowns with how I’ll respond to treatments and how the tumor might recur even if initial treatment respond is good.  Glioblastoma is a ^%@$ of a battle, and I intend to fight hard.

Dexcom G6 restarts and resets

Since the last time I’ve written, there’s been some new info worth sharing on the G6 front.

Sensor restarts

The G6 sensor restarts can’t be done with the same old tricks like disconnecting bluetooth, using a microwave or faraday bag, etc.  The Dexcom app has gotten smarter than that now, so we basically only have one option for restarting those 10-day sessions on your G6 sensor.

In order to restart a session on an existing G6 sensor you’ve already used for a session…

  1. Stop the session. You can do this either by letting it expire naturally, stopping the session on the app, or stopping the session on the receiver.
  2. Remove the transmitter from the sensor. There’s some easy ways to do this, but the one I recommend the most is to use a couple test strips. The are skinny enough to fit between the edge of the transmitter and sensor edge. They are stiff enough to get the sensor to “pop” the little latch loose from the transmitter. And, most of us have a couple test strips hanging around. If you want…I suggest watching this good little video on how-to remove G6 transmitter using test strips.
  3. Set a timer for 20 minutes once you’ve removed the transmitter.
  4. After the 20 minute wait, replace the transmitter into the sensor.
  5. Go through the usual steps to start a new session. You’ll have to wait the normal 2 hour warmup, but after that…good to go.

Resetting Transmitters

Unfortunately, awhile back, the Dexcom app was updated with a “kill switch” that detects reset transmitters. (What’s a reset transmitter? Transmitters that have gone passed their 110 days since activation, or have had their battery replaced, need to be “reset” to a new start date.) The kill switch in the app checks for reset (exact way it’s checking is unclear to me so far) about 40 minutes into a warm-up. The kill switch will kill the transmitter and tell you that you need a new transmitter. So the old ways of resetting your G5 and original G6 transmitters, using the Reset Transmitter app, are no longer working.

Here’s the interesting parts of this new development.

  1. I’m not certain if this kill switch is embedded in Dexcom apps outside the USA.
  2. There’s a way around this kill switch for USA users. If you disconnect the transmitter from your iPhone’s bluetooth, you can use the receiver to start your sensor sessions with the reset transmitter. You will have to use the receiver ALONE for EVERY new session start…from the start of the session through the whole 2 hour warmup. Only after the warmup is finished can you open your Dexcom app and reconnect the transmitter on your phone’s bluetooth.

Exciting new developments

So, while things have looked a little sad for the last year for the current “firefly” G6 transmitters…(firefly transmitters can’t be reset and the batteries are very hard to replace)…I have some exciting news to report that FIXES those previous statements.

A group of dedicated people down-under (Australia) have a project that involves both replacing the battery AND addressing the reset issue. Their project is called Anubis.  You can read more about it here. The transmitters will be able to have their batteries replaced, extended time beyond the 110 days, and easier restarts without needing to remove the transmitter for 20 minutes.

Call for Donations

The Anubis project post that I linked above has information about where you can donate your used firefly transmitters to help the group get production ramped up. People who donate will have earlier access to the Anubis transmitters. I highly encourage everyone to NOT throw away your transmitters…even if you don’t intend on using Anubis. The donation you make could help someone struggling to self-pay for their supplies.


One month Control-IQ results

Anna has finished one month (36 days technically) on Control-IQ.

She has pretty much operated on sleep mode 24-7 because we have a good idea of her settings from years of Loop experience and observation/testing of settings, therefore didn’t believe the tighter range would yield an increase in potential for low BG issues. If we hadn’t had a good grasp on settings going into Control-IQ, I would’ve opted for the normal target range (112.5-160 mg/dL).

Nothing in life had changed that much between the month on Loop vs the month on Control-IQ…same school schedule, same weekends. Health was the same between the two months.

As you can see, the results are pretty similar between the two. The average BG on both systems was just about 112 mg/dL…but Anna’s correction targets while using Loop were 95-100 mg/dL. So even though we used lower targets in settings, we didn’t achieve any better BG average on Loop as a result.

My biggest take aways in terms of experience has been noticing the standard deviation drop (39 vs 33 mg/dL). If you aren’t familiar with standard deviation, it’s a measure of the variability in your data set. The larger your standard deviation, the more spread there is in your data.  So a lower standard deviation means more of your data is closer to the average…aka a smoother ride of BGs. We’ve had a decent increase in time in range as a result.

The second take away was the decrease in low percentages, in particular overnight lows. We have pretty much eliminated the pesky lows from situations where we accidentally had slightly too high of scheduled basals. I’m not advocating intentionally setting basals too high on Control-IQ, but rather remarking on Control-IQ’s ability to compensate more effectively than Loop did for us when this situation happens (that’s life with the human body after all, it happens). On both systems, the low percentage is artificially higher than we truly experience due to the first 4-6 hours of new sensor sessions. We get an awfully lot of false lows during brand new sensors…so every 10 days we usually add to our low percentage without really being low.

I hope this helps answer some questions for Loop users about how Control-IQ might measure up against Loop. In our experience, you can get pretty similar end results between the two.

Safety and risk analysis in a closed loop algorithm

As we started to begin our order of the Tandem Control-IQ system, the sales rep was touting “safety”. I thought to myself “yeah, yeah…safety. I don’t think my definition of safety is the same definition that a commercial pump company uses.”

My primary thought was biased by the 670G system.  A system designed to keep the person “safe” would instead leave many people significantly higher than their programmed target of 120 mg/dL for long periods of time.  A system that because of “safety” would require heaps of calibrations for the sensor, and getting kicked out of automode if the sensor got nervous. And that lovely “safety” of people setting dangerously aggressive (short) insulin durations of 2 hours and super strong carb ratios in order to trick the overly “safe” algorithm that left them higher than targets so consistently. Having such artificially aggressive settings in order to overcome a bad algorithm means you’re exposed to a pretty great risk if your loop stops working. So when I heard “safe” as a selling point, I was admittedly more apt to say “ummm, that might not be the strongest word to choose as a marketing choice.”

I totally agree that closed loops are more “safe” than just winging it on normal pump therapy. And the clinical data supports that statement…more time in range and fewer incidences of hypo/hyperglycemia in the clinical studies. But, the problem I had is that we already have been in a “safe(er)” zone using Loop (and OpenAPS) for years now. We have benefitted from closed loop technology’s “safety”. Did Tandem just mean “safer” because it was raising the BG targets compared to Loop, and therefore avoiding more “dangerous” lows? (That’s what I thought they might have meant…but the answer apparently isn’t that.)

But some things happened recently that got me pushed into researching if there was something more behind the rep’s use of the word “safe”. It seemed as though she was insistent on Control-IQ having something about “safety” beyond just simply trying to sell me on closed loop in general or BG targets alone, but rather Control-IQ algorithm in particular. I wasn’t quite grasping what she was meaning, and it wasn’t something she could explain in detail (not her fault…I have a pretty demanding threshold for the details of technology. It was a hard bar to meet for an average rep, so I’d need to do my own digging). Around this same time, I attended the 2020 ATTD conference on diabetes technologies as part of JDRF’s platform to discuss the Open Protocols Initiative. While there, I had the chance to have some really interesting, in-depth discussions about algorithm developments, pitfalls, and successes with researchers and clinicians who run trials for the devices/systems.

So I rolled up my sleeves and started researching. Here’s what I learned…and it was a lot.


I kind of worked backwards in my Control-IQ development research because I knew current info the most, but I’ll present this discussion in chronological order for clarity of information. The University of Virginia (UVA) and JDRF play a large role in the history of Control-IQ. So, let’s start there.

In December 2005, the FDA (along with NIH and JDRF) held an open public workshop titled “Obstacles and Opportunities on the Road to an Artificial Pancreas: Closing the Loop“. About 75-80 of the industry’s leading researchers, regulators, and clinicians were in attendance to discuss the critical path items needed to move closed loop technologies forward. FDA offered to review research proposals from JDRF to assist them in progressing closed loop technologies. Shortly after in 2006, JDRF announced the Artificial Pancreas Project and funded six centers to carry out closed loop research. Among the funding recipients was a group of interdisciplinary researchers from the UVA Schools of Medicine and Engineering and the University of Padova in Italy.

Things were really getting interesting by 2008. Modeling of insulin and blood glucose regulation in the human body was an area of a lot of active research. In 2008, the UVA-PADOVA partnership produced a Type 1 Diabetes Simulator to simulate insulin-glucose changes during a meal…in other words this simulator could “pretend” to be a person with T1D (actually, about 300 virtual T1D patient profiles were available in simulator).  This is loosely referred to as the “metabolic model”. The simulator was updated in 2013 based on newer data and modeling, which improved its accuracy. How complex is the metabolic modeling?  Check out this figure (source):

Modeling allowed researchers to test control algorithms on virtual patients (in silico) before ever moving to tests on real humans (in vivo).  The FDA accepted it as a substitute for animal trials, which advanced the work of the UVA team and the entire JDRF Artificial Pancreas Project.

As the pace of research progressed, things had miniaturized and improved. Algorithms and controls were now small enough to fit on an Android phone. In 2014, UVA had an in vivo nighttime-only closed loop interventional trial using its DiAs (Diabetes Assistant) system and the Unified Safety System (USS) Virginia algorithm…basically 42 participants spent 5 nights in a hotel using a closed loop system for overnight control only. After that trial’s success, they moved on with in-home trials for a longer period of time. The UVA algorithm was moving along well.

Meanwhile during this 2014/2015 timeframe, UVA licensed their algorithm to TypeZero Technologies. TypeZero Technologies began using “inControl” for their technology’s name, replacing the DiAs name…but very similar algorithm.

The International Diabetes Closed Loop (IDCL) Trial began in 2016 and was the pathway for Control-IQ’s eventual FDA approval. As outlined in the IDCL protocols, there would be three studies leading to the pivotal trial (in support of Control-IQ’s submittal to the FDA) using Tandem’s t:slim x2 pump, Dexcom G6 sensor, and the inControl algorithm:

The initial pilot study with Dexcom G6, Tandem t:slim x2 pump, and TypeZero’s inControl was completed in December 2017. This was a supervised 36 to 48-hour pilot study in 5 subjects conducted at the University of Virginia.

The Nightlight study was completed April 2019.

The last phase, a pivotal trial, started in June 2018, completed in April 2019, and had participants use the system at home for 6 months. By now the system was termed “Control-IQ” (see paragraph below for brief explanation of the name change from inControl). The results of this trial were submitted in August 2019 to the FDA for approval of the Control-IQ algorithm.

Around the same time as the pivotal trial began, Dexcom announced it had acquired TypeZero Technologies. This gave Dexcom closer access to the closed loop algorithm, which had already been a part of over 30 successful trials with more than 450 participants at that point, to go along with its G6 iCGM system which had been FDA-approved just months before. This acquisition also explains some of the name-changing between inControl and Control-IQ as the business relationships between all the parties were changing. From the pivotal trial’s protocol “The Tandem X2 insulin pump with Control-IQ Technology is a third-generation closed-loop control (CLC) system retaining the same control algorithm that was initially tested by UVA’s DiAs system and then implemented in the inControl system.” This gives us a pretty good idea that the algorithm wasn’t changing significantly even though the naming was evolving during this time.

The FDA approved the Control-IQ algorithm in December 2019, clearing the way for Tandem to start marketing and selling the Control-IQ system in early 2020. (Note: the pivotal trial originally did not include pediatric enrollments, but that trial is finishing up now for kiddos between 6-13 years old. Initial results presented at ATTD looked in-line with the adult trial results.)

So What’s Different?

Well, all that history didn’t get me any closer to understanding what would be “safer” other than Control-IQ had undergone clinical trials. Which since we’d run our own n=1 clinical trial with my daughter for the last 4 years…all of this research hadn’t much helped me understand the differences in algorithms that might explain a “safety” difference yet. Merely doing clinical trials, while great, wasn’t exactly enough of a sway for me.

And so now I started to read all the research papers that I could find about UVA’s (and other group’s) algorithms and models. I read about the underlying metabolic model. I read about algorithm development in general, and specific. I read about control systems. It’s been non-stop.

Ultimately, there has been a difference that I learned about…and it does actually make me feel “more safe” with Control-IQ than Loop/OpenAPS. But, to explain it I need to go backwards a bit again.

Loop’s Algorithm

Loop’s algorithm has 4 contributions; insulin effects, carb effects, retrospective correction, and blood glucose momentum. Those four effects are summed together to form the predicted BG curve. Loop then automates insulin delivery adjustments based on where that predicted curve is for the next 6 hours relative to your correction range and your suspend threshold.

An important piece to understand in Loop’s algorithm is this: The algorithm does not differentiate between a unit’s potential risk at a low/high blood sugar vs normal blood sugar. In other words, so long as you are above suspend threshold, there is no “risk” assessment of Loop’s actions that would change depending on where you are in the BG range. The two “safety” factors for low BGs below correction targets are:

  1. The suspend threshold being the full-brakes on insulin delivery, and
  2. A rising BG (predicted to stay above suspend threshold through DIA) will get scheduled basals while below the correction range; in other words, high temp basals will not enact until the BG crosses above the bottom of your correction range.

This means at times when you are below targets, but carrying negative IOB because you have your basals scheduled too high, you’ll get a pattern of suspends alternating with scheduled basals.  If you cross the correction range’s minimum value, then you may even get some strong high temp basals to try to “replace” the negative IOB that has lead to a high predicted BG now.  That negative IOB can be a pesky term in Loop if it accumulates significantly while you are in lower BG range. That’s one reason why settings are so important in Loop. Making basals artificially high in the hopes of making Loop more aggressive will backfire with a pattern of lows and lots of negative IOB to be covered later when the low is treated.

RiSK terms in Algorithms

BIG DISCLAIMER HERE: All the commercial closed loop systems are black-box…meaning we don’t really know for sure what all their controls systems are comprised of. I am only working from the published literature and available research. So, while the papers describe the research that lead to the systems…they do not necessarily represent the final versions that end up in a commercial system. 

Much of my recent research has revealed that most algorithms, including the work by UVA’s published papers, include a component of risk-based dosing in their strategies.

What do I mean by that? Well, let’s use an example where you have the time and inclination to be a helicopter parent. If your kid’s BG was 100 mg/dL but headed down…you may choose to conservatively set a smaller temp basal of about 80% to help head off that low that appears to be coming. If your kid was 60 mg/dL, you might be more aggressive in your treatment decisions. You might set a temp basal, but also treat with some small carbs. That situational awareness is because you’re evaluating risk…and you are recognizing the inherent risk from low blood sugar events grows as the lower the blood sugar gets. Similar for increasing blood sugars getting into a high BG range. You would probably choose more aggressive treatments as you see higher blood sugars because you are perceiving a greater risk in those BG ranges. We have all rage-bolused…our instinctive desire to mitigate the high bg risk? There’s a sweet spot in your life, probably near 100 mg/dL, where you feel little risk from maintaining that BG.

This risk concept has been written in many papers about closed loop and diabetes (such as here, here, here, and here.) The concept can be visualized as shown in these graphs:


(Interesting side note: Notice where the low point of the risk curve is in that first graph? That’s where Control-IQ likely gets its 112.5-120 mg/dL nighttime targets…you’re in the lowest risk area during a time when the biggest variables, like exercise and food, aren’t in play. The same figure can be found in UVA paper here.)

So what does this mean in terms of making an algorithm “safer”? Well, if your algorithm incorporates some “situational awareness” as part of its dosing strategy and risk mitigation, then you will more effectively have a way of mitigating that risk. While you’re between 70-90 mg/dL, you should perhaps make more conservative decisions that reflect your BGs are in an area of greater risk. Same for if you are between 200-300 mg/dL…you should have an algorithm recognizing the risk of remaining that high is undesirable and it might be time to be more aggressive.

Control-IQ’s algorithm, while I haven’t seen the inner guts of its details for sure…I have seen the research papers on UVA’s algorithm development and watched presentations at conference discussing risk mitigations. So, I feel pretty sure that Control-IQ has risk awareness incorporated into the algorithm. (Disclaimers still apply)

This risk mitigation makes sense to me in a very gut-feeling way. Let’s look at one example where I feel like risk awareness may/could play a role…when Anna has overnight basals that are scheduled too high. What happens in Loop with that situation? Loop will suspend when the BG prediction goes below her suspend threshold (we had that set at 75 mg/dL). So, she’d get a BG dropping for awhile, hit the suspend threshold and then often times tip-toe touch her low BG alarm of 65 mg/dL.  We would treat the low conservatively…but even that action would usually just bring her (prediction curve) up enough so that scheduled basals would turn back on. She would have a lot of negative IOB built up from all the previous suspended basals…her prediction would say she would be going high, but instead the scheduled basals being on would soon send her low again. We’d be stuck in that repeat cycle of off/on scheduled basals with small treatments.

It would be nice in those situations if Loop had some situational awareness that we were in the low BG area of the risk curve…that maybe this would be a time to not just treat all my settings as the “gold standard” of math to work from. Perhaps if there was something that made the algorithm instead say “hey, I see all that negative IOB and yeah yeah…but you’re still low now and have been. Let’s ease back into this until the issue has really passed.” In other words, not jump right back to scheduled basals. And really please don’t jump to aggressive high temps if we treated a little more…enough to cross over the correction range minimum.

Visually what does this situation look like? Here’s an example shown in the orange box below. That represents about 9 hours of overnight BGs for Anna. Her scheduled basals were clearly too high (exercise before bed? Hormones changed? I don’t remember the cause that particular night, but this happened about 2-3 times a month usually). She kept getting BGs pulled back down after we treated lows with minimal carbs. The negative IOB was the source of crushing high temps if we treated enough to bring BGs above the correction range minimum (early in the orange box). And if we just let things play out, as later in that orange box, then scheduled basals would resume and stay on…eventually she still went low again because the scheduled basals were just too much.

Now, let’s compare with how Control-IQ works with its logic in a very similar situation. Here’s a graph, below, from a night recently. Anna was using a transmitter that had very low battery and we had gotten signal loss during the times in the red boxes. You can see the system, in those situations, would revert to her scheduled basal and she would have a small low afterwards. Not too surprising. BUT, look at what happens when Control-IQ turns on in the blue box. Notice how it does not go to scheduled basals despite having negative IOB accumulated? Instead, Control-IQ uses a fraction of the scheduled basal rate. Control-IQ is likely adjusting its insulin delivery not just based on a correct-to-range adjustment alone…there’s likely also a component of situational awareness about the low BG range it is in. We aren’t getting full suspend (not predicted to go below 70 mg/dL in next 30 minutes) but also are not automatically dropped off at scheduled basals like we would be in Loop. We coast along at a lower-than-scheduled basal rate.

This night above was actually the impetus for me to start researching Control-IQ’s algorithm possibilities. We had gone nearly a whole month without having one of those nights where her basals were peskily too high waking us up with nagging repeat low alarms. Usually we’d have a night or two like that during hormone shifts each month on Loop. I’d deal with it by finally recognizing the pattern was sticking around (usually after two low treatments wouldn’t fix it), and I’d edit her basal schedule lower. When this happened to us on Control-IQ that night, it kind of stood out like a sore thumb since we hadn’t had it happen in nearly a month. I downloaded the pump data to try to figure out what the difference was for that night and that led me to do the digging that I’ve tried to summarize in this post. Now, this lower-than-scheduled-basals Control-IQ behavior is not necessarily entirely the result of the risk component of an algorithm…there may be other things at play, too. But I am quite happy with the results in the end, no matter whatever combination of effects lead to it.

So…UVA’s algorithm likely has this insulin adjustment modified by a risk component. Low and high BG risks would yield appropriately modified insulin adjustments to mitigate that risk. Interesting, right? You can read this paper and the associated equations presented for this idea:

I am by no means an expert on any of this. And certainly, nobody has shared the actual equations/algorithm in Control-IQ or UVA in particular. But, I have noticed that our low and high extremes seem to be better managed (restored more quickly to targets) on Control-IQ…I’m still trying to explore why and quantify it. It’s the same kid, in the same body, with the same habits…so I feel pretty confident that our experience is at least in some part simply the difference in algorithms. The risk component that I believe is in Control-IQ in some fashion seems like a reasonable cause.

In short…I think now I can finally say that I am more appreciative of the marketing word “safe” and what it probably means for Control-IQ. I can see that whatever they are doing has resulted in some improvement in BG results for us over Loop…which had us quite happy for years before. In particular, we really notice it avoiding lows for those accidentally too-high-of-scheduled-basals times at night. We are happy to see Control-IQ choose lower basals rather than off/on scheduled basals in those situations. That is a safety measure.


Control-IQ vs Loop FAQs

Just a summary post to address a lot of the questions that I’ve gotten about Control-IQ, and also specifically about how it differs from Loop. This is not a QUALITATIVE kind of post…meaning I’m trying my best to not make pros/cons judgements in this post. Certainly I have opinions about the pros/cons, but this is more just meant to be straight dry info.

Also: Just to be clear, I have no affiliation with Tandem. I have not been provided any compensation, either in money or gear. We were out-of-warranty on our old original pod system and knew that system was not what Anna could go back to using (her insulin needs are too high and she gets more cannula leaks on pods than she wants to deal with). We paid for the t:slim x2 system and supplies through my insurance (regular co-pays and deductibles). Hopefully the reason for our trying out the Control-IQ system was well-explained in my previous post, check that out if you are wondering why.

Target Range

Control-IQ has three different sets of  target ranges. The standard range is 112.5-160 mg/dL. There are two “activity” modes that will change the target range…sleep mode is 112.5-120 mg/dL and exercise mode 140-160 mg/dL. You can schedule sleep based on days of week so that the system automatically switches to the sleep targets at those times/days. Sleep targets can also be turned off/on manually at anytime by the user. Exercise targets cannot be scheduled, but instead must be manually turned off/on by the user specifically. The target ranges work as the triggers for when Control-IQ will maintain your profile basal* (up to 3.0 U/hr…see discussion below on system-initiated changes to settings) or when it will increase/decrease basals. For when exercise or normal modes are active, the predicted 180mg/dL within 30 minutes threshold also will trigger an automatic correction bolus. In normal and sleep modes, your basal insulin delivery will be suspended if predicted BG in 30 minutes is below 70 mg/dL. In exercise mode that basal suspend is raised to 80 mg/dL.




[Note: recent investor call with Tandem reportedly included the information that users would be able to specify targets in an update to Control-IQ. I have no specifics on that info. It’s possible it could be something like exercise mode could be 150-180 for some people…or that normal mode could be 112.5-140…or something entirely different. It’s too soon to know, but interesting for sure.]

Loop allows you to set your own target range between minimum of 60 mg/dL and maximum of 180 mg/dL. Loop will also let you save target ranges differently based on time of day.

Kinds of Insulin Adjustments

Control-IQ uses temporary basal adjustments. If you are in normal targets mode or exercise mode, you will also have access to an automatic bolus correction if you are predicted to go above 180 mg/dL within 30 minutes. An automatic bolus aims to give 60% of the insulin needed to achieve 110 mg/dL in normal mode, 140 mg/dL in exercise mode. Automatic bolus corrections are not available in sleep mode.  Automatic boluses are also only available if there hasn’t been a bolus within the previous 60 minutes…doesn’t matter if it was a food bolus or a correction bolus…any bolus within previous 60 minutes will prevent an automatic bolus.

Loop uses temporary basal adjustments. *If you build an experimental branch of Loop, you can try a version that uses automatic boluses instead of temporary basal adjustments, for correcting high blood sugars. If using automatic boluses, you will not get any increased basal rates for correcting high BGs…all corrections are in the form of boluses.

Prediction Timeframes for Adjustments

Control-IQ basal adjustments (and automatic boluses) are based on the BG value predicted in 30 minutes time. The user will not see the value of the 30-min predicted BG, but you can see whether the basal is being raised, lowered, stopped, or kept at the user’s profile. A few clicks on the pump screen will also show you the exact active basal rate if you wanted to know. (Note: I hear that Tandem will be soon be releasing a mobile app that will allow the user to see all that info on your mobile device without needing to pull pump out.)

Loop uses a 6-hour predicted BG curve to make insulin adjustment decisions. The full prediction curve is shown on Loop’s main screen. If any part of the 6-hour prediction goes below the user’s suspend threshold, Loop will suspend basals. And, Loop will not add additional insulin, even if you are above targets, if your BG is predicted to be in range within 6 hours. In fact, if you are above target and predicted to go below targets within 6 hours, Loop will start to decrease basals. That full 6-hour window is often difficult for new users to be “in agreement with” and probably is the most common FAQ in Looped group. You can read more about the details for when Loop increases/decreases basals here.

USER-initiated settings changes

The ability to let a closed loop system know about a change from “standard operating conditions” is an important design point. For example…taking a new medication, doing an exercise, or hormonal shift in insulin needs can all require a “heads up” to your closed loop that the usual settings for basal, carb ratio, or correction factor/ISF are not going to apply for awhile. By telling your closed loop about these changes, your loop should do a better job at predicting BG movements and therefore keeping you in range more successfully.

Control-IQ has the user enact/turn-off the sleep and exercise modes to change your default targets. This can help influence when (or better said “at what BG”) your temp basal adjustments will kick in. Sleep mode can be pre-programmed on a daily schedule so that it automatically turns off/on at certain hours on certain days of the week. Exercise mode is turned off/on by the user intentionally and cannot be pre-programmed. Both modes can be left “on” for as long as the user would like…24/7 is not prevented for either sleep or exercise modes. In the event of a conflict (like you stayed at the gym late one night…later than your sleep mode profile was due to turn on per a scheduled time that evening), exercise mode will remain on until you turn it off. You will have to manually turn on sleep mode after that since the window for the “automatic” start of sleep mode was missed.

With Control-IQ, you also have the ability to save six user profiles with different basals, carb ratios, and correction factors to help quickly change between different overall insulin needs. This can help with weekdays vs weekends, hormonal cycles, and illness/medications.

Loop has override presets that you can program to signal an overall needs change. HOWEVER, those overrides are simplified to a single overall adjustment…so basals, carb ratios and ISF/correction factor are all adjusted at the same time and in the same percentage adjustment.  You don’t have the ability to unlink those adjustments. For example, you can’t have a preset that only makes basal rates 20% higher…you will also be making carb ratio 20% stronger and correction factor/ISF 20% more aggressive. This may or may not work well for all situations…so care needs to be taken, as the more aggressive you stray from defaults you will be getting a lot of adjustment since all three settings are moving. The override presets can be active for any period of time, including indefinitely, and can be scheduled to start in advance. However, you cannot pre-schedule more than one override at a time. Additionally, activating any override manually BEFORE a pre-scheduled override was due to start will end up canceling the pre-scheduled override’s start. You can also use IFTTT integrations to have a preset enact based on alarm clock or location (e.g., arrive at school).

With Loop, you do not have the ability to save profiles for different regularly encountered patterns such as weekdays vs weekends, hormones, or illness. Instead you will either need to adjust your settings (basal, carb ratios, and ISF/correction factor) manually or try a preset to see if that will suffice. If you work swing/rotating shifts, you would need to manually change your settings to accommodate the change in work schedules.

SYSTEM-initiated changes from settings

Another consideration is whether your closed loop system is automatically changing or limiting any of YOUR specified settings without your ability to stop that adjustments. For example, is your closed loop deciding that your personal profile of 2.0 U/hr basal rate between 1:30pm-5:00pm isn’t “right” and instead decides to use 1.75 U/hr as the basis for calculating your predictions? That would be a pretty important thing to know about.  While the excitement of a closed loop being able to detect these settings changes automatically is understandable…it’s also a long way off from being done well in reality from what I’ve seen so far. The Medtronic 670G‘s automatic basal profile is super clunky in practice and too slow to react. The adjustments it has been making for many people have overly conservative and leaving many users suck on high blood sugars.  Additionally, I’ve heard rumors that the Horizon system does a bit of an “override” of your user-inputed basal profile and instead uses a distributed basal schedule calculated as a 50% allotment of your previous day’s total daily insulin deliveries. Not super keen on a system that assumes Anna uses 50% basal and bolus ratio since her data has consistently been around a 65-70% basal needs. We’d be left pretty high from a system that assumed a 50% split.

The problem with all commercial systems is that we don’t REALLY know all those automated decisions because they are internal and proprietary. At least with open-source closed loop systems, we have all the information about those operations. So, when evaluating commercial systems…it gets a little difficult to say FOR SURE what’s going on in guardrails or limits that we might not be seeing. I scoured the Control-IQ manual to learn what I could as well as any published articles on the system that I could find that may have helpful info.

The Control-IQ manual doesn’t have a nice easy section about any automatic overrides/limitations that it does for you, this is all conjecture and observational for the most part. I did see one little interesting nugget tucked in here on page 280 of the manual. It’s highlighted in blue.

That little statement led me wonder if maybe the system restricts “active profile” situations to 3.0 U/hr in general…beyond just times of CGM loss. So, I rooted around for a bit and sure enough…it does. Below is a screenshot of when her scheduled basal rate was 3.7 U/hr, and due to 30-min predicting BG not requiring a needed basal adjustment, the system should have been using a “active profile” basal rate. However…as you can see…Control-IQ dropped her off at a limited 3.0 U/hr basal rate instead of 3.7 U/hr. This is pretty curious limit and worth noting if you are someone who has basal rates greater than 3.0 U/hr and want to use Control-IQ. It means that when you are predicted to be in range for 30 minutes, you’ll be dropped off at a maximum of 3.0 U/hr, even if your schedule profile would’ve had you at a greater rate. Probably really good to keep in mind if you have to go on steroids or medicines that push your basal needs over 3.0 U/hr on the regular…you may want to temporarily consider turning off Control-IQ in some really high-needs situations, and run with regular pump mode. Regular pump operations allow for basal profiles up to 15 U/hr.

Another point I was interested in comparing with Loop was any maximum temp basal rate in Control-IQ. This is a user-specified setting in Loop, but there is nowhere to manually enter that setting in Control-IQ.

I’m quite certain there is a limit on the maximum temp basal rate that Control-IQ can access and I’m also sure that the limit is not necessarily the same day-to-day or hour-to-hour perhaps. For example, here’s February 12th’s data and the temp basals were limited to 5 U/hr. Pretty evident by the prolonged highest temp basal lasting more than 5 minutes around 1pm in that graph.

The next day on February 13th, the max temp basal rates are looking a bit higher, closer to 5.8 U/hr. Notice, the scheduled basals for the day were also changed so that may affect the maximum basal limit. There was a higher average and total basal scheduled for February 13th than for the previous day.

So, what influences the maximum basal that the system is allowed to use? Hard to know for certain right now…but I’d guess it is in part based on the scheduled profile basal and some multiplier on top of that. I’ve seen temp basal rates as high as 2.5x the scheduled basal. This is consistent with the not-using-Control-IQ limit of 250% for temp basals. But there are also times where the limit appears to be a more hard limit (like the 5.0 and 5.8 limits on the previous example), even if that is less than 2.5x the scheduled basal…and that hard limit could be a function of the average basal scheduled to be delivered for the entire day.

To start Control-IQ mode, you have to enter a weight and total daily dose of insulin. From what I’ve heard those values are only used to get you started with Control-IQ the first day and after that are not used significantly. BUT…again…I don’t have any solid information to substantiate exactly how those are used on the first day (or not used later). I suspect they play a part in how the maximum temp basal is set for sure…but beyond that I’d love to know.

Those are the biggest “hidden” things that I’ve noticed. Everything else thus far seems to be operating according the user-saved profile values. Meaning, adjusting a setting will result in an expected change in your insulin delivery as well. If you change a carb ratio, you’ll see different boluses recommended. If you change a scheduled basal rate (below 3 U/hr), that basal rate will be respected and used as a the basal to use when no adjustment is needed (because you are predicted to be within target range for next 30 minutes).

Loop doesn’t have any “hidden” constraints such as discussed above. And since the code is open source, any user with questions about the priority decisions or function of the algorithm could look up the code themselves.

What Stops Automated Adjustments?

Control-IQ allows you to manually exit automated adjustments by sliding a slider in the pump menu to turn Control-IQ off. If you do that, you will be reverted to scheduled profile basal immediately.

Control-IQ will stop automatically adjusting insulin deliveries if your CGM readings discontinue for 20 minutes or longer, for example with sensor error or signal loss. When that happens, you will be reverted to the active profile setting (limited to 3 u/hr, as discussed above). Control-IQ technology will automatically resume automated insulin dosing once the pump has CGM data again.

Robustness check? Control-IQ has been rock solidly on except one period of time…we did have one prolonged stretch where Anna’s app was receiving CGM data, but her pump was showing signal loss. Prolonged like a whole day because…well…teen brain? She just thought it was coincidentally off each time she looked as opposed to long-term off and ignored the alert on the pump that was pretty helpful. The signal loss was likely because we are using a very old transmitter that had sat on the shelf long after its scheduled “start before this date or Dexcom doesn’t promise it will work the full 90 days”. I suspect it has a fairly weak battery. Regardless, the fix was easy although not published in the Control-IQ manual, and likely not going to be told to me by the Tandem technical support reps either I would guess. I posted the short version of the instructions on twitter…so if you get the “you’ve lost CGM on the pump for more than 20 minutes” alarm…follow these steps in the pump’s CGM menu and CGM should reconnect within 5 min or less:

Loop allows you to manually exit automated adjustments by sliding to “Open Loop” mode from within Loop settings. If you do that, your existing temp basal will continue to run until it expires (up to 30 minutes in duration). Therefore, it is good practice to cancel any active temp basal (by suspend insulin and resume insulin commands back-to-back) before turning on Open Loop mode. There is also a consideration around bolusing while in Open Loop mode that is discussed in the bolusing section later.

Loop will exit automated adjustments if your CGM loses data for 20 minutes. Loop will also exit automated adjustments if your RileyLink fails to properly communicate with the pump to retrieve pump history or confirm commands. Loop will also exit automated adjustments if any of your settings are deleted or missing (either manually or as a result of an iOS glitch).

Robustness check? Loop’s dependence on RileyLink for pump communications is a critical element and probably the most likely source of losing automated insulin delivery. Interference from other wireless sources, a long standing bug in the RileyLink firmware (that seems more prevalent during major iOS updates, oddly), and simply range/transmission issues cause the majority of red loops stretches of Loop-not-looping. Although, there are also a lot of reports that have to do with Dexcom issues. Often times users have reported the Dexcom app is still getting current CGM readings, but Loop is failing to gather those readings until the person has restarted RileyLink, restarted phone or rebuilt Loop app. I spent a couple hours at ATTD troubleshooting someone’s Loop app that was failing often after months of working fine. No discernible cause was found; tried new batteries, new pump, new RileyLink. Ultimately, the only solution was the rebuild the app entirely. Loop’s problems “staying green” have come in waves for us personally. Major iOS updates were the most problematic times for us as they seem to affect Loop’s ability to stay connected both for Dexcom and RileyLink. Lately my iPhone has been randomly shutting itself off in the middle of the night (only happened to Anna’s phone once) over the last several months and that would concern me if I were looping for myself.


Control-IQ allows you to bolus for meals in a pretty traditional way. You enter the carbs, your CGM value can be automatically used for the BG entry for the meal, and a recommended bolus based on carb ratio is provided. You then can make two choices…(1) Do you want to increase/decrease the bolus amount based on Control-IQ’s determination that you need more/less to get to range? and (2) Do you want to extend any portion of the total bolus?

Control-IQ provides the exact information on the screen about what part of the bolus is the carb ratio alone vs. any +/- corrective insulin beyond that amount. You are limited to a maximum extended bolus time of 2 hours…no 4 hour extended boluses. If you have an extended bolus running when Control-IQ determines that you need basals suspended (predicted to go below 70 mg/dL in next 30 min), your extended bolus is not canceled and will continue (unlike how that worked in Basal-IQ).

Loop offers bolus recommendations quite differently than most all other systems. You use a “food type” (lollipop, taco, or pizza icons are the defaults) to indicate whether the carbs to be consumed will be quick, medium, or slow digestion. Loops algorithm will use that food type to predict quicker/harder vs slower/sustained impacts on blood sugar. As a result, bolus recommendations from Loop are never simply a function of carb ratio or insulin on board alone. They are always a function of the predicted blood glucose curve, your suspend threshold, food type, and how all that information plays together…such that Loop offers an initial bolus that will be predicted to keep you from going lower than suspend threshold in the next 3 hours, and target range between hours 3-6. Any additional bolus that might be needed beyond that initial amount is provided via high temp basals when the prediction curve allows for increased basals.

As a result of Loop’s unique bolus ways, if you are using Open Loop mode…you may have times where you need to more actively engage in providing bolus insulin later in a meal because the system won’t have the ability to automatically cover longer/slower carb impacts after an initial (smaller-than-carb-ratio) bolus. Loop will not automatically alarm when any additional bolus is useful in those situations.

Correcting for Stubborn Highs

I don’t know how to compare the two systems on this topic because they are just so different of an experience.

Control-IQ is using a prediction is only 30-min ahead for adjusting actions, you aren’t fighting a long 6-hour prediction. This means, if you think that you want to add insulin to correct a stubborn high BG, you won’t find yourself automatically zero-basaled as a counter-balance like you often do in Loop. Control-IQ holds off on lowering basals for a longer period of time. For Loop, most of the time you’d use fake carbs, edit old carbs, or set an override for a short time to deal with stubborn high BGs. If those didn’t work, maybe a settings adjustment was in order.

That said, we have had less instances of needing to manually intervene with Control-IQ so the lack of “tricks” isn’t missed. Why fewer interventions? I think part of that is probably due to the more direct carb-ratio-based bolus recommendations (so we are more often getting full boluses up front as opposed to covered later). Anna is less apt to spike with meals overall, but she is having to remember bolus splits again for slower carb meals like pizza. At least when we do intervene with a manual correction, it feels like a more straight-forward process…a small (critical adjective there) bolus correction and we stop. No overrides, no fake carbs, and no editing carbs.

Anna had one meal that was 44g on the nutrition label but was bolused as 6g (don’t ask, teen brain issue). I can safely tell you that just like our Loop experiences, Control-IQ did not “prevent a spike” such a mismatch. Still broke 200 mg/dL, but recovery was smooth and all was fine in the end. Insulin is still slower than we’d all like (hello Afrezza…someday!) and carb counting is still needed.

Anna also had full hormonal shifts on both systems now. On Control-IQ, we saw some stubborn highs (just like we saw on Loop during similar times) that helped tip us off to the need for a settings change. For Control-IQ, we dealt with it through switching to her “higher needs” profile. For Loop, we’d typically use an override preset until we had a chance to adjust her profile settings. Most often, Anna’s carb ratios don’t need adjusting due to hormones…just mostly basals changes with a little bit of ISF/correction factors.

Data Access

Control-IQ data in live format is (so far) only accessible from the pump screens itself. Tandem does have a mobile app in limited testing currently that allows users to see all their pump info on the mobile device. That app should be released this year, and a follow-up app update is expected shortly after that would allow for remote bolusing through the app…don’t need to access the pump to bolus then. Nightscout isn’t going to work with your Control-IQ pump right now, sorry.

For endo appointments or settings adjustments, you’ll want to use either Tidepool’s uploader tool or Tandem’s t:connect system. Both are free to use. Both require using a cable connected between the pump and the computer to upload the pump’s stored information. Uploads take about half a minute if you do them about once a week. If you want a longer period of time in-between uploads, it might get up to a couple minutes. One pooper to be aware of…t:connect won’t install on Mac computers that are using Catalina macOS (at least not as of the date of this blog posting). I’m dusted off an old PC computer with old Windows version for t:connect uploads.

If you’ve never seen t:connect data, it looks like these:

Loop data is remotely available in Tidepool and Nightscout live time…you just have to create the accounts and link them with a couple steps. Nothing hard and instructions are all online. For endo appointments, Tidepool and Nightscout are what you’ll need to show comprehensive data from looping.

Both Control-IQ and Loop still have Dexcom clarity reports just the same, as that is provided separately from any closed loop system…just need to have a Dexcom mobile app uploading data.

Batteries and Charging

Control-IQ seems to need a pump charge about every 4-5 days or so? It charges fairly fast and is easily little micro-B cable that you have around the house with many devices. Most people charge the pump while they are in the shower or driving in the car. You don’t have to take it out of the case to charge. Admittedly, I am a little removed from the hands-on experience with this since Anna does this work. From what I hear, charging about 15 minutes a day is enough to keep going if you don’t want to do a 1-2 hour full blown 0-100% charge on a less often basis.

Loop is running on your iPhone so there’s nothing really extra required there. Loop doesn’t seem to drain batteries any faster from what we experienced. RileyLink needs a charge nightly and charges in about an hour.

Wireless Headphones

Someone asked about wireless audio devices…we haven’t had problems on either system. I have heard of others having problems with Loop failing when people use their car audio bluetooth though…that seems to be the most common wireless failure point and is more related to the iOS resources than Loop itself. Loop is simply the victim of iOS then.


Control-IQ has a lot of the usual alarms and alerts that you’d expect…but the unexpected one I like a lot is that the pump has a quick beep alarm if insulin delivery has been suspended for 15 minutes. AND…it’s loud enough that Anna actually hears it (as opposed to her old Medtronic pump). We know call this the “Anna your shower has gone on long enough” alarm. Our water bill is so happy. Loop users have often requested a similar alarm option if insulin delivery has been suspended for 15 minutes or more…and now I can see why. Very useful.

Loop mainly relies on the pump system itself to supply the alarms (like Medtronic Loop) or emulates a limited set of alarms (like Omnipod Loop). The alarms specific to Loop are loop-not-looping alarms at 20, 40, 60, and 120 minutes.