Building myself an @openAPS DIY artificial pancreas, or how I spent my summer holiday…

Two weeks off work in Cornwall. A great time to sit in the sun and build an Artificial Pancreas. What an amazing world we live in these days, where I can connect my laptop to wifi and then talk to a small Raspberry Pi in the house while I sat in the sun and enjoyed the weather. The surrounds were great, and looked a little something like this:

Oh yes, there was also a dog on holiday with me…

Over the two weeks, with plenty of reading and a few evenings/days of work, I moved through the stages of getting the Pi set up, getting OpenAPS installed:

Getting it talking to the pump:

Having it talk to Nightscout for glucose data:

The first command line TBR, which was very exciting:

And then, after a few hits and misses with Cron jobs, I finally started closed-looping… It’s important to note here that due to my experience using HAPP, I was confident that the closed loop would be okay with its settings, so I didn’t undertake the normal 3-day open loop trial. I ran it on closed loop for a day unconnected before running it attached to me.

Whilst these images might not look the most exciting, they demonstrated progress and success, which was nice!

Going through the process of building the platform, the walkthrough is fairly straightforward, and in reality, if what you build is exactly what the walkthrough is doing, it probably is.

Due to the CGM on my set-up, I’ve had to produce a set-up that doesn’t seem as well documented (I should document it!) and due to one or two issues with the 640G uploader and Nightscout Dev branches not cooperating, I’ve had to make a few workarounds. But I guess that’s what you build it yourself for. In addition, due to the way the docs have been built and updated, sometimes it’s not always 100% clear how to do things. But that’s why there’s Gitter! The other thing I’d mention on the topic of CGM is that, without good CGM, the system obviously doesn’t work.

While the 640G CGM system works very well (in my experience) with the 640G, on the uploading front, it’s definitely not as reliable as the Dexcom/xDrip pairing and I may need to revert back to that for running with this set-up.

I’d also add, I’m not a coder by trade. I have a decent understanding of Unix and have spent a fair bit of time messing around with PHP, so it was a bit of a learning curve to get this far, but it’s also quite cool to be able to say I’ve done it. And let’s be fully clear here. This is just the basic functionality. I’ve not enabled meal assist so far, nor sensitivity adjustment. Both those things are still to do, but given the lack of portability of the rig, I’m not so bothered right now about that. Once on an Edison, it makes a lot more sense (or on the iPhone Loop, which is where I am likely to go next).

I have to say that without the Gitter/Intend to Bolus channel, where I’ve asked dumb questions and been shepherded to find my own answers, it would have taken longer, so a big thanks to all the guys in there.

The other comment I’d make about this is that it highlights the issues that the big boy manufacturers will have had in bringing this stuff to market. At least they own the ecosystem, but when you’re pulling disparate parts together, it makes life so much trickier, especially when they aren’t all under your control.

My three biggest gotchas in getting this running weren’t openAPS related:

1. 640G Uploader talking to nightscout Dev branch. For some reason this continues not to work and that means that while I’m driving the glucose monitoring from nightscout, I can’t display the OpenAPS data in the master branch. A frustration that I am sure will work out.
2. Getting the loop to work – sounds simple, but due to having managed to set up two competing processes in Cron, the second would find the Carelink stick in use and thinking it dead, reset the USB ports to restart it. Very frustrating and only spotted by tailing the syslog to see what was going on.
3. The Carelink stick. It’s really rubbish. There are a lot of errors where data isn’t being properly communicated between the stick and the pump, and that causes a loop fail. It also has a dreadful range, which causes quite a few issues. So bad is it that I’ve already ordered parts to create an alternative connection to the pump.

We can’t forget the biggest difficulty, which is of course getting hold of the obsolete pump that works with the OpenAPS system… Thanks MedWOW!

Having built the basics, there’s then a whole load of work to update the system with better radio, meal assist, insulin sensitivity adjustment and additional hardware options, plus a different approach to capturing glucose data, but for now I’m just pleased that I built it and it loops. Next step… Let’s see if it does that via the Mobile Phone when tethered. Then it’ll be a mobile rig… And we can progress from there!

Then of course there’s the challenge of running it alongside the 640G and seeing how the two compare. My initial reaction is that oref0 is much happier to lift the reduced basal levels earlier than the 640G auto-suspend function, and I think that’s the way it should be, but further investigations need to be undertaken!

So, one small DIY Aritificial Pancreas/Advanced Insulin Delivery device for me, many more steps to go… Nothing like a challenge!