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.

Diabetes control and its tech: reverse engineering the OneTouch Verio

Bear with me — this post will start with a much longer trial-and-error phase than the previous one…

I have received the OneTouch Verio glucometer from LifeScan last year, when I noticed that my previous glucometer (the protocol of which was fully specified on their website) was getting EOL’d. I have used it for a couple of months, but as I posted that review, I was suggested a different one, so I moved on. It was for a while in the back of my mind as LifeScan refused providing the protocol for it, though.

So over the past week, after finishing the lower-hanging fruit I decided to get serious and figure out how this device worked.

First of all, unlike the older OneTouch devices I own, this device does not use a TRS (stereo-jack) serial port, instead it comes with a standard micro-A USB connector. This is nice as the previous cables needed to be requested and received before you could do anything at all with the software.

Once connected, the device appears to the operating system as a USB Mass Storage device – a thumbdrive – with a read-only FAT16 partition with a single file in it, an HTML file sending you to LifeScan’s website. This is not very useful.

My original assumption was that the software would use a knocking sequence to replace the mass storage interface with a serial one — this is what most of the GSM/3G USB modems do, which is why usb_modeswitch was created. So I fired the same USBlyzer (which by now I bought a license of, lacking a Free Software alternative for the moment) and started tracing. But not only no new devices or interfaces appeared on the Device Manager tree, I couldn’t see anything out of the ordinary in the trace.

Since at first I was testing this on a laptop that had countless services and things running (this is the device I used for the longest time to develop Windows software for customers), I then wanted to isolate the specific non-mass storage USB commands the software had to be sending to the device, so I disabled the disk device and retried… to find the software didn’t find the meter anymore.

This is when I knew things were going to get complicated (thus why I moved onto working on the Abbott device then.) The next step was to figure out what messages were the computer and meter exchanging; unfortunately USBlyzer does not have a WireShark export, so I had to make do with exporting to CSV and then reassembling the information from that. Let me just say it was not the easiest thing to do, although I now have a much more polished script to do that — it’s still terrible so I’m not sure I’m going to publish it any time soon though.

The first thing I did was extracting the URBs (USB Request Blocks) in binary form from the hex strings in the CSV. This would allow me to run strings on them, in the hope of seeing something such as the meter’s serial number. When reverse engineering an unknown glucometer protocol, it’s good to keep in mind essentially all diabetes management software relies on the meters’ serial numbers to connect the readings to a patient. As I’ve later discovered, I was onto something, but either strings is buggy or I used the wrong parameters. What I did find then was a lot of noise with MSDOS signatures (for MBR and FAT16) appearing over and over. Clearly I needed better filtering.

I’ve enhanced the parsing to figure out what the URBs meant. Turns out that USB Mass Storage uses signatures USBC and USBS (for Command and Status) – which also explained why I saw them in the Supermicro trace – so it’s not too difficult to identify them, and ignore them. Once I did that, the remaining URBs didn’t make much sense either, particularly because I could still notice they were only the data being written and read (as I could see many of them matched with blocks from the device’s content.)

So I had to dig further. USB is somewhat akin to a networking stack, with different layers of protocols one on top of the other — the main difference being that the USB descriptor (the stuff lsub -v prints) containing the information for all levels, rather than providing that information on each packet. A quick check on the device’s interface tells me indeed that it’s a fairly standard one:

Interface Descriptor:
  bLength                 9
  bDescriptorType         4
  bInterfaceNumber        0
  bAlternateSetting       0
  bNumEndpoints           2
  bInterfaceClass         8 Mass Storage
  bInterfaceSubClass      6 SCSI
  bInterfaceProtocol     80 Bulk-Only
  iInterface              7 LifeScan MSC

What this descriptor says is that the device is expecting SCSI commands, which is indeed the case of most USB thumbdrives — occasionally, a device might report itself as using the SDIO protocol, but that’s not very common. The iInterface = LifeScan MSC setting, though, says that there is an extension of the protocol that is specific to LifeScan. Once again here I thought it had to be some extension to the SCSI command set, so I went to look for the specs of the protocol, and started looking at the CDBs (command blocks.)

