Tidepool and Loop






Actually, let me borrow my own employer’s words:










Well, I’m here with wonderful news!

Tidepool is bringing in Loop data!  

How does it work?


Is this a replacement for Nightscout?


What data will you see in desktop Chrome view?


How can I share this data?


Are there any known issues?



What will I see in the Tidepool Mobile app?





What cool thing does Katie use this Tidepool Mobile app for?





Is this app only for Loop users?


How can I get this?



WWLD: What would Loop Do?

Probably one of the hardest things about closed looping is when you find yourself not understanding the direction that your loop is taking.  “WHY is Loop not giving more insulin right now?” or “Why is Loop doing nothing?”

To answer these questions, you have to Think Like A Loop.  In other words, we need to know about Loop’s algorithm and understand what its decision points are.  Tonight in Looped group, I posted this figure of a simulated BG curve and asked:

It’s 8pm and your predicted BG curve looks like the following. What do you expect Loop to recommend/enact at 8pm?

A. Zero (suspend) temp basal
B. Scheduled basal from your settings
C. High temp basal
D. Lower temp basal (between zero and scheduled)

Let me just say…LOVED the engagement and thought people put into it.  The responses also help me focus on the next project I’m working on…super excited to release it in a week or two.  But, back to question at hand.

What would your answer be?  Before you give your final answer…consider this next twist.  Would you give the same answer to this graph as you gave the graph above?  If not, what would the answer be for this graph and why? (ignore the timestamp mismatch)

This second case has a dramatic drop happening.  Suspend threshold is still at 60 mg/dL, correction range is still 90-110, the lowest value on the predicted BG chart is 75 mg/dL, and the eventual BG is 171 mg/dL for this example.  So, pretty similar to the first example except this precipitous drop going on right now.

Let me tell you some of the common pitfalls we all can easily slip into when trying to answer these “Why is Loop giving me this basal?” questions.

  • Wondering about IOB, COB, or DIA in order to answer…those aren’t a factor to answering the question as they have already been used to make the predicted BG curve.  In other words, they are accounted for already in the information presented.  All you need to answer this question is provided by the predicted BG curve, your suspend threshold, and your correction range.
  • Thinking about this as a human…humans tend to say “well, I’m on a rise/fall right now so…[insert Loop action based on that]”  Loop isn’t looking at the past BG movement, instead it’s looking at the prediction curve ahead and applying its rules based on that.  Any drop or rise going on will have been added to the predicted curve through the BG momentum and retrospective correction components of the algorithm…so again they’re already incorporated into the predicted curve.

Restating for emphasis:  All you need to answer this question is provided by the predicted BG curve, your suspend threshold, and your correction range.

The answer is B:  Loop will give your scheduled basal in both situations shown above.  When your predicted BG curve (A) drops for a time below correction range but (B) all of the curve still above suspend threshold, and Eventual BG is (C) above range or (D) within range…Loop will give your scheduled basal.

The logic is a bit of a wait and see.  Scheduled basal will maintain the delivery of insulin.  Your settings haven’t told it this is an “oh my gosh…stop the insulin!” moment (you’re predicted to still stay above suspend threshold), but we also don’t want to give high temps yet (to correct the eventual BG) because we’d like to safely make it through the part that is below correction range coming up.

  • If BGs were to drop (enough) or keep dropping (enough), your predicted BG curve would likely slip to your suspend threshold and then Loop would suspend. (One important take away is to not to set your suspend threshold so low that it no longer acts as a safety in these situations.)
  • If BGs were to rise enough such that the whole predicted curve comes back into or above the correction range completely, you’d then get high temp basals to correct for that eventual BG that is above correction range.

Want to practice a little more?  Here’s a sequence of actual screenshots from a running Loop.  Think for each of these…

A. Zero (suspend) temp basal
B. Scheduled basal from your settings
C. High temp basal
D. Lower temp basal (between zero and scheduled)

Time A

Time B

Time C

Ok, got your answers?  You can see what Loop has done by looking at the middle basal rate change in the head’s up display.

Time A

Loop has provided no adjustments to the scheduled basal rate.  The predicted BG curve has a temporary excursion below correction range, doesn’t dip as low as the suspend threshold and eventual BG is above correction range.

Time B

