FreeStyle Libre and first responders

Over on Twitter, a friend asked me a question related to the FreeStyle Libre, since he knew that I’m an user. I provided some “soundbite-shaped” answers on the thread but since I got a few more confused replies afterwards, I thought I would try to make the answer a bit more complete:

@EoghanCon11 @FreeStyleDiabet @FreeStyleLibre @AmbulanceNAS @Hannah199911 @flameeyes any idea if this is possible?… twitter.com/i/web/status/1…
—
Ciarán Handley (@ciaranhandley) July 29, 2018

Let’s start with a long list of caveats here: I’m not a doctor, I’m not a paramedic, I do not work for or with Abbott, and I don’t speak for my employer. All the opinions that follow are substantiated only by my personal experiences and expertise, which is to say, I’m an user of the Libre system and I happen to be a former firmware engineer (in non-medical fields) and have a hobby of reverse engineering glucometer communication protocols. I will also point out that I have explicitly not looked deeply into the NFC part of the communication protocol, because (as I’ll explain in a minute), that crosses the line of what I feel comfortable releasing to the public.

Let me start with the immediate question that Ciarán asks in the tweet. No, the communication between the sensor and the reader device (or phone app) is not authenticated or protected by a challenge/response pair, as far as I know. From what I’ve been told (yes I’m talking through hearsay here, but give me a moment), the sensor will provide the response no matter who is asking. But the problem is what that response represent.

Unlike your average test strip based glucometer, the sensor does not record actual blood glucose numbers. Instead it reports a timeseries of raw values from different sensors. Pierre Vandevenne looked at the full response and shed some light onto the various other values provided by the sensor.

How that data is interpreted by the reader (or app) depends on its calibration, which happens in the first 60 minutes of operation of the sensor. Because of this, the official tools (reader and app) only allows you to scan a sensor with the tool that started it — special concessions are made for the app: a sensor started by a reader device can be also “tied” to the app, as long as you scan it with the app during the first hour of operation. It does not work the other way, so if you initialize with the app, you can’t use the reader.

While I cannot be certain that the reader/app doesn’t provide data to the sensor to allow you to do this kind of dual-initialization, my guess is that they don’t: the launch of the app was not tied with any change to the sensors, nor with warnings that only sensors coming from a certain lot and later models would work. Also, the app is “aware” of sensors primed by the reader, but not vice-versa, which suggests the reader’s firmware just wouldn’t allow you to scan an already primed sensor.

Here is one tidbit of information I’ll go back to later on. To use the app, you need to sign up for an account, and all the data from the sensor is uploaded to FreeStyle’s servers. The calibration data appears to be among the information shared on the account, which allows you to move the app you use to a new phone without waiting to replace the sensor. This is very important, because you don’t want to throw away your sensor if you break your phone.

The calibration data is then used together with non-disclosed algorithms (also called “curves” in various blogs) to produce the blood glucose equivalent value shown to the user. One important note here is that the reader and the app do not always agree on the value. While I cannot tell for sure what’s going on, my guess is that, as the reader’s firmware is not modifiable, the app contains newer version of the algorithms, and maybe a newer reader device would agree with the app. As I have decided not to focus on reversing the firmware of the reader, I have no answer there.

Can you get answers from the sensor without the calibration data? As I’m not sure what that data is, I can’t give a definite answer, but I will note that there are a number of unofficial apps out there that purport of doing exactly that. These are the same apps that I have, personally, a big problem with, as they provide zero guarantee that their results are at all precise or consistent, and scare the crap out of me, if you plan on making your life and health depend on them. Would the paramedics be able to use one of those apps to provide vague readings off a sensor? Possibly. But let me continue.

The original tweet by Eoghan asks Abbott if it would be possible for paramedics to have a special app to be able to read the sensor. And here is where things get complicated. Because yes, Abbott could provide such an app, as long as the sensor was initialized or calibration-scanned by the app within the calibration hour: their servers have the calibration data, which is needed to move the app between phones without losing data and without waiting for a new sensor.

But even admitting that there is no technical showstopper to such an app, there are many more ethical and legal concerns about it. There’s no way that the calibration data, and even the immediate value, wouldn’t be considered Sensitive Personal Data. This means for Abbott to be able to share it with paramedics, they would have to have a sharing agreement in place, with all the requirements that the GDPR impose them (for good reason).

Adding to this discussion, there’s the question of whether it would actually be valuable to paramedics to have this kind of information. Since I have zero training in the field, I can’t answer for sure, but I would be cautious about trusting the reading of the sensor, particularly if paramedics had to be involved.

