Replies to This Discussion

Permalink Reply by Jessopher on December 6, 2010 at 1:08pm

yep. i want to of course be involved in development of standards, but i think some things reqire more depth. or even less depth. people with diabetes need things that ultimately make their lives more managible, and i think that is the real goal.

Permalink Reply by Gil DePaula on December 8, 2010 at 9:27am

Definitely. A lot of these standards are developed with some T1 team members. Both Insulet and Medtronic MiniMed had decision-making T1 marketing/engineering personnel.

Permalink Reply by jojojovich on January 13, 2011 at 8:17am

Interesting! I was just going to search around for hackability to omnipod's thing, so I can get around it when it expires, if plenty of insulin is still in there.

Too, reading some posts in this group, I keep thinking that the liability issues of closed-looping are fairly easily avoided by the pump *requiring* a finger-stick test, in its integrated tester to deliver any insulin.

I'm not sure how making recommendations or asking the user questions can raise liability issues. Auto-delivery would, sure, but put in the finger-stick stop-gap, and requirement, and it seems like it could work well, fairly easily.

Permalink Reply by Gil DePaula on January 13, 2011 at 4:44pm

1) Some people use a syringe and take the left over insulin from the pod.

2) You're right. When the user is involved, then the risk is MUCH lower and the FDA likes that.

Permalink Reply by Jerome Radcliffe on February 10, 2011 at 1:07pm

I am currently working on a project/presentation for a hacking conference that would aim to do deconstruct the communication protocol(s) for some of the medical devices I have (Dexcom, Minimed pump/GuardianRT and OneTOuch Ultralink). Currenlty working on how to capture the data transmission for analysis. I agree with much of what is said here in the thread. It has the potential to be dangerous, which is why it needs to be researched and published. I would love to get in touch with Gil to see if he could shed any light on the best way to accomplish that task. As I progress through the project I'll provide updates on my progress.

Permalink Reply by Gil DePaula on February 12, 2011 at 4:10pm

Hi Jerome,
I wrote a good portion of the Insulet Onipod communication protocol/interface software, but only from the network layer and up. Other people wrote the link layer (bit parsing) and designed the physical layer (HW, antenna, etc). I was also involved in the Guardian RT software, but only had some exposure to the communication part. However, I can't tell you more than this on that subject as that stuff is intelectual property belonging to Medtronic/MiniMed and Insulet. What I can tell you is that, mainly, you'll need to know at what frequency the data is transmitted and have a spectrum analyzer to capture it. It's tricky then to identify the bits in the signal so you can eventually build the bytes and put together the whole messages going back and forth. Another way is, by knowing the frequency, build a similar HW/antenna circuit attached to a microprocessor and write the link layer software to parse out the analog signal and get the bits/bytes/messages. There might be commercially available HW and software to do all this but I've never searched for it. Disclaimer: I'm telling you about these methods because it's common engineering knowledge, but I don't recommend you doing this unless you have the manufacturer's (and maybe the FDA's) approval. Good luck. My email is gdepaula@pancreum.com.

Permalink Reply by David on February 12, 2011 at 5:40pm

Hi Jerome,

Good luck on your project, I look forward to hearing about your progress! Determining the frequency is the first easy part as that is public knowledge. You can find information about licensed wireless devices on the FCC website here:

https://fjallfoss.fcc.gov/oetcf/eas/reports/GenericSearch.cfm

Searching for Insulet as the Applicant returns 5 devices that all operate at the ISM frequency of 13.56MHz. If you click into these you'll see pictures of the pods and 1st/2nd gen PDM.

Good luck!

Permalink Reply by bewest on February 24, 2011 at 10:58am

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.

https://bitbucket.org/bewest/carelink-python/src/7d624e5d0fd8/src/i...

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
using jython or javascript to drive some of the classes
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?

Permalink Reply by Jerome Radcliffe on March 15, 2011 at 7:31pm

I think we are working on the same concepts, but in a different format. I am looking to intercept the wireless transmissions between the different devices (In my case Dexcom, Minimed 722, Guardian RT, OneTouch Ultralink). Dexcom provides some of the details (402.142mHz, OOK modulation, Chip is a AMIS-52100M). Of course I need to determine the format that the data is being exchanged. Minimed is a 916.5mHz with OOK modulation using the TR1000 chip). I am using an Arduino board with the RFM22B module.

Permalink Reply by bewest on March 15, 2011 at 8:14pm

Jerome,

Interesting. Can you build a usb stick to talk to all of them? I'd love to help out with the format. I've got Minimed's system almost figured. I believe I'm getting sequence errors, so I'm at least on the right track.

It would also be nice to build a small adapter that could fit into a meter's data port and broadcast test results over the air.

-bewest

Permalink Reply by Jerome Radcliffe on March 15, 2011 at 8:45pm

Yes, I believe I could build one stick to talk to them all, eventually. I am working on a presentation for a hacking conference to show the.......evil things that are possible. :) feel free to email me jay.radcliffe@gmail.com and we can compare notes.

Permalink Reply by Bernard on February 28, 2011 at 6:18am

As you uncover the data formats used by different devices, I'd appreciate it if you'd share them with me.

I know many device makers won't share the protocols, or will but won't allow you to share them. I'm not interested in those. I've been trying to maintain a catalog of diabetes device data formats on a wiki, hoping that it will enable folks to develop better visualization and analysis software. If you can share info with me, I'd be happy to host it on that wiki. You can email me directly at bernard.farrell@gmail.com. Thanks.

• ‹ Previous
• 1
• …
• 3
• 4
• 5
• 6
• 7
• 8
• Next ›
• Page