glucometerutils news: many more meters, easier usage and Windows support

You probably have noticed by now that I write about glucometers quite a bit, not only reviewing them as an user, but also reverse engineering to figure out their protocols. This all started four years ago when I needed to send my glucometer readings to my doctor and I ended up having to write my own tool.

That tool started almost as a joke, particularly given I wrote it in Python, which at the time I was not an expert in at all (I have since learnt a lot more about it, and at work I got to be more of an expert than I’d ever expected to be). But I always known that it would be for the most part just a proof of concept. Not only exporting CSV is mostly useless, but the most important part in diabetes management software is the analysis and I don’t have any clue how to do analysis.

At first I thought I could reuse some of the implementation to expand Xavier’s OpenGlucose but it turned out that it’s not really easy for those meters that are using serial adapters or other USB devices beside the HID ones that he implemented already. Of course this does mean it would probably work fine for things like the FreeStyle Libre which I appear to have written the only Linux software to download from, but even in that case, things are more complicated.

Indeed, as I have noted here and there previously, we need a better format to export glucometer data, and in particular the data from continuous or mixed meters like the Libre. My current out format for it only includes the raw glucose readings from the meter that are not marked as errors; it does provide an unstructured text comment that tells you whether the reading is coming from the background sensor, an explicit scan or a blood sample, but it does not provide all the level of details of the original readings. And it does not expose ketone readings at all, despite the fact that most of the FreeStyle-line devices support them and I even documented how to get them. But this is a topic for a different post, I think.

On the other hand, over the past four years, the number of meters increased significantly, and I even have a few more that I only have partially reversed and not published yet. Currently there are 9 drivers, covering over a dozen meters (some meters share the same driver, either because they are just rebranded versions or simply because they share the same protocol). One is for the InsuLinx, which also loses a bunch of details, and is based off Xavier’s own reverse engineering — I did that mostly because all the modern FreeStyle devices appear to share the same basic protocol, and so writing new drivers for them is actually fairly trivial.

This would make the project an interesting base if someone feels like writing a proper UI for it. If I ever tried to look into that, I may end up just starting an HTTP server and provide everything over HMTL for the browser to render. After all that’s actually how OpenGlucose is doing things, except there is no server, and the browser is embedded. Alternatively one could just write an HTML report file out, the same way Accu-Chek Mobile does using data URLs and JavaScript bundles.

One of the most important usability changes I have added recently, though, is allowing the user not to specify the device path. When I started writing the tool, I started by looking at serial adapter based devices, which usually come with their own cable, and you just access it. The next driver was for the LBA-over-SCSI used int he OneTouch Verio, which I could have auto-detected but didn’t, and the following ones, mostly based off HID, I just expected to be given an hidraw path.

But all of this is difficult, and indeed I had more than a few people asking me which device are they meant to use, so over the past few months I adapter the drivers to try auto-detecting the devices. For the serial port based meters, the auto-detection targets the original manufacturer’s cable, so if you have a custom one, you should still pass them a path. For HID based devices, you also need the Python hidapi library because I couldn’t bother writing my own HID bus parsing on Linux…