The first warning comes from Abbott themselves, that recommend using blood-based test strips to confirm blood sugar readings during rapid glucose changes (in both directions). Since I’m neither trained in chemistry nor medicine, I don’t know why that is the case, but I have read tidbits that it has to do with the fact that the sensor reads values from interstitial fluid, rather than plasma, and the algorithms are meant to correlate the two values. Interstitial fluid measurements can lag behind the plasma ones and thus while the extrapolation can be correct for a smooth change, it might be off (very much so) when they change suddenly.

And as a personal tale, I have experienced the Libre not reporting any data, and then reporting very off values, after spending a couple of hours in very cold environment (in Pittsburgh, at -14°C). Again, see Vandevenne’s blog for what’s going on there with temperatures and thermal compensation.

All in all, I think that I would trust better a single fingerprick to get a normal test-strip result, both because it works universally, whether you do have a sensor or not, and because its limitations are much better understood both by their users and the professionals. And they don’t need to have so many ethical and legal implications to use.

Diabetes Software: the importance of documented protocols

You may remember that just last week I was excited to announce that I had more work planned and lined up for my glucometer utilities, one of which was supporting OneTouch Verio IQ which is a slightly older meter that is still sold and in use in many countries, but for which no protocol is released.

In the issue I linked above you can find an interesting problem: LifeScan discontinued their Diabetes Management Software, and removed it from their website. Indeed instead they suggest you get one of their Bluetooth meters and to use that with their software. While in general the idea of upgrading a meter is sane, the fact that they decided to discontinue the old software without providing protocols is at the very least annoying.

This shows the importance of having open source tools that can be kept alive as long as needed, because there will be people out there that still rely on their OneTouch Verio IQ, or even on the OneTouch Ultra Easy, which was served by the same software, and is still being sold in the US. Luckily at least they at least used to publish the Ultra Easy protocol specs and they are still available on the Internet at large if you search for them (and I do have a copy, and I can rephrase that into a protocol specification if I find that’s needed).

On the bright side, the Tidepool project (of which I wrote before) has a driver for the Verio IQ. It’s not a particularly good driver, as I found out (I’ll get to that later), but it’s a starting point. It made me notice that the protocol was almost an in-between of the Ultra Easy and the Verio 2015, which I already reverse engineered before.

Of course I also managed to find a copy of the LifeScan software on a mostly shady website and a copy of the “cable drivers” package from the Middle East and Africa website of LifeScan, which still has the website design from five years ago. This is good because the latter package is the one that installs kernel drivers on Windows, while the former only contains userland software, which I can trust a little more.

Comparing the USB trace I got from the software with the commands implemented in the TidePool driver showed me a few interesting bits of information. The first being the first byte of commands on the Verio devices is not actually fixed, but can be chosen between a few, as the Windows software and the TidePool driver used different bytes (and with this I managed to simplify one corner case in the Verio 2015!). The second is that the TidePool driver does not extract all the information it should! In particular the device allows before/after meal marking, but they discard the byte before getting to it. Of course they don’t seem to expose that data even from the Ultra 2 driver so it may be intentional.

A bit more concerning is that they don’t verify that the command returned a success status, but rather discard the first two bytes every time. Thankfully it’s very easy for me to check that.

On the other hand, reading through the TidePool driver (which I have to assume was developed with access to the LifeScan specifications, under NDA) I could identify two flaws in my own code. The first was not realizing the packet format between the UltraEasy and the Verio 2015 was not subtly different as I thought, but it was almost identical, except the link-control byte in both Verio models is not used, and is kept to 0. The second was that I’m not currently correctly dropping out control solutions from the readings of the Verio 2015! I should find a way to get a hold of the control solution for my models in the pharmacy and make sure I get this tested out.

Oh yeah, and the TidePool driver does not do anything to get or set date and time; thankfully the commands were literally the same as in the Verio 2015, so that part was an actual copy-paste of code. I should probably tidy up a bit, but now I would have a two-tier protocol system: the base packet structure is shared between the UltraEasy, Verio IQ and Verio 2015. Some of the commands are shared between UltraEasy and Verio IQ, more of them are shared between the Verio IQ and the Verio 2015.

You can see now why I’ve been disheartened to hear that the development of drivers, even for open source software, is done through closed protocol specifications that cannot be published (or the drivers thoroughly commented). Since TidePool is not actually using all of the information, there is no way to tell what certain bytes of the responses represent. And unless I get access to all the possible variants of the information, I can’t tell how some bytes that to me look like constant should represent. Indeed since the Verio 2015 does not have meal information, I assumed that the values were 32-bit until I got a report of invalid data on another model which shares the same protocol and driver. This is why I am tempted to build “virtual” fakes of these devices with Facedencer to feed variants of the data to the original software and see how it’s represented there.

On the bright side I feel proud of myself (maybe a little too much) for having spent the time to rewrite those two drivers with Construct while at 34C3 and afterwards. If I hadn’t refactored the code before looking at the Verio IQ, I wouldn’t have noticed the similarities so clearly and likely wouldn’t have come to the conclusion it’s a shared similar protocol. And no way I could have copy-pasted between the drivers so easily as I did.

