@OpenAPS – Standing on the shoulders of giants – #wearenotwaiting for an artificial pancreas!

As I mentioned previously, I’d spent a fair amount of time building the Artificial Pancreas on my Pi whilst on vacation, but it wasn’t really in a state that I was happy with. It could use nightscout data and loop and that was okay, but there were a few things that bothered me, namely:

1. No offline data – using the loop with nightscout really doesn’t fill me with joy if I’m going to lose signal somewhere.
2. No upload to nightscout as I was having to use the master version with my glucose data, and all the monitoring that comes with the Dev version was unavailable.
3. I wasn’t that happy with the range of the carelink stick (but it was less of an issue than the above items).

So I went away and reviewed what I had, and this is where I pay a huge amount of thanks to Matt of LittleT1D and Lennart Goedhart. The work they did on building the Android 640G Uploader and the start in Python on Linux proved invaluable to me.

Okay, I’m meandering a bit. What am I talking about. For issue 1, I’ve been using the 640G with Enlites, and my set-up is therefore rather different from the standard model that uses Dexcom for offline looping. I’d been using the 640G Uploader on an Android phone that Lennart built to upload my data and then running off NightScout. The original version of this was built on OSX and Linux in python, and the Github repositories for that are here: littlet1dmatt and Lennart.

Looping Offline!

To use this with an artificial pancreas instance offline though? Well, we could get the data off the pump, but it needed to be passed to oref0 to use with some historic data and in a certain time order. So I took Matt’s code and munged it with Lennart’s updated code to start off by uploading to Nightscout from the Pi. This worked very nicely, once I’d figured out that the timestamp had been modified slightly.

The next step was to write to a file that I could use as the data store, much like the downloads that OpenAPS pulls from NightScout. Due to the data order, it all got a little complex, and I had to learn some sed (when I say learn, I mean, “Copy/Paste from Stackoverflow.com” and then modify. I also needed to ensure that the delimiter on the end of each line matched what OpenAPS was expecting.

It took a  few goes, and it’s almost there, but there’s a slight flaw that only makes itself evident when I get a timeout on the pump/contour next link connection due to interference on the sensor. That’s work in progress, but I’m pleased to say that the system does run effectively, does move data around off line and does loop without a network. That’s awesome enough.

At this point I must mention the work that Scott’s done to provide an install script. When I decided to enable Meal Assist, I was recommended to use the Install Script that is in beta and do it with the dev version to get Advanced Meal Assist (AMA). The script made it very, very easy, and modifying what was created to take account of this rather unusual set-up was very simple. Aside from one or two cut and paste errors, this has made the whole process absurdly easy.

I think it’s also probably the only Loop in existence that is using the 640G as the sensor glucose value  (SGV) receiver! I think that’s quite cool. It makes my set up a little different. I guess it’s a little like having the Dexcom receiver but you don’t need to attach it to anything!

The second item was the lack of communication with Nightscout. Thanks to the flip to dev I was able to undertake with the system all running in offline mode on the Pi, this seems to have resolved itself. Which I love because it means I get to post pictures like the below all over twitter and facebook!

This afternoon I’ve been testing the Advanced Meal Assist with a Chicken Katsu curry with Noodles and a pot of Wasabi peas. In my book it’s worked really well. I’ve been using it tethered to mains at my desk, and had to leave it to go to various meetings, resulting in the noticeable breaks. The additional commas also cause a few breaks. But it’s really pretty cool in terms of how it works. I’m suitably impressed.

As you can see from the picture, there’s a lot of data up there. And it’s all very useful. The mouseover on the various pill boxes give you a huge amount of information in relation to the decisions that oref0 has made.

I still need to fix my “Comma bug”, although I think the guys on Stackoverflow may have done that for me, which will be great.

In terms of an OpenAPS set-up, it’s very cool to have a mobile system monitoring what’s going on in the background and adjusting things constantly. I’ve found it does a magnificent job of keeping glucose levels really flat, with less involvement from me. As I’ve said before, Scott, Dana and Ben have done a great job here.

Another little tip is to get your hands on an SSH client for whatever phone you use. I run my “OpenAPS network” phone separately from my everyday phone, but when things don’t seem to be working quite right, it’s reassuring to be able to open up the terminal and connect across to the Pi to just check it out. Very reassuring indeed.

What’s not so hot about this set-up?

Let’s be honest, there’s a very good reason why I don’t think anyone else has done this. While the quality of the glucose value data from the new Guardian 2 updated transmitter is easily good enough (and the next gen with the 670G is supposedly even better), the elephant in the room is the comms between the pump, the transmitter and the Contour NextLink stick.

Unfortunately, when the bluetooth signals overlap, the connection drops. and takes a while to recover. I know that Lennart has fixed this on the Android version and I hope he can do the same for the Python. If not, I’ll have a go!

The other thing I see quite frequently is that the CNL stick seems to misbehave quite frequently. I’m not entirely sure why that is, but it can be frustrating.

Finally, I hadn’t realised that when the pump needs calibration, it puts out a glucose value of 42.8mmol/l alongside a status of “Calibrating”. As I put the calibration in snooze, OpenAPS was reacting to the rather high values. That caused a monumental hypo two hours later on… Still, you live and learn. I need to modify my data extract script to account for this!

Finally there’s still the carelink stick. I’ve a Slice of Radio card to add to the Pi to try and take that out of the loop (pun intended), but that’s a little more work that I’ve yet to do.

So far, after not a lot of time in operation, I’m very happy with what I’ve got. It’s brilliant. I don’t say that a lot!

But what’s next?

I’m rather in two minds. I like OpenAPS. A lot. it does what I want and it has the features I want. But my rig is not a small one. And the question is how to make it more portable?

Amongst the stuff I’ve got my hands on, there’s a RileyLink and I use an iPhone. The obvious answer is therefore to migrate to “Loop”. Another open source algorithm that’s slightly different to oref0, and runs on the iPhone, using the Dexcom G5 for it’s glucose values. That means an outlay for the G5 transmitter (and most likely a receiver).

Here we are then. Successfully looping, and loving it.