Monday, 14 September 2015

Predicting raw Dexcom values. Part 1

I've been playing around with the "raw" values that can be extracted from the Dexcom G4 sensor. The xDrip android app saves the values to a database which can be exported and inspected. The raw and calculated values are saved, together with all the blood glucose calibration values. To get a better idea of what I'm talking about, have a look at the graph below. The red shows the raw values and the green shows the calibrated calculated glucose values. The blue dots are blood glucose calibration points (This is where I manually checked my blood glucose with a finger prick). Also, remember that glucose measured from interstitial fluid lags behind blood glucose with about 5-15 minutes. It can be seen in the graph at several locations where the blue dot shows a risen glucose level before the graph does.
The current calibration algorithm in xDrip simply fits a y=mx+c line through the calibration points. There is also an age adjusted raw value that is used instead of the standard raw which somehow improves the accuracy slightly. I'm still trying out different calibration algorithms and will report on them at some stage. 
There is also a prediction algorithm currently implemented in xDrip that will show you the predicted glucose value while you wait for the next Dexcom packet to appear. The algorithm simply fits a y=ax^2+bx+c parabola to the latest 3 readings. When predicting more than 7 minutes ahead, the predicted value stays fixed. The parabola can quickly shoot off to a very low or high value, therefore the prediction is limited to a maximum of 7 minutes ahead. The prediction algorithm can be seen in action in the animated graph below. The red line shows the raw values, the green shows the predicted value 5,10,15 and 20 minutes ahead. The animation cycles through 5-20 minutes prediction time. The perfect prediction algorithm should show the red graph in green just shifted to the left 5-20 minutes.

Why is it useful to predict 5-20 minutes ahead?
  • Interstitial fluid lags behind, predicting ahead might help reducing the latency.
  • Knowing what the near future values will be, can improve the accuracy of a calibration algorithm. Especially when the user is trying to calibrate when the glucose levels is falling or rising rapidly.
  • Closing the loop. Artificial Pancreas might find it useful to know what is going to happen in order to inject insulin or glucagon at the right time. 
  • Alerting the user of an incoming low or high before it happens.
I used a basic neural network, nothing fancy, in order to try and predict raw values more accurately than the parabola method. The data was split into 80% training data and 20% testing data. The latest 50 minutes of raw data is provided as the input to the network and the output is the predicted raw value 5,10,15 and 20 minutes ahead. If there was any missing values within the 50 minutes, a fifth order polynomial is fitted to the available values and missing values are estimated by using the polynomial. The animated prediction results can be seen in the image below:
The mean absolute error for the described methods on the testing set can be seen in the table below:
5 minutes 10 minutes 15 minutes 20 minutes
Parabola 4.09 7.03 9.59 12.21
Neural Net 2.55 5.17 8.05 10.41

It does not make sense to predict further ahead unless information such as insulin and carb intake is available. I have more advanced algorithms that will hopefully help improving prediction and calibration in the future. Stay tuned for Part 2.

Moving on to sensor 3 and the backup Tic-Tac xBridge2

I'm already on sensor number 3. Sensor 1 lasted 30 days, Sensor 2 lasted 19 days and I'm currently on day 9 with Sensor 3. When you live with T1D, everyday is a different day and certainly a gift. You don't know how the day will go, the best approach is to take it day by day because everyday comes with it's own challenges. The day on the left was a good day, my glucose stayed amazingly good between my target range (except for a "short" low period shown in red). The day on the right looks like a typical day, lots of ups and downs with a bad high at the end. My 2nd sensor started to show a lot of noise at day 18 which can be seen in one of the images. Surely, time to put on a new sensor when you see stuff like that going on.

I wanted to have a backup xbridge device and I finally got hold of another wixel. Unfortunately, the wixel was already assembled with the header pins on... in order to fit everything into a tic tac box, the pins had to be removed. It caused me a bit of a headache because I'm not a soldering / electronics expert. The easiest way I found to remove the pins was to first cut off all the headers with a wire cutter and then try to de-solder the pins I wanted to use. Placing the tip of the soldering iron on a pin and then pushing the pin out with a needle seemed to work nicely. I followed the plan for the xBridge2 which can be found in the apps/xBridge2 folder from this repository: The xBridge2 differs from the first version in the following ways:

  • Requires you to solder 1 extra wire between the BLE module and wixel.
  • Transmits the message between the bridge and xDrip app in binary instead of text.
  • Powers down the BLE module while waiting for the next packet to arrive, saving you precious battery power.
I will be using the xBridge2 as a backup and development device while adding new features to the xDrip android application.