Taking #OpenAPS to Glastonbury Festival – preparing for 5 days in a field, off-grid and offline

If you hadn’t guessed from the title, I’m off to Glastonbury Festival at the end of June. And I intend to take OpenAPS with me. So that’s requiring a little bit of planning.

For those who aren’t aware, Glastonbury Festival is in Somerset, and the key factor pertinent to taking OpenAPS is that it is a couple of hundred thousand people, camping, with limited access to any form of electricity. Add to that that it will be 250,000 people in fields that normally don’t have much in the way of phone signal (although EE have stated that they are providing “more than ever” this year), and you can see where this starts to become an interesting challenge.

So in preparation for trekking for 10 miles a day around a bunch of muddy fields and still benefiting from the use of an artificial pancreas, I thought I’d list out what I need to consider, and as I need to do that anyway, I’m sharing it. Apologies if this seems like a bit of a ramble. In many ways it is, as I get my thoughts in order, but hopefully, someone can take something useful from it in respect to going offline.

The preamble

First up, power. Now power is obviously critical, and there appear to be a number of options for this, not least of which is the ability to recharge phones at various locations around the site. But that requires leaving a phone or device in that location in order to charge it, and presents the requirement to manage multiple rigs to be charged throughout the time period.

Also on the topic of power, is the amount of power required by the rig to keep it running. My usual 2000mAh battery generally lasts about 12 hours, and given the amount of time spent running around the fields, that’s just not going to be enough.

So even at the start, we have the consideration that I need to charge a phone and a rig to last me for five days.

This in its own right raises questions about portability. And that’s the second set of points.

Last year I used a 640G with Enlites and Predictive Low Glucose Suspend (PLGS). This worked very well, and was a single box that did everything I needed. On this occasion I can see the benefits of the 670G, in that a single box will do everything (basic) to manage glucose levels and will do it on a single AA battery. That’s not a lot to have to carry, or charge.

Importantly, I’d have a phone with me anyway, so the reality is that the things I really need to be able to handle are powering the rig and managing the glucose data. Then making this as portable as possible.

So let’s take a look at these three as separate items.

Powering the rig

As I’ve mentioned, I normally carry around a 2000mAh battery attached to the rig, and that’s normally good for 12 hours. Based on previous experience, that isn’t going to be enough. Fortunately, a month or so back, I invested in some larger 16850 based batteries that have capacities variously of 4400mAh and 6600mAh. These do last 24 hours. And then some. So at the expense of a slightly larger rig, I’m planning on taking these, with a couple of charged 2000mAh LiPos as back up kept somewhere safe.

But I’ll still need to recharge those batteries and for that we have the same facilities as the phones. A couple of 10,000mAh, a couple of 25,000mAh and one 30,000mAh packs that should allow everything to stay charged up over the five day period. Not to mention the two iPhone cases at 4,400mAh and 8,000mAh. And if the worst comes to the worst, the batteries can be plugged in at a recharge point for some recovery time. I’ll be packing a lot of Lithium.

So we’ve got power accounted for. What next?

Managing glucose data

I currently run a Dexcom G5 talking to an Android 7 phone. I do this because the G5 is (based on my measurements) continually the most accurate sensor I’ve used and consistently so. It needs minimal calibration and just works. Which makes it ideal for walking around fields. And with the Android phone, it can work offline with my rig when phone signal is lost. And yet. It is talking to a phone that I don’t use as my everyday phone and that doesn’t have the world’s best battery.

But that’s not the only option.

Glucose data can come from one of three sources. Nightscout, Dexcom G5 directly (either via xDrip on an Android phone or via adjusted Loop on iPhone, or by connecting a receiver to the rig) or from a Medtronic Enlite talking directly to the pump.

The Enlite has its downsides (mainly accuracy and calibration), but the key upside is that it runs offline by default. With some of the tweaks I’ve instigated on the rig, I don’t need nightscout to understand what’s going on, so in an environment where data signal quality may be poor, but enough to create a Personal Area Network (PAN) with iPhone, this may be the best option, especially as I don’t own a Dexcom G5 receiver to plug in to the rig!

