Hey we should chat. I've done some analysis. I now have
several partial transcripts showing the messages flowing
between the PC and the usbstick. I also have analyzed the
java applet and have been able to produce a python library
capable of talking to Lifescan's OneTouchUltralink,
Profile, and the usbstick.
The usbstick functionality is still limited. The usbstick
is a really elegant device: it basically exposes a buffer
with which you interact with the radio and any device that
expects to recieve the messages you send. The messages
written and read from the buffer must be correctly
formatted. There is a set of local "diagnostic" commands
to inspect the USB stick itself, and then some special
commands to manipulate the buffer.
While I've been able to implement the local commands, the
end-to-end operation of successfully executing radio
commands is still incomplete. I'm thinking that the best
bet at this point is to produce a document on the
communication protocol. The traces indicate that to send
and recieve one piece of data, a flow of at least commands
are required, which is too onerous to get right using the
"poke it with a stick" method I've been using.
Is anyone interested in helping to document their
protocol? I've got a full time job, and this stuff is
eating up my time. At the current rate, it'll take at
least another 6 months before I've got fully working
version talking with pumps.
This is purely about auditing current therapy. It's
shameful that Medtronic has a policy preventing us from
gaining access to our own data. Everyone should put a
call in to Medtronic, ask for the "Advanced Software
Group" and request access to the "communication protocol
used by the usbstick." If they respond with "software
codes" tell them you don't know what they are talking
about and you want the protocol.
Personally, I expect to be able to audit the device,
confirm the presence or absence of defects, and
communicate therapy progress with caregivers. In order to
do that I need access to the data on the device, which
Medtronic has a policy against. I don't expect them to
support every possible use case, but I do expect to be
able to audit my own data if they prove unable.
It would be interesting to use a JVM language to drive the
java classes and replace that crappy Jungo/SerialIO stuff.
I'm not sure why anything fancy is needed; the usbstick
will load as an ordinary serial port under Linux. While
driving their java classes would be useful to test parts
of the communication model, I'm not sure if it would put
me on the bad side of their ToS. Has anyone considered
implementing the protocols?
To the glucosurfer guys: I tried looking for a way to
upload data to you but failed to find anything. What
format are you expecting? Can I request an ATOMPUBSUB
interface to the data so that other "cloud controllers"
can interoperate with you?