Glucometerutils News: Continuous Integration, Dependencies, and Better Code

You may remember glucometerutils, my project of an open source Python tool to download glucometer data from meters that do not provide Linux support (as in, any of them).

While the tool started a few years ago, out of my personal need, this year there has been a bigger push than before, with more contributors trying the tool out, finding problem, fixing bugs. From my part, I managed to have a few fits of productivity on the tool, particularly this past week at 34C3, when I decided it was due time to start making the package shine a bit more.

So let’s see what are the more recent developments for the tool.

First of all, I decided to bring up the Python version requirement to Python 3.4 (previously, it was Python 3.2). The reason for this is that it gives access to the mock module for testing, and the enum module to write actual semantically-defined constants. While both of these could be provided as dependencies to support the older versions, I can’t think of any good reason not to upgrade from 3.2 to 3.4, and thus no need to support those versions. I mean, even Debian Stable has Python 3.5.

And while talking about Python versions, Hector pointed me at construct, which looked right away like an awesome library for dealing with binary data structures. It turned out to be a bit more rough around the edges than I’ve expected from the docs, particularly because the docs do not contain enough information to actually use it with proper dynamic objects, but it does make a huge difference compared to dealing with bytestring manually. I have started already while in Leipzig to use it to parse the basic frames of the FreeStyle protocol, and then proceeded to rewrite the other binary-based protocols, between the airports and home.

This may sound like a minor detail, but I actually found this made a huge difference, as the library already provides proper support for validating expected constants, as well as dealing with checksums — although in some cases it’s a bit heavier-handed than I expected. Also, the library supports defining bit structures too, which simplified considerably the OneTouch Ultra Easy driver, that was building its own poor developer version of the same idea. After rewriting the two binary LifeScan drivers I have (for the OneTouch Verio 2015 and Select Plus, and the Ultra Easy/Ultra Mini), the similarities between the two protocols are much easier to spot. Indeed, after porting the second driver, I also decided to refactor a bit on the first, to make the two look more alike.

This is going to be useful soon again, because two people have asked for supporting the OneTouch Verio IQ (which, despite the name, shares nothing with the normal Verio — this one uses an on-board cp210x USB-to-serial adapter), and I somehow expect that while not compatible, the protocol is likely to be similar to the other two. I ended up finding one for cheap on Amazon Germany, and I ended up ordering it — it would be the easier one to reverse engineer from my backlog, because it uses a driver I already known is easy to sniff (unlike other serial adapters that use strange framing, I’m looking at you FT232RL!), and the protocol is likely to not stray too far from the other LifeScan protocols, even though it’s not directly compatible.

I have also spent some time on the tests that are currently present. Unfortunately they don’t currently cover much of anything beside for some common internal libraries. I have though decided to improve the situation, if a bit slowly. First of all, I picked up a few of the recommendations I give my peers at work during Python reviews, and started using the parameterized module that comes from Abseil, which was recently released opensource by Google. This reduces tedious repetition when building similar tests to exercise different paths in the code. Then, I’m very thankful to Muhammad for setting up Travis for me, as that now allows the tests to show breakage, if there is any coverage at all. I’ll try to write more tests this month to make sure to exercise more drivers.

I’ve also managed to make the setup.py in the project more useful. Indeed it now correctly lists dependencies for most of the drivers as extras, and I may even be ready to make a first release on PyPI, now that I tested most of the devices I have at home and they all work. Unfortunately this is currently partly blocked on Python SCSI not having a release on PyPI itself. I’ll get back to that possibly next month at this point. For now you can install it from GitHub and it should all work fine.

As for the future, there are two in-progress pull requests/branches from contributors to add support for graphing the results, one using rrdtool and one using gnuplot. These are particularly interesting for users of FreeStyle Libre (which is the only CGM I have a driver for), and someone expressed interest in adding a Prometheus export, because why not — this is not as silly as it may sound, the output graphs of the Libre’s own software look more like my work monitoring graphs than the usual glucometer graphs. Myself, I am now toying with the idea of mimicking the HTML output that the Accu-Check Mobile generate on its own. This would be the easiest to just send by email to a doctor, and probably can be used as a basis to extend things further, integrating the other graphs output.

So onwards and upwards, the tooling will continue being built on. And I’ll do my best to make sure that Linux users who have a need to download their meters’ readings have at least some tooling that they can use, and that does not require setting up unsafe MongoDB instances on cloud providers.

Diabetes management software, online apps, and my projects

So my previous post with glucometerutils news got picked up by Hackaday, and though the comments ended up mostly talking about the (more physical, less practical) note about fiddling with the glucometers hardware themselves (which would suggest me the editor should probably have avoided moving the spotlight in the post, but never mind), I ended up replying to a few comments that were actually topical, to the point that I thought I should be writing about this more extensively.