A few more BG readings have come in and affected the predicted BG curve.  Now the predicted curve is entirely within or above the correction range…and since the eventual BG is above correction range…let the high temps begin.  Loop is safe to correct for that eventual BG. (see Loop has increased temp basal by 1.5 u/hour)

Time C

And a few more BGs later, that BG has dropped some and the predicted BG curve has now gone below the correction range again.  Hasn’t dipped low enough yet to hit the suspend threshold at the lowest predicted point…so Loop is going to continue to just provide scheduled basals.

Hopefully that little walk through helps illustrate what you can be looking at to understand why your Loop is recommending/enacting basals at a particular time.  It’s all about the predicted BG curve, your suspend threshold, and your correction range.

Pre-soak, hotswap, and 65 minute “warm up” for G6

Since we use Loop (ok…and because we just like having as much continous BG coverage as we can possibly get with the supplies we have)…we had gotten into the habit of “pre-soak and hotswap” with the G5 system.  If you haven’t heard of those terms before, let me explain them quickly.

Pre-soak:  Inserting a sensor hours in advance of before you intend on putting it into service.  Why pre-soak?  When you insert a sensor, there are micro-traumas under the skin that take some immune response.  Chemical changes and tiny micro-responses to the “insertion trauma”.   Plus there’s a coating on sensor wires that needs to come into equilibrium with the surrounding tissues where you have inserted.  That time to equilibriate with the new tissue surrounding is why there is a 2 hour warm-up.  It’s a balancing time for the system to settle down from the trauma of insertion.  You’ve probably already seen this yourselves if you’ve noticed that even the first 6-10 hours after warm-up can still be jumpy.  So, pre-soaking a sensor is a way to let the new sensor settle into its surroundings before putting it into use.  This helps the sensor start off right away with less jumpiness and more closely holding calibrations quickly.

In order to pre-soak, you need to NOT wait for your existing sensor to fail.  In other words, when you start to suspect that your sensor is going to fail soon, or you notice that it isn’t holding calibrations well, then you would want to go ahead and insert a new sensor ahead of time.  YES, this means that the person is wearing two sensors at once…(1) the existing one that is soon to fail and still has transmitter in it and (2) a new one, just inserted, that doesn’t have a transmitter in it yet.  For safety, you want to go ahead and put a band-aid, wrap, or dead transmitter to hold down the little flap in the middle of the new sensor that attaches to the wire in the skin.  You don’t want that flap accidentally being pulled up while the sensor is presoaking.

Hotswap:  Hotswap is when you take the transmitter directly from one sensor over to another without stopping the sensor session.  The idea being that you are trying to avoid the two-hour warmup.  While some people get lucky and have minimal downtime during a hotswap…I have ALWAYS had 65 minutes without CGM data right after a hotswap.  It’s not surprising to have some ??? from the hotswap as the transmitter is noticing that the environmental conditions from one reading (in old sensor) and next reading (in new sensor) are very different.  The ??? is giving the sensor time to “find its legs” again and get used to the new surroundings.  From what I’ve experienced, that’s a 65 minute wait for the ??? to clear and BG data to start coming in.  So, while the hotswap doesn’t totally avoid the whole 2-hour warm up, it can shorten it to about 65 minutes of time without BG data.

Here’s the important part though…you really should only do hotswaps with a presoaked sensor.  That 2-hour warm up gives a chance for the sensor to settle in…so hotswaps should only be done onto a sensor that has had at least 2 hours soaking, if not more.

For the G5, the hotswap wouldn’t stop your existing session…it would just keep going.

But, for the G6 as outlined below, it does involve stopping and starting a new sensor session.  So…technically not the same kind of “hotswap” that you did (or will do) with a G5…but same idea.  Avoiding the full 2-hour warmup by using a pre-soak with it.

Can the G6 do a pre-soak and hotswap?

Tonight I experimented with trying a pre-soak/hotswap with the G6 for the first time.  Our sensor was starting to show signs of wear.  Normally we test once each morning to make sure the sensor is still accurate.  This morning the sensor was off by about 15 mg/dl.  Sure, not a huge amount…but for the G6 this is usual for us.  And then we noticed a few steep BG changes that clearly were just out of place and unusual for the G6 trends we normally see.  If you look at the screenshot below, the red dots are what her finger check was on the meter.  You can tell that the first check of the morning was quite a bit higher than the sensor value, and then the second check of the morning (done to test the sensor since it was off in the first check) showed that it was off quite a bit but this time low.

