This is one of the posts I lost due to the blog problems with draft autosaving. Please bear with the possibly missing pieces that I might be forgetting.
In the previous post on the subject I pointed out that thanks to a post in a forum I was able to find how to talk with the OneTouch Ultra 2 glucometer I have (the two of them) — the documentation assumes you’re using HyperTerminal on Windows and thus does not work when using either picocom or PySerial.
Since I had the documentation from LifeScan for the protocol, starting to write an utility to access the device was the obvious next step. I’ve published what I have right now on a GitHub repository and I’m going to write a bit more on it today after a month of procrastination and other tasks.
While writing the tool, I found another issue with the documentation: every single line returned by the glucometer is ending with a four-digits (hex) checksum, but the documentation does not describe how the checksum is calculated. By comparing some strings with the checksum I knew, I originally guessed it might have been what I found called “CRC16-Syck” — unfortunately that also meant that the only library implementing it was a GPL-3 one, which clashed with my idea of a loose copyleft license for the tools.
But after introducing the checksum verification, I found out that the checksum does not really match. So more looking around with Google and in forums, and I get told that the checksum is a 16-bit variation of Fletcher’s checksum calculated in 32-bit but dropping the higher half… and indeed it would then match, but when then looking at the code I found out that “32-bit fletcher reduced to 16-bit” is actually “a modulo 16-bit sum of all the bytes”. It’s the most stupid and simple checksum.
Interestingly enough, the newer glucometers from LifeScan use a completely different protocol: it’s binary-based and uses a standard CRC16 implementation.
I’ve been doing my best to design the utility in such a way that there is a workable library as well as an utility (so that a graphical interface can be built upon it), and at the same time I tried making it possible to have multiple “drivers” that implement access to the glucometer commands. The idea is that this way, if somebody knows the protocol for other devices, they can implement support without rewriting, or worse duplicating, the tool. So if you own a glucometer and want to add support for it to my tool, feel free to fork the repository on GitHub and submit a merge request with the driver.
A final note I want to leave about possible Android support. I have been keeping in mind the option of writing an Android app to be able to dump the readings on the go. Hopefully it’s still possible to build Android apps for the market in Python, but I’m not sure about it. At the same time, there is a more important problem: even though I could connect my phone (Nexus 4) to the glucometer with an USB OTG cable and the one LifeScan sent me, but the USB cable has a PL2303 and I doubt that most Android devices would support it anyway.
The other alternative I can think about is to find an userland implementation of PL2303 that lets me access it as a serial port without the need for a kernel driver. If somebody knows of any software already made to solve this problem, I’ll be happy to hear.
The Nexus 4 only supports OTG with some hacking as far as I know.
Thanks for putting together this tool. I’ve got it working on my MacBook, and it will be really helpful managing my son’s diabetes. I’ve been looking for a way to avoid the OneTouch software and Medtronic CareLink online service.Is there enough information in the protocol spec to extend the tool’s features somewhat? Being able to interpret the comment fields would be a nice addition, as well as an option to purge the stored tests and displaying the meter serial number.I don’t have any coding experience beyond basic bash and perl, but I would be willing to assist with user-level documentation if you are interested in packaging the tool for easy download. I think your software would be useful to lots of other people.Thanks again for the tool, and you’ve got an interesting blog.
Hi Jim, glad to know that it is useful to others as well.LifeScan publishes the full protocol specification of all their devices, which is actually a great thing of them. I can’t republish the PDF for what I read of the Terms of Service, but you can find them [at this page](http://www.onetouch.com/sof… just look at “For developers” under “Get Software”.Considering how Abbott answered me about having access to their devices’ protocols, I’m definitely happy that LifeScan/OneTouch published the whole protocol, even if there are a few things that were not obvious and that I documented in these posts and even if every other device has a different protocol.For what it’s worth, I just requested a OneTouch Ultra Easy, as when I went to look for the right page they noted that my device is obsolete (they just sent me it a few months ago), so I might be writing a second driver soon.I’ll also try to add support for downloading the comments and clearing the history: both things are possible and relatively easy to implement.