In the comments, someone brought up Tidepool, which is a no-profit in California that develops what to me appears to be its own data storage and web application for diabetics. This is not far from what Glucosio is meant to be — and you might remember that an interaction with them, had me almost leave open source development, at least for what diabetes is concerned.

The problem with both projects, and a number of others that I’ve been pointed to over the years, is that I find most of them either not practical or web-oriented, or a mixture of the two. With not practical I mean that while building an “universal glucometer” capable of using any random strip is an interesting proposal, it does nothing to improve the patients’ life, and it actually can significantly increase the risks of misreading values and thus, risk the life of the user. For this reason, plus the fact that I do not have enough of a biochemistry understanding to figure out how to evaluate the precision of the meters that are already certified, I don’t invest any time looking into these projects.

Web-based applications such as Tidepool and similar are also far from my interests. I do not have a personal problem with accessing my blood sugar readouts for the sake of research, but I do have some concerns about which actors are allowed access to them. So in particular a startup like Glucosio is not someone I’d be particularly fond of giving access to my data to. Tidepool may be a no-profit, but that does not really make me feel much better, particularly because I would expect that an US-based no-profit would not have gone through all the possible data processing requirements of EU legislation, unlike, say, Abbott. I have already written a lot about why I don’t find self-hosting a good solution so I don’t think I need to spend much time on it here.

Except, there is one extra problem with those apps that require you to set up your own instance — like some of the people who have not been waiting some time ago. While running an app for my own interest may sound like an interesting thing to do, particularly if I want to build up the expertise to run complicated web app stacks, my personal ultimate goal is to have my doctor know what my blood sugar levels are over time. This is the whole point why I started that tool, I wanted to be able to output a PDF that my doctor could see without having to jump around a number of hoops to produce it — I failed to do so, but in part because I lost interest after I started using the awesome Accu-Chek Mobile.

If I were to tell my doctor «Log in on this site here with these credentials and you can see my readouts» he might actually do it, but mostly because of novelty and because he entertains my geekery around trying different meters and solutions. If he started to get this request from dozens of his patients, not only he’d have to keep a password managers just to deal with credentials, but he’d probably just couldn’t have the time to deal with it. The LibreLink app does have the ability to share data with a few services, and he did suggest me to look into diasend, but it looks like it got merged into something else that might or might not work for now, so I gave up.

Now, here is an interesting prospect, and why such apps are not completely worthless in my opinion. If the protocols are open to be used, and the apps are open source and can be set up by anyone, there is space for the doctors to have their own instance set up so that their patients can upload their data. Unfortunately, the idea that being open source this does not involve a significant investment in time and money is patently false. Particularly for important data like this, there has to be proper security, starting from every session being encrypted with TLS, and the data encrypted at rest (it is ironic that neither Tidepool nor Glucosio, at the time of writing, use TLS for their main websites). So I still don’t expect doctors in the public sector to be using these technologies any time soon. But on the other hand, there are more and more apps for this being built by the diabetes tech companies, so maybe we’ll see something happening in the future.

Where does this leave my project? Well, to begin with it’s not a single project but two of them. glucometerutils was born as a proof of concept and is still a handy tool to have. If someone manages to implement output to HTML or to PDF of the data, that would make it a very useful piece of software that does not need to interact with any remote, online application. The protocols repository serves a distinct need: it provides a way for more people to contribute to this ecosystem without requiring each of them to invest significant time in reversing the protocols, or getting in bed with the manufacturers, which – I can only guess – involves NDAs, data-sharing agreements, and similar bureaucracy that most hobbyist developers can’t afford.

Indeed, I know of at least one app, built for iOS, proprietary and commercial (as in, you have to pay for it), that has built support for meters thanks to my repository (and the author gave back in form of corrections and improvements on the documentation!). This is perfectly in line with my reasons to even have such a repository. I don’t care if the consumers and contributors to the repository build closed-source tools, as long as they share the knowledge on how to get to the data. And after that, may the best tool win.

As I said before, smartphones are no longer a luxury and for many people they are the only way they can access the Internet. It makes sense that the same way, for many diabetics it is their only way to analyse their readouts. This is why Contour Next One comes with Bluetooth and a nice app, and why there even are standard Bluetooth specification for glucometers (GLP/GLS) and continuous monitors (CGMP/CGMS). If my work on an open-source tool brings more people the ability to manage their diabetes, even with closed-source software, I’ll consider myself satisfied.

