Category: Uncategorized

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.

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.

 

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.

 

**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.

 

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.

SUPER INTERESTING LOOPHOLE SIDE EFFECT

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.