AndroidAPS and Open Looping on an Omnipod

So anyways… There had been a bit of chatter on FU about how a few of us want a pump that calculates IOB based on both bolus and basal insulin.

I use xdrip+ to capture my CGM data and I use Nightscout for reporting (I use a Dexcom G5 transmitter, a Sony SW3 watch as the collector, and a Samsung Galaxy S5 phone). xdrip+ does a great job of tracking IOB for boluses and doing BG predictions based on carbs on board; however, it does not take into account either temporary basals or extended bolus - both of which I use. I recently started to use a lot more temp basals for putting the brakes on a downward trend that will end in a low (or at least end in glucose tab consumption) or to stop an upwards trend that will result in a high. xdrip+ also does not have an insulin curves for Fiasp, so since my switch to Fiasp, the prediction does not work as well.

I figured that the openAPS systems would calculate some sort of total IOB, so I installed AndroidAPS to see if if would give me the IOB information I was looking for. I picked Android APS because it runs directly on an Android phone, does not require a “rig” or extra hardware to run, and directly can get the CGM data from xdrip+. Pretty much install the software and play with it - my kind of easy (ok you do have to compile the APK but the instructions are pretty easy to follow on the GitHub site.).

Sure enough, AndroidAPS keeps track of IOB in an intelligent way. You can see in the picture below IOB is made up of a bolus IOB (including extended boluses) and a basal IOB. For example (1.98 bolus/ 0.05 basal) in the picture below. Basal can be positive or negative based on your standard basal profile. Estimated carbs on board (COB) are also tracked. OpenAPS also logs all the temp basals and extended bolus to Nightscout for record keeping. Android APS also has Fiasp curves that I can use.


The purple line to the right of the green BG line are the predictions of BG based on IOB and carbs on board. There are three predicted lines because the algorithm takes into account that carb absorption is not an exact science and uses three models of carb absorption speed to calculate

After having negative thoughts about positive and negative basals I realized that I actually like it. It helps understand how much you deviate from the normal and you know if you are going for a run or something that you want negative IOB of a certain amount at the start a run.

AndriodAPS runs the openAPS oref0 algorithm and was designed to control a Sooil Dana R pump. The algorithm issues both positive and negative temp basal rates to the pump control to the target BG. It can also work with a “Virtual Pump” with the user doing the “temp basals” when reminded. There is also an MDI option (it even has curves for long acting insulin).

After joining the AndroidAPS Facebook group, I noticed that some people were “open looping” with Omnipods. At first I thought - these folks are nuts. There is no way that I would manually enter basal rates on my Omnipod controller a million times a day but then I though - hey may as well give it a shot (no pun intended) - I will try for a couple of days to see if I can learn anything.

So I have been using it for a few days. Here are the messages that show up on my watch to change the temp basals. I then go in and tweak the basal rates on my Omnipod controller.


Here is a yesterday of data - with a couple of examples.

For Event #1 - I did not bolus correctly for a piece of pie covered with whipping cream. It was a wild guess. I knew temp basals were not going to do it, so I did a couple of boluses. I knew that I gave too much insulin, but there was a recommendation to turn off the basal. This lead to a pretty nice landing without going low.

For Event 2 - I really need to change my morning IC ratio as I gave too much insulin, but again, the recommendation to cut back on the insulin worked and I was at an ok place for lunch.

This is an ongoing experiment. Here are my feelings so far:

  1. I love being able to look at the total IOB. Seeing the total IOB has made me realize that I probably need to tweak my basal rates in a few places of the day where I do not feel like doing basal testing. In the first couple of days I significantly changed my basals for the better - moved more insulin to basal from the bolus. It just gives a better view of what is going which helps me learn.

  2. The openAPS algorithm is pretty cool. It was mentioned on another thread that there is a new oref1 algorithm that is better than the oref0 I have been playing with. It has been fun to try the openAPS algorithm out without having to buy any hardware. I just had to install some software on my phone.

  3. I hate that the pod beeps every time I cancel a temp basal - this is annoying. Does anyone know if you can turn if off?

  4. Open loop control is not optimal but it is ok to do for a short while. In a way it is like sugar surfing where you have to pay attention to the BGs throughout the day and make corrections. I do ignore the temp basal suggestions when I am in meetings etc. as I do not want to be fiddling with my phone. I also do not wake up to adjust basals, but will adjust them if/when I am awake. It still works ok if you ignore it but would likely be better if you did ever command.

  5. When I sugar surf, I usually get impatient and go big with my correction boluses and often land with a glucose tab or two. I find that the AndroidAPS algorithm is more rational and does not overcorrect for me (yet).

So I have seen the future and I want to get this loop closed with the Omnipod. As you may know, people are looking into this but progress is slow.

As a final thought - you probably can think of a bunch of problems with this arrangement that I will probably agree with (examples: How does AndriodAPS know exactly how much basal was given during that temp basal? It does not communicate with the pump - or - Insulin absorbtion curves are not accurate… etc.). But I see it the other way - If I can get 90% of the way there it is still better than nothing :slight_smile:


@Aaron, this is a fabulous and innovative post, thanks so much for posting it!

It will take me several days to go through it in depth and understand thoroughly all your thoughts.

