Reverse engineering an IR protocol, For Accu-chek blood glucose meter Options

[lardman]

I'd like to be able to download my blood sugar readings from my meter to my Z (I'm diabetic). I have some software on the PC which can download the readings, but the Z is of course best ;-).

I hope the protocol will be fairly simple - you just hold down a button on the meter and it starts spitting out data to the PC once they've enstablished comms. It must also pass its current time as the meter can be reset if the clocks change, but that's about all it can do.

Anyway I've never tried anything like this before and was just wondering how to go about it?

I presume some tools like LIRC, xmode2 will be required, I have an IR serial adaptor.

Any suggestions gladly accepted. I'll be doing the development work on a desktop Linux box for the most part - though I may need to use the Z to record the PC's part of the conversation (as I dual boot Windows & Linux at home).

Cheers,


Si

[doseas]

Lardman, since you have the IR serial adaptor, rather than trying to understand the IR signal itself, a better plan of attack might be to use a packet sniffer, such as Ethereal, and record the entire conversation over the serial channel between the meter and the PC software during normal use.

That way, you can see what the handshaking looks like between the two devices. After a couple of recorded sessions, it should be easy to pick out what is handshaking & what is data.

Good luck!

[lardman]

Good idea, are the baud rates etc. standard for IR connections or am I going to have to fiddle about to get them set correctly (actually are they even the same type of settings as a standard serial connection - I assume so).


Si

[cwaig]

If the device is outputting IRDA serial data, you're in luck - just load up minicom on your Zaurus, set it to /dev/ttyS2 (SL5500) or /dev/ttyS1 (SL5600 and more recent clamshells), and you can fiddle with the baud rates to find a setting that get's you a stable, repeatable data stream....

Don't use LIRC if the device is doing IRDA serial data as it won't handle it.

