Decoding the Accu-Chek Active blood glucose meter IR protocol

Update – 26/11/14

This page is quite old but still comes at the top of the Google search page for e.g. “accu-chek protocol”, so I thought I should give those who are interested a bit of an update (which is someone every other month on average, so we are not alone!)

 

If you look below you will find a Perl script linked, this works with IR devices that can be accessed directly as serial devices (i.e. without any IrDA layers in between your serial commands and the hardware, which was the case on the Zaurus.) I’ve not done any significant extra work on this or the protocol, though I have seen mention on a forum somewhere that someone got it working by re-implementing the Perl algorithm in Visual Basic (this is in my ToDo list, so I can provide a download, but see below for more on the IR hardware issues) and I believe someone also used the algorithm in a Windows Mobile app.

 

The major reason that I’ve not done any more work (aside from my then girlfriend moving in with me, finishing my PhD, getting married, moving house and having 2 children – I told you the page was old!) is that I moved on from the Zaurus, and then didn’t have a device that offered direct serial access to an IR port. Unfortunately nowadays one tends to only be able to purchase IrDA USB dongles (and the ones in your laptop are often USB under the skin too), and I’m not sure how to force an IrDA dongle to only use the IrPhy layer, which I believe is the lowest layer and would then potentially make them work. If you have any experience of this, please drop me a line and I’ll update the page accordingly.

 

With that said it is possible to buy IR-serial devices (I got one with some Accu-Chek software long ago, Compass I think it was called), or to make them yourself, so I don’t really have all that much of an excuse for not having done more reverse engineering, except that I also bought an Accu-Chek SmartPix. You plug this USB device in and it appears as a mass storage device which hosts a webpage on which you can tell the device to talk to your meter, and to display the results it downloaded from your meter. This is all well and good, but we want access to the raw data, and this is also available if you look on the mass storage device in the form of and XML file (with a name such as G4812174.XML, which changes every time.) I use MATLAB to analyse the data, and it’s trivially easy to read the data in (I will put up some scripts when I get a spare minute probably over Christmas for use with MATLAB or the open source equivalent Octave).

 

I’m not sure whether the SmartPix is still available in the UK (it appears to be available abroad though), and there’s another piece of software and hardware called Accu-Chek 360, which comes with a USB IR dongle. I’ve got hold of one of these (as this is readily available), and started work reverse engineering the protocol used to talk to the USB dongle – for reference this device appears as a HID device. I’m afraid this is also on the back-burner for the time being until I look into better ways to intercept the USB communications between the dongle and 360 software (I used a piece of trialware software which has long since expired, so again any advice on methods of intercepting USB HID communications under Windows appreciated – I suppose I could write a shim driver to sit in the driver stack or experiment with running under Wine, both of which would be interesting, but I realistically lack the time at the moment.)

 

So that’s where I am, I can get hold of the data with the SmartPix, and the next step would be to make the meters work with readily available/cheap hardware to aid other people, and I’m not sure whether the best bet is therefore to reverse engineer the protocol further (and look for a way of working with IR USB devices, or find a source of IR serial devices) or to get on with the 360 HID device reverse engineering work. The best thing would actually be for Accu-Chek to get on and release a device that communicates over Bluetooth, which pretty much everyone has now, and let’s not forget to use an open protocol too!

 

As an aside I’m trying to find the time to write an Android app (as I now have an Android phone) to log food intake, insulin/other medication, potentially blood sugar (though I intend to analyse all of the data on my desktop box rather than the phone in the first instance), activity, mood, HbA1c and other interesting parameters (weight, blood pressure, other blood test data, etc.) The idea is to look at HbA1c prediction, insulin effectiveness, effects of exercise in the days following, etc., etc.

 

Time is short though, so if anyone has any recommendations on existing applications (at least for the food/drink and insulin parts) then that would be appreciated – once I have some data that may well improve my motivation to capture more/better data. I’ve experimented with a few existing apps, but they either don’t let you log the time at which you eat/drink something (which is then pointless – they are designed for daily calorie intake tracking), don’t let you export data, or only handle American foods, etc.

 

 

 

 

Original page below this point (though I’ve changed my emails to point to my Gmail account):

 

 

What is an Accu-Check Active

The Accu-Chek Active is a blood glucose test meter made by Roche (link). It's a decent bit of kit, robust (about the smallest thing you can get - more about this later on) and basically does the trick. An added bonus is the fact that it has an IR port which can be used to download the last 200-odd results from in the in-built memory.

Why decode the protocol....?

As an Engineer this is a great bit of kit and I'm sure there's useful stuff that can be done with this data, it's just working out exactly what to do. Roche supply some software (called Compass) which can download the data but, in my humble opinion, it's a bit clunky, and there's far more analysis which could be performed. But they've thought of that too - you can export the data as a CSV file so you can then do what you want with it.