@Michel It is a bit long and jumbled. Feel free to ask questions.

Aaron, so if I understand it, Open Looping is using a software solution (on your phone) to keep track of Carb-On-Board as well as Insulin-On-Board (including basal) and reacting to the software’s predictions by adjusting your basals to keep better control. Is that an adequate description?

How do the temp basals get into the software, manual entry?

1 Like

@Aaron Thanks for the terrific writeup!

Does AndroidAPS read directly from xDrip+, or is it required to upload to Nightscout? If so can NightWatch be used as an intermediary?

I looked briefly at autotune yesterday using one of your posts as a jumping off point. Although I like the concept, it left my head spinning.

I would like to use this concept with MDI, but I’m not too keen on setting up a Nightscout site and uploading.

1 Like

Great article. Thanks for taking the time to write it! Got this post bookmarked. Before your explanation, I had no idea what “Open Looping” meant…and I was trying to connect it somehow to the “closed-loop” systems (Artificial Pancreas systems.)

1 Like

@Chris - I would say in a closed loop system, the software automatically sends the temporary basal commands to the pump. In open looping - the user gets a suggestion of what the temporary basal should be and manually enters it if they want to.

So basically -

  1. Software suggests a temp basal.
  2. User enters the temp basal in the pump.
  3. User clicks “confirm” on the software to accept the suggestion. Then the temp basal is recorded.

EDIT: AndroidAPS can also be used to log temp basals and track IOB without making temp basal suggestions.

@docslotnick - No Nightscout is required. Android APS reads directly from xDrip+ and you can keep a “local profile” on your phone. If I enter treatments in AndroidAPS they show up in xdrip+ through nightscout.

@claudendaye - Open looping uses the same algorithm as the closed-loop systems, except the user does all the work to get the commands into the pump :frowning: …baby steps to APS (artificial pancreas systems).


So it reads only glucose values from xDrip+, not treatments?

I am not sure.

I expect it only gets glucose from xdrip but there is a setting you can enable in AndroidAPS to send data directly to xdrip.

Why don’t you install it and try it out😀

How accurate do you think the basal on board is? For example, if you turn off basal at noon, and there is no bolus IOB, how long before it shows you at zero? Is it like 4 hours or whatever your duration is set for?

And does the decline use a non-linear formula?

I made a spreadsheet that calculates if for me. I was able to make my own formulas that calculate the amount of insulin as it degrades over the course of my duration, which is not linear.

It looks like this:


1 Like

@Aaron thanks for the fantastic post about using AndroidAPS open loop. That’s a great way to get a taste of closed-loop operation!

Yes it does - all DIY systems (OpenAPS, AndroidAPS, and Loop) now include accurate nonlinear insulin activity curves based on published data for ultra-rapid insulins, and for Fiasp.


@Eric, I am surprised by your spreadsheet: possibly I don’t understand it?

For instance, I am surprised that, in the first hour where you start a 0.55 basal rate, you would already expect 0.28 insulin delivered, i.e. 51% delivery in the first hour. And I would expect the insulin delivered to be cumulative after the first hour, so I would have thought a peak would build, then stabilize to 0.55.

I originally thought I understood your last column, but now I am unclear about exactly what it means.

I may be hijacking this thread – may need to split…


Same here. If you could explain your math a little it would be helpful for me.

1 Like

Good question, and very observant of you!

My spreadsheet is setup for an entire day, but just for the sake of simplicity I did not show the entire 24 hours in what I pasted in.

So the part you are seeing, the part I pasted into the thread for example at 4:30 pm, is not showing the delivery that happened for the previous 4 hours.

So the calculation for “Active Insulin this 1/2 hour”, also has stuff from 12:30-4:30 that has been calculated in there. But it isn’t displayed in my screen shot because putting in the whole 24 hours would have been a bit unwieldy. Does that make sense?

My formula for each 30 minutes is still something I am playing with. I have it setup so I can adjust the delivery % calculation, for different insulins or whatever. Or for different people. You can just plug in your own numbers.

Here is what mine is currently set at. But again, still playing with these numbers:
(these are not cumulative %'s, just the individual 30 minute segments)


1 Like

I would really like to install it, but when I went over to the files on guthub I could find no instructions on what to do with them.

Any suggestions?

1 Like

@docslotnick did you ever get round to installing AndroidAPS and running it in Open Loop?

@Aaron thank you for writing this post. I read it a few weeks ago when I was considering which system to go with and your experience helped me decide on AndroidAPS.


I tried, but it didn’t really make sense to me because I’m on MDI. I’ve never used a pump, but that’s a whole different story.

@sanfran I notice I posted this about 5 months ago.

As an update - I am still using AndroidAPS open loop with the Omnipod.

I have the BG range set fairly wide (target is 100) so I am not bombarded with basal recommendations.

The three reasons why I still use it:

  1. IOB calculations that include the basal.
  2. Early Alerts - the basal recommendations basically alert you to take an action when your BG still looks ok. This is way before you every would get a hi/low alarm on an CGM.
  3. Helps be turn the basal off at the right time to prevent lows after a too big bolus for a meal or an correction bolus that was too much.

@Aaron, how do you get the predictive curves to appear in the AndroidAPS GUI?