I’m not sure at this point if I was completely surprised not to see any special command at all. The only commands in the trace seemed to make sense at the time (INQUIRY, READ, WRITE, TEST MEDIA READY, etc). It was clear at that point that the software piggybacked the standard volume interface, but I expected it to access some hidden file to read the data, so I used an app to log the filesystem access and… nothing. The only files that were touched were the output Access files used by the tool.

I had to dig deeper, so I started parsing the full CDBs and looked at which part of the disk were accessed — I could see some scattered access to what looked like the partition table (but wasn’t it supposed to be read-only?) and some garbage at the end of the disk with System Volume Information. I dumped the content of the data read and written and used strings but couldn’t find anything useful, even looking for Unicode characters. So I took another trace, started it with the device already connected this time, and compared — that started sending me to the right direction: I could see a number of write-then-read requests happening on three particular blocks: 3, 4 and 5.

At that point I tried to focus on the sequence of writes and reads on those blocks, and things got interesting: some of the written and read data had the same content across sessions, which meant there was communication going on. The device is essentially exposing a register-based communication interface-over-SCSI-over-USB. I’m not sure if brilliant or crazy. But the problem remained of understanding the commands.

At this point was hoping to get some help by looking at what commands were actually being sent to the kernel, so I downloaded the latest Windows SDK and fired up WinDbg, hoping to log the events. I didn’t that, but I did find something even more interesting. The OneTouch software and drivers have been built with debug logging still on, probably because nobody would notice there is logging unless they attach a debugger… just like I did. This was a lucky breakthrough because it allowed me to see what driver the software used (and thus its symbol table and function names — yes, PE would allow you to obfuscate the function names by using an import library, but they didn’t) and also to see what it thoughts about things.

An interesting discovery is that the software seems to communicate with its drivers via XML documents (properly human-readable ones at that), while the driver seemed to talk to the device via binary commands. Unfortunately, said commands didn’t match what I was seeing in the trace, at least not fully — I could find some subsets of data here and there, but not consistently, it looks like one of the libraries is translating from the protocol the device actually accepted to another (older?) binary protocol, to speak to a driver that then converted it to XML and to the device. This does sound dopey, doesn’t it?

Anyway, I decided to then start matching messages in the sequences. This started to be interesting. Using hexdump -C to have a human-readable copy of the content of the SCSI blocks written and read, I would see the first few lines matching between messages in the same sequence, while those after 255 bytes to be different, but in a predictable way: a four-bytes word would appear at a certain address, and the following words would have the same distance from it. I was afraid this was going to be some sort of signature or cryptographic exchange — until I compared this with the trace under WinDbg, that had nothing at all after the first few lines. I then decided to filter anything after the first 16-bytes of zeros, and compare again.

This lead to more interesting results. Indeed I could see that across the three sessions, some packets would be exactly the same, while in others the written packet would be the same and the read packet would be different. And when they would be different, there would be a byte or two different and then the last two bytes would differ. Now one of the things I did when I started looking at WinDbg, was checking the symbol table of the libraries that were used by the software, and one of them had a function that included crc_ccitt in its name. This is a checksum algorithm that LifeScan used before — but with a twist there as well, it used a non-standard (0xFFFF) seed. Copying the packet up until the checksum and pasting it in an online calculator confirmed that I now found the checksum of the packet.

At that point I opened the OneTouch UltraEasy specs (an older meter, of which LifeScan published the protocol), which shared the same checksum, and noticed at least one more similarity: the messages are framed the same with (0x02 at the beginning, 0x03 at the end). And the second byte matches the length of the packet. A quick comparison with the log I got off the debugger, and the other binary protocol does not use the framing but does use the same length specification and the same checksum algo. Although in this case I could confirm the length is defined as 16-bit, as this intermediate protocol reassembled what soon clearly appeared to be a set of separate responses into one.

Once you get to this point, figuring out the commands is much easier than you think — some of them will return things such as the serial number of the device (printed on the back), the model name, or the software version, which the debug log let me match for sure. I was confused at first because strings -el can’t find them in the binary files, but strings -eb did… they are not big-endian though. At tis point, there are a few things that need to be figured out to write a proper useful driver for the meter.