Alternatively, EE is claiming that they will have excellent connectivity over the site, so the alternative is to buy a PAYG SIM card for the weekend and swap over networks, leaving the other phone on my normal SIM.

At this point my thinking is that maybe the Enlite is potentially the best option as it also allows me to take the 640G as a back-up pump and know that I will have data and PLGS available should everything else fail.

Portability…

It comes down to the point that I really don’t want to be carrying two phones, the rig, a back up battery and the pump around the site, however, there’s a big “Hold on a mo” here. I’ll be carrying a back pack with me anyway. Why? Well you have to keep the bag of wine somewhere. And the waterproof, jumper, etc. I’ll be carrying stuff anyway. So is the extra portability really that big a deal? Not really. I think the real question on portability is really how many items I want to have to recharge intraday, and the answer to that is “As few as possible”.

Decisions, decisions… What to do next?

I’ve been testing use of the rig with my iPhone, and had no issues with that. It all works very well. I’ve also built the modified version of Loop to feed xDripAPS (Lookout from here). I’ll shortly be testing the nex Dexcom app and seeing how well that all works with the loop.

But at this point, I’m thinking along one of these lines to make this work best.

• Take the iPhone linked rig, run it with Dexcom on the iPhone (and the local Loop based feed if I can get it to build) and use that for the duration, with a PAYG SIM to guarantee connectivity; or
• Get hold of some enlites, build a Medtronic system just for the Festival and put up with slightly less accurate BG numbers, a couple of additional calibrations a day, but know that it will all work in spite of network connectivity, with the additional ability to fall back to the 640G with glucose data should everything go belly up.
• Then, or course, there’s the other option. Don’t take OpenAPS, use Loop. Whilst this is the easiest of the three, I’d prefer the oref1 capabilities to the current Loop ones. But it’s always worth considering and taking RileyLink with me.
• Buy an enormous great battery case for the Pixel, and run from the Android phone as I do now, with all the smarts I’ve shoved into it, and simply leave it in my bag. Disable the oref0-online cyclic functionality and simply have bluetooth connect the PAN at reboot (this technically may work for the iPhone too).

So, a tricky choice. But in the same breath, a wonderful choice. That I am considering what is the best way to be running a Hybrid Closed Loop at Glastonbury is pretty cool and not what I would’ve been expecting 12 months ago.

How does this relate to commercial systems?

It’s also quite an eye opener when you consider what I’ve discussed here to spend 5 days “off grid” in regard of what the commercial manufacturers need to consider. As I mentioned, last year I took a 640G with Enlite CGM and my power consideration was simply a pack of AA batteries. When they’re building AP systems, whether those are phone user interface based or embedded software within the pump, they also need to consider this same set of semi-functional requirements. When you consider it yourself, it highlights the physical challenges of building an efficient and highly portable AP system that is robust enough for the public at large.

• The system needs to store enough data to work off for a long enough period for it to function correctly. Whilst we clamour for data upload, it’s more important for a single device that data is stored and useable and can be forwarded when online.
• It’s also more important that the device can run without any form of connectivity to the outside world, so that you can bolus from it, and it can make decisions without needing to talk to a device or service that may have run out of power or be inaccessible (we achieve this in the OpenAPS world through use of the pump as the input device talking directly to the rig).
• Finally, the commercial system needs to be built from a power perspective in such a way that you don’t need to recharge it twice daily, but it manages to run a physical pumping system, radio receiver and all the required electronics for a decent period of time (probably a week or so) on a relatively low capacity power supply (an AA or small rechargeable). This is achieved by writing the code as firmware and optimising the hell out of it so it has as little impact as possible.

Yes, there are lots of things to consider, and the above is far from an exhaustive list. At best it’s illustrative only! And in reality it demonstrates quite how much of a feat of engineering the Medtronic 670G really is. Forget the algorithm, that’s the easy part. Making the algorithm run within the physical constraints required. That’s much tougher!

But let’s face it, this is a huge first world problem presenting itself to me. It is, in many ways, a nice one to have. So whichever way I end up managing it, first and foremost, I’ll simply get on with enjoying the festival, and letting Type 1 Diabetes very much take the background.