Now, there is one more interesting bit with Tidepool, though: they actually publish a Chrome-based uploader app that is able to download data from many more glucometers than my own tool (and the intersection between the two is minimal). This is great! But, as it happens, it comes with a little bit of a downside: the drivers are not documented at all. I confirmed the reason is that the access to the various meters’ protocols is subject to NDA — so while they can publish the code that access those meters, they cannot publish the specs of the protocols themselves, and that appears to include in-code comments that would make it easy to read what’s going on.

So, one of the things I’m going to do is read through those drivers, and try to write a protocol spec for the meters. It appears that they have a driver for Contour Next meters, which may or may not work for the Contour Next One which I’ve been trying to reverse engineer — I know there is at least one other open-source implementation of accessing data from Contour Next meters, but the other one is GPL-2 and, like OpenGlucose, I’ve avoided looking too closely to the code.

Projects such as Tidepool are extremely important to provide a proper alternative to the otherwise closed-garden of proprietary cloud diabetes management software. And if they become simple, and secure enough to set up, it is possible that some of the doctors will start providing their own instances where their patients can upload the readings, and that will make them also practical. But for now, to me they are only a good source of confrontation to figure out a way forward for my own tools.

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.

Reverse Engineering Notes: Accu-Chek Mobile

A couple of years ago, upon suggestion by a reader of this blog, I switched my glucometer to an Accu-Chek Mobile by Roche. I have not even looked into reverse engineering it at the time, as the killer application of that meter was not needing software at all. Indeed all the data is made available over a USB Mass Storage interface as CSV and graphs.

While there is a secondary interface available on the device to connect to software on PC, you had to order a copy of the download software online and receive it physically to be able to download the data to a computer, which I still find kind of silly for a device that is designed to have a standard USB connector.

Things changed recently, as Roche joined Abbott (and probably more to come) on the bandwagon of “show us yours”: upload your blood glucose reading to their cloud systems, and they will help you managing diabetes. I guess this is what happens when people are not waiting. I’m not particularly fond of uploading my health information to the cloud, but signing up for this service also meant being able to grab a proper chatter of the protocol over USB.

The software I’m using right now for snooping over the USB connection is USBlyzer which is proprietary and closed source — I’m not proud, but it gets its job done. I have been thinking of switching of a hardware snooping solution, and I bought a BeagleBone Black to use for that, but I have not started working on that due to time.

So instead, I have collected over time a set of libraries and utilities that operate on the CSV files that the software export (particularly as with version 2.2 they are actually quite well written, the older version was messier to post-process). I should look into publishing this collection, and I promise I’ll give it a try to publish before end of this year.

One of the tools I have prints out the “chatter”, coded hexdumps with include direction information to make it easier for me to read the stream. The first run of it was a bit noisy, but a quick check told me that what I’m interested in is bulk transfers (rather than control transfers, which are the most basic), so I filtered for those only, and then the first thing became obvious very quickly.

The maximum length of the bulk transfers in the trace is 64 bytes, which corresponds to the maximum size of bulk transfers for full speed endpoints. But the chatter shows the device sending multiple packets back from a single command, which is not unusual, as you can’t fit much blood sugar data in 64 bytes. And as usual when there is fragmentation, the actual data transfer size is coded somewhere at the beginning of the message.

