***UPDATED 8th February 2017 to include portability options from OpenAPS with Edison and Explorer board***
Okay, you’ve looked at the looping options, and you know that there are three out there. OpenAPS, Loop and AndroidAPS. You’ve probably also read the getting started guide on here. It goes into the pros and cons to some level but what if you want a more detailed look? Well I’ve created a little table here that describes the pros and cons.
So let’s get started…
That’s the high level view of the options. For me personally, the balance is between Loop and OpenAPS as I can’t get hold of a Dana-R or supplies, although the Dana is perhaps the easiest to link directly to a phone.
Whilst not wanting to ignore AndroidAPS, I will do for now. Once the Medtronic drivers are available for HAPP, then I’ll include that into this round up to. So on to Loop and OpenAPS.
The RileyLink as the only item you have to carry makes it very portable portable, as you are simply carrying your iPhone and the tiny wee box.
Combine that with the Dexcom G5 integration, and you’ve got something that works regardless of whether you have a network connection and that is compact and easy to use. For offline use, it can also use Medtronic CGM on compatible pumps (according to the documentation that’s working with the x15, x23 and x54 models) and Dexcom’s G4 with Share, although, if you are in Europe, that’s quite a faff to set up due to share only being a US feature. That Loop allows you to bolus as well is great, but for me isn’t a killer feature of the app. The user interface that Nate created in Loop is very nice, and a real bonus for using the software.
The downside of Loop is the carb absorption models. It uses the Scheiner curves to calculate the carb absorption and then has a feature called Retrospective Correction which looks at the prediction versus the actual looking at what happens with a decay over 60 mins. It’s okay, but the carb absorption models take some getting right and can be quite hit or miss. It also means that if you don’t have your Duration of Insulin Action (DIA) quite right, it can really mess up the algorithm. As a result, you spend the first week or so on Loop working out how these things interact in order to “tune” it to best fit you. This also includes, potentially, changing the install on the phone to better fit with your settings.
But it’s also worth being aware that if you’re an iPhone user but not a Mac user, Loop is going to be a bit more difficult to setup. You need to have a Mac or access to OSX/MacOS to build it and put it on to your iPhone, and you need to keep rebuilding it every 90 days. So it’s not simple as Pi to deploy.
The other key aspect of Loop is the framework within which it is built, Loopkit. This has the tools that would allow someone to build their own algorithm using Loopkit terms and structures and deploy it on to the iPhone.
OpenAPS provides a framework and toolkit to run, currently, on pretty much any UNIX environment. As a result it doesn’t run on a phone. The two most popular platforms are the Raspberry Pi and the Intel Edison, and with the new Explorer board, it is about the same size as the RileyLink. So, in terms of portability, we’re talking similarly portable to Loop.
The other aspect with OpenAPS is the sensor glucose data. In the original form, this is obtained by connecting the receiver or pump to the openAPS hardware, for off-line use. Given the plethora of options for obtaining glucose data, including xDrip, Dexcom G5 without a receiver, Medtronic Veo and 640G connections and others, there are now plenty of options:
- A connection to the web so you can pull data from NightScout online
- Using the xdrip cgm option in the set-up scripts that allows xDrip or xDrip+ to provide data directly to the OpenAPS device via a bluetooth connection.
As I use a G5 without a receiver, I’m taking this second option. This way I can operate offline and capture all the data, as well as mostly control the device locally (Temp targets don’t yet work, but it’s a feature that I’m sure can be added).
OpenAPS is now just as portable as Loop, and although the integration options are slightly trickier for offline use, it’s not that hard and many people are using it.
The real killer (for me anyway) is the oref0 algorithm, due to the way it handles carb absorption and the Autosens and Advanced Meal Assist (AMA) function. Its carb absorption model works out the rate at which carbs are being absorbed based on the BG rise seen and the ISF and IC ratios and then calculates a temp basal accordingly. The full details are here. In use, this, combined with the Advanced Meal Assist is far more effective than the static and unvarying models used in Loop and seems to manage a lot better, as well as being a lot quicker to get going with.
Talking of AMA, what is it and what does it do? Basically, it determines when you’ve eaten and gives you additional TBRs to cover it. And does it very well. The link earlier discusses the algorithm that’s in use there, and even if you don’t remember to bolus, the system does an impressive job of trying to cover you, taking into account the issues with insulin action time of current insulins.
The final point, Autosens, determines whether your ISF has changed on a day to day basis, and adjusts dosing accordingly. This is obviously really handy when you’re unwell, and is something I found worked very well in that scenario.
Setting up and using OpenAPS doesn’t require you to have a Mac. You can do it all via Putty from a Windows PC. This may be a very significant reason why you might build OpenAPS over Loop. It’s simply more accessible in this respect. It also has some neat set-up scripts that make it very easy to get up and running quickly.
For interacting with OpenAPS you use two methods. Your pump, which the software picks up and uses for calculation, and NightScout. The main difference compared to Loop is that you bolus using the pump’s bolus commands. But you can set temporary targets and tell it about carbs from NightScout, so there’s a pseudo GUI available.
So the reason you might opt for OpenAPS over Loop would be functionality and ease of access to tools for deployment. The functional aspects of it, are in my book, much better.
If you want a detailed review of the algorithms present in the two systems, that can be found here.
So which are you using?
Ultimately, it has to be about ability to use it, and as my data is collected via Dexcom G5, my everyday phone is an iPhone and I don’t want to carry too much extra stuff, I use Loop. Even though I miss oref0. That’s the long and short of it really. It’s the portability and integration that have beaten functionality for me. That’s not to say that when I’ve got the explorer board when it comes out that I won’t build an OpenAPS with local NightScout and run xDrip for G5 to have a properly portable OpenAPS instance, as that’s very likely if we haven’t got oref0 onto Loopkit at that point.
Whilst I had used Loop for portability reasons until the Explorer boards became available, since it is now here, and a very small package, my preference for the Dynamic Carb Absorption model in OpenAPS means I use this constantly.
So, while the choice seems stark, it isn’t really. That there’s choice at all is incredible, when you consider where we were two years ago. That the choice is between two great options that simply offer different things is just where we are. And the gap isn’t too far from closing. Roll it on, as #wearenotwaiting!