The first low-hanging fruit is usually to be found in the functions to get and set time, which, given I couldn’t see any strings around, I assumed to be some sort of timestamp — but I couldn’t find anything that looked like the day’s timestamp in the trace. To be honest, there was an easier way to figure this out, but the way I did that, was by trying to figure out the reading record format. Because something that looked like a 32-bit counter in high numbers could be found, so I compared that with one that looked like it in a promising command, and I looked at the difference — the number, interpreted as seconds, gave me a 22 weeks delta, which matched the delta between the last reading and the trace — I was onto something! Given I knew the exact timestamp of the last reading, the difference between that and the number I had brought me exactly to January 1st 2000, the device’s own epoch.

Once again, from there things get easier — the format of the records is simple, includes a counter and what I soon realized to be a lifetime counter, the timestamp with the device’s own epoch, some (still unknown) flags, and the reading value in mg/dL as usual for most devices. What was curious was that the number shown in the debug log’s XML does not match the mg/dL reading, but the data in the protocol match what the device and software show for each readings, so it’s okay.

While I was working on this, I got approached over twitter from someone having a OneTouch Select Plus meter, which is not sold in Ireland at all. I asked him for a trace of the device and I compared it with my tools and the reverse engineering I had to that point, and it appears to be using the same protocol, although it replies with a lot more data to one of the commands I have not found the meaning of (and that the device don’t seem to need — there’s no knock sequence, so it’s either to detect some other model, or a kind of ping-back to the device.) The driver I wrote should work for both. Unfortunately they are both mmol/L devices, so I can’t for sure tell which unit the device is supposed to use.

One last curiosity, while comparing the protocol as I reversed it and the OneTouch UltraEasy protocol that was published by LifeScan. Many of the commands are actually matching, including the “memory reset” one, with one difference: whereas the UltraEasy commands (after preamble) start with 0x05, the Verio commands start with 0x04 — so for instance memory reset is 05 1a on the UltraEasy, but 04 1a on the Verio.

The full documentation of the protocol as I reversed it is available on my repository and glucometerutils gained an otverio2015 driver. For the driver I needed to fix the python-scsi module to actually work to send SCSI commands over the SGIO interface in Linux, but that is fixed upstream now.

If you happen to have this device, or another LifeScan device that appears as a USB Mass Storage, but using mg/dL (or something that does not appear to work with this driver), please get in touch so I can get a USB trace of its dumping memory. I could really use the help.

I won’t be spending time reverse engineering anything this weekend, because I’m actually spending time with friends, but I’ll leave you confirming that there will be at least one more device getting reverse engineered soon, but the next post will first be a review of it. The device is the Abbott FreeStyle Libre, for which I can’t link a website, as it would just not appear if you’re not in one of (the one?) country it’s sold in. Bummer.

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!

New glucometer: LifeScan OneTouch Verio

I have visited LifeScan’s website and I noticed that their homepage is suggesting people with glucometers of the OneTouch Ultra series to upgrade to a new series. The reason for the change is purported to be found in new regulations on quality and precision of glucometers, but I could not find any reference for it.

As usual, this is a free upgrade – glucometer manufacturers are generally happy to send you a free meter, since they make most of the money on the testing strips instead – so I ordered one, and I received it (or rather picked it up) this Monday. It’s a OneTouch Verio.

The first impression is that it’s a very bad match for my previous Ultra Mini: it’s big and clunky. The whole case is about twice as big in volume. For me, as I travel a lot, this is a bit of a problem.

On the bright side, this is the first meter that I own that is not powered by CR2032 button cells. This model uses AAA batteries, which not only are much simpler to source, but are already always present in my luggage, as my noise-cancelling headphones uses the same. I also bought a 40-pack of them last time I’ve been to Fry’s.

Also, while the upgrade from OneTouch Ultra 2 to Ultra Mini maintained the same set of testing strips, the Verio comes with a new strip type. This puts it into the same bucket as the Abbott Precision Xtra in my perception, which also requires a different set of testing strips. The reason why I consider those the same is that they both have “costs” associated with the change in strips. In particular since I already have two meters (actually, three if I count the one that is set to Italian readings), which means I can keep one at home and one at the office.

