Port and Portability – some further thoughts. A truly portable, offline instance of #OpenAPS

Port and Portability – part two. A truly portable, offline, wireless instance of #OpenAPS
Port and Portability – part two. A truly portable, offline, wireless instance of #OpenAPS

Late last year, I wrote about form and physicality of the hybrid closed loop, bemoaning the stuff I was carrying, and a few other things. My shopping list of likes was:

  • A delivery device and remote control
  • The remote control to be an app on a phone.
  • Interact with the system from my phone
  • Upload the data real time to my choice of service provider.
  • An APS Algo App Store, where I can select the algorithm I’d like to use and deploy it to my phone or the cloud

In my further building out of my OpenAPS rigs, I’ve managed to address a fair number of these, to come up with what I like to call my “Two Box Rig”.

What’s that then? Well, it’s taking everything that I need the OpenAPS system to do, and sticking it into a single box, and having it run alongside the pump. And it looks a little something like this:

That’s an OpenAPS Edison rig running on the Explorer Board (available here) with a Wireless Charging receiver attached, and the 722 pump, providing Medtronic Enlite CGM capabilities and obviously insulin delivery. As a result, it is a self contained rig that doesn’t need a network connection in order to do anything. It’s useful to have for monitoring, but even that can be overcome with the Pancreabble tool, which will talk locally to a Pebble watch, or you can use the pump itself, as it will tell you the current TBR, how long it’s run and the CGM data.

So a true offline, portable device. The ideal go-to rig. How does it match off against the list above? Well dependent on what you install, i.e. if you put nightscout on the Edison rig, then it can achieve points 1-4. Number 5? We’re a bit of a way from yet, but that’s one thing that’s less of an issue.

And if you don’t like the Medtronic Enlites for your CGM, well, we might have a solution for you there too. xDripAPS. A local database on the rig that collects the data from the xDrip or xDrip+ app.  It may require you to change from an iPhone to an Android phone, but with a Dexcom G5 and an app, you can have xDrip upload to NightScout via the Mongo API and also send to your rig, via the REST API, and no extra boxes. This is currently available in the Dev branch of the OpenAPS/oref0, and is straightforward to set up, although you have to remember not to use https when you set up the REST API details. So far, all I’ve only had this working via a Wi-Fi connection, but technically, it should be possible to do so over bluetooth.

Yup, you can have Dexcom feeding your rig offline too. It works very nicely, and if you use xDrip instead of the Dexcom app, as long as it receives the data, it uploads it to NightScout, and will complete missing entries when you lose connectivity, which the Dexcom native app doesn’t do.

If you’re using G4, you’d need the xDrip Wireless Bridge as well.

What does that give you? Fully offline looping, in a very small form factor, which is ideal. It’s what I felt I wanted when I started on this journey.  The only real outstanding point is the control system.

For the most part it is run through the pump for carb entry and insulin dosing, and when using Pancreabble on your pebble, you have real time data. If you use the xDrip approach, you have a decent sized visual glucose graph as well.

I think the next step is likely to be installing the local NightScout instance on the Explorer rig so that I have a full control system running locally. Then it’s practically perfect.

So, where are we? Well here we have a truly portable system that doesn’t care whether it’s connected. It does everything I need to and provides me full time looping wherever I am. That, for me, is a great step forward. Whilst I had the same with Loop, I didn’t have the power of Autosens and Advanced Meal Assist, which I find make a huge difference to my use of this technology.

So, it’s further small steps forward and more portability. This is why I wanted the Explorer board and Edison. And I’m very pleased that I have taken that step!

5 Comments

  1. Very nice development / updates here!

    I’m actually fine with having it work over Wi-Fi only as I don’t want to rely on another thing potentially having BT issues.

    Love that it will send the data STILL to NS and also into your OpenAPS rig…looks like sqlite becomes the datastore for the data!

    Thanks for the heads up on all this!

  2. We are using G4 with xDrip right now (over BT) to pull data from the G4 receiver…so in that case, we shouldn’t NEED the xDrip Bridge (using a Wixel) since we have BG numbers straight in the xDrip app, correct?

    • If you’re using G4 I don’t see a way around using the Wixel bridge, as I wasn’t aware that the G4 could be used directly with a phone and the xDrip app.

      The G5 works without the wixel bridge because it’s Bluetooth.

        • I’m not sure, to be fair, as I have no experience of Share.

          I think you need to the BLEShareable code, which I know has caused a few people issues. Still, worth investigating.

          What I like about the G5 with xDrip and MDT approaches is that I don’t need an additional box of some description. Either the pump or my phone becomes the receiver and I’m therefore good to go.

Leave a Reply

Your email address will not be published.


*