Pages

Tuesday 17 November 2015

Nightscout on the 640g: First Details

First, thanks to everyone who's been in touch after my post about getting the first Medtronic 640g connected to Nightscout. It's been humbling to read some of these messages and also nice to hear that it's given other 640g users - particularly those with small children - hope.

To give hope for other 640g users was exactly my intention with the post the other day. 
It can be done. It has been done.

Calm after the storm. BG and SG data - nice line, except for sensor compression...

Let's get some important bits out of the way
I am going to outline how I've pulled together this concept. I prefer to badge it as a "Proof of Principle", "First Step", "Alpha Release". You get the picture. It's clunky and it wobbles every now and then (it does rely on CareLink after all ;-) ). Therefore, I am certainly not recommending you go ahead and try this at home. I am saying this is a positive start - well, I think so. 

I'm a Medical Physicist - I solve scientific problems for a living, including writing clinical software solutions where no commercial software exists (oh, that sounds familiar...). I've had great fun over the years dreaming up and coding novel dose planning systems for internal radiation therapies, building simulations of clinical gamma and x-ray imaging systems to see how they cope at extremes and generally trying to enable the clinical work to get done as quickly and safely as possible. I am not a Software Developer or Computer Scientist*. Most of the day-job coding is in IDL - the Interactive Data Language - VB or occasionally Matlab. I'm not particularly familiar with Python, less so with Java or USB I/O.

*One of the academic computer scientists I've worked with on a few research projects was gracious enough to say that I "do a pretty good impression of being a computer scientist," which was lovely, but I've not let that go to my head ;-)

Because of all of the above I'm not going to put up online each and every line of the rough-n-ready code that's currently flung together to get this working. A robust (and hopefully more flexible) solution will emerge for sharing. I'm talking to the NS devs about the best way to tie this back in to NS if possible.

What is set out below is pretty dry if you're not at all tech-minded... If you'd rather just get a feel for what it's given us, here's a grab from Sunday night, after a weekend of general household illness, a set failure, possibly a growth spurt (again) and on the back of a recent run of dodgy Enlites (fingers crossed, the first of the new batch is doing fine!).  