Similarly to the Abbott device, and unlike the Ultras, the new strips are not coded — it makes sense since the Ultra strips also have had the same code – 25 – for the past four years. This is good because at least once every two weeks I have to draw a second sample of blood because I put the first one too soon, before the meter accepted the code. These strips also require less blood than the old ones, and even less than the Abbott strips. Funnily enough, I never got in Europe the “new” Ultra strips I’ve used in the USA before, which require about half the blood as the standard European strips. Go figure.

Also most obvious difference in these trips is that they load blood on the side rather than the tip. I’m not sure why, but I like it — it feels like it’s less likely to get ruined when you shake the strip bottle.

New meter also means new protocols of course. Unfortunately, LifeScan already refused sending me the protocol of this device, which once again puts it into the same category as Abbott’s. Interestingly enough, unlike both Abbott and the old Ultras, this device has a standard microUSB connection. Unfortunately by default it shows up as a mass-storage device with exactly one file in it: a redirect to the LifeScan website. I assume the software (which I have not installed yet) will modeswitch it to serial somehow and then proceed from there. If I had enough time I’d be setting up my Windows laptop for logging USB traffic and try to reverse engineer both this and Abbott’s protocol.

Funnily enough there is another meter, called OneTouch Verio Flex only available in Ireland, which has bluetooth connectivity. Whereas there’s the Verion Sync in the USA, which syncs with an iPhone app (no Android app, though.) I wonder if I should call them up and see if I can get myself one of those as well; it uses the same strips and would solve my problem of having more than one meter using the same stash of strips.

The meter also came with the new “OneTouch Delica” lancing system. Once again the same that was true of the meter is true of the system: it uses a new type of lancets, which is something that not even the Abbott device did. Indeed I have some four lancing devices that share the same kind of lancets already, and they even fit each other case, mostly, as they usually only have an elastic loop to fit on.

Comparatively, I’m happier about the new lancing device than I am about the meter. Not only the lancet is finer, which hurts significantly less – but would not work well with the old strips’ need of blood – but exactly as they promise on the website the new device does not vibrate, which also makes for a less painful experience.

In my experience, pricking your finger multiple times a day is the most painful side effect of the light diabetes I have, so reducing that pain has a quite significant improvement in my daily quality of life.

All in all, I’m happy that there are improvements always going on… I just wish the improvement went towards reducing the size of the device as well as improving its precision and information.

Diabetes control and its tech; should I build a Chrome app?

Now that I can download the data the data from three different glucometers, of two different models with my glucometer utilities I’ve been pondering on ways to implement a print out or display mode. While the text output is good if you’re just looking into how your different readings can be, when you have more than one meter it gets difficult to follow it across multiple outputs, and it’s not useful for your endocrinologist to read.

I have a working set of changes that add support for a sqlite3 backend for the tool, so you can download from multiple meters and then display them as belonging to a single series — which works fine if you are one person with multiple meters, rather than multiple users each with their glucometer. On the other hand, this made me wonder if I’m spending time working in the right direction.

Even just adding support for storing the data locally had me looking into adding two more dependencies (SQLite3 support, which yes, comes with Python, but needs to be enabled), and pyxdg (with a fallback) to make sure to put the data in the right folder, to simplify backups. Having a print-out or an UI that can display the data over time would add even more dependencies, meaning that the tool would be only really useful if packaged by distributions, or if binaries were to be distributed. While this would still give you a better tool on non-Windows OSes, compared to having no tool at all if left to LifeScan (the only manufacturer currently supported), it still is limiting.

In a previous blog post I was musing the possibility of creating an Android app that implements these protocols. This would mean already reimplementing them from scratch, as running Python on Android is difficult, so rewriting the code in a different language, such as Java or C#, would be needed — indeed, that’s why I jumped on the opportunity to review PacktPub’s Xamarin Mobile Application Development for Android, which will be posted here soon; before you fret, no I don’t think that using Xamarin for this would work, but it was still an instructive read.