0023 >>>> 00000000: E3 00 00 2C 00 03 50 79  00 26 80 00 00 00 80 00  ...,..Py.&......
0023 >>>> 00000010: 80 00 00 00 00 00 00 00  80 00 00 00 00 08 00 60  ...............`
0023 >>>> 00000020: 19 00 01 08 00 00 00 00  00 01 01 01 00 00 00 00  ................

0025 <<<< 00000000: E7 00 01 0A 01 08 00 00  01 01 01 02 00 00 FF FF  ................
0025 <<<< 00000010: FF FF 0D 1C 00 F8 50 00  00 05 00 F2 00 06 00 01  ......P.........
0025 <<<< 00000020: 00 04 00 24 09 2F 00 04  00 02 71 BC 0A 46 00 02  ...$./....q..F..
0025 <<<< 00000030: F0 40 09 96 00 02 08 52  0A 55 00 0C 00 02 00 08  .@.....R.U......
0025 <<<< 00000040: 09 90 00 08 0A 4C 00 02  00 06 00 02 00 04 00 24  .....L.........$
0025 <<<< 00000050: 09 2F 00 04 00 02 71 D0  0A 46 00 02 F0 40 09 96  ./....q..F...@..
0025 <<<< 00000060: 00 02 08 52 0A 55 00 0C  00 02 00 08 09 90 00 08  ...R.U..........
0025 <<<< 00000070: 0A 4C 00 02 00 05 00 03  00 03 00 1E 09 2F 00 04  .L.........../..
0025 <<<< 00000080: 00 80 71 D8 0A 46 00 02  F0 40 0A 55 00 0C 00 02  ..q..F...@.U....
0025 <<<< 00000090: 00 08 09 90 00 08 0A 66  00 02 00 05 00 04 00 03  .......f........
0025 <<<< 000000A0: 00 1E 09 2F 00 04 00 80  72 48 0A 46 00 02 F0 48  .../....rH.F...H
0025 <<<< 000000B0: 0A 55 00 0C 00 02 00 08  09 90 00 08 0A 49 00 02  .U...........I..
0025 <<<< 000000C0: 00 3D 00 05 00 08 00 46  0A 4D 00 02 98 20 09 43  .=.....F.M... .C
0025 <<<< 000000D0: 00 02 00 00 09 41 00 04  00 00 17 70 09 44 00 04  .....A.....p.D..
0025 <<<< 000000E0: 00 00 01 E5 09 53 00 02  00 00 0A 57 00 12 00 10  .....S.....W....
0025 <<<< 000000F0: 50 61 74 69 65 6E 74 20  52 65 73 75 6C 74 73 00  Patient Results.
0025 <<<>>> 00000000: E7 00 00 0E 00 0C 00 01  01 03 00 06 00 00 00 00  ................
0047 >>>> 00000010: 00 00                                             ..

0049 <<<< 00000000: E7 00 00 F6 00 F4 00 01  02 03 00 EE 00 00 00 08  ................
0049 <<<< 00000010: 00 E8 09 28 00 0E 00 06  52 6F 63 68 65 00 00 04  ...(....Roche...
0049 <<<< 00000020: 31 32 30 35 09 84 00 0A  00 08 00 60 19 04 B5 1B  1205.......`....
0049 <<<< 00000030: DF 5C 0A 44 00 02 40 00  09 2D 00 78 00 04 00 74  ..D..@..-.x...t
0049 <<<< 00000040: 00 01 00 00 00 18 73 65  72 69 61 6C 2D 6E 75 6D  ......serial-num
0049 <<<< 00000050: 62 65 72 3A 20 30 30 31  38 32 36 36 35 32 00 04  ber: 001826652..
0049 <<<< 00000060: 00 00 00 14 73 77 2D 72  65 76 20 4D 45 3A 20 56  ....sw-rev ME: V
0049 <<<< 00000070: 30 33 2E 31 33 20 20 20  00 05 00 00 00 16 66 77  03.13   ......fw
0049 <<<< 00000080: 2D 72 65 76 69 73 69 6F  6E 3A 20 56 30 33 2E 39  -revision: V03.9
0049 <<<< 00000090: 30 20 20 20 00 06 00 00  00 1A 70 72 6F 74 6F 63  0   ......protoc
0049 <<<< 000000A0: 6F 6C 2D 72 65 76 69 73  69 6F 6E 3A 20 52 50 43  ol-revision: RPC
0049 <<<< 000000B0: 20 31 2E 30 09 87 00 08  20 17 02 24 21 07 00 00   1.0.... ..$!...
0049 <<<< 000000C0: 0A 45 00 10 C0 00 1F 00  FF FF FF FF 00 64 00 00  .E...........d..
0049 <<<< 000000D0: 00 00 00 00 0A 4B 00 16  00 02 00 12 02 01 00 08  .....K..........
0049 <<<< 000000E0: 01 05 00 01 00 02 20 11  02 02 00 02 00 00 0A 5A  ...... ........Z
0049 <<<< 000000F0: 00 08 00 01 00 04 10 11  00 01                    ..........

As you can see in this particular exchange, bytes at offset 2-3 represent a (big-endian) length for the whole transfer. You just keep reading until that is complete.

While I have not (yet at the time of writing) figured out what the command and response actually convey, one thing that is kind of obvious is that there is some kind of (type-)length-value encoding at play, although in a bit of a funny way.

All records with type 0xE700 appear to have two-level lengths, as you can see on the two responses and the second command: in red it’s the length of the packet, in magenta the same length minus two (which matches the size of the length itself). There are also a number of strings, some zero terminated (Roche) and some not (1205), but still encoded with a 16-bit length in front of them.

The next thing to figure out in these cases is whether there is a checksum or not. For effectively all the meters I have reverse engineered up to now, except for maybe the cheap Korean one, include a checksum somewhere. I checked the chatter and found that there are a number of packets that appear to include the same information, but adding a checksum to the packet showed them different.

Once I dumped the (recomposed) packets to binary files, I noticed a number of packets with the same sizes. hexdump, wdiff and colordiff make it very easy to tell what changed between them. It didn’t quite look like a cryptographic checksum, as changing one byte would replace it with a very different number, but it didn’t quite match up with a “dumb” checksum of all the bytes values.

A couple of diff later, it become obvious.