We have access to the numbers literally at a glance and peace of mind (when it's available), enabling us to, I think, better manage Janki's T1D (particularly when we're both feeling unwell on top of everything). This is what Nightscout on our 640g gives us within the home.

Another pause before we dive in
We went on to the 640g in February. As mentioned in previous posts, my understanding is that (currently) the radio data-stack is not well defined or known, plus it is also encrypted. 

With a group of interested users, parents and developers sprinkled around the world, it appeared that things had stalled. There are some very clever people interested and involved - getting their brains and know-how and all the 640g kit (a pump, a Guardian 2 Link transmitter and a Bayer Contour Next Link 2.4 meter) physically together in one place has been a challenge.

The more I read and the more I saw about Nightscout, particularly the huge expansion in it's capabilities with the Funnel Cake release, the more I knew this was something I had to unlock for the 640g, particularly for classroom and overnight use.

As our four year daughter relies on her 640g insulin pump 24/7 and without a spare 640g system to test, it goes without saying that it was essential that whatever solution I came up with didn't put her (or her pump) in harms way.

Currently, the only tried and tested way of getting data out of a 640g is via CareLink. And so that's the path I've taken for this first step.

Setup Nightscout

Aim: Get our Nightscout website and associated database working

Solution: Carefully follow all the instructions set out in the setup wiki hosted by Nightscout here.

A Little More:-
By the end of the setup process, we have the following up and running
  • Mongo DB, with a unique DB name, user and password set
  • Github to fork the main Nightscout CGM Remote Monitor
  • Azure website account and website setup, including:
    • Linked to Github fork of CGM Remote Monitor
    • Correct connection strings, which must include the following names:
      • mongo
      • mongo_collection
      • API_SECRET
      • enable [for the plugins]
I didn't enter the Dexcom settings. Neither did I enable the Medtronic Connect plugin (although I'm very excited to see this being developed by Mark Wilson as I can see us using some / all of this in the months ahead!)

Nightscout (as we'll see later) expects to see glucose readings from a Dexcom G4 in mg/dL, not mmol/L so I opted to change my CareLink settings accordingly. No doubt I'll forget to change them back before the next clinic visit ;-)

Pump to CareLink -- CareLink to PC
Aim: To automatically deal with the CareLink website to request a regular data upload from the pump and then download a CSV report

Solution: Windows (7,8 or 10), Firefox, Selenium and a command line mouse clicker

A Little More:-
Firefox (along with the Firebug development tool-set) meets the requirements for CareLink uploading with its Java plugin. 

I always log in manually once a day to check all is well in CareLink Land.

The Selenium IDE enables website interactions to be recorded in a macro-like language. These instructions can then be exported to Java or Python, for example.

However, it (doesn't appear to) cope with interaction within the Java plugin used by CareLink for uploading data... Hence in the middle of the script to interact with the the CareLink site, I call a command-line based mouse clicker with a predetermined click location based on the 'Final' button location. Low tech I know (and not very robust in theory) but it works...

My script looks along these lines:-
# Goto the CareLink website (the European version in my case)
self.selenium = selenium("localhost", 4444, "*chrome", "https://carelink.minimed.eu/")

# Step along to the patient login page and pass over your username and password details for CL
sel.open("/patient/entry.jsp?bhcp=1")
sel.type("id=j_username", "YOUR_USERNAME")
sel.type("id=j_password", "YOUR_PASSWORD")
sel.click("id=loginButton")

# Once that's loaded, move to the upload page
sel.click("link=Upload Data from My Device")

# Twiddle electronic thumbs for say 30-60 seconds once Java sorts itself out
time.sleep(60)

# At this point go call your mouse clicker to left click over the Finish button

# Twiddle electronic thumbs again say for 60 seconds to allow for upload to complete
time.sleep(60)

# Now move to reports page and select CSV file download (#11)
# By default you'll get today's report (if your upload worked)
sel.click("id=toReports")
sel.click("link=Data Export (CSV)")
sel.click("css=#reportPicker11 > span.reportNav_right > #reportNav_button")

So at this point we should have downloaded the latest CSV report file from CareLink.
I do some housekeeping at this stage to make life easier later, renaming the latest file. 
In a batch file it'd look something like this:

FOR /F "delims=|" %%I IN ('DIR %DownPath%"\*.csv" /B /O:D') DO SET NewestCSV=%%I
MOVE %DownPath%\%NewestCSV% %DataPath%\%NewestCSV%
COPY %DataPath%\%NewestCSV% %DataPath%"\latest640g.csv"


Local CSV File to NightScout
Aim: Get the local CSV file, with the Sensor Glucose values, up to Nightscout

Solution: Modify Ben West's mmcsv routines; run within simple bash script using API to upload

A Little More:
Well, it turns out Ben West has already done much of ground work with some code looking at extracting details from this file and packaging them up in the JSON format Nightscout is expecting. Thank you Ben! 

His mmcsv repository has some fantastic routines scattered around, including fetch.js, that could be used to retrieve the CSV file (but not upload the pump data).

In terms of parsing the CSV data, I looked at the /lib sub-directory and the JavaScript files in the parser folder.

There are some small changes in the 640g CSV file compared to what I've seen from a Veo (ie a 530g). Fortunately the general column structure has not changed, but these tweaks alone here that may trip up some of the routines as written (before the 640g of course). At this stage four main changes were required in the JavaScript routines:
  • If you're in Europe, change the default, hardwired default time format from  MM/DD/YYTHH:mm:ss to DD/MM/YYTHH:mm:ss in /lib/utils.js, to reflect the EU CareLink format.
  • Add an Epoch date, along the lines of: function reformatDate (str) { var m = moment(str,CARELINK_TIME); return m.valueOf(); }
  • Change some of the type headings to match those expected by Nightscout
  • Change some of the pattern strings to reflect changes in the newer 640g files
As examples of the changes of type headings from Ben's code to the bits of script I run to upload our 640g data to Nightscout, I moved 'smbg' to 'mbg' (measured BG, looking for column 'BG Reading (mg/ml)') and 'cbg' to 'sgv' (sensor glucose value, looking for column 'Sensor Glucose (mg/dL)').

For each parser used I've added the epoch date (in ms) to each data packet.

As an example, here's SGV (ie one Enlite sensor 5-minute Sensor Glucose value):
{ "sgv": 100,  "type": "sgv",  "date": "1447286884000" }, ...

I run the modified code from within a bash shell script. As I'm on Windows (for CareLink), I run this within a GitHub bash shell window, which works well. Don't forget to install nodejs and update your local path accordingly. You'll also need to install mocha if you want to run the makefile and test routines.

The bash shell script is simple, running continuously looking for a suitable, new CSV file.
Once the file has been spotted (ie downloaded), I used Ben's modified JS scripts to extract the relevant data and package (in JSON) ready for Nightscout. The command is along the lines of:

./mmcsv/bin/cmd.js parse --filter=all /CSV/latest640g.csv >  /CSV/latest640g.json

I then need to get this json file (which holds each of the data packets as in the SGV example above) up to Nightscout. Whilst you could, I guess, add the records directly as Mongo DB entries, Nightscout make it easier - and safer- to do this via it's API. I use cURL to do this:

curl -vs -X POST --header "Content-Type: application/json" --header "Accept: application/json" --header "api-secret:HASH_API_SECRET" --data-binary @latest640g.json "https://YOURWEBSITE.azurewebsites.net/api/v1/entries"

NB HASH_API_SECRET is the sha1 hash of your API-SECRET, set during setup. You can use a number of online converters to do this for you (Sha1-online for example).
All being well, our SG - and any other data I've packaged accordingly will be safely and securely delivered up to our Nightscout website :-)
SG only on this one


Important Limitations
As mentioned in my first post on 640g Nightscout, it is important to remember that this is:
  • Automated for (up to a day currently) transfer of 640g CGM data into Nightscout
  • Potentially a candidate for monitoring inside the home or school classroom environment
BUT it is not:
  • Ready for prime time: this is at Proof of Principle development stage
  • Fully mobile: it is not currently as mobile as an xdrip / Dexcom receiver solution. In theory this solution would run on a small Windows 8/10 tablet.
  • Instantaneous: there is a 5-10 minute delay on SG data with the current setup
Please remember, this setup is completely reliant on the Medtronic CareLink service and its servers as well as connectivity to Nightscout:
  • I need to be able to get reliable data access to CareLink. There is no 'camping mode' fallback to avoid the need for a network connection.
  • I need to be able to take the data-hit of a 0.2-3Mb of a day's CSV file coming across my network every, say 5-10 minutes (not likely important on WiFi, but a consideration if I hook this up via 3G/4G).
  • Pump data transfers are limited in an identical way to the usual CareLink upload:
    • The transfer will fail if the pump is "busy" i.e.
      • Temp basal ongoing
      • Dual / square wave bolus ongoing

The Future
There's a ton of interesting and useful data inside each CSV file. I've used it extensively across this blog to look at how the 640g might be calibrating its Enlite Sensor Glucose readings, how SmartGuard might work (in terms of risk management) and how those pesky sensor errors pop up. Over the coming weeks I hope much of that can be transferred over to Nightscout.

I'm posting this to show other 640g users that there's NS hope, not to claim a final, polished solution exists. I'm sure there is a better way and that way will be found and developed. But I hope this represents a solid start on the journey to bringing full NS functionality to the Medtronic 640g.

None of this would be possible without the former and current Nightscout developers and the "support" team that drive CGM in the Cloud. To all of you, thank-you.

As ever, feel free to post a comment below, on Facebook or on Twitter :-)

Update: If you've landed here looking for Nightscout on your 600-series pump, thanks for stopping by :) The simplest way to get your pump on to Nightscout is to use the 600-series Android Uploader. Enjoy!

4 comments:

  1. Baffling but wonderful, just wonderful to see what you've achieved, wonderful to see you credit the stuff you've nabbed from elsewhere, wonderful that you've got Nightscout going so I no longer feel guilty talking about it with you :)

    ReplyDelete
    Replies
    1. ha ha, I don't think I've nodded off during your NS videos Kev :-) Sorry for the baffling stuff - had several requests from devs to show how it was done, hence this post. And it's absolutely built on the great work of others - I hope I've not forgotten anyone over the two posts so far.

      Delete
    2. http://www.farnell.com/datasheets/1841854.pdf
      Have you seen this item? I think I may get one and have a play. What do you think?

      Delete
    3. Hi Wifisetup. Yes that should pick up the transmissions from the G2L and pump. But if they are encrypted for protection you'd need a strategy to deal with that. I may well be likely that the Bayer stick can handle that and so, personally, my focus would be on looking at the USB packets from the stick and seeing what can be done there to first remove CareLink from the equation. I know there are others with far more knowledge on the radio side over at the Nightscout for Medtronic UK FB group. We'd love to hear how you get on. Thanks, Matt

      Delete