A weekend at Glastonbury Festival. Sun, wind, a little rain, no mud, and lots to occupy myself. Plus cider, wine, and a range of foods acquired from places with no carb counts. All ably assisted by OpenAPS. How would I fair? How would the rig hold up? What issues would I face? How did it look overall?
Well let’s start with the results. And I’d say they weren’t too bad given some of what went on. Ahead of reading into them, my behaviour at this year’s festival was rather different to last year.
This year, with OpenAPS using oref1 and Pushover, I operated rather differently. Instead of spending time carb counting, accurately bolusing and double checking, I easy bolused for food with a rough estimate, often didn’t bother entering carb details into the system and just let it get on with it, using UAM. If it thought I needed either more insulin of carbs, it would then tell me via pushover. A very comfortable way of managing things. There were a couple of anomalies, more of which later, but for the most part, this approach heralded a decent outcome, and one that meant that the diabetes could take a much lesser part in enjoying the festival. I should also mention that it had to deal with all sorts of foods at all random times of day, and of course some interesting fun with both normal and hot, spiced cider, just to add to the challenge.
The overall stats show 79% in range (which I define as 3.8-10 mmol/l) for the festival, but it does rather belay the fact that on the first day, the sensor was producing nonsense, showing a high of 12 on a glucose reading of 6.9 and a low of 2.9 on a reading of 6.8 mmol/l. These results obviously skew the overall numbers rather badly and also show the challenges of using an APS system. There was also an overnight anomaly ending up in Dexcom readings of around 20 mmol/l, but I’ll go into that later.
So how did it really fair? Well, based on the blood data, that low level that Nightscout is showing is really much lower than I got to. Unfortunately I can’t say the same for the high levels, but again, I’m not confident in some of that data either. So all in all, in terms of management, whilst I’d say it was okay, due to the disparities I had over the first 24 hours and battery issues, I’d have to suggest that the data isn’t good enough, statistically, to say whether OpenAPS did a good or great job as a whole, which is rather disappointing. What I can confidently say is that it did a great job in terms of how it allowed me to manage eating and drinking whilst at the festival.
Fortunately, a Sensor restart seems to have resolved the issues with the reporting and calibration, and we were back in business on the Friday.
Lesson one: Your APS system is only as good as your CGM, and when that’s bad, you’re stuffed.
During the day, when I was walking around the festival, occasionally adding in carb data, bolusing, etc, it didn’t do too bad a job.
As I mentioned, we had a rather spectacular anomaly on the Saturday night/Sunday morning, which looks a little like this:
What was odd/bad about this was that for some reason, my battery pack shut down (more of that later) and whilst I’d bolused for the food I at a little after midnight, and that seemed to remain stable at a little over 6mmol/l for a couple of hours, the loss of the basal as a result of the bolus snooze, and the loss of the loop at around 1.15am meant that the lack of basal prior to that point started to have an effect, and quite a substantial one.
Having not added any carbs in to the system, that suspend ended up being quite a long one and shows nicely what happens when you don’t quite do things right. That linear rise until the pump basal rate kicked back in then flattens out as I gained IOB, but what we can also see is that the drop off from about 7.30am coincides with my raise in basal rate about an hour earlier.
Lesson two: While Unannounced meals are a great innovation, if you don’t announce, you may find your bolus snooze is too long in the event of a rig outage…
Clearly, in addition, I need to adjust what is on the pump to match the output from Autotune…
Lesson three: Autotune is there for a reason, and a regular review of the output and update of the pump is a really good idea…
So results aside (and to be honest, for the most part, the highs were stopped and the lows managed, especially given the cider drinking, random food and mis-configuration of boluses that went on), what were the takeaways?
Battery Packs are not all created equal
Frustratingly as it turns out, and not one I have a good answer for, only guesses. The outage discussed in the previous section occurred after putting the rig on the 25,000 mAh battery, using the 1mA power socket. One that lasts for ages. Or should. Yet it turned itself off. I can only assume that the power draw on the rig under these conditions (i.e. in the cool air overnight) wasn’t enough for the battery pack to register enough power was being drawn, and disconnect itself. Highly frustrating, especially given the outcome. The addition of the three-cell 18650 pack to give it something to charge eventually fixed that issue, but it wasn’t what I was expecting to see. The moral is be careful about the battery packs you use and keep an on whether they turn themselves off.
If you’re using an iPhone, cellular signal is pretty important
Because without it, you have no rig. While my standard provider was pretty useless, although the signal never dropped, my personal tethering got blocked, frustratingly. I was able to switch to the back-up provider and everything worked, with 24/7 coverage on the site, although, and this is important, there were times when the data service was so congested that there was no communication with Nightscout or Dexcom share services.
And hopefully it wasn’t this guy causing the issues…
So that was no data upload nor carb control and temp targets with it either. The network IP address remained in place, so the rig still had a local network to work off, which was some consolation, and meant it received the glucose data via the modified form of Loop I was using. It also meant that status webpage that my rig was generating every five mins became critical in understanding what was going on.
As an aside, on the Pay As You Go tariff I used, the system showed I used roughly 175Mb per day using OpenAPS 100% of the time via the phone and using the data connection as normal. Something to bear in mind when looking at data tariffs for use with a system like this.
Don’t forget that you always have the pump…
Why? Because it means you can always enter carbs and boluses via the bolus wizard, meaning that you’ve always got that information available to you and the rig to keep looping safely on. It also gives you a way to adjust targets. Okay it’s a bit cludgie, but it’s better than nothing. Combined with the Loop feed to the rig and it all still worked. There’s just no Nightscout, which is less of an issue if you have the web status page.
It’s worth building a small status webpage on the rig
Okay, it’s not shiny like a Dexcom or Nightscout graphical interface, but when you can’t get to Nightscout, it’s really useful for checking what the state of the loop is without needing any further digging. And it shows up nicely on Glimpse on the Lock Screen and watch, making it even easier to use.
Tethering with bluetooth still eats into phone battery, especially in a cellphone congested environment
The phone is desperately trying to maintain a data signal, in an environment where there were 200,000 other phones doing the same thing. That’s tough anyway. But then you also have bluetooth drawing power. As it transpired, I was using the equivalent of two iphone 7+ batteries a day. That’s a lot of power for the phone. Admittedly, I was also using the phone to take photos, videos and do normal on-line stuff, but when you’re in a power constrained environment it soon adds up. Fortunately the ton of power I took with me sufficed.
Lots of 800MHz cellular data connections are bad for rig communications…
You what? Yes, that’s right. Of course, I’m using a Worldwide 722 as my primary pump, and it operates on the 868MHz frequency. I was also sharing a small area with a lot of people, with cellphones, trying to share their videos of Rag ‘n Bone Man or Ed Sheeran with their friends, family and the world. While the main cellular provider runs mostly at 2100MHz, they also have an 800MHz band. Two of the three remaining providers run mostly on 800MHz. Assuming that out of the 200,000 people there, around 50% at any one time were on the 800MHz frequency, there were a lot of people (up to 100,000 at a time or more) running in this band. And in a crowded field accompanied by 130,000 others, that’s a large number in very close proximity.
And that poses a problem.
For the two most packed crowds I was in, there were some very long wait times between the pump and rig trying to communicate, with multiple mmtunes, and the familiar issues we’ve seen with that. Doing some digging, it transpires that there is interference on the 868 MHz channel when there is a strong 800MHz broadband transmitter nearby. Does that also correlate to 35,000 cell phones trying to transmit data?
I’m fairly sure that this is what I could see going on. The periods of the longest wait times coincided nicely with those where Dexcom share (and consequently Nightscout) got no data from the iPhone, in spite of a supposed data connection. So it looks as though a high concentration of cell phones all trying to transmit data isn’t a good thing for something using 868 MHz, which probably also explains issues in busy underground stations, and other crowded environments.
I think this is likely to be a limitation of this type of system on worldwide pumps, regardless of whether you are using OpenAPS or a RileyLink, and one that’s difficult to overcome without having a bluetooth link directly to the pump. Incidentally, even via Bluetooth Tethering to share the network, once the rig was connected, it stayed connected, so the volume of users with bluetooth devices connected to phones was either small or didn’t impact connectivity. A not quite so expected side effect, it turns out.
Don’t delay set changes with Fiasp
Ever. Full stop. I changed the set on Friday six hours late, and this resulted in the usual rising glucose level as the effect of the insulin was blunted. Just a little reminder of why we do what we do…
Check the autotune log for any changes to Insulin Carb Ratio, and bear in mind your current calculated ISF
Why? On more than one occasion over the weekend, with my estimating approach to carbs, I overbolused. But at the same time, this was often due to use of an incorrect IC ratio, given the current insulin sensitivity I was showing, having walked some 45 odd miles over the course of the weekend.
Something well worth looking at when you are active, as an increased sensitivity to insulin almost certainly requires less insulin for carbs, and you have the factors to adjust that at your finger tips.
So what else have I learned from this weekend?
Firstly, I’m unlikely to ever use iPhone and Dexcom as my primary connectivity source again when going into sub-optimal connectivity surroundings. It enhances my belief that in any commercial rig, you need the rig, pump comms and glucose data all talking safely to each other, which in this case got a little precarious.
As a result, my most likely future festival and offline solution is likely to be Enlite sensors to the pump and run it off the rig (as then it can do everything except temp targets without access to a phone), then use Pancreabble as my main offline observation kit on a pebble. Nice as the Apple Watch is, the issues with phone comms just aren’t worth it. And I don’t have a Dexcom receiver to attach to the rig. If you do have one, it may be a good alternative, but adds to the battery needs.
As an alternative, I’d set up an Android phone for fully offline mode with Dexcom, if I was having Enlite issues, as this would also give me temp targets, and do everything through that.
I think there’s room for expanding that further to allow something to replace the carb entry via Nightscout and do it off hot buttons or a webpage. Maybe modifying xDripAPS to have a treatments database on the rig so that carb entries can be done within it and passed over in place of NS, and reducing the risk of SMB functionality clashing with the bolus wizard to cause an A52 error and pump reset.
Given the variation in insulin sensitivity over the weekend, it might also be beneficial to create a bolus calculator that incorporates this data from OpenAPS into the calculation, adjusting your base IC ratio for better results when things have changed. Something else for the development queue.
Overall, this experience has confirmed that while OpenAPS can be perfectly portable, it’s the interface for management and interaction that needs some help when you can’t really use NightScout and IFTTT, and that’s probably where a number of us should focus our efforts. Yes, with certain limitations, it can be totally offline, but the benefits of a good offline user interface are clear.
But otherwise, well done OpenAPS, on making Glastonbury an easier festival to attend and not having to spend any time worrying just how high that cider or croissant is going to send me…! I have another coming up later this summer, and I’ll absolutely be taking the rig along for the ride…
This is the best Glastonbury review I’ve read! Very, very itneresting.