Noticing that the sensor was on its end of days (this was day 11.5 for us…about average), we did the following steps to have just 65 minutes of lost BG data vs the usual 2-hours.  Extra bonus?  When a pre-soaked sensor comes online, it doesn’t have the jumpiness that a new sensor usually has.

Pre-soak, Hotswap Procedure
    1. Got out a new sensor.  Took note of the new sensor’s code.
  1. Got out the receiver and WHILE between BG readings (they happen every 5 minutes), did a “stop sensor”, “new sensor”, entered sensor code from above, and then “start sensor”.  Immediately after starting the new sensor, I put the receiver in a faraday bag (you can put it in microwave, etc) to let the two hour warm up go by without connecting to transmitter again.
  2. Inserted the new sensor from step 1 onto Anna’s other arm.  Wrapped the new sensor in vet wrap to keep the sensor protected while no transmitter was in it.
  3. Waited 4 hours.  Ideally, I like to pre-soak for about 6 hours with the G5 system, but 4 hours is the way our life worked out tonight.  It was my first try doing this with the G6, so I wasn’t sure what to expect.  (Spoiler alert: four hours seems to have worked nicely)
  4. After 4 hours, we took the old sensor off and removed the vet wrap from the new sensor.  Immediately moved the transmitter over to the new sensor and then took the receiver out of the faraday bag.  Pretty soon after (less than 5 minutes), the transmitter connected and we got the following on the screens (both I expected).  The transmitter noticed the dramatic difference between the old sensor’s surroundings and the new sensor’s surroundings…and thus begins the ??? time period. 
  5. The next thing that happened was we got one errantly high BG before the session when to ??? sensor error for 65 minutes.
  6. After 65 minutes, the G6 came back online with a value of 149, and finger check was 163.
  7. We calibrated and VOILA…our new pre-soaked sensor was online, super accurate and not jumpy at all with only 65 minutes of lost BG data.  Here’s to the next 10 days of awesome G6 use.

So why doesn’t everyone do this?  Because a lot of us like to squeeze every last day out of our sensors and we end up having them completely fail before we start a pre-soak.  BUT, I have found that I usually can see a G6 sensor failure coming up about 6 hours ahead.  We tend to see either a few missed BG readings start to happen, jumpiness in the data, or calibration drifting.  Given that heads up, this process will be pretty easy to implement for the G6 going forward.  Small amount of pre-planning and we can get immediately smooth CGM data on a new sensor session with just 65 minutes of downtime.  Pre-soak, receiver warming up in faraday bag, hotswap, wait 65 minutes and new session underway.


But I wasn’t restarting….why the error??

Last night, we had a bleeder on a new Sensor #1.  A couple hours into its session, the sensor was losing data and just plain struggling.  Anna also said it was hurting a bit.  With those symptoms all together, we opted to pull Sensor #1 and put in a new one.

I called Dexcom to get it replaced while she put on her new Sensor #2 for the night.  Not long into warmup, about 35 minutes, the dreaded “Replace Sensor Now” message popped up accusing us (incorrectly) of trying to restart an old sensor.  (Turns out a lot of people have been having this happen to them, too.)

Anna thought it was weird, cleared the message without telling me, and tried restarting the warmup again.  Same message after another 35 minutes again.  At this point, she woke me up and told me she was having troubles.  The screen on the app was taunting us to start a new sensor, but that just didn’t sit right with me.  This was a NEW sensor.  It was about 3am now.  The last thing I wanted to do was:

  • Call Dexcom again,
  • Waste a brand new sensor,
  • Have to do a third sensor insertion, or
  • Dig out a transmitter from the brand new sensor.

So, instead I told her to just go to bed, and we left her app screen asking for a new sensor.  I grabbed the receiver out of the closet where we store it normally (we don’t usually use a receiver except for restarts).  I started a new session on the receiver, without even having the receiver connect to her transmitter first like I normally do when we are doing Option 1 restarts.  I just entered the sensor code for Sensor #2 that was still on her body, started a new session, put it in the faraday bag and went to sleep.  (If you don’t have a faraday bag, then you can keep the receiver out-of-range of the transmitter simply with adequate physical distance or by shielding it in a good microwave for the two hours.)  When I woke up about 4 hours later, I took the receiver out of the faraday bag.  It was showing “no data” and “signal loss” (like this old screenshot).  Exactly what I expected and wanted to see.  The receiver had stayed out-of-range of the transmitter for the whole warmup time.