But after discussing with some colleagues, I had an idea that is probably going to give me more headaches than writing an app for Android, and at the same time be much more useful. Chrome has a serial port API – in JavaScript, of course – which can be used by app developers. I don’t really look forward to implement the UltraEasy/UltraMini protocol in JavaScript (the protocol is binary structs-based, while the Ultra2 should actually be easy as it’s almost entirely 7-bit safe), but admittedly that solves a number of problems: storage, UI, print out, portability, ease-of-use.

Downloading that data to a device such as the Chromebook HP11 would also be a terrific way to make sure you can show the data to your doctor — probably more so than on a tablet, definitely more than on a phone. And I know for a fact that ChromeOS supports PL2303 adapters (the chipset used by the LifeScan cable that I’ve been given). The only problem with such an idea is that I’m not sure how HTML5 offline storage is synced with the Google account, if at all — if I am to publish the Chrome app, I wouldn’t want to have to deal with HIPPA.

Anyway, for now I’m just throwing the idea around, if somebody wants to start before me, I’ll be happy to help!

Diabetes control and its tech: OneTouch Ultra Easy (or Mini)

I recently received a new glucometer from LifeScan, as when I tried to re-download the specs of the protocol of my previous one they realized I had a very old model – even though they just sent it to me last summer – and offered to get me a new one. They sent me a OneTouch Ultra Easy (also called Ultra Mini in the United States it seems), which is just an evolution of the same design obviously.

The device also comes in two variants, as far as I can tell: the one I have uses the same TSR serial cable that I have already for the Ultra 2, even though it does not use the same protocol at all; according to the FAQ on LifeScan’s website, there also is a miniUSB version too. In either case, to be able to use it on the original Windows software, an extra driver is required.

Of course what I needed to do was to write a driver for my glucometerutils and so I did in the 48 hours following me receiving it. The protocol is very different, it’s binary, and not very obvious. The documentation gives you all the possible commands, but it does not explain why a given number is in a command rather than a different one, so they are all mapped to byte-array literals, not the nicest thing in the world.

The driver, without comments, is just as long as the Ultra 2 driver, which is fully commented, so it is a bit more complex than the textual protocol used in the previous two versions (the Ultra device should share the same protocol as Ultra 2, but I can’t verify that). On the other hand, at least this time they used a standard CRC implementation (16-bit CCITT), but I couldn’t find an obvious implementation of it so I wrote my own — they actually provide the full C sources to the CRC function in the specs, which is good.

The driver already supports the full features of the device; they are somewhat short of the Ultra 2, as there is no definition of comments or pre/post meal indication. As usual the device reads internally in mg/dL, and converts to mmol/l when displaying the data, or downloading the data to the computer. The same goes with my driver; the interesting part is that this sometimes lead to a slightly more precise reading than the device itself would show.

On the user side of the device, the new form factor is quite nice; it goes away without the power button, and without the backlight. The case is nice, not far from everything else, and now the compact pricking device makes much more sense.

Once again, thanks to LifeScan for actually being open on their protocols!1

  1. Update (2018): clearly that didn’t last long.

Diabetes control and its tech, take 6: multiple devices, multiple interfaces

In my previous post on the topic I complained about Abbott not being forthcoming with specifications for their devices. I’ve since then started looking into ways to sniff the protocol while keeping the device talking with the Windows software but I haven’t really had any time to proceed with the plan.

On the other hand, when I was providing another person a link to LifeScan’s full protocol specifications, they decided to tell me that my device is now completely obsolete, and they offered to send me a newer one. I filled in the form and I’m now waiting for the device itself. This means that I’ll probably be writing soon a second device driver for my glucometer utilities, for the OneTouch UltraMini. The protocol itself is quite different, as it’s this time a fully binary protocol, where dates need not as much be parsed as being formatted (they are reported as UNIX timestamps), although it loses a few features in the process, namely the comment/meal options. Not extremely important but it’s a bit sad — not that I ever used the features beside for testing.

