I sniffed the data coming back from the pump. I noticed that reading is done by polling bytes while writing is done all at once. Also, I noticed hex 55 seems to be a sort of EOF type value. I looked up 0x55 in an ASCII table and it’s uppercase U. Not very useful. I think we can do some data manipulation to see more. I think we should consider hex to ASCII and hex to decimal. After that we should investigate if the numbers are being sent back in some sort of floating point binary encoding. Also, it seems writing 02 is a repeated action. Maybe it’s one of the more important commands? I can’t believe you guys haven’t started this project yet! Then we decode the transmitter.
9124-pump_read.LOG (953 KB)
Hmmm, very interesting stuff. Why would they have so many EOF commands in a row? 0x55 has to be the most widly used command on there. Also, what program did you use to pull this data?
GJ though! This is really pretty neat
portmon. http://www.microsoft.com/technet/sysinternals/utilities/portmon.mspx
link to dl: http://download.sysinternals.com/Files/PortMon.zip
I did write an app to get the data from an accu check compact meter once. very similar file.
This sucks. BD has asshats as engineers.
Thanks for the log, Jack. I do a little work with hex coding /decoding of radio transmission formats. This could be fun. I will let you know what find. The 055 might be some sort of heartbeat. I’ve got an email address for a local guy who did programming for Medtronic Minimed pumps. I could get brave and ask him what he would about this subject. I suspect that, as a contractor, he is obligated to say nothing.
Steve, Are you going to ask him about the sensor transmitter? That is what I am really interested in working on. Find out the protocol. We know the frequency. What kind of receiver, if the transmitter is bi-directional,etc. I think he can tell you general things. Do you think that this is the kind of receiver we would need?
http://www.laipac.com/easy_916f_eng.htm
Did you talk the contractor guy. He will spill the beans. It’s not like it is a big deal.
I’m an AMX programmer, so integrating with different devices via RS232 is something I do daily. I just got the pump (722 though) a couple of weeks ago, and I’m more interested in hacking the thing to allow more than a 25.0u bolus. But - I also sniffed it out with PortMon and got a slightly different write / read log. I don’t have it with me, so I can’t quite compare line for line - but it is just a little different. Anyway . . .
By just knowing how serial devices talk, there needs to be some kind of patern, rhyme and reason such as:
- by checksums (and/or) [side note: I think the 0x55 could be some kind of checksum coupled with other bytes]
- some kind of header / footer
I haven’t run across a device yet (and most likely won’t) that doesn’t have one of those - loosely said - requirements. Converting the hex to ASCII won’t do much (ASCII is just something that we humans can read); converting it to binary could help.
I did notice a few more things:
- The “longer” write commands are 13 bytes in length, (ex. lines 164,280,396,etc.) with the exception of 7 write commands totally 109 in length. (Still a bit confused by that.)
- After those “longer” write commands, a {0x55,0x33} is the response, followed by a {0x02} write, then the response {0xE1,0x6B,0x55}, followed by {0x08}, at which point I believe the data is recieved containing the checksum to say it’s “finished” with that “request”.
A few things to keep in mind: 0x02 is STX (start of text); it appears every data request response starts off with {0xA9,0x6D,0x23,0x66,0x6D,0x34} - which appears to be the header, and ends with what I’m guessing is the checksum.
Anyway, I’m probably just stating the obvious and things already known, but I thought I’d make this a “public record” now.
Just an addition to my previous posting:
- Responses from a 13-byte command are always 107-bytes in length. Coupling that with the information from my previous post, the last 101-bytes are probably the data and the checksum. The last three bytes of the response are always different. I can’t quite find the correlation between the question and the answer - meaning I can’t find where the checksum is and/or how it is determined.
Anyway, again - stuff that can be found by just studying the log. I’ll be heading home tomorrow, so I can check out my pump log and compare my findings. This is of course all just my interpretation of the log, and I may be very wrong in my conclusions. That said, anyone want to take a stab at verifying or discounting my logic and train of thought with this whole thing?
Very cool. Thanks for investigating. we should write a program to send the log back to the pump. We would convert it from hex to a byte array and then send it to the pump. We may break the pump but I guess that’s what warranties are for! I would love to get the protocol for the transmitter.
I’m starting to wonder if this is a moot point since the Paradigm is going to be replaced by a Lifescan meter next year (probably the OneTouch Ultra.) The protocol for that is much easier (that’s if they don’t change much of it.)
So you are saying the meter the pump uses will be replaced? Wonder why?
Yes - Minimed will be using a model of the One Touch series from Lifescan in Spring. I didn’t mean it will be replaced, you’ll just have another option, so I guess it’s not completely pointless. I just prefer the OneTouch over this BD piece of junk.
Article: http://www.minimed.com/products/insulinpumps/components/meter_announcement.html
The piece that sticks into the meter of the USB cable broke a few weeks ago, that’s why I haven’t been able to play with my meter & pump.
Ooops - silly me. I have no idea what I was thinking. The protocol between the meter (whatever the meter) and the pump would need to be the same (unless Minimed is going to update our pumps by having the firmware/software shot across through thin air via the meter - not a good idea IMO.)
But to re-re-clarify what I meant . . . the protocol between the meter and the PC will most likely change, however the protocol between the meter and the pump won’t. If my speculations are true, then we’ll be able to hack the meter / pump in no time. The OneTouch protocol is readily available, but I’m sure there will be a few extra commands for the pump in the meter. 
Gosh I can’t wait!!
Hi !
Has somebody here tried to write software to read pump data? Or maybe tried to “hack” software that Minimed has written (java classes used on CareLInk web site)?
Andy