[flameeyes@saladin Accu-Chek]$ wdiff <(hexdump -C 0039-0034-in) <(hexdump -C 0049-0046-in) | colordiff
00000000  e7 00 00 f6 00 f4 00 [-2d-] {+01+}  02 03 00 ee 00 00 00 08  [-|.......-........|-]  {+|................|+}
00000010  00 e8 09 28 00 0e 00 06  52 6f 63 68 65 00 00 04  |...(....Roche...|
00000020  31 32 30 35 09 84 00 0a  00 08 00 60 19 04 b5 1b  |1205.......`....|
00000030  df 5c 0a 44 00 02 40 00  09 2d 00 78 00 04 00 74  |..D..@..-.x...t|
00000040  00 01 00 00 00 18 73 65  72 69 61 6c 2d 6e 75 6d  |......serial-num|
00000050  62 65 72 3a 20 30 30 31  38 32 36 36 35 32 00 04  |ber: 001826652..|
00000060  00 00 00 14 73 77 2d 72  65 76 20 4d 45 3a 20 56  |....sw-rev ME: V|
00000070  30 33 2e 31 33 20 20 20  00 05 00 00 00 16 66 77  |03.13   ......fw|
00000080  2d 72 65 76 69 73 69 6f  6e 3a 20 56 30 33 2e 39  |-revision: V03.9|
00000090  30 20 20 20 00 06 00 00  00 1a 70 72 6f 74 6f 63  |0   ......protoc|
000000a0  6f 6c 2d 72 65 76 69 73  69 6f 6e 3a 20 52 50 43  |ol-revision: RPC|
000000b0  20 31 2e 30 09 87 00 08  20 17 02 24 21 [-06 53-] {+07 00+} 00  | 1.0.... [-..$!.S.|-] {+..$!...|+}
000000c0  0a 45 00 10 c0 00 1f 00  ff ff ff ff 00 64 00 00  |.E...........d..|
000000d0  00 00 00 00 0a 4b 00 16  00 02 00 12 02 01 00 08  |.....K..........|
000000e0  01 05 00 01 00 02 20 11  02 02 00 02 00 00 0a 5a  |...... ........Z|
000000f0  00 08 00 01 00 04 10 11  00 01                    |..........|
000000fa
[flameeyes@saladin Accu-Chek]$ wdiff <(hexdump -C 0039-0034-in) <(hexdump -C 0073-0068-in) | colordiff
00000000  e7 00 00 f6 00 f4 00 [-2d-] {+02+}  02 03 00 ee 00 00 00 08  [-|.......-........|-]  {+|................|+}
00000010  00 e8 09 28 00 0e 00 06  52 6f 63 68 65 00 00 04  |...(....Roche...|
00000020  31 32 30 35 09 84 00 0a  00 08 00 60 19 04 b5 1b  |1205.......`....|
00000030  df 5c 0a 44 00 02 40 00  09 2d 00 78 00 04 00 74  |..D..@..-.x...t|
00000040  00 01 00 00 00 18 73 65  72 69 61 6c 2d 6e 75 6d  |......serial-num|
00000050  62 65 72 3a 20 30 30 31  38 32 36 36 35 32 00 04  |ber: 001826652..|
00000060  00 00 00 14 73 77 2d 72  65 76 20 4d 45 3a 20 56  |....sw-rev ME: V|
00000070  30 33 2e 31 33 20 20 20  00 05 00 00 00 16 66 77  |03.13   ......fw|
00000080  2d 72 65 76 69 73 69 6f  6e 3a 20 56 30 33 2e 39  |-revision: V03.9|
00000090  30 20 20 20 00 06 00 00  00 1a 70 72 6f 74 6f 63  |0   ......protoc|
000000a0  6f 6c 2d 72 65 76 69 73  69 6f 6e 3a 20 52 50 43  |ol-revision: RPC|
000000b0  20 31 2e 30 09 87 00 08  20 17 02 24 21 [-06 53-] {+07 02+} 00  | 1.0.... [-..$!.S.|-] {+..$!...|+}
000000c0  0a 45 00 10 c0 00 1f 00  ff ff ff ff 00 64 00 00  |.E...........d..|
000000d0  00 00 00 00 0a 4b 00 16  00 02 00 12 02 01 00 08  |.....K..........|
000000e0  01 05 00 01 00 02 20 11  02 02 00 02 00 00 0a 5a  |...... ........Z|
000000f0  00 08 00 01 00 04 10 11  00 01                    |..........|
000000fa
[flameeyes@saladin Accu-Chek]$ wdiff <(hexdump -C 0039-0034-in) <(hexdump -C 0087-0084-in) | colordiff
00000000  e7 00 00 f6 00 f4 00 [-2d-] {+04+}  02 03 00 ee 00 00 00 08  [-|.......-........|-]  {+|................|+}
00000010  00 e8 09 28 00 0e 00 06  52 6f 63 68 65 00 00 04  |...(....Roche...|
00000020  31 32 30 35 09 84 00 0a  00 08 00 60 19 04 b5 1b  |1205.......`....|
00000030  df 5c 0a 44 00 02 40 00  09 2d 00 78 00 04 00 74  |..D..@..-.x...t|
00000040  00 01 00 00 00 18 73 65  72 69 61 6c 2d 6e 75 6d  |......serial-num|
00000050  62 65 72 3a 20 30 30 31  38 32 36 36 35 32 00 04  |ber: 001826652..|
00000060  00 00 00 14 73 77 2d 72  65 76 20 4d 45 3a 20 56  |....sw-rev ME: V|
00000070  30 33 2e 31 33 20 20 20  00 05 00 00 00 16 66 77  |03.13   ......fw|
00000080  2d 72 65 76 69 73 69 6f  6e 3a 20 56 30 33 2e 39  |-revision: V03.9|
00000090  30 20 20 20 00 06 00 00  00 1a 70 72 6f 74 6f 63  |0   ......protoc|
000000a0  6f 6c 2d 72 65 76 69 73  69 6f 6e 3a 20 52 50 43  |ol-revision: RPC|
000000b0  20 31 2e 30 09 87 00 08  20 17 02 24 [-21 06 53-] {+20 55 15+} 00  | 1.0.... [-..$!.S.|-] {+..$ U..|+}
000000c0  0a 45 00 10 c0 00 1f 00  ff ff ff ff 00 64 00 00  |.E...........d..|
000000d0  00 00 00 00 0a 4b 00 16  00 02 00 12 02 01 00 08  |.....K..........|
000000e0  01 05 00 01 00 02 20 11  02 02 00 02 00 00 0a 5a  |...... ........Z|
000000f0  00 08 00 01 00 04 10 11  00 01                    |..........|
000000fa

It may become much clearer if you go back at the first dump and observe the part highlighted in blue: it’s 8 bytes that represent 20 17 02 24 21 07 00 00. To help understanding this, you should know that I was looking at this around 9pm on February 24th, 2017. Indeed, these bytes effectively represent the date and time in binary-coded decimal, which is not something I was expecting to see, but make sense.

Once you know this, it’s easy to tell that there is no checksum in the messages, and that is one less problem to worry about. Indeed, when looking for the “big” packets, I could find the telltale representation of fixed-size records with what looked like (and I confirmed being) glucometer readings (in mg/dL, even though the device is mmol/l based).

If you’re wondering why the peculiar change in time on the last part of the diff, the reason is quite simple: the software noted that the time on the device didn’t match the time on the computer, and asked me to sync it. Which means I also know the command to set the time now.

Looking at the commands, there are a few more things that are interesting to see:

0037 >>>> 00000000: E7 00 00 0E 00 0C 00 2D  01 03 00 06 00 00 00 00  .......-........
0037 >>>> 00000010: 00 00                                             ..

0047 >>>> 00000000: E7 00 00 0E 00 0C 00 01  01 03 00 06 00 00 00 00  ................
0047 >>>> 00000010: 00 00                                             ..

0071 >>>> 00000000: E7 00 00 0E 00 0C 00 02  01 03 00 06 00 00 00 00  ................
0071 >>>> 00000010: 00 00                                             ..

0081 >>>> 00000000: E7 00 00 1A 00 18 00 03  01 07 00 12 00 00 0C 17  ................
0081 >>>> 00000010: 00 0C 20 17 02 24 20 54  57 00 00 00 00 00        .. ..$ TW.....

0085 >>>> 00000000: E7 00 00 0E 00 0C 00 04  01 03 00 06 00 00 00 00  ................
0085 >>>> 00000010: 00 00                                             ..

0095 >>>> 00000000: E7 00 00 14 00 12 00 05  01 07 00 0C 00 05 0C 0D  ................
0095 >>>> 00000010: 00 06 00 01 00 02 00 00                           ........

The time change command is 0081 (and I highlighted in green the new time, also provided as BCD). The remaining commands appear to be querying some information about the device. Commands 0037, 0047, 0071 and 0085 are exactly the same, except as I found out initially, no packet was identical. In blue I highlighted what appears to be a packet counter of sorts. I’m not sure why it starts at 0x2D, but after that it appears to increment normally, although only after 0xE7 commands (there appear to be a handful more).

Unfortunately this does not cover enough of the protocol yet, but it’s a good starting point for a few hours spent trying to prod things around on a Friday night (what an exciting life I live). I also managed to find how the device is reporting the readings, in blocks of less than 1KB records, but I have not figure out how the software knows when to stop asking for them. In this case it definitely is handy that I have so many readings on the device — this is probably the glucometer I used the most, and I still think is the best blood-reading glucometer, for handiness and results.

Stay tuned for more details, and hopefully to see a spec for the protocol soon, too.

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.