Podding observations

Just some observations from recent experience. For the past few days I’ve been using another Omnipod DASH with my closed-loop system. This is also being tested by many people with the latest beta version of AndroidAPS 3.0. Along the way I’ve noticed a few things.

These do not seem to be anything related to beta code quality: the issues I’m writing about here are more systemic.

Not a perfect setup – Bluetooth consistency is key

On the whole it’s worked well, but there have been some challenges that haven’t occurred with other pumps. Not wearing my pump in a running belt around my waist (and sorting what to do with it during a shower) was a bit of a change. But the main hassle has been related to radio reception.

Keep in mind that the radio frequencies used by Bluetooth are high enough that they do not travel far through solid water. As a result they don’t travel through our bodies, and do best with a line-of-sight connection. Two devices against the skin on opposite sides of the body will probably not be able to “hear” each other. Mind you, move one of them a few cm away, and often the radio signals bounce and skip around enough that it can improve things a lot.

We often notice this with CGMs, where depending on which pocket we put our phone into we might not get all the CGM updates as they happen. So we tend to find a location that works, and stick with it.

In general with an insulin pump the choice of where the cannula is located should be guided by the need for regular site rotation for long-term health and for insulin absorption. But with an Omnipod the pump has to go on top of that location too, and that means the pump’s Bluetooth radio is there.
With a tubed pump we have choices of tubing length, generally for my pumps it’s between 45-110cm. This means I can have a pump site on my arm with the pump right beside it (held in place with elastic support bandage). Or I can have the pump at my waist, with the tubing snaking up inside my shirt and down my sleeve to the cannula in that same location. Or I can have the cannula on my abdomen or legs, and not have to have the pump on top of it.

With a tubed pump it is easier to put the pump’s Bluetooth radio where it is easier to maintain reliable communications. The difference with the Omnipod has been noticeable.

My loop needs to be responsive

I am running a very closed-loop system. I tell it about significant exercise, but I don’t tell it about any food. I’m relying on it to detect and react to the rises (guessing about the food where appropriate). I’m using faster insulins to allow it to react as promptly as possible.

This is affected by getting reliable CGM data, but it can also be affected by the reliability of the communications with the pump to enact changes.

CGM signals

My Dexcom CGM currently provides a new glucose reading every 5 minutes, prompting the loop to re-evaluate things. I’ve known for years that the reliability of this can make a big difference to the loop. If the CGM misses some readings it will eventually back-fill it (unless there were sensor errors) but even if it fills in the history later, that’s time that the loop has been blind and unable to react.

xDrip+ conveniently shows us the “realtime packet capture percentage” for the CGM over the last 24 hours. Ideally it would be 100%. But if 1/10 of the packets are missed, that obviously drops to 90%. I have tried some phones (cough-Oppo-cough) where the operating system kept putting apps to sleep and I couldn’t get the rate above 56%. Completely unacceptable. So I only use devices with decent performance. Even 90% is sub-optimal in practice.

The rule of thumb I’ve built up over the years is that above 97% is good. 95% is OK, but below that we start to get too many delays in the loop operation. I’ve found that in general the phone that’s talking to the Dexcom transmitter is best placed on the same side of the body as the transmitter. It can be moved around a bit, but on the other side of the body I’ll start getting gaps in the CGM data.

DASH Bluetooth delays

The little pod seems to be conservative with its battery consumption (unsurprisingly). Connections to the pod can sometimes take over 30s to start (even if the phone is right beside it), after which they complete fairly quickly. Sometimes it connects straight away, sometimes it drags on. This delay isn’t usually itself a major problem, except when the radio signal is weak and the connection fails.

Location is all we can control

Just like with a CGM, to improve the reliability of the loop-to-pod connections I’ve needed to make sure the phone is somewhere it can “see”/”hear” the pod. Therein has lain the problem with the last pod I’ve been using.

This Omnipod has been on the back of my right arm. But the G6 transmitter has been on my left bum-cheek (high up, just below the waistband). This has been a fairly reliable G6 location on the whole, with very little physical disturbance of the sensor. Generally I’ve had the phone on the left side of my body when using other pumps.

To have the best chance of reliable loop operation, I had to set up a belt pouch so the phone is on my waistband at the rear to my right. There it has a good chance at clear comms with both the G6 and the pod. But sometimes I’ve thrown the phone into another pocket out of habit. The loop keeps working, but sometimes gets unreliable when it can’t talk to one or both of the devices clearly.

Measured signal strength

With the phone in this position the Bluetooth signal strength (RSSI) indicator for the pod has ranged from -60 dB down to -90 dB. Keep in mind that -99 dB would be “we can’t hear the pump over the background static”. It’s a logarithmic scale: each increase of 3 dB is roughly a doubling in strength. An increase of 10 dB is a ten-fold increase in energy.

Across one day I measured the signal strength reported by the operating system towards the start of each connection. For comparison I also show the same measurement when talking to my YpsoPump OPN (on an earlier day).

That’s not to say that the DASH radio is “bad” in some way, but it is a noticeable difference in real-world usage. Being in a fixed location for 3 days and probably weaker to start with, both contribute. The YpsoPump is also worn right against my body.

Both sets of data were measured on the same phone: a Cubot KingKong Mini 2 which is my “daily driver”. In my measurements its Bluetooth signal strength has been comparable to mainstream phones from Samsung and Google.