The Pocketop keyboard sends IRDA serial data (that's how IRK works....).

[Guest_tapjpa_*]

Lardman -

My wife saw your post and you peaked her interest she's diabetic also. Yes she has a Z but for some reason won't participate here. Please let us know how this works out.

Thanks,

Jim

[lardman]

and you can fiddle with the baud rates to find a setting that get's you a stable, repeatable data stream....

I can run at 38400, 19200, 9600 and 4800 all with 8N1 (the only ones I've tried thus far) and always get the same stuff out (for each baud rate, different data for different baud rates).

I'm not quite sure what the data should look like, so where do I go from here?


Si

[tz]

Try something like

cat /dev/ttyS1 | od -tx1z -Ax

to see the data stream in hex (/dev/ttyS2 if that is your IrDA port).

Try it at different baud rates.

Also if you have or can borrow an oscilliscope and ir sensor (solar cells may work) you can see the data stream.

[lardman]

How would I alter the port settings if trying to use od?

I'm currently investigating the use of a Windows driver which attaches to the serial port and can then (hopefully) grab the data going back and forth. Fingers crossed ;-)


Si

[lardman]

All looking good. I downloaded portmon from http://www.sysinternals.com

Nice bit of (free!) software, respect to the authors.

I have captured the PC side (and this is what I want to emulate) of a couple of conversations. Time to start comparing the hex with the data I know was in the unit.

It actually looks reasonably simple:

IOCTL_SERIAL_SET_BAUD_RATE: 9600

IOCTL_SERIAL_SET_RTS

IOCTL_SERIAL_SET_DTR

IOCTL_SERIAL_SET_LINE_CONTROL: StopBits: ERROR Parity: NONE WordLength: 8

IOCTL_SERIAL_SET_CHAR: EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13

IOCTL_SERIAL_SET_HANDFLOW: Shake:1 Replace:40 XonLimit:0 XoffLimit:4096


Not sure what the StopBits: ERROR means (other than it's trying to use an illegal value - can you have no stop bit?). Any guesses?


Si

P.S. I've stuck up a web page about this: http://sgp.zaurii.net/howtos/accu-chek.html

Edit: This page has moved now: http://students.bath.ac.uk/enpsgp/Zaurus/accu-chek.html

No actual data yet, but I'll put it up there and report back here as I progress.

This post has been edited by lardman: Feb 2 2005, 09:51 AM

[Entropy]

Thanks for putting up your logs...

This has to be the most incredible timing, you started this thread the day my endocrinologist gave me an Accu-Chek Compact when I asked him about it. (Gotta love the "give away the razor, rip em' off on the blades" concept that the bloodsugar meter companies adopted.)

Going through portmon logs is really unpleasant... All those *$#@)* status checks, but I eventually figured out a good deal of what's going on by looking through the log you posted. (I don't have Compass myself, nor do I even have the cable, but neither have stopped me thanks to your log.

The protocol is standard IrDA serial, 9600 8N1. If you happen to have a machine with an IrDA port (The Zaurus is a good example, I'm not a Zaurus owner myself but I do have a Dell Inspiron 8200 with an IR port that is dual-boot Linux/Win2k)., no need for Roche's $30 cable.

The protocol seems to be a mix of ASCII with the occasional nonprintable control character thrown in. Most prominent are that all commands seem to have 0x0D as a postfix, and most return strings are preceded by 0x0602 and followed by 0x0406. I have actually been able to see my bloodsugar results in plaintext returned from the meter.

I'm working on a Perl script that retrieves the readings from the meter. I'll post it after I clean it up slightly. I also need to bump up the count of readings by one so I can figure out which of the return values is indicating the number of current readings in the meter. Yours is obviously at the maximum value of 200, mine isn't (5 right now... Since I only have one drum I'm switching back and forth between my Compact and my Glucometer DEX.), and the number of readings to retrieve must be specified. (If you specify too high a value, it won't work. Appears to give some sort of error, but I have no idea if it's actually an error or what. )

Edit: Just did my evening bloodsugar test, and the number of results is returned after the "`" command is issued. Yes, one of the commands is simply "`" followed by 0x0D.

The other commands present in that log are:
C4
C 3
S 1
S 2
S 3
a 1 N - where N is the number of readings to retrieve. The command actually be
a X Y - where X is the index of the first reading to retrieve and Y is the index of the last.

The second to last printable character of EVERY return string seems to be 6.

Another last edit: For some reason you cannot send characters to the meter very fast. In my script I need to put a small sleep in between each sent character - If I send them all at once, or each in a seperate write() command without any sleep commands in between, things break.

[Entropy]

Attached is a somewhat cleaned-up version of my Perl script. It's still a mess. There are a lot of print statements commented out - uncomment them to see what the meter is spewing back.

This version actually pretty-prints the results and times.

[lardman]

Great stuff! I've been a bit busy this weekend (at the rugby) so hadn't a chance to even do anything with the logs.

I'm glad they were useful and even more so that you've managed to put together a perl script in such a short time.

And there I was thinking this would be a fairly random thread, I didn't realise anyone else might actually be interested in its application :-)

Time to put Octave to work and do some data processing (once I decide just what to do with it all ;-))


Si

[cwaig]

Although I'm not diabetic myself, my wife's a nurse who deals with diabetics a lot (community nursing - not sure if you have it outside the UK). Anyway, she tell's me she has a couple of these meter's in the boot of her car so I'll try to find some time to have a look at it myself as well...

[Guest_Peter Drozd_*]

Hello :
I am lalso a diabetic. I am also trying to download data from my meter. I have a One Touch Ultra. They have a communications spec defining control signals but there is a problem. I can talk to the meter using hyperterminal with no problem and am able to download the information. When I try with my application, I am not able to power up the meter. I used a serial port spy to see what was happening and found out that I am setting everything the same except for the following that does nto match.

I see IOCTL_SERIAL_SET_HANDFLOW with the following data.
01 00 00 80 40 00 00 80 50 00 00 00 c8 00 00 00

I do not know how to set this using the Win32 APIs. Can anyone help me solve this problem? Maybe someone out there has solved this already.


my email is peterd_330q4@yahoo.com

thanks
-peter

[Guest_Guest_*]

Hello :
I am lalso a diabetic. I am also trying to download data from my meter. I have a One Touch Ultra. They have a communications spec defining control signals but there is a problem. I can talk to the meter using hyperterminal with no problem and am able to download the information. When I try with my application, I am not able to power up the meter. I used a serial port spy to see what was happening and found out that I am setting everything the same except for the following that does nto match.

I see IOCTL_SERIAL_SET_HANDFLOW with the following data.
01 00 00 80 40 00 00 80 50 00 00 00 c8 00 00 00

I do not know how to set this using the Win32 APIs. Can anyone help me solve this problem? Maybe someone out there has solved this already.


my email is peterd_33014@yahoo.com

thanks
-peter

Hello :
I am lalso a diabetic. I am also trying to download data from my meter. I have a One Touch Ultra. They have a communications spec defining control signals but there is a problem. I can talk to the meter using hyperterminal with no problem and am able to download the information. When I try with my application, I am not able to power up the meter. I used a serial port spy to see what was happening and found out that I am setting everything the same except for the following that does nto match.

I see IOCTL_SERIAL_SET_HANDFLOW with the following data.
01 00 00 80 40 00 00 80 50 00 00 00 c8 00 00 00

I do not know how to set this using the Win32 APIs. Can anyone help me solve this problem? Maybe someone out there has solved this already.


my email is peterd_33014@yahoo.com

thanks
-peter