While the new meters no longer allows you to provide your before/after meal indication, the OneTouch software does have heuristics to provide said information. I’m not sure exactly how they do that, but I would venture a guess that they use time and relative time. So if you have two measurements let’s say at 7 and 9 in the morning, it will count them as before and after breakfast, while a measurement at 11 is going to be considered as before lunch. One of my entries in the infinite TODO list is to actually implement time-based heuristics for my utilities.

Now, while my utility works fine as a CLI tool, it does not really help to keep track of diabetes over time, and does not have even a fraction of the features of LifeScan’s or Abbott’s software. One of the things that I plan on working on is a way to store the data downloaded from the meter in a local database, such as SQLite, and then show it over time with a half-decent UI. This is going to be my target for next year at least.

Also in a previous post I noted how I’d like to have an Android app to download the data on the fly. I’ve not started working on that area at all, on the other hand, I was able to secure not one but two devices supporting USB OTG. Unfortunately, neither support the PL2303 serial adapter that LifeScan uses in their cables. Since mobile devices are not my speciality, I’d love to hear from somebody who has a clue about them: does it make sense to write an userland, libusb-based implementation of the PL2303 protocol so to use it as OTG, or would time be better spent on devising a Bluetooth adapter?

On the Bluetooth adapter side, the LifeScan devices – at least the old ones but, as far as I could tell from the website, the new ones as well – use a minijack interface similar to the osmocom serial cable, but not compatible, so don’t waste your time with those cables. The OneTouch cables have Rx/Tx swapped, so that Rx is at tip, and Tx at sleeve. On the other hand if I’m not mistaken it should be possible to have a device (small or big is beside the point for development) that interface with the device as a “dock” and provides a Bluetooth serial that can work with a paired computer — what I have no idea of is whether a mobile device could use a Bluetooth connection as a serial port.

At any rate these are my current musings. When I’ll have some more details, and especially if somebody out there can give me suggestions on the direction to move to, I’ll post more. And in the mean time, if you have a glucometer, a cable, and the protocol, you can write a driver for it and send me a pull request on the GitHub repository, I’ll be happy to review and merge!

Diabetes control and its tech, take 5: Abbott devices

I’m still working, on the little spare time my job lets me have, on the glucometer utilities that I recently published on GitHub supporting my main glucometer (LifeScan OneTouch Ultra 2).

Since most (but not all) the protocol for my glucometer has been implemented already, I decided to look into the other glucometer, you know, the one that they gave me because mine reported the wrong measure unit and so sprung this series of posts. It’s an Abbott FreeStyle Optium device, that supports both standard testing and β-ketone strips.

While I was looking for a TRS (mini-jack) connection on the device and found none, its website showed clearly that it supported a software to download the data. Abbott also deliver the cable free of charge, as long as you register your device on their website (which is a pretty sensible thing to do). I received the cable today, and as I suspected they did the user-proof thing: the serial port is hidden within the strip reader. The cable is USB on one side and a little strip-shard connector on the other.

As I hoped, the device is also a standard USB-to-serial adapter. While LifeScan uses PL2303 cables, which are pretty much standard and with drivers available almost everywhere, Abbott uses Texas Instruments TI3410 for their device. It is not clear to me whether this device always require a firmware, there definitely are a few entries that require an uploaded firmware, and that might be a pain point for people who cares about software purity. While the driver seemed to already list the correct USB ID for the device, as of Linux 3.21-rc4 it is not correctly recognized as it lacks a second listing of the VID/PID pair in the right table. I sent a patch for it to Greg (as he’s the maintainer for usb/serial), hopefully that will be fixed soon.

Unfortunately, there is no documentation for the protocols coming with the cable. This is a pity considering that LifeScan publishes their full protocol (even if it’s incomplete, or confusing, for many points) for each of their meters. There is Windows software for it but that’s about it. In my original post, Daniel pointed at his dumper for FreeStyle devices — but as I found out, the reverse engineering of the protocol is only valid for the older, mini-jack serial port devices, not for the new “strip port” devices like mine. I’ve now sent an email to Abbott asking them if they would share the serial protocol specification (reminding them that otherwise I’ll keep using LifeScan’s devices for which the protocol is public already).