The DASH software driver also gathers another metric about connection quality: a simple count of successful connections along with the total number of attempts. Over the 3 days the ratio of these varied between 50-85% success.

Specific to looping

People using the Omnipod PDM wouldn’t usually notice this. The use-cases for the PDM involve picking it up and issuing some commands (e.g. a bolus or setting a temp rate) and then putting the PDM away in a pocket again.

With looping we have a device that can be trying to talk to the pod every 5 minutes, even when the phone is stashed away in a pocket. If everything’s stable then we should keep going on a fairly straight line and the gaps shouldn’t matter. But when dynamic things happen (for example BG rises/falls suddenly due to carbs or exercise) it can sometimes have significant impact.

Breakfast failures

All of the above may seem a little theoretical, but I can show one mild real-world example from this pod. Across the 3 days of this pod I had the same breakfast every day. Not my usual yoghurt and berries which usually hardly makes a dint in my BG, but a challenging bowl of GF Sultana Bran cereal and milk. Around 50g of carbs, with plenty of it as fast-acting sugars. The same breakfast every day (kitchen scales were involved).

On one day I managed to keep the phone positioned so that it had regular communications with both the G6 CGM and the pod.

This was a holiday, so a fairly late breakfast. You can see the system had been keeping me on target overnight, and then dipped a bit when I got up and walked around the house and prepared breakfast in the kitchen. That’s normal and expected.

Then I went and sat at my desk while I checked emails/etc. Soon the cereal kicked in, and my BG rapidly rose. Every 5 minutes the system poured more insulin in, both by boluses (the blue triangles, although they don’t show the bolus size) and by basal (the “cityscape” line at the bottom). The largest “micro-bolus” it administered was 0.7U.

It crested at 9.6 mmol/L before coming down back towards target. Not terrible for an unusual breakfast like that. It did remind me why I usually don’t have that sort of food to break my fast (later in the day when my gut isn’t empty it usually isn’t absorbed as rapidly).

But with everything else the same, here’s what happened 2 days earlier when I wasn’t so careful in keeping the phone positioned:

The cereal kicked in and drove the BG up at about the same rate, but because the system missed many CGM updates (some of the dots here were back-filled later) you can see there were fewer boluses and basal changes, and it thus look longer to get the insulin in. There were also a few times the system failed to send commands to the pump. With fewer opportunities to bolus, the largest was 1.6U as it was trying to catch up.

As a result I crested at 12.0 mmol/L before coming down again. Not “terrible” compared to some people’s experiences (keep in mind that I did not announce or manually bolus for any of this) but noticeably higher than 9.6. Some people may feel that these are close enough to be “in the same ballpark”, but a 25%-higher BG does not seem insignificant to me. Also I feel I’ve probably removed/controlled most of the “random” factors that some people experience.

There were fewer boluses during the rise, although they did get larger (not shown here) as the system realised I’d risen a lot. I’m using a fairly fast insulin at the moment, and those 15-20 minute delays before more insulin was delivered did make a noticeable difference.

The CGM capture rate over 24 hours had dropped to 91% (I mentioned earlier that 95+% is preferred).

The observant amongst you who are familiar with AndroidAPS may notice the raised temp target from ~11:40. I went for a ride on my bike during that time. Actually two rides: one at 12:40 going to a 13:00 meeting, then heading home at 14:00.

A non-radio observation

This next point isn’t a problem per se, just an observation about the pods.

Unlike the other pumps I’ve been using lately, the Omnipod isn’t silent. It’s not loud, but when in a quiet room it’s not unusual to notice the little “click” as it administers each 0.05U. I didn’t find it a problem, but it was noticeable. These happen whenever needed to produce the programmed basal rate, but also any bolus will result in a series of clicks (at a maximum of one every 2 seconds). Incidentally it wasn’t just me. Occasionally one of my cats would hear it too and jump up trying to find the tiny creature…

Mind you, we do generally get used to the feedback of every pump we use.

With the Medtronic Paradigms I would rarely hear the pump unless I held it close to my ear (it would dose up to once every 5 minutes or whenever there was a bolus). But every hour the pump would vibrate (because a temporary basal rate was usually in effect). I quickly got used to that and it faded into the background. Some people have their pump set to beep instead of vibrate, but again they get used to it (the people around them maybe not so quickly).

The Accu-Chek Combo also doesn’t make a lot of noise (except when rewinding). But it does give a short vibrate on each bolus. Again that vibration quickly faded into the background of the day. Whenever I noticed it, there was an immediate thought of “oh good, it’s looking after me”. My partner could hear that vibration at night too, and eventually reached the same thought pattern.

To all intents and purposes the YpsoPump OPN is silent, so when changing from that to the Omnipod I quickly noticed the pod’s clicks. Maybe I would get used to it over time. However because I’m likely to be reserving the expensive pods for things like “watersports weekends” maybe it will surprise me every time!

Summary

Overall I think the DASH pods work well in a loop. But there are some limitations. I’m sure they’ll work even better where the pod and CGM are both located on the same side of the body as the loop controller (phone).

I am happy to say that although the intermittent connection issues sometimes let my BG run higher than normal, the system did bring me back down to target safely. At no point was I tempted to override the loop. But I was happy to return to a tubed pump.