Now this is all well and good if you have a Windows PC or a Palm to hand (the software is available for both of these platforms), and although I do have a Windows PC, I'd far prefer to be able to download everything to my Palmtop - a Sharp Zaurus running Linux. I presume there are also other people out there running Windows CE/PocketPC and Linux on desktop boxes who might also want to be able to download their readings without having to use two machines. Therefore I contacted Accu-Chek/Roche to ask whether they'd be willing to release the spec of the IR protocol to me. I even offered to sign an NDA.

The people on the end of the telephone and email helpline (to whom I sent my request) were very helpful, if something's broken they are more than happy to replace it and they were very helpful with my email request(s). Unfortunately I was eventually told that I would not be able to obtain the specification. This was the ruling from the higher echelons.

I questioned why the protocol should be a secret. My understanding is that Roche make the vast majority of their money (with respect to blood glucose testing) from the blood test sticks rather than the blood testing meters and the software which are heavily subsidised. This makes sense - subside the one-off cost of the hardware (and software) so that people will have to use the sticks (much like the deal with computer consoles and their games so I've read). So I can seen no real reason why they wouldn't be willing to share the protocol - anything to get more people using their products and buying the sticks must be a good thing, and they often give the software away anyway. Nevertheless I was told that I'd not be able to get the specification.

Shame.

Decoding the protocol

So I did a bit of research, downloaded portmon from http://www.sysinternals.com (this is a great bit of free software, and there's lot of other interesting stuff over there too, highly recommended) and started pulling the protocol to bits the hard way.

I've not finished yet, but I have serial data logs of the comms and it looks like it should be reasonably easy to write a proof-of-concept app to grab the data. If anyone's interested in helping/using the resulting protocol get in touch with me (simon.pickering@gmail.com), whatever I write will of course be released under the GPL.

Log file - no connection (just the PC doing its thing)

Log file -successful connection & data transfer

I've enlisted help (or people felt sorry for me ;-)! The good people of the ZaurusUserGroup (of which I'm a member) have come to my rescue. There's even an initial Perl script available to grab the IR info. Take a look here: ZUG Thread. I'll try to do some more work on this when I have a bit of time.

Perl script (by Entropy from the ZUG) here: metertest.pl

I was contacted by Jon Misurda, the author of a PocketPC app called GlucoComm that downloads your blood sugar readings, to say that he’s used the info in the perl script to enable GlucoComm to download Accu-Check Active data.

Here’s a link to his page: http://www.cs.pitt.edu/~jmisurda/ppc/GlucoComm/GlucoComm.htm

(this should serve as some sort of inspiration – I really ought to do something like this, when I have a bit of spare time ;) )

Random musings

During my email to-and-fro, part of which was asking about why meters don't have more in-built analysis facilities, I was fortunate enough to speak (via email) to one of the developers of the Compass software. He told me that there was little demand for this kind of thing in this country. Fair enough, I really have no idea, none of my close friends is diabetic and I don't think I know anyone else who is either (but then again no-one would know that I'm diabetic unless I told them) so I can only base my judgments on what I want. If anyone can supply me with any more info (demographic or other) I'd be interested to see it.

This leads nicely onto another point. Why do all of the blood glucose testing meters have HUGE displays? I'm 26, I can see quite well thank you, I really don't need 1 inch high numerals. In fact what I'd really like (and would pay some decent money for) is a blood test meter which is tiny - the kind of thing you can stick in your pocket and take with you when you go for a night out on the town (there used to be one of these which was pen sized - I'll try to find out what it was called) - 5 sticks would be more than enough for an evening - certainly better than the no-sticks I have to use at the moment (e.g. blood test before meal, then one during the evening, one before bed, one in the morning, and one left over just in case - ideal).

This also leads me onto the size of insulin pens. I normally do 2 injections per day mixing my own Humulin Soluble and Isophane Insulins depending on what my blood sugar is, how I feel and what I think I'll be doing that day (some say this is a new technique but I've been doing this for the best part of 19 years, seemed pretty obvious to tell the truth).

That's all well and good but too many things to take with you if you're going out to eat, etc. Therefore I also use a Mixtard 50-50 mix in a pen when I go out. The problem is that this pen is significantly bigger than it need be for me and indeed for just about anyone who wants something convenient (I use perhaps 20 units in the evening and the pen holds something like 300 - overkill). It's a real pain to have to carry this around unless you happen to have, or know someone with, a handbag. Surely I can't be the only young, active and generally normal person with diabetes who suffers from these problems of wanting convenient ways to do blood tests and take insulin so that they don't interfere with normal life (and they wonder why young people go off the rails and just don't bother to test and inject)?

Anyway I feel much better with that off my chest. If anyone has any questions, comments or constructive criticism then please contact me at: simon.pickering@gmail.com