Oh, Sugar sugar....
 |
| "Winter is coming" how can they not have used that tagline? |
Mainly tech talk. but a leetle bit of running.
Telemetry
So I've been getting carried away with running telemetry, was generally happy with my GPS tracker (although I do have some ideas for switching to different underlying hardware) but I'd always thought it would be neat to have a remote view of heartrate on long runs* but I never got around to adding it although I had purchased an additional wireless module to get the ANT+ data ages ago. This has been sitting on my desk for months, although my main excuse here was because an ebay ordering oversight which meant the board that arrived was the size of a postage stamp.
*e.g. tracking HR drift can highlight issues with dehydration during extreme events.
Core
Then I happened upon the CoreTemp body temperature sensors and thought this might be a neat way to keep an eye on how things are going and spot in advance before I get into trouble (having had multiple failures from both overheating and also cold conditions in the past) so this gave the impetus to actually get on with it and enhance the old tracker which had been gathering dust from lack of racing recently, with a race in the calendar coming up it was time to add some bells and whistles.
 |
| Programming/debugging two separate, connected SoC's at the same time. |
Sugar
But this then also rekindled my interest in blood sugar tracking, after all if I can track something... why not? Would it be possible to spot fuelling issues by tracking blood sugar?
 |
| Patch me in... |
I'd looked into this topic a few years ago with the relatively new Abbott Libre2 sensors... unfortunately doing this I'd discovered they would be extremely difficult to integrate into custom systems. (I bricked several sensors experimenting, no laughing matter given the cost of them!)
But now I'd got remote heart rate and body temperature running so I thought I'd take another look. (aka waste hours and hours of free time experimenting and developing)
Libre
The Libre sensor is a bit of a faff to deal with technically, although it supplies streaming live data over Bluetooth, you can't just listen to it. The process involved is firstly a phone needs to scan the sensor with NFC to send it an "activate" command, then an hour later "after it has warmed up and calibrated" it needs another NFC scan command to "pair" sharing a secret key, it then replies with a private key. Then a bluetooth connection can be initiated using this key to "login" and then data is returned.
Additionally everyone one of these operations needs to be encrypted with a secret proprietary algorithm. Obviously none of this is open or documented.
There is an open project called xDrip+ to provide alternative glucose monitoring across devices and they had already implemented and supported the libre2. They don't provide code or details for the encryption part though, keeping this as a separate blob to (hopefully) avoid any litigation from Abbott (who have taken action against previous projects).
But at least this gave some possible options to work with so this gave two separate projects to try: 1. can the xDrip app be used, but also 2. could I talk to a sensor myself?
Both ideas were successful, although I stuck to the former for race day since it was more likely to be a more robust solution on the day.
The first course of action was to get something reliable up and running fairly quickly, so this needed to be a bit of a lashed together Heath Robinson solution:
 |
| Artists impression / detailed design document |
For this the Libre patch is activated with the official Libre software, then it's paired with xDrip app which runs on my phone, I then have an app that hooks into the notifications from xDrip and uploads them to my tracking server where it tries to merge them into the updates I'm getting from the GPS tracker (which is uploading the body temperature and heart rate).
Some (i.e. loads and loads of) minor issues to resolve first (e.g. if the glucose uploads every five minutes, the GPS every five minutes, the sync every five minutes.... well it's not very timely for live tracking!
Oh and it turned out that the A9G which is the underlying basis of the tracker hardware has a nasty bug which means you can't use use the GPS and serial interfaces at the same time. Rather embarrassing to discover something that worked perfectly fine when run slowly, stepping through in debug worked perfectly, but then once out running and the data was coming in every second everything went to shit*.
*(technical terminology)
So long term plan then, switch this over to alternative hardware anyway. I've got a RAKWireless board to try out next:
 |
| New tech... board on the left should replace all of the tangle in the right... |
Anyhow, once the basics of getting the various bits linked together and uploading, the server needed quite a bit of massaging to give it a slick user experience and we had a workable system to use for race day.
OK so back to the glucose sensor.
I'm a bit torn about the idea of using these for recreational purposes, the waste involved is huge, although I'm only planning on using them for racing rather than all the time.
 |
| So much "stuff". |
Here you can see the patch dismantled at the bottom and the "applicator" system used. These patches last 14 days and all of this is disposable even though almost all of it could be reused, the only non-reusable bit is the actual sensor component which is the tiny piece at the bottom right. There really must be a better way to supply these, perhaps there will be alternatives brought to market from competition.
 |
| So very clever. |
I spent an inordinate amount of time digging through the code, working out what was going on and experimenting. In my previous experiments I'd managed to destroy several sensors, but I knew a lot more about how these worked now so was able to be a lot more careful.
Finally I managed to monkey together enough code to:
- First manage to actually connect to the patch (I was running code from a Bangle.js watch to do this) and...
Connected! - Then once connected decode the received data stream. et voila.
 |
| Decoded! (although I'm not sure how to process the temp - final number) |
This *would* be seriously cool to be able to run glucose monitoring on an open-source watch without needing any other phone hardware or software, but given the encryption and hoops needed to jump through - probably unrealistic. Certainly worth keeping that as an idea on the back-burner.
The race
The race? Oh, well the technology worked really well (in fact noticeably better that the event's own tracking 😁)... this was a relatively short 44 mile race, the majority on the flat.
 |
| Dodgy HRM battery caused central slump. |
The battery in the heart rate strap was dodgy which mucked up for a period, which as it would happen mucked up the core temp output for the same period (the CoreTemp uses the heart rate strap to calibrate).
The glucose graph is really interesting to see though (no dramas on this) but you can see the drop at the start as I run then an initial blip back up at the start as the body is pulling glycogen in from the stores, then it slowly drifts down with occasional blips each time I snack along the way, followed by another big peak after the race as I scoff biscuits and milk. It's going to be interesting to see that sort of data on a longer more extreme event.
 |
| Perfect conditions |
The race on the other hand, not good, not bad, just not good. I've run this three times now, that was my slowest finish, even slower than my first attempt where I got everything wrong and even got lost, so need to work out why that was, what I did wrong, and what to change.
 |
| Overjoyed at the end |
One highlight was the multiple times I could point out the correct direction to other runners at various points along the way.
Oh and saw a black swan which was cool....
Race 1 done for 2022... need a (proper) plan for the rest now.
Comments
Post a Comment