Within 5 minutes, the receiver connected with the transmitter and was showing the last part of the warmup circle.  Also exactly what I expected and wanted to see.

And then 5 minutes after that…voila, receiver was showing its first BG value and my new Sensor #2 was no longer “needing to be replaced”.

So…the question is “Why would a brand new sensor be failing as if it is a reused one?”  I have heard from some people that Dexcom tech support is telling them that the sensor needs to pick up the “signs of trauma” that are expected from a recent insertion.  If the insertion doesn’t produce that kind of scatter and trauma in the data, the algorithm decides that this is a reused sensor.  It would appear the algorithm checks for this sensor scatter at 35 (or 65?) minutes (as that is when the “replace sensor now” messages pop-up).  By keeping the entire warmup period shielded from the transmitter, you bypass those scatter checks and can finish the startup.  I have no idea if all of this “trauma insertion check” is the truth…but that’s what Dexcom is telling people and it actually sounds plausible to me based on the observations.

The real problem is for consumers…we (and Dexcom, too) are having to be inconvienced as part of this “trauma detection” issue.  Pulling perfectly good sensors will cost Dexcom and/or the users money that doesn’t need to be spent.  And, even if the G6 doesn’t hurt for insertion (your experience may vary), nobody wants to have to do another pull of fresh adhesive off their skin unnecessarily.  Ouch.  Plus, Dexcom tech support is spending time answering phone calls about perfectly good sensors that are being rejected…adding wait times for us all unnecessarily.

So, until the “issue” is resolved (which I wouldn’t expect given the required FDA-approvals that went into this product’s design)…I highly recommend just pulling out your receiver and doing the restart like I’ve described above if you experience the same issue on a new sensor.  Save yourself the call to tech support, save yourself the new insertion, save the hassle.

Side Note:  This also confirms another nugget.  You could do this same procedure to restart an old sensor in the event you forgot to start the restart process in time.  Instead, wait for the session to end, then do this procedure that I’ve outlined above.  You’ll be able to restart an old sensor.

Side Note #2:  Based on what we know so far, I expect that a person who does not have a receiver could also just do Option #2 and restart similarly.     I haven’t tested it, but it would seem probable to be successful so long as there is no communication with the transmitter during the warmup.

No-Code vs Code sessions

On the Dexcom G6 system, the sensor is factory-calibrated according to a parameters and associated response in the sensor, and assigned a calibration code.  There is still work being done, but it appears that dexcom is using the following sensor codes:

  • 5915
  • 5917
  • 5931
  • 5937
  • 5951
  • 5955
  • 7171
  • 9117
  • 9159
  • 9311
  • 9371
  • 9515
  • 9551
  • 9577
  • 9713

Since these codes are presumably based on certain parameters and associated sensor responses, it would not be a good idea to just randomly choose a code for a sensor if you were uncertain of the sensor’s assigned code.  In other words, save the paper if you intend on restarting a session using a sensor code.

No-Code vs Code sessions

Sensor Code sessions: A sensor session that was begun using the assigned sensor code will not prompt for initial BG values at the end of the 2-hour warmup nor during the session.  For the 10 days, you should not expect to have any prompts for finger checks.  Having a sensor code entered should help the sensor maintain accuracy without the need for finger sticks and calibrations.

No Sensor Code sessions: A sensor session that was begun by choosing the “No code” option will ask for 2 initial calibration BGs after warmup.  After that, the session will prompt the user for a calibration point 12 hours later. If that calibration is not given, the prompt will reappear until it is given.   Inputting a calibration point resets that timer and you won’t be bothered for another 12-24 hours for a calibration.

Calibrations vs No Calibrations

Even with an active Sensor Code session (aka no-calibration prompts every 12 hours), there may be times when you should calibrate.  Dexcom has a very helpful set of G6 calibration guidelines to help you decide if/when to calibrate.  They are very useful for your 10-day old or less sensor:

  • When meter BG is less than or equal to 70 mg/dl, calibrate if sensor BG is 30 mg/dl or more different from meter value.
  • When meter BG is above 70 mg/dl, calibrate if sensor BG is not within 30% of the meter value.
  • If a calibration does not bring the sensor into acceptable limits, repeat the process 15 minutes after the first calibration.
  • If a series of 3 calibrations, each entered 15 minutes apart, does not bring the sensor back into acceptable limits, call Dexcom to discuss getting sensor replaced.