… and the library also brings another important feature: it works on non-Linux operating systems. Indeed I now have not one but two confirmed users that managed to use the tool on Windows, for two separate FreeStyle devices (at the time of writing, the only ones implementing HID-based protocols, although I have another one in the pipeline.

Supposedly, all of this should work fine on macOS (I almost called it OS X), though the one person who contacted me trying to have it working there has been having trouble with it — I think the problem has something to do with the Python version available (I’m targetting Python 3 because I had a very hard time to do the right processing with Python 2.7). So if you want to give it a try feel free.

And yes, I’m very happy to receive pull request, so if you want to implement that HTML output I talked above about, you’re awesome and I’m looking forward to your pull request. I’m afraid I won’t be much help with the visualisation though.

Glucometer Review: Contour Next One

In my current quest for documenting glucometer protocols and implementing tooling to download data I ended up ordering myself a Contour Next One glucometer, currently marketed by Ascensia Diabetes Care, but originally developed by Bayer (to the point that devices and manuals still mostly refer to Bayer).

The Contour Next One is marketed as a smart glucometer that can connect to an app on a smartphone, as it supports Bluetooth Low Energy. I have not tried that yet because I already have an app I care about on the phone. In addition to that the physical device is very small, but includes a nice, complete and bright display, a three way buttons, a coloured LED for the strip port device, and a beeper.

The size of the device reminds me closely the OneTouch Ultra Mini, which is quite favourable, as every other device I have is significantly bulkier, and for the most part using a different form factor that I don’t particularly enjoy.

The strip port has a coloured LED as I said, and it’ll be white to tell you where to insert the strip, and then turn either green or red depending on the value. You can associate one out of three states for meal information, represented by an apple (why is it always an apple?) crossed out (fasting), full (before meal) or taken two bites of (after meal).

If there is one thing that I can complain about is that the first-time setup is a bit tricky. I have received the meter a couple of months ago, but since I’ve been travelling so much, I have not managed to try it out until earlier this month. When I finally put the strip into the device, and provided blood to it, I found it wanted to confirm date, time and settings… and did not actually give me a result, oops!

On the practicality, the device is really the kind of size I’d like to keep around, if it wasn’t for the fact I switched to the Libre. While it is not all-in-one like the Accu-Chek Mobile, it is small and compact, and looks sleek for a device.

I have installed the Irish app – it seems they have separate app entries for multiple countries, although it does not appear to have country limitations, as I could ask for it to be installed on my Italian SIM device – the first thing it asked me was the country or region, and Ireland was not in the visible list. Turns out the problem is that the list is actually very long and the app’s scrolling is misconfigured, as scrolling up appears to only scroll a third of a row at a time, so scrolling down to Ireland takes quite a while. For United Kingdom I don’t even want to consider the idea. Looks like Ascensia does have some rough edges with testing the first-time setup of their systems.

The setup process is a bit bothersome, if what you want to do is just downloading the data. It tries to convince you to set up an account to back up your data (this appears to be more and more common), and then it goes through give or take the same first-time setup as happens on the meter. In addition to the meter’s own settings, it also allows you to define time bands to divide your meals into breakfast, lunch and dinner, which I liked: instead of just assuming, it asks you to confirm the expected ranges.

There is also a request to configure two phone numbers: the local emergency number, and a personal emergency contact, so that if you have a low-blood-sugar event you can make a call directly. While the idea is interesting on principle, since it already asked me for my region I wonder why it can’t just default to 999. Finding the contact by name in the list is also extremely hard because of the scrolling issue above. I ended up just typing my own name and phone number, as there is never anyone who could actually help me if I have a sugar low, and the request is unskippable.

The app itself appears very simple, showing by default your last reading and a small graph of your recent readings. If you turn your phone or click on the graph, a more detailed (but still rough) graph appears:

The probably most interesting thing about this the app is that if you take a reading on your meter it will be “pushed” to the device, and appear in real-time. It also allows you to set the markings and a number of comments straight from the app, well exceeding the amount of details that the device can set for you, particularly given it’s a three-buttons device.

It reminds me of the iHealth Align but in a much less clumsy way. It also requires significantly less bother with the strips, and there is no validation of when the bottle was open or whether the strips expired, which makes it probably a better choice for those people who only test occasionally.

On more technical sides, the device uses two CR2032 batteries, which while beefier than the iHealth, need to sustain a full BLE connection – which by the way I couldn’t figure out how to turn off at first try – and are at the same time easier to find replacements for (though not as easy as the AAA batteries used by more clunky meters). It has a micro USB connector on the back, behind a rubber seal, and it uses an HID-based protocol to communicate. I’m halfway through reversing and documenting it of course.

Chinese Glucometer Review: Sannuo

As I start this draft I’m in Shanghai (mainland China), for a work trip. I have visited Shanghai before, but this time I have some more random time around, and while I was browsing stores with a colleague also visiting the city, we ended up in a big (three, four stories) pharmacy. We would have left right away if it wasn’t that I noticed a big sign advertising a Countour by Bayer glucometer, and I decided to peek around.

I found indeed a whole floor dedicated to health hardware, including, but clearly not limited to, glucometers. It had a long series of Omron hardware, blood pressure measurements, thermometers, etc. And a few desks of glucometer, some from brands that are established and known in the West, and a few I never heard of.

I looked around for the prices, and the meters are more expensive than in Europe, but about on par with the US, between ¥150 and ¥400. I asked if any of the ones they had that I did not recognize would allow downloading to the computer, and they showed me one for ¥258 (around €35), branded Sannuo and manufactured by Sinocare. I decided to buy it for the sake of figuring out how things differ in China for diabetes.

Before getting to the device itself, a few words of the act of buying one. First of all, as it appears to be common in China, or at least in Shanghai, buying something is a bit of a trip around: you select what you want, they send you to the cashier, you pay, and then you go back to the clerk who you chose the item with. If you’re lucky, you’ll be able to pay with card, and if you’re really lucky, they will accept yours. In this case the store accepted my Tesco Visa, but not my Revolut MasterCard, which means it probably costed me closer to €40, but it’s okay.

After I paid for the device, the clerks assisted me not only by giving me the box of the meter, but configuring it up, particularly date and time. You’d think this would be obvious to do (and it is) but one of the things that kept surprising me in Shanghai is that every time you buy something, the seller will configure it for you, and make sure it works at least to a point, the same was true when I bought a SIM card at the airport. They did not ask me to take blood there and then, but they showed me how to set up the date and time.

Finally, they gave me a box of two bottles of strips, told me there were two bottles in the box, and even warned me to use them one bottle at a time (valid warning for glucometers’ reactive strips). And just to make a point here: only one of the two clerks who assisted me spoke any English, and even she didn’t speak it very well. They still did quite a bit to make me understand and explain how to use it.

Now to go back to the meter itself, the €40 got me a fairly clunky meter, a box of lancets and 50 test strips, which declare themselves having a fairly wide range (from 1.1 mmol/l). In the box with the device came the usual (by now) carrying case, and a lancing device. The lancets appear to be “standard” or at least as close as that word as can possibly be used for lancets and lancing devices.

What became very obvious both on the box of the meter, and on the wall ads of all the other meters, is that China, like the UK and Ireland, use mmol/l measurement for blood sugar. I honestly thought that was just a UK (and Ireland, Australia) thing, but clearly it is much more common. Since I’m writing this before getting back to Europe, I cannot tell whether the meter uses this in the wire protocol or, like all the western meters, uses mg/dL internally.

The meter itself feels clunky and it’s fairly big, just shy of the size of an Accu-Chek Mobile. It uses two AAA batteries, and that has only three buttons: power and up/down arrows. The display is a monochrome LCD, but it also has two LEDs, red and green, to tell you whether you’re in range or not. Oh, and it speaks.

It felt funny when I arrived at the hotel and tried it with a blood sample (it seems consistent with the variation of other meters), and it started announcing… something. I don’t speak Chinese so I have not understood anything, I should probably start Google Translate next time I try it. Part of the reason why this feels funny is because it reminded me of the i-ching calculator from Dirk Gently: The Long Dark Tea-Time of the Soul radio series, which was effectively a calculator that spoke the results out loud. I did not make much of a parallel until this, but it then reminded me of the devices in the taxis I took last year, too.

Unfortunately even though I’m now at home, I have not been able to start on the reverse engineering, because I can’t seem to get the device to work on my laptop. According to Linux, the device is not accepting the assigned address. I should wire it up to the proper logic analyzer for that.

Glucometer Review: Abbott FreeStyle Precision Neo

During my December trip to the United States, I did what I almost always do when I go there: I went to a pharmacy and looked through the current models of glucometers that are for sale there. Part of the reason is that I just got to the point I enjoy a challenge of figuring out what difference in the protocol the various manufacturers put version after version, and part of it is that I think it is a kind of a public service that we provide tools not only for the nice and fancy meters but also for those that most people would end up buying in store. I have one more device that I got during one of my various trips that I have not written about, too, but let’s not go there.

This time around the device I got is an Abbott FreeStyle Precision Neo device. The factors I used to choose, as usual, were price (I didn’t want to spend much, this one was on sale for less than $10), and the ability to download the data over direct USB connection (the device I have noted above requires a custom cradle which I have not managed to acquire yet). In addition, while the device did not come with any strip at all, I (mistakenly) thought it was a US brand for the Optium Neo, which looks very similar and is sold in Europe and Canada. That meter I knew used the same strips that I use for the FreeStyle Libre, which means I wouldn’t have to pay extra for it at all. As I said I was wrong, but it still accepted the same strips, more on that later.

The device itself is fairly nice: at first it may appear to share a similar shape as the Libre, but it really seems to share nothing with it. It’s significantly flatter, although a bit wider. The display is not LCD at all, but rather appears to be e-ink and reminded me of the Motorola FONE. The display is technically a “touchscreen” but rather than having a resistive or capacitive display on the device, it appears to just have switches hidden behind the screen.

Given the minimal size of the device, there is not much space for a battery and charging circuitry, like there is in the Libre, instead the device is powered by a single CR2032 battery which is very nice as they are cheap enough, and easy to carry around, although you’re not meant to leave them in checked-in luggage.

Overall, the device is flatter than my current smartphones, and extremely light, and that gives it a significant advantage over a number of other meters I tried in the past few years. The e-ink display ha very big and easily readable numbers, so it’s ideal for the elderly or those who need to take the test even without their glasses.

Putting aside the physical size factor, the package I bought contained a small case for the meter, a new lancing device, and some lancets. No strips, and I guess that explains the very low price point. I would say that it’s the perfect package for the users of previous generations’ FreeStyle devices that need an upgrade.

As I said at the start, the main reason why I buy these devices is that I want to reverse engineer their protocol, so of course I decided to find the original software from Abbott to download the data out of it. Unfortunately it didn’t quite work the way I was expecting. I expected the device to be a rebranded version of the Optium Neo, but it isn’t. So the software from the Irish Abbott website (Auto-Assist Neo, v1.22) tried connecting to the meter but reported a failure. So did the same software downloaded from the Canadian website (v1.32).

Given that this is a US device, I went to the US website (again, thank you to TunnelBear as Abbott keeps insisting with the GeoIP-locking). The US version does not offer a download of the simple desktop software I was looking for, instead pointing you to the client for their online diabetes management software. What is it with online systems for health data access? I decided not to try that one, particularly as I would be afraid of its interaction with the FreeStyle Libre software. I really should just set up a number of virtual machines, particularly given that the computer I’m using for this appears to be dying.

On the bright side it appears that, even though the software declares the device is not compatible with it, the USB capture shows that all the commands are all being sent and responded to, so I have a clear trace for at least the data download. The protocol is almost identical to the Insulinx that Xavier already reverse engineered in parts, and both seem to match the basic format that Pascal found how to dump from the Libre so it was easy to implement. I’ll write more about that separately.

So what about the strips? Since the device came with no strips, I assumed I would just use the strips I had at home, which were bought for my Libre device and were of the Optimus series, and they worked fine. But when I looked into completing the reverse engineering of the protocol by figuring out which marking is used for the β-ketone readings, the device reported E-2 on the screen. So I looked into it and I found out that the Precision Neo device is meant to be used with Precision series strips. Somehow the Optimus blood glucose strips are compatible (I would guess they are effectively the same strips) while the β-ketone strips are not. So I still don’t have data of how those readings are reported. But this put a final nail in the coffin to the idea that this is the same device as the one sold outside of the USA.

Having this device was very useful to understand and document better the shared HID protocol that is used by Abbott FreeStyle devices, which made it very easy to implement the basic info and data dump from the Libre, as well as an untested InsuLinux driver, in my glucometerutils project. So I would say it was $10 spent well.

Glucometer Review: iHealth Align

You’d expect that with me being pretty happy with the FreeStyle Libre, new glucometer reviews would be unlikely. On the other hand, as you probably noticed as well, I like reverse engineering devices, and I have some opinions about accessing your own medical data (which I should write about at some point), so when I drop by the United States I check if they have any new glucometer being sold for cheap that I might enjoy reversing.

The iHealth Align is a bit special in this regard. Usually I just buy what’s on offer at Walgreens or CVS (sometimes thanks to Rebate just paying taxes for it), but this time I ordered it straight from Amazon. And the reason whas interesting: I found it with a “heavy” discount (the page I ordered it from is gone, but it was something along the lines of 30%), and I guess this is because the device is mostly advertised to be for iOS, and since it uses the TRRS (headphone) jack, it will not work on the more recent devices. On the other hand, it still works fine on Android.

Originally I wanted to wait to go back home to look into it, as I also bought some TRRS breakout connectors to be able to run my newly-bought Saleae Logic Pro 16 onto it, but a funny accident got me to open it while on my trip, in Pittsburgh, and try it out already.

As for the funny accident, I am not entirely sure how that happened but after dinner with Rick, after I went back to my room, my FreeStyle Libre reported a fall from 10 mmol/L (138mg/dL) to LO within two readings (and missing a few data points after that), and then reported me as being having a low blood sugar event. I was not hypoglycemic at that point, as I can feel it, so I double checked with the new meter, that showed me just fine in the 7 mmol/L range, which meant I was good. After an hour or two the self-calibration of the sensor went back to normal and it aligned again with the other meter.

My doctor suggests that the -15℃ weather outside would affect the chemical reaction, and make even blood testing unreliable. On the other hand, I had a second happening of the same failure mode after a shower last night, it might be a defect of this sensor.

I’ll start with a first impression before actually going onto the details of what I found in deeper inspection of the device, mostly out of need since I’ve started the post while travelling through airports.

The device is very small and it’s an active device: it has a button cell inside, and it comes with replacement ones, likely because they are not very common ones: CR1620 — not to be confused with CR2016! The package I got had no strips, but came with “sanitary phone covers” — I think they meant it to be for medical professionals rather than self-use, but that might explain the cheaper price.

To use it with your phone, you obviously have to install the iGluco application from iHealth, and that application needs obviously permission to listen to your microphone to use the audio jack. What surprised me was that just plugging the device in opens the application. I was scared that the application was constantly listening to the microphone waiting for a magic handshake, but a friend suggested that they may just be registering an intent for the jack-sensing, and playing back a handshake when they receive that. Plugging in a pair of headphones doesn’t do anything, and I have yet to fire up the analyser to figure out if something else may be going on.

Before you can take a reading you have to sign up for the iHealth remote service, and provide it with a valid email address. It also asks a couple of basic questions meant to be useful to track your health in general, found those a tad creepy too but I understand why they are there. It’s not surprising, given that the LibreLink does something very similar (without the questions though). It does give me a bigger incentive to try to figure out the device, although I’m also concerned it might be too locked in for the vendor. On the bright side, I confirmed all the communication with the remote service happens over HTTPS; what I did not confirm is whether the app is validating certificates correctly so don’t trust my word for it.

There is a blast from the past when I tried using it the first time: the strips are coded. I have not seen a device using coded strips in years by now. The OneTouch Ultra strips have been coded in the past, but over the past four years or so, they only sell code 25 — and they stopped selling them altogether in the UK and Ireland. To code the strips in, the strip bottles come with a big QR code on the top. This QR code embeds the date of issue and expiration of the strips, and appears to provide a unique identifier on the bottle, as the application will keep track of a shorter expiration time for the bottle when you start using it, which means it’s hard (or impossible) to use two bottles (like I used to do, one at home and one at the office).

The app includes some interesting metadata with the reading, but that’s nothing new. It’s definitely easier to write notes or select pre- or post-meal readings than with a normal glucometer, but again, this is not really exciting. It does, though, allow you to select in which measurement unit you want your readings in, whether mg/dL or mmol/L. This marks a first in my experience; as far as I knew, it is against regulation in most countries to let the user switch units, as the risk of a patient to misconfigure the glucometer makes it a deadly risk. But who am I to complain? I have written my tools because I needed to dump an Italian meter in a way that my Irish doctor liked.

As for the testing strips, they are huge compared to anything else I’ve used, although they don’t require so much blood as they may look like doing. They are a bit difficult to fit properly into the meter at first, requiring a bit more force than I’m used to either, and sometimes the app gets stuck if you don’t fit them in properly. All in all this makes it a bit of a shoddy meter on the practical level in my opinion.

From what I can tell, iHealth has a newer model of their meter that uses Bluetooth instead of the audio jack, and is thus compatible with the new iPhone models, and that may be more user friendly with regard to the app freezing, but I would expect the issue with the force needed to fit the strip to still exist.

I have not yet started looking into the communication between device and phone yet, although I have all the pieces I need. This weekend I think I’ll be soldering up a couple of things I need and then post pictures of the resulting breadboards, I’m sure it’s going to be a funny one.

Abbot FreeStyle Libre, the mobile app

You may remember I reviewed the Abbott FreeStyle Libre and even tried reverse engineering its protocol. One of the things that I did notice from the beginning is that the radio used by the sensors themselves is compatible with the NFC chip in most cellphones.

This was not a surprise to everybody; indeed I was pointed at a website (which I refuse to link) of Nightscouters (self-proclaimed people who “are not waiting”), which in turn pointed to an unofficial Android app that is able to read that data. The app is unsafe though (thus the lack of links), as it does not wait the first hour to get a reading, and allows to keep reading the sensor after the two weeks provided by the manufacturer. Their excuse is that you should be able to get the data and judge by yourself; I don’t like that answer, particularly as the raw readings need to be normalized by the Abbott reading device for it to have a valid reading.

Indeed, the various groups I see proclaiming “they are not waiting”, are vastly interested in the idea of quantified self, rather than having an actual health need for this data. They would be harmless, if they didn’t suggest using similarly risky methods to gain information that could be used to make medical decision. But this is a topic for another time.

Instead, a few months ago, Abbott themselves sent out an email to the register users that they made an official Android app available. Called LibreLink, and developed by a company identified as AirStrip Technologies based in San Antonio, Texas, this app is able to initialize and read a FreeStyle Libre sensor from an NFC-capable Android phone. It can be used to either replace the original Abbott reader device, or in addition to it.

I have tried it as soon as I could, which meant not right as I received the mail: the app is only able to read a sensor that it either initialize by itself, or one that was scanned during the one hour window in which the readings are not available. I suppose this has something to do with the pseudo-calibration that the FreeStyle Libre system provides.

Having the ability to take my readings from the phone turned out to be a good thing. While I would still try to keep the readings on the official device, which allows downloading them to a computer, and provides a full PDF I can send my doctor with the history, it allowed me to forget my reader at home for a day, and not having to worry, or being able to take a reading during a meeting in which I did not think to take the reader with me. It also provides more information than the reader itself, including what Abbott calls the Ambulatory Glucose Profile (AGP), which ends up being a graph of 10-90 percentiles, 25-75 percentiles, and median.

Aside: turns out that getting used to read percentile graphs, which is something my dayjob trained me to do, made it much more obvious to me what the AGP graphs were; I had to correct the Diabetes Ireland website, that listed it as a set of superimposed graphs. It took me a good half-hour to realize that it was just obvious to me due to my work, which is totally unrelated to health-care, but it would not be so to a doctor who has not seen that kind of monitoring before. Cross-discipline information exchange is good.

Unfortunately, it seems like the app likes to share data with its developers. This makes sense to a point: science is progressing, and they want to know how exactly it makes your life different, does it make it easier to keep your sugar within limits? Does it make it more likely to get sugar-lows, rather than highs? These are all good questions. I have not tried investigating (yet) whether the app shares this data over a properly encrypted channel or if it’s an actual privacy risk. I might better not know, since it does scare me a bit, but I guess I should do that at some point.

Again as an aside, I did get myself an Android phone capable of NFC, for the sole reason of being able to use that app while inspecting its traffic. The phone I used previously for that is my corporate phone, so I would not be able to fiddle with the traffic dumping on it. But I guess I’ll have to find more time for that, nowadays.

While I have been happy that the app was around, it was not perfect either. In particular I have a bad feeling that it might have something to do with two sensors failing on me with an error I did not see in the eight months before the app was introduced. I have made the mistake of not contacting Abbott right away about them, which meant I thrown them out without sending them for inspection, I have since realized my mistake but could not risk causing more failures until about this month, since I’ve been traveling a bit, and it takes me about a week or two to get new sensors in Dublin.

The reason why I suspect this is related to the app is not just that I didn’t get those kind of errors before I started using it, but also because I had read of similar failures happening when using the unofficial app suggested by Nightscouters, though in that case it’s said to be dependent on the NFC chip used by the cellphone. The two things together made me suspicious.

I’m actually told (by both my doctor and Diabetes Ireland) that Abbott is meant to start selling the device (and sensors) in Ireland before next month. Right now they do have an Irish website, which is more than they had when I started looking into it. I do not know as of yet, whether my long-term illness coverage includes these sensors or if I’ll have to keep paying for them myself (at least the falling Sterling is helping), but either way it’s going to be simpler to procure them if one of them fails.

As a final note, I should probably write down my own impressions when the sensor failed, compared to the article Daniel pointed me at back when I posted about my experimentation with this CGM (pardon, flash glucose monitoring system.) Although the first time this happened, it was not due to the mobile app; instead the application packet for the sensor failed, and I “primed” a sensor without a needle.

This happened when I was in Lisbon on vacation, and I only noticed after the hour passed, and I was queuing up for a train ticket to Cascais. I’ll admit it: I started panicking. I did not plan for it and I did not want to be out and about alone without the sensor. Part of the problem was to be found in me not having the normal glucometer with me, so having absolutely no way to make sure I was okay. The panic probably would have limited itself had I managed to get a ticket in less than twenty minutes. At the end I gave up when I got to the machine and it refused to accept either my cash (too wrinkly) or my card (too foreign.) So I turned around, went back to the hotel and put a new sensor (yes I traveled with a spare.)

Would I have panicked like in the linked article? Maybe, but I would like to think not. When the sensor actually failed me at home, this time indeed possibly due to the app, I didn’t have a spare sensor at home, and that made me angry. But at the same time, I knew it was not that important, I lived without it before, and I can live without it now, it’s just more inconvenient. What I did was putting a new cassette into the Accu-Chek which is significantly nicer to bring around than the kit for the Libre-as-glucometer, and ordered more sensors. I ended up staying a week without the Libre; it bothered me but I didn’t change much of my habits: the Libre trained me on how to relate my sensory experience with blood sugar, and what I can and cannot eat when, so I felt fairly safe overall.

Last words on diabetes and software

Started as a rant on G+, then became too long and suited for a blog.

I do not understand why we can easily get people together with something like VideoLAN, but the moment when health is involved, the results are just horrible.

Projects either end up in “startuppy”, which want to keep things for themselves and by themselves, or we end up fractionated in tiny one-person-projects because every single glucometer is a different beast and nobody wants to talk with others.

Tonight I ended up in a half-fight with a project to which I came saying “I’ve started drafting an exchange format, because nobody has written one down, and the format I’ve seen you use is just terrible and when I told you, you haven’t replied” and the answer was “we’re working on something we want to standardize by talking with manufacturers.”

Their “we talk with these” projects are also something insane — one seem to be more like the idea of building a new device from scratch (great long term solution, terrible usefulness for people) and the other one is yet-another-build-your-own-cloud kind of solution that tells you to get Heroku or Azure with MongoDB to store your data. It also tells you to use a non-manufacturer-approved scanner for the sensors, which the comments point out can fry those sensors to begin with. (I should check whether that’s actually within ToS for Play Store.)

So you know what? I’m losing hope in FLOSS once again. Maybe I should just stop caring, give up this laptop for a new Microsoft Surface Pro, and keep my head away from FLOSS until I am ready for retirement, at which point I can probably just go and keep up with the reading.

I have tried reaching out to the people who have written other tools, like I posted before, but it looks like people are just not interested in discussing this — I did talk with a few people over email about some of the glucometers I dealt with, but that came to one person creating yet another project wanting to become a business, and two figuring out which original proprietary tools to use, because they do actually work.

So I guess you won’t be reading much about diabetes on my blog in the future, because I don’t particularly enjoy writing this for my sole use, and clearly that’s the only kind of usage these projects will ever get. Sharing seems to be considered deprecated.

CGM review: Abbott FreeStyle Libre

While working on reverse engineering glucometers I decided to give a try to a CGM solution. As far as I know the only solution available in Ireland is Dexcom. A friend of mine already has this, and I’ve seen it, but it felt a bit too bulky for my taste.

Instead, I found out on Twitter about a new solution from Abbott – the same company I wrote plenty before while reverse engineering devices – called FreeStyle Libre. When I first got to their website, though, I found out that the description videos themselves were “not available in my country”. When I went back to check on it, the whole website was not available at all, and instead redirected me to a general website telling me the device is not available in my country.

I won’t spend time here to describe how to work around the geolocking, I’m sure you can figure it out or find the instructions on other websites. Once you work around accessing the website, ordering is also limited to UK addresses for both billing and shipping — these are also fairly easy to work around, particularly when you live in Éire. I can’t blame Abbott for not selling the device in this country (they are not allowed by law) but it would be nice if they didn’t hide the whole website though!

Anyway, I have in some ways (which I won’t specify) worked around the website geolocking and order one of the starter kits back in February. The kit comes with two sensors (each valid for 14 days) and with a reader device which doubles as a normal glucometer.

The sensors come with an applicator that primes them and attaches them to the arm. The applicator is not too difficult to use even with your weak hand, which is a nice feature given that you should be alternating the arm you attach it to. Once you put the sensor on you do feel quite a bit of discomfort but you “get used to it” relatively quickly. I would suggest avoiding the outer-side of the arm though, particularly if you’re clumsy like me and tend to run into walls fairly often — I ended up discarding my second sensor after only a week because I just took it out by virtue of falling.

One of the concerns that I’ve been warned about by a friend, on CGM sensors, is that while the sensor has no problem reading for the specified amount of time, the adhesive does not last that long. This was referred to another make and model (the Dexcom G4) and does not match my experience with the Libre. It might be because the Libre has a wider adhesive surface area, or because it’s smaller and lighter, but I haven’t had much problem with it trying to come away before the 14 days, even with showers and sweat. I would still suggest keeping at hand a roll of bandage tape though, just in case.

The reader device, as I said earlier, doubles as a normal glucometer, as it accepts the usual FreeStyle testing strips, both for blood and for ketone reading, although it does not come with sample strips. I did manage to try blood readings by using one of the sample strips I had from the FreeStyle Optium but I guess I should procure a few more just for the sake of it.

The design of the reading device is inspired by the FreeStyle InsuLinx, with a standard micro-USB port for both data access and charging – I was afraid the time would come that they would put non-replaceable batteries on glucometers! – and a strip-port to be used only for testing (I tried putting the serial port cable but the reader errors out.) It comes with a colourful capacitive touch-screen, from which you can change most (But not all) settings. A couple of things, such as the patient name, can only be changed from the software (available for Windows and OSX.)

The sensor takes a measurement every 15 minutes to draw the historical graph, which is stored for up to eight hours. Plus it takes a separate, instantaneous reading when you scan it. I really wish they put a little more memory in it to keep, say, 12 hours on the device, though. Eight hours is okay during the day if you’re home, but it does mean you shouldn’t forget the device home, when you go to the office (unless you work part-time), and that you might lose some of the data from just after going to sleep if you manage to sleep more than eight hours at a time — lucky you, by the way! I can’t seem to be able to sleep more than six hours.

The scan is at least partially performed over NFC, as my phone can “see” the sensor as a tag, although it doesn’t know what to do with it, of course. I’m not sure if the whole data dumping is done over NFC, but it would make it theoretically possible to get rid of the reader in favour of just using a smartphone then… but that’s a topic for a different time.

The obvious problem with CGM solutions is their accuracy. Since they don’t actually measure blood samples (they do use a needle, but it’s a very small one) but rather interstitial fluid, it is often an open question on whether their readings can be trusted, and the suggestion is to keep measuring normal blood sugar once or twice a day. Which is part of the reason why the reader also doubles as a normal glucometer.

Your mileage here may vary widely, among other things because it varies for me as well! Indeed, I’ve had days in which the Libre sensor and the Accu-Chek Mobile matched perfectly, while the last couple of days (as I’m writing this) the Libre gave a slightly lower reading, between 1 and 2 mmol/l (yes this is the measure used in UK, Ireland and Australia) lower than the Accu-Chek blood sample reading. In the opinion of my doctor, hearing from his colleagues across the water (remember, this device is not available in my country), it is quite accurate and trustworthy. I’ll run with his opinion — particularly because while trying to cross-check different meters I have here, they all seem to have a quite wider error range you’d expect, even when working on a blood sample from the same finger (from different fingers it gets complicated even for the same reader.)

Side-by-side picture of Accu-Chek Mobile and FreeStyle Libre

I’m not thrilled by the idea of using rechargeable batteries for a glucometer. If I need to take a measurement and my Accu-Chek Mobile doesn’t turn on, it takes me just a moment to pick up another pair of AAA from my supply and put them in — not so on a USB-charged device. But on the other hand, it does make for a relatively small size, given the amount of extra components the device need, as you can see from the picture. The battery also lasts more than a couple of weeks without charging, and it does charge with the same microUSB standard as most of my other devices (excluding the iPod Touch and the Nexus 5X), so it’s not too cumbersome while traveling.

A note on the picture: while the Accu-Chek Mobile has a much smaller and monochromatic non-touch screen, lots of its bulk is taken by the cassette with the tests (as it does not use strips at all), and it includes the lancing devices on its side, making it still quite reasonably sized. See also my review of it.

While the sensors store up to 8 hours of readings, the reader stores then up to three months of that data, including additional notes you can add to it like insulin dosage (similar to InsuLinx), meals and so on. The way it shows you that data is interesting too: any spot-check (when you scan the sensor yourself) is stored in a logbook, together with the blood sample tests — the logbooks also include a quick evaluation on whether the blood sugar is rising, falling (and greatly so) or staying constant. The automatic sensor readings are kept visible only as a “daily graph” (for midnight to midnight), or through “daily patterns” that graph (for 7, 14, 30 and 90 days) the median glucose within a band of high and low percentiles (the device does not tell you which ones they are, more to that later.)

I find the ability to see these information, particularly after recording notes on the meals, for instance, very useful. It is making me change my approach for many things, in particular I have stopped eating bagels in the morning (but I still eat them in the evenings) since I get hypers if I do — according to my doctor it’s not unheard of for insulinoresistance to be stronger as you wake up.

I also discovered that other health issues you’d expect not to be related do make a mess of diabetes treatment (and thus why my doctors both insisted I take the flu shot every year). A “simple” flu (well, one that got me to 38.7⁰C, but that’s unrelated, no?) brought my blood sugar to raise quite high (over 20 mmol/l), even though I was not eating as much as usual either. I could have noticed with the usual blood checking, but that’s not something you look forward to when you’re already feverish and unwell. For next time, I should increase insulin in those cases, but it also made me wary of colds and in general gave me a good data point that caring even for small things is important.

A more sour point is, not unusually, the software. Now, to be fair, as my doctor pointed out, all diabetes management software sucks because none of it can have a full picture of things, so the data is not as useful, particularly not to the patients. I have of course interest in the software because of my work on reverse engineering, so I installed the Windows software right away (for once, they also provide an OSX software, but since the only Mac I have access to nowadays is a work device, I have not tried it.)

Unlike the previous terrible experience with Abbott software, this time I managed to download it without a glitch, except for the already-noted geolocking of their website. It also installed fine on Windows 10 and works out of the box, among other things because it requires no kernel drivers whatsoever (I’ll talk about that later when I go into the reverse engineering bits.)

Another difference between this software and anything else I’ve seen up to now, is that it’s completely stateless. It does not download the data off the glucometer to store it locally, it downloads it and run the reports. But if you don’t have the reader with you, there’s no data. And since the reader stores up to 90 days worth of data before discarding, there are no reports that cross that horizon!

On the other hand, the software does seem to do a good job at generating a vast number of information. Not only it generates all the daily graphs, and documents the data more properly regarding which percentiles the “patterns” refer to (they also include two more percentile levels just to give a better idea of the actual pattern), but it provides info such as the “expected A1C” which is quite interesting.

At first, I mistakenly thought that the report functionality only worked by printing, similarly to the OneTouch software, but it turns out you can “Save” the report as PDF and that actually works quite well. It also allows you to “Export” the data, which provides you with a comma-separated values file with most of the raw data coming from the device (again, this will become useful in a separate post.)

That does not mean the software is not free from bugs, though. First of all, it does not close. Instead, if you click on the window’s X button, it’ll be minimized. There’s an “Exit” option in the “File” menu, but more often than not it seems to cause the software to get stuck and either terminated by Windows, or requiring termination through the Task Manager. It also keeps “prodding” for the device, which ends up using 25% of one core, just for the sake of being open.

The funniest bit, though, was when I tried to “print” the report to PDF — which as I said above is not really needed, you can export it from the software just fine, but I didn’t notice. In this situation, after the print dialog is shown, the software decides to hide any other window for its process behind its main window. I can only assume that this hide some Windows printing dialog that they don’t want to distract the user with, but it also hides the “Save As” dialog that pops up. You can type the name blindly, assuming you can confirm you’re in the right window through Alt-Tab, but you’ll also have to deal with the software using its installation directory as work directory. Luckily Windows 10 is smart enough, and will warn about not having write access to the directory, and if you “OK” the invisible dialog, it’ll save the file on your user’s home directory instead.

As for final words, I’m sure hoping the device becomes available in Republic of Ireland, and I would really like for it to be covered by the HSE’s Long Term Illness program, as the sensors are not cheap at £58 every two weeks (unless you’re clumsy as me and have to replace it sooner.) I originally bought the starter kit to try this out and evaluate it, but I think it’s making enough of good impact that (since I can afford it) I’ll keep buying the supplies with my current method until it is actually available here (or until they make it too miserable.) I am not going to stop using the Accu-Chek Mobile for blood testing, though. While it would be nice to use a single device, the cassette system used by the Roche meter is just too handy, particularly when out in a restaurant.

I’ll provide more information on my effort of reverse engineering the protocol in a follow-up post, so stay tuned if you’re interested in it.

Diabetes control and its tech: FreeStyle Optium reverse engineering

As I said in previous posts, I have decided to spend some time reverse engineering the remaining two glucometers I had at home for which the protocol is not known. The OneTouch Verio is proving a complex problem, but the FreeStyle Optium proved itself much easier to deal with, if nothing else because it is clearly a serial protocol. Let’s see all the ducks to get to the final (mostly) working state.

Alexander Schrijver already reverse engineered the previous Freestyle protocol, but that does not work with this model at all. As I’ll say later, it’s still a good thing to keep this at hand.

The “strip-port” cable that Abbott sent me uses a Texas Instrument USB-to-Serial converter chip, namely the TIUSB3410; it’s supported by the Linux kernel just fine by itself, although I had to fix the kernel to recognize this particular VID/PID pair; anything after v3.12 will do fine. As I found later on, having the datasheet at hand is a good idea.

To reverse engineer an USB device, you generally start with snooping a session on Windows, to figure out what the drivers and the software tell the device and what they get back. Unfortunately usbsnoop – the open source windows USB snooper of choice – has not been updated in a few years and does not support Windows 10 at all. So I had to search harder for one.

Windows 7 and later support USB event logging through ETW natively, and thankfully more recently Microsoft understood that those instructions are way too convoluted and they actually provide an updated guide based on Microsoft Message Analyzer, which appears to be their WireShark solution. Try as I might, I have not been able to get MMA to provide me useful information: it shows me fine the responses from the device, but it does not show me the commands as sent by the software, making it totally useless for the purpose of reverse engineering, not sure if that’s by design or me not understanding how it works and forgetting some settings.

A quick look around pointed me at USBlyzer, which is commercial software, but both has a free complete trial and has an affordable price ($200), at least now that I’m fully employed, that is. So I decided to try it out, and while the UI is not as advanced as MMA’s, it does the right thing and shows me all the information I need.

Start of capture with USBlyzer

Now that I have a working tool to trace the USB inputs and outputs, I recorded a log while opening the software – actually, it auto-starts­ – downloading the data, checking the settings and change the time. Now it’s time to start making heads and tails of it.

First problem: TI3410 requires firmware to be uploaded when it’s connected, which means a lot of the trace is gibberish that you shouldn’t really spend time staring at. On the other hand, the serial data is transferred over raw URB (USB Request Block), so once the firmware is set up, the I/O log is just what I need. So, scroll away until something that looks like ASCII data comes up (not all serial protocols are ASCII of course, the Ultra Mini uses a binary protocol, so identifying that would have been trickier, but it was my first guess.

ASCII data found on the capture

Now with a bit of backtracking I can identify the actual commands: $xmem, $colq and $tim (the latest with parameters to set the time.) From here it would all be simple, right? Well, not really. The next problem to figure out is the right parameters to open the serial port. At first I tried the two “obvious” positions: 9600 baud and 115200 baud, but neither worked.

I had to dig up a bit more. I went to the Linux driver and started fishing around for how the serial port is set up on the 3410 — given the serial interface is not encapsulated in the URBs, I assumed there had to be a control packet, and indeed there is. Scrollback to find it in the log gives me good results.

TI3410 configuration data

While the kernel has code to set up the config buffer, it obviously doesn’t have a parser, so it’s a matter of reading it correctly. The bRequest = 05h in the Setup Packet correspond to the TI_SET_CONFIG command in the kernel, so that’s the packet I need. The raw data is the content of the configuration structure, which declares it being a standard 8N1 serial format, although 0x0030 value set for the baudrate is unexpected…

Indeed the kernel has a (complicated) formula to figure the right value for that element, based on the actual baudrate requested, but reversing it is complicated. Luckily, checking the datasheet of the USB to serial conveted I linked earlier, I can find in Section 5.5.7.11 a description of that configuration structure value, and a table that provides the expected values for the most common baudrates; 0x0030 sets a rate close to 19200 (within 0.16% error), which is what we need to know.

It might be a curious number to choose for an USB to serial adapter, but a quick chat with colleagues tells me that in the early ‘90s this was actually the safest, fastest speed you could set for many serial ports providers in many operating systems. Why this is still the case for a device that clearly uses USB is a different story.

So now I have some commands to send to the device, and I get some answers back, which is probably a good starting point, from there on, it’s a matter of writing the code to send the commands and parse the output… almost.

One thing that I’m still fighting with is that sometimes it takes a lot of tries for the device to answer me, whereas the software seems to identify it in a matter of seconds. As far as I can tell, this happens because the Windows driver keeps sending the same exchange over the serial port, to see if a device is actually connected — since there is no hotplugging notifications to wake it up, and, as far as I can see, it’s the physical insertion of the device that does wake it up. Surprisingly though, sometimes I read back from the serial device the same string I just sent. I’m not sure what to do of that.

One tidbit of interesting information is that there are at least three different formats for dates as provided by the device. One is provided in response to the $colq command (that provides the full information of the device), one at the start of the response for the $xmem command, and another one in the actual readings. With exception of the first, they match the formats described by Alexander, including the quirk of using three letter abbreviation for months… except June and July. I’m still wondering what was in their coffee when they decided on this date format. It doesn’t seem to make sense to me.

Anyway, I have added support to glucometerutils and wrote a specification for it. If you happen to have a similar device but for a non-UK or Irish market, please let me know what the right strings should be to identify the mg/dL values.

And of course, if you feel like contributing another specification to my repository of protocols I’d be very happy!

Diabetes control and its tech: reverse engineering glucometer tools, introduction

In the time between Enigma and FOSDEM, I have been writing some musings on reverse engineering to the point I intended to spend a weekend playing with an old motherboard to have it run Coreboot. I decided to refocus a moment instead; while I knew the exercise would be pointless (among other things, because coreboot does purge obsolete motherboards fairly often), and I Was interested in it only to prove to myself I had the skills to do that, I found that there was something else I should be reverse engineering that would have actual impact: my glucometers.

If you follow my blog, I have written about diabetes, and in particular about my Abbott Freestyle Optium and the Lifescan OneTouch Verio, both of which lack a publicly available protocol definition, though manufacturers make available custom proprietary software for them.

Unsurprisingly, if you’re at least familiar with the quality level of consumer-oriented healthcare related software, the software is clunky, out of date, and barely working on modern operating systems. Which is why the simple, almost spartan, HTML reports generated by the Accu-Chek Mobile are a net improvement over using that software.

The OneTouch software in particular has not been updated in a long while, and is still not an Unicode Windows application. This would be fine, if it wasn’t that it also decided that my “sacrificial laptop” had incompatible locale settings, and forced me to spend a good half hour to try configuring it in a way that it found acceptable. It also requires a separate download for “drivers” totalling over 150MB of installers. I’ll dig into the software separately as I describe my odyssey with the Verio, but I’ll add this in: since the installation of the “drivers” is essentially a sequence of separate installs for both kernel-space drivers and userland libraries, it is not completely surprising that one of those fails — I forgot which command returned the error, but something used by .NET has removed the parameters that are being used during the install, so at least one of the meters would not work under Windows 10.

Things are even more interesting for FreeStyle Auto-Assist, the software provided by Abbott. The link goes to the Irish website (given I live in Dublin), though it might redirect you to a more local website: Abbott probably thinks there is no reason for someone living in the Republic to look at an imperialist website, so even if you click on the little flag on the top-right, it will never send you to the UK website, at least coming from an Irish connection… which mean to see the UK version I need to use TunnelBear. No worries though, because no matter whether you’re Irish or British, the moment when you try to download the software, you’re presented with a 404 Not Found page (at least as of writing, 2016-02-06) — I managed getting a copy of the software from their Australian website instead.

As an aside, I have been told about a continuous glucose meter from Abbott some time ago, which looked very nice, as the sensor seemed significantly smaller than other CGMs I’ve seen — unfortunately when I went to check on the (UK) website, its YouTube promotional and tutorial videos were region-locked away from me. Guess I won’t be moving to that meter any time soon.

I’ll be posting some more rants about the problems of reverse engineering these meters as I get results or frustration, so hang tight if you’re curious. And while I don’t usually like telling people to share my posts, I think for once it might be beneficial to spread the word that diabetes care needs better software. So if you feel to share this or any other of my posts on the subject please do so!