#OpenAPS Winter 2015 update

Home  >>  OpenAPS  >>  #OpenAPS Winter 2015 update

#OpenAPS Winter 2015 update

The #OpenAPS community has made some amazing progress toward the end of this year. There are now, as of 12/31/15, (n=1)*22 people with DIY closed loops! (As of 4/28/16, it’s (n=1)*53!) And as always, several others in the testing and development phases, so this number will continue to grow.

(If you’re new to #OpenAPS, we encourage you to check out the reference design, which is now also posted in Github alongside our documentation so you can track changes as it evolves. If you’re starting to close the loop for yourself, or are thinking about it, we invite you to join the OpenAPS-dev google group, and pop over to the #intend-to-bolus channel on Gitter and introduce yourself there. This is the best place to see works in progress, ask questions and get help, or get pointed to various projects. And of course, read the publicly available documentation here to get an overview for the steps of closing the loop.)

There are several iterations and works in progress around both software and hardware to support the vision of #OpenAPS. Originally, #OpenAPS was implemented with an older version of a Medtronic pump and a Raspberry Pi and a Carelink stick. As you’ll see below, there’s been progress made communicating with other pumps; variations on hardware for how to communicate with Medtronic pumps; and iterations on software such as an improved algorithm option to better support meal times.

Hardware update:

  • One of the most frequent questions we get is “what pumps can be used with #OpenAPS?”. The answer to that question is explained here in the documentation, but there’s work in progress being made with other (non-Medtronic) pumps.
    • Notably, Marius has made progress with the RF communication protocol with the Animas Ping pump. See his Vine here showing it in action! He’s demonstrating pushing button on the pump remote so the packets are picked up by a CC1110 and the iOS app communicates over BLE to get packets which are buffered by a nRF51. (His goal is to create a custom hardware setup to enable communication from a phone to the device to the Animas Ping in order to close the loop. Here is a picture of what the demo equipment looks like.)
    • There’s also a group of folks working to do the same work to understand the OmniPod pump communications. If you’re interested in this body of work (OmniPod, Animas, or working on another pump), click here to join the Slack collaboration channel where this conversation is happening.
    • The DANA R pump is also being successfully used in some loops; although it is not documented yet, so does not show up on our official list (see our hardware docs) yet of pumps. (The DANA R is not yet FDA-approved, so it’s only available outside the US.  It also uses a proprietary battery, so keep this in mind if you are evaluating this pump for loop reasons; the frequent communication a loop requires will draw more battery than standard operations. This is true for all pumps, but AAA batteries are a little more universal than the DANA R batteries.)
  • The next question we get is “Do I have to use a Raspberry Pi and a Carelink stick?”. The answer to that is, no! You don’t have to use anything you don’t want to. Use what you can make work. Which until now…has mostly been a Raspberry Pi (or a laptop) and a Carelink stick. However, there are limitations with the Carelink stick (notably, the range (~3 feet)) and also the Pi (complaints center around power consumption and physical size). This, however, is changing:
  • What about [question about various CGMs]?
    • Some loopers are using a Medtronic CGM and incorporating the data into their loop. It’s not well documented in the docs (mostly references Dexcom G4), but multiple people are using it; same for using xDrip.
    • Dexcom G5 has been confirmed to work if you plug the receiver into the Raspberry Pi (same as Dexcom G4, with or without SHARE). (Details buried in this thread.)
    • Some oref0 implementations are set up to retrieve glucose data directly from Dexcom’s Share servers when the receiver is not plugged in to the Pi (but the Pi has Internet connectivity).  This is also not well documented yet. The same is true for pulling glucose data from Nightscout.
    • Additionally, Nate recently announced xDripG5, which will allow development of a non-Dexcom iOS app that can communicate via BLE with the G5 transmitter.  This could in the future allow a completely offline iPhone-based closed loop system using something like the RileyLink or CC1110.

Software/algorithm update:

  • We originally began with “openaps-js” as the backbone of the loop in #OpenAPS. If you haven’t checked out Github in a while, or are wondering what the code looks like, make sure you take a look at the “oref0” repository. As of the time of this post, the most recent release and master branch is oref0 version 0.1.2. This includes some cleanup / refactoring in the code; the addition of tools to make it easier to upload information to Nightscout / elsewhere for visualizations; a fix to IOB calculation; and using “expected delta” as a calculation instead of BGI/2 to improve what the system does if someone is very high when they start looping and/or if they are riding flat and high over a period of time.
  • There are some significant additions coming in the development branch of oref0. This includes what we call “meal-assist” (or in cases where you’re rising for no obvious reason, and you haven’t eaten a meal, what some are unofficially calling “wtf-assist”).
    • As noted in the reference design, #OpenAPS is not intended to replace meal boluses. Instead, #OpenAPS has a “bolus snooze” so that it would not interfere with your meal bolus, and would otherwise kick in more if needed after a time period (scaling down based on DIA/2). However, some people still wanted #OpenAPS to do more, so we’re experimenting with the meal-assist option to step in sooner if certain conditions are met (if it is alerted by using the bolus wizard on the pump that carbs are involved in a bolus). Meal-assist will kick in if there are more carbs than insulin, and based on IOB and changes in BG when more insulin is needed.
    • This is an option that people will likely have to specifically enable in their system in the future, if it makes it to the master version of oref0. It is meant to support larger meals where a person can’t do all of their meal bolus up front based on the timing of insulin absorption and carbohydrate absorption rate. It still will not replace a meal bolus (the user must still do an original meal bolus, and must enter carbs by using the pump’s bolus wizard in order to trigger the meal-assist feature), but it will help sooner if more insulin is needed over the course of carbs absorbing from a meal.
  • As these features are tested in individual branches; tested more thoroughly in our development environments; and eventually move to the master branch of oref0. We will continue to update the reference design of OpenAPS accordingly so that is is always aligned with the released version of oref0 and vice versa.

What’s next?

Two obvious areas of focus overall this year have been reducing the size/improving the portability of the hardware needed for the loop, and improving the range of devices to better and more efficiently communicate with pumps. As we head into 2016, this community will likely have dozens of other iterations and improvements in hardware, software and protocols (for example, deciding on a common BLE service so that all hardware in this community can easily be interchangeable), all in pursuit of the #WeAreNotWaiting vision of OpenAPS (an open and transparent effort to make safe and effective basic Artificial Pancreas System technology widely available, to help reduce the burden of Type 1 diabetes).

We encourage you to get involved if you are interested in closing the loop for yourself or interested in contributing to the various pieces of hardware, software, and protocol projects. Please contact us at @DanaMLewis (dana@openAPS.org) and @ScottLeibrand (scott@openAPS.org) if you have questions or ideas about how to contribute to #OpenAPS – we’d love to hear from you! (You can also follow and connect with the community on Twitter at #OpenAPS and @OpenAPS.)

4 Comments so far:

  1. Esther says:

    I heard about this on NPR. Could this be used if someone has pancreatic cancer, that is, a person could have their pancreas removed and use a mechanical one?

    • Dana Lewis says:

      Hi Esther, no. This is called an artificial pancreas but it is a system used to automate insulin delivery using existing medical devices that people with diabetes have. It does not replicate any of the other pancreatic functions, and it’s not an implanted organ or system.

  2. Bronte says:

    Hi there. I am very interested in creating my own closed loop system. I know that the closed loop system requires manual input of meal boluses, however, one thing I want to know before I start building is whether you can give these manual meal boluses via your phone (or whatever you’re reading your data on). I find it incredibly irritating to pull out my pump at meal times (when I’m wearing skirts or dresses). I know that I can currently give a remote bolus from my contour next bg monitor to my medtronic 640G but I’m worried using the older pump model I’d no longer have this option. Also, having the capability on my phone would be that much more convenient and ideally I’d like to have a bolus wizard in the same device as whatever I’m delivering my manual bolus from. To what extent does the closed loop system currently have these capabilities? Or if not would I be better to wait until the Dana R is properly documented to use in the system (I live in Australia) as I know this currently as the capabilities to deliver boluses from your phone. Many thanks and sorry for the long question!

Leave a Reply

Your email address will not be published. Required fields are marked *