Using these guidelines, it was pretty easy to identify our recent bent wire sensor when it wouldn’t settle down early in our session.

Personal experience tells me those Dexcom rules are generally pretty good with a couple of additions:

  • Don’t enter a calibration point during times of rapidly changing BGs.  Try to find a smoother time of day where food and insulin bolusing is minimal and BGs are calm.
  • Don’t let the new sensor just flail on a bad starting point.  If the initial BGs starting a Sensor Code session are not within acceptable range of the meter readings, calibrate.
  • Don’t calibrate when very high or very low.
  • Don’t calibrate during compression lows.

If you get beyond 10-days and are having problems with the sensor maintaining accuracy, it’s best to just replace the sensor vs. suffering through jumpy, inaccurate BG data.

Q: Do I need to calibrate every time I am prompted in a No Sensor Code session?

A: Not necessarily.  You should calibrate at times that make sense as opposed to simply calibrating on a schedule.  For example, calibrating at 9:00 am just because a prompt showed up may not be the best idea if you just at a bowl of cereal at 8:30 am.

Q: What happens if I don’t calibrate when prompted?

A: If this is a normal, timed calibration prompt, nothing will happen.  Your sensor session will keep going.  You’ll get reminders until you finally do calibrate.  If you don’t want to be pestered with those alerts, you can go into your phone’s Notification settings for the Dexcom G6 app and turn off banner notifications.  Then you won’t be bothered by the little notification banners that appear.

Q: But what if I really never calibrate during a session?

A: The Dexcom G6 was approved for 10 days of no-calibration mode.  After that, you are in the “what makes you comfortable?” realm.  If you are restarting sensors, you will likely find that your sensor’s accuracy will decrease over time.  Calibrating may help restore accuracy for awhile.  However, you should never keep extending your sensor sessions to the point that the sensor is unable to maintain decent accuracy.  If you are needing to consistently calibrate often to maintain accuracy…it’s time to replace the sensor IMO.  Clinical trials were run with once-per-day calibrations.  There are lots of people who go days without calibrating.  Personally for us, we test (but don’t calibrate) every morning no matter what.  If we find the sensor is starting to lose accuracy on those morning readings, we plan on replacing the sensor.

Q: How has your sensor accuracy been after restart?

A: Pretty darn good.  We enter the sensor code during restarts and the sensor is maintaining its accuracy quite well.   We use CGM data in our closed-loop system, so accuracy is quite important to us.  We have not noticed any sudden or crazy drop-off in accuracy from a restart.

Q: How many restarts can you do on the G6?

We are finding, just like with our G5 experience, that we don’t get much extended time out of a restarted session before the sensor kind of “drifts” off its accuracy.  My daughter usually never gets more than about 13-14 days per sensor before we find the accuracy decreases enough that we want to replace it (remember we loop with this so accuracy is important).  I expect that your ability to maintain accurate sensor data with the G6 will be similar to whatever you got on the G5.   If you went 20 days before on the G5, you’ll probably get similar from the G6.

Restarted Sessions with Reset Transmitters

My original blog post on G6 restarts indicated that all restarted sessions would end up behaving as No Code sessions (i.e., sending calibration prompts twice per day) regardless of whether or not you entered a sensor code during the restart process.  After further testing and feedback from other users, I think I’ve narrowed down the source of the issue.  I was using a reset transmitter for much of my testing.  Subsequent testing has revealed a little more information:

Reset transmitters will cause EVERY session (new and restarted) to be a “No Code” behavior and you will get calibration requests…even if you entered a sensor code.

If you are using a normal transmitter that has not been reset, you should be able to restart sessions using the sensor code, and not have calibration prompts.   If however, you are using a reset transmitter, you’ll get calibration prompts on every session, even brand new sensors.  So if you intend on using your transmitter beyond 112 days or replace the battery, you can say good bye to no-calibration sessions.

How to enter code?

There have been reports of regular (non-reset) transmitters still yielding calibration requests even when the sensor code had been entered  I believe that issue, according to what I’ve been told and read, is an issue with the app’s failure to properly read the sensor code when users use the camera feature to enter the sensor code.  Therefore the current recommendation is to always manually type in your sensor code instead of using the phone’s camera.


I’ll be updating that blog post to reflect the new info shortly.