Given that both LifeScan and Abbott do not make people pay for the device, but only for the strips, they would have all the reasons to give me the protocol so that more people can rely on their devices. Or maybe they won’t care, and I’ll have to figure out a way to sniff the protocol myself.

Diabetes control and its tech, take 3: report format

So my new doctor is actually keeping an eye out on my glucometer reading (unlike the previous one), and asked me to send him my glucometer reading. This made me glad I asked LifeScan for the USB cable to download the data. Unfortunately I haven’t found a tool for downloading data from my current meter; there are a bunch of tools for other versions such as the UltraMini or the old Ultra, but not for the Ultra 2.

Luckily I was able to find the documentation about it on LifeScan’s website, behind a registerwall — and an interesting post on a forum where they pointed out that the official documentation lies about the “meter acknowledgement” command (the documentation reports it as trn while it’s just tr.

I actually started working on a tool to set up and download the data out of my meter, but this is still a work in progress — I plan on publishing something this weekend, leaving enough hooks around so that support for other models and brands will be possible.. there is way too much fragmentation right now I’m afraid.

In the mean time I’m downloading the data with the Windows software that LifeScan provides for free, which is actually designed more for a doctor than a patient, as it lets you register the meter’s serial number to a patient’s records. This is fine in general, but there is one big issue: it does not let you export the data in any useful format. It lets you fax the data, or send it by email (as long as you have an email program), or finally print it.

Now while I don’t have a printer, Windows 7 comes with a default XPS printer; XPS being Microsoft tentative at replacing PDF… I did not know whether my doctor could read it or not. Well, if you ever get yourself into that situation, the easiest way to get out of it is to simply copy the file into Google Drive, and then print it from there. Rather than printing, it will save it as PDF, So if you ever see yourself getting into that kind of trouble, now you know how to get out of it.

Hopefully, I’ll be able to send my doctor a CSV next week instead.

Diabetes control and its tech

You might or might not know it, but I’m diabetic. Type 2, if you want to say it that way; it’s probably a tricky combination between my pancreatitis, some genetic predisposition, and my old bad habit of drinking at least one two litres bottle of Coca Cola (not Diet!) back before I got hospitalized.

I have been able to maintain a decent lifestyle and keep my blood sugars under control for a few years, but in the late part of last year things changed and I was totally messed up. After three months in Dublin, it was time to get back on track, and I went to visit the doctor a couple of weeks ago. And turns out that there is a slight hurdle with my glucometer (the device that gives blood sugar readings): in Italy, the glucometers give readings in mg/dl, while here in Ireland and in the UK they use the “more proper” mmo/L.

While there are plenty of apps that do the conversion on the fly between the two measures (the conversion ratio is well known), the doctor logically wanted me to have a glucometer for the right measure right away. So I called in LifeScan, which is the company that manufactures the OneTouch Ultra 2 I’ve been using, to see if I could reconfigure the glucometer…. they instead decided to just send me a new one free of charge, no question asked. Great.

To be honest, the doctor sent me to pick up a free one straight at the pharmacy. But it’s a different brand, which means that my reserve of test strips would be useless with it. And it turns out, that glucometer also has a lower cutoff point (where it just tells you that your blood sugar is too high) than the OneTouch Ultra 2.

Together with the glucometer, I asked for, and they sent me, the USB cable — they have a software for Windows that lets you download the historic results from the device. The cable is actually a USB-to-serial (PL2303 chip) with the serial port being stuck into a phone minijack.. I’m not sure if this configuration is compatible with Osmo devices1, but it’s the same idea.

Unfortunately, I can’t seem to find a proper open source project that downloads that data. You can find a few utilities written by somebody who had a need, but there is space for improvement. In particular, there is space for improvement by, like a colleague suggested today, making a minijack-to-Bluetooth adapter instead of going through USB, so that you can send the data to a smartphone, or to a computer without dealing with wires.

So if somebody else has this kind of problems, and just needs someone to give a hand to get it rolling, just let me know — I’m afraid I won’t have time for any new personal projects for quite a while, and I’d rather get back on track with Gentoo at this point that start working on a new thing altogether, but helping out is something I can do.

  1. Update (2018-01-07): It isn’t, it’s inverted.