For years many of us have been wearing these devices and carrying phones in our pockets talking to them. And we’ve usually worked out what we need to to do let everything operate smoothly. Now with more people starting to use them (with the recent expansion of the CGM Subsidy and the launch of AID systems like CamAPS) we’re hearing from “newcomers” who haven’t learnt these lessons yet.
Such as when we hear that their fancy new system keeps dropping the connection to either their CGM or pump. Sometimes people blame the new phone they bought for the purpose. Sometimes they blame the device or app at either end of the connection. Sometimes those things can be part of the issue, but usually there are some things you can do to help.
Understandably there’s sometimes an expectation that things Just Work perfectly all the time. However in the real world it turns out that we usually have to cater to the devices’ foibles a bit.
But it probably helps to understand the constraints.
Bluetooth frequencies and water
Bluetooth is a radio protocol runs at around 2.4 GHz (similar to microwaves and WiFi) and although many people just assume two devices will be able to talk if they’re within a specific distance (sometimes “within 5m” is quoted) that’s just not true. Life is not that simple.
These frequencies do not pass through water very well. For example if you immerse either end of the connection (e.g. a CGM sensor on your skin) in a bath or a pool then usually you will lose communications.
Retries and recovery
Hopefully the devices will re-try the connection and get a chance to get data through while the sensor is momentarily out of the water (or maybe only just under the surface) but often that doesn’t happen. For example a Dexcom transmitter will spend a short time trying to contact its controllers, and then will go back to sleep for the next 5 minutes. It doesn’t matter how close the devices are during those 5 minutes: it’s what’s going on during the next short connection window that matters.
Insulin pumps remain contactable for a lot more time. But depending on how the software that’s talking to it has been written, at some point the software may give up and try again after a delay.
Operating system configurations
One issue that often crops up with phone applications is the power management in the operating system. On today’s phones there’s a lot of incentive to make the battery last as long as possible. And sometimes the operating system does that “aggressively” by putting apps to sleep when it thinks you’re not using them.
Of course if the app in question is running in the background and because we’re not interacting with it when the CGM transmitter happens to wake up and try to talk to it just when it’s been put to sleep, that’s never going to end well. Ideally the operating system allows the app to request close-to-realtime performance.
Android has got better at this in more recent versions, but there are still some of the lower-end systems which have unusably-aggressive power management. I had insurmountable problems with this on Oppo and Ulefone devices a few years back for example.
The details can vary by phone brand, but for a start I tend to turn off any “Battery Manager” and “DuraSpeed” functions. I usually still end up with a device that lasts all day without running out of battery. There are also per-app configurations and permissions such as not “Optimizing for battery”.
Physical usage patterns
So with the above things maybe you’ve managed to set it up so the devices talk to each other reliably when they’re sitting on the workbench. But then when you put the phone in your pocket and get on with your day, at some point you notice that nothing’s talking to each other!
There are obviously more issues to consider. One of them comes back to the way radio signals don’t travel well through water. And our bodies are mostly water…
You are a bag of water
Consider two radio devices sitting snug up against opposite sites of a big balloon full of water. They’re unlikely to be able to talk to each other. From each device’s perspective, all the signals on one side end up being absorbed by the water. Everything in the other direction is “open sky”, but that’s not in the direction of the other device!
However if you move one or both devices even a few cm away from the balloon, they might suddenly get a connection. Sure there’s still a big blob of water directly between them, but there’s much more chance for radio signals heading off-axis a bit to then bounce around off other surfaces and reach their target.
Obviously if both devices are flat up against the balloon but are not on opposite sides, their chance of communication is much higher. Even if they’re “just over the horizon” from each other.
Think about this but substitute your body for the balloon of water…
Phone and CGM
It’s common for people to use Dexcom G6 CGMs connected to their phone. The two should communicate automatically in the background every 5 minutes. But if you put your phone in a pocket on the opposite side of your body, sometimes it will fail to get a signal. Then you pull the phone out to look at it, and after a few minutes it magically connects.
Conscious decisions about which pocket you put the phone into can improve this.
Tandem t:slim X2
The t:slim pump talks to a G6 transmitter (and in the US also to a phone intermittently). With Basal-IQ and Control-IQ it needs to be doing this in the background so it can react to the glucose changes in your body.
The pump’s Bluetooth transmitter is behind the glass screen (apparently behind the big “T”) and the back of the pump has a lot of signal-blocking aluminium.
So the communications are much more reliable if the pump and G6 are on the same side of the body. It can especially become an issue if the pump ends up in a pocket with the screen (and radio) flat up against us (a “big bag of water”).
The Omnipod 5 AID (closed loop) system in the US uses a pod on the skin communicating with both the PDM controller (only whenever the user wants to interact with it) and with a Dexcom G6 transmitter also on the skin. Users are having to be careful to place both the G6 and pod on the same side of the body. Sometimes referred to as each having “line of sight” to the other.
The different replacement cycles (3 days for the pod, and often 10 days for the CGM) and the need to rotate locations for good health does sometimes complicate things.
The official instructions for using the DASH pods involves using the PDM controller to issue commands. At that point the PDM is out in your hands, and the radio signal has a chance of reaching around to where the pod is.
However with opensource looping AID systems that talk to the pumps, they want to communicate often (and without your input). The phone will be sitting in a pocket (i.e. close to your skin) and the app will regularly be trying to contact the pump. This is much more reliable if the phone is either in a pocket on the same side of the body as the pod, or at least in a jacket pocket that swings further away from the “big bag of water” that is you.
At the same time, the phone will need to be maintaining regular communication with the CGM on your skin. So although the CGM and pod do not talk to each other directly, the phone needs to be “in the middle” somehow.
Just as with Omnipod 5, the 10-day vs 3-day device cycles can complicate placement decisions.
The Combo similarly has an official use-case with intermittent communications to the linked BG meter, but in opensource AID systems again the phone needs to regularly communicate with the pump.
The Combo does have an advantage over the DASH here though. The tubing between the pump and its infusion site can be up to a metre in length, giving you a lot more flexibility in deciding which pocket to put the pump into. And the pump body doesn’t have to be flush against your skin like a pod is.
Some of the symptoms of poor Bluetooth connectivity can be W6: TBR CANCELLED and W8: BOLUS CANCELLED alarms on the pump. These can happen when the connection to the pump is disconnected part-way through setting up a temp basal or bolus, and then the action is aborted.
Medtronic 770G/780G and Guardian CGM
The CGM transmitter is obviously in a fixed location on your skin. Like other tubed pumps there’s some flexibility in being able to move the pump to a location where it can communicate regularly with the CGM.
In this case the CGM doesn’t talk to the phone: the MiniMed Connect app on your phone gets the CGM data from the pump.
The “Dose” update to the YpsoPump is now being used with the CamAPS FX loop (AID) system running on Android phones. Just as above:
- The phone needs reliable communications with both the pump and the CGM.
- The tubing from the pump to the infusion site can be between 45-110 cm in length. Choose a length that gives you flexibility without getting in the way.
When using CamAPS, you may occasionally see this warning appear on the pump. It’s the “temp basal has finished” alert.
If you see this, it’s generally a sign that CamAPS has lost contact with the pump (otherwise it would have renewed the temp basal before expiry).
The research version of the YpsoPump that we used in AndroidAPS clinical trials had a “feature” that has been resolved in updated versions. If the communications with the app were interrupted the the pump raised a warning that you needed to physically acknowledge on the pump (even though the app would have retried and hopefully succeeded in its task).
This made it annoyingly obvious when you’d put the pump somewhere that the communications weren’t reliable. The updated pump versions don’t raise the warning if the host re-establishes communication soon enough, which works much better.
It catches me out too
For some time I’ve been alternating my CGM sites between two locations on the same side of my body. My “pancreas phone” usually lives in a pocket on that side of my body, and the insulin pump (in a SPIbelt under my clothes) is also on the same side. Communications are usually very reliable.
In the last few days I started using a new phone (trialling the KingKong Mini 3) and went through the expected configuration that should produce reliable comms. And it seemed to work very well. But then every now and then I would find that my CGM hadn’t connected for 15 minutes.
The first time it happened I got the phone out of my pocket and put it on the bench beside me. After a while things came back to life. All was good except for a sneaking worry about maybe there was something funny with the new phone. The second time it happened I realised what was going on.
I have a routine hospital visit coming up where I know that both my CGM sensor and infusion sites should be located away from their usual spots in order to make it easier for theatre staff while I’m not conscious (e.g. a blood-pressure cuff is best not on top of a CGM site). So in preparation my current CGM sensor is on the other side of my body to usual!
Instead of running on auto-pilot and putting the phone into the regular pocket, I’m now conscious again of putting it on the same side of my body as the CGM.
Hey presto, the CGM connectivity is perfect again. Well, I figure a 99% success rate is close enough to perfect…
Sometimes the signal at distance is better than close up!
Yesterday after getting dressed I found myself working in my study, and eventually reached for my “pancreas” phone. I couldn’t find it. But my watch was showing me current data, the pump at my waist had been getting updates, etc. It turns out I’d left the phone on the bed several rooms away.
It was able to maintain connections with the watch, the CGM, and the pump. Through the walls and intervening furniture, and everything kept running.
In fact it was on almost the opposite side of my body to the CGM. But it wasn’t flat up against my body…
Luckily the weather was too warm for any of the animals to snuggle up to the phone while I was away from it. Cat and dog bodies are (like ours) great blockers of radio!