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:
  • Although not in the mainstream OpenAPS docs yet, Oskar has been working on a physical setup option that will allow you to skip the Carelink stick and/or the Raspberry Pi. This setup is quite a bit smaller than the Pi/Carelink combo, and he’s got another version in progress that could be even smaller! That being said, please note that it’s a work in progress and will involve more work than simply buying a Pi and a Carelink in order to close your loop. Check out pictures and descriptions here, and the project’s Gitter channel here.
  • Also not in the mainstream docs: Andrew has put together a more compact case for the Raspberry Pi and it’s necessary components. Similar to the above project, it’s much more involved (desoldering, etc.) than the standard setup. (While he has recently closed the loop using a custom algorithm and the openaps toolkit to pull data from devices, bolusing with a pump remote as noted in his link above is not an approach that follows the OpenAPS reference design. Check out the OpenAPS reference design for more about the recommended approach of only utilizing temporary basal rates for safety reasons. Andrew has also done an excellent writeup contrasting the differences in his system.)
  • Another option we’ve mentioned before that is still a work in progress is the RileyLink, which is a custom designed Bluetooth Smart (BLE) to 916MHz module. It can be used to bridge any BLE capable smartphone to the world of 916Mhz based devices. This project is focused on talking to Medtronic insulin pumps and sensors (to replace using the Carelink stick, thus improving the range).
• 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.)