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 meantime, 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!
Have you looked into their java based android driver sdk?http://www.prolific.com.tw/…There’s also a similar sdk for ftdi I believe, and this one focusing on arduino devices https://github.com/mik3y/us…I believe Bluetooth serial profile is possible in android but only with a custom kernel, so that’s probably not worth the effort.
Bluetooth and mobile devices is yet another area where vendor software limitations make hardware an utter pain. Last time I looked at getting serial data out of (a custom) gadget over bluetooth the situation was something like:* Android can do serial-over-bluetooth, but not Bluetooth 4 / low power* iOS will allow Bluetooth 4 / low power, but anything else needs a special chip licensed from Apple* Neither works on Windows PhoneSo there is no one-shot solution (which is a real pain for small-run hardware manufacturers).There was a thread on linux-usb recently which indicated someone else had tried to do a USB serial device with libusb, but couldn’t get it to work. They didn’t get much help as they had already proved that the in-kernel driver does work with their hardware.Why does Andoid lack a way to add extra kernel modules (from the same kernel version) when required for hardware? Only allowing peripherals that the handset vendor has thought of prior to release doesn’t make for much of a user experience (especially as they seem to vary from vendor to vendor). But then the whole update process (if you don’t get a stock phone or 3rd party ROM) seems to be prehistoric.
stop killing animals, get a vegan diet : less tech and gluco-* tools but better health results guaranteed.