Replies to This Discussion

Permalink Reply by Jake on February 26, 2010 at 4:58am

No promotions/discounts whatsoever, Limited retail vendor avalibility, No windows 7 64bit support, It looks cool but the phone person kinda made me feel like a complete idiot for asking for some sort of discount.. None whatsoever... and I dont think my insurance will pay for this model.I passed on it

Permalink Reply by Derek on September 27, 2010 at 9:19pm

I just bought this meter from Walgreens for $29.99 and I gotta say so far I am really liking it. I am running Windows 7 Home Premium 64 bit, and aside from autorun not loading, I love it so far. I just open the program then plug the meter in, it downloads and then I remove it or let it charge. Ill review it more as I get more use out of it, right now I just am using the 25 test strips it came with since I need $60 for my RX of strips(150)

Permalink Reply by Jake on September 28, 2010 at 1:00pm

I ended up buying it recently on sale for 29.95 or so as well... Not too bad..

Permalink Reply by Holger Schmeken on March 2, 2011 at 3:18am

Is it possible to access the data files (XML would be great)? If possible we could develop an import filter for our Glucosurfer project.

Permalink Reply by bewest on March 6, 2011 at 12:27pm

Holger,

How do I upload data to glucosurfer? I tried some csv and tab delimited formats but failed. I'm formatting like this:
https://bitbucket.org/bewest/carelink-python/src/5ce2331c0ee1/src/i...

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

Has anyone just tried asking them?

I suggest everyone call them or write them an email and ask them for the protocol.

from Bayer Mail
reply-to Bayer Mail
to bewest@gmail.com
date Tue, Mar 8, 2011 at 3:03 PM
subject communication protocol to access data stored on contour usb [Incident: 110308-000039]

.

Subject
---------------------------------------------------------------
communication protocol to access data stored on contour usb


Discussion Thread
---------------------------------------------------------------
Response (Syvel) - 03/08/2011 03:03 PM
Dear Mr. West,

Thank you for your e-mail to the Bayer HealthCare web site.

We would like to inform you that your request requires additional research. We have escalated this to the appropriate department who will look into the matter. We will e-mail you a resolution as soon as possible. We apologize for the delay and any inconvenience this may cause.

For more information and other inquiries, please feel free to contact one of our trained Contour USB representatives at 1-800-348-8100. They're available between 8 AM to 10 PM EST, 7 days a week.

We are committed to helping you simplify your life with Diabetes.

Sincerely,

Bayer HealthCare, Customer Service

Customer (Benjamin West) - 03/08/2011 02:40 PM
Greetings,

Lifescan publishes the communication protocol for their meters, but
I'm having trouble finding documentation for the communication
protocols needed to access the data on the Bayer Countour Meter.

Can someone please provide the communication protocol? It's critical
for patients to be able to access their own data directly from the
device.

Thanks,
Ben West
-bewest


[---001:001145:43496---]

Permalink Reply by bewest on March 9, 2011 at 2:12pm

FWIW: I sent an email to Bayer and they gave me a document explaining the communication protocol for all their devices. I was told it applies to the bayer usb contour as well and was given this document:
http://userportal.iha.dk/~jrt/BayerContour/MeterInterface.pdf

It probably just has an extra usb interface that acts as mass storage.

Now if only Medtronic would play ball.

Permalink Reply by Holger Schmeken on March 10, 2011 at 1:44am

This is great! Well done!

Now we just have to think about the USB HID Interface and its use. The communication traffic itself should be readable with the help of your document. Right now my time is just too limited to start this. How about a GPL open source project hosted at SourceForge so we can all participate from time to time?

Permalink Reply by bewest on March 10, 2011 at 9:35am

I do think we will get more done if we work together. It would be nice if there were a library that contained reference implementations to communicate with lots of devices with documentation on both a more or less common set of APIs and the protocols. I'm currently working on doing this. It looks like you are a fan of .NET and there are lots of java people around. We should collaborate on test suites and documentation so that we can test our libraries against one another.

I've chosen python because I can generate excellent documentation from the source and add annotations with rst using sphinx. sphinx can also document java and I believe .NET, so I think it's a good choice. The Indivo stuff also happens to be in python, so that's nice. It's critical that we have high quality software to audit all of our data. I don't know who makes better software than the open source community.

Permalink Reply by Holger Schmeken on March 11, 2011 at 5:17am

Let us use Java for the project. I think this will attract more developers - and we can cover more platforms.

What is the aim of the project?

I think it should provide something like a library. It should be able to traverse the data stream. Giving back the records/objects step by step. Maybe via CallBack function. By calling the function with a specific callback function multiple needs can be met. I could develop a simple XML exporter. Others could use it to directly import data into their applications (like Andy Rozman's App).

How do we call the project? For example BayerMeter lib?

Should we use SourceForge?

Permalink Reply by bewest on March 11, 2011 at 10:45am

The goal should be similar to the work the html5lib guys
or the indivo guys have done. A set of libraries that
establish high quality communication with a wide variety
of diabetic devices. The goal is to enable application
developers of all stripes to develop ways of auditing
therapy data. It's important that users of these devices
have access to tools that provide appropriate information
at the right time. Following the unix philosophy of doing
one thing and doing it well will help us restrict the
scope.

Ideally we'd have implementations in every popular
language for talking to these devices, and they could all
interoperate using more or less the same APIs and data
formats. The only way this is possible is if the
communication protocols are well understood and the
implementations interoperate with as many test suites as
possible. This method provides peer review and a quality
of software that I don't believe can be matched using
proprietary methods.

Several of us already have piles of code laying around in
our favorite language. What we should do is make sure
that the pieces that any piece of software will have to
do, such as extracting data from a device, reformatting
it, etc, is abundantly available, peer reviewed, tested,
and interoperable.

This will make it easier for everyone to make progress on
monitoring care.

I think google code would be better than sourceforge.
I've already got several repositories with some code, in
bitbucket and github. I'm not likely to commit any code
to a java only project, but the idea of being able to test
against a variety of well known implementations is very
attractive.

For me, the essence of such a project would be focused
on communicating with the devices, and repackaging the
data in a variety of ways. There'd be tests for parsing
and reformatting data, and tests for communicating with
devices, complete with tests to validate all the known
flows.

From there, some proponent of a particular language may
want to provide a library that is idiomatic and includes
integration for other features, but the scope of an open
source project should be very very small, focus on lots of
implementations and lots of tests.

-bewest

Permalink Reply by Holger Schmeken on March 14, 2011 at 7:04am

I have read the documention and the main efford is parsing the bytestream. A non trivial task with their strange format but nevertheless managable. Still I am askin myself if it is really worth the efford? We should ask Bayer to integrate an XML export into the operating software of their Bayer USB device. From what I have read it should be possible to update the operating software on the meter. If they deny our request then we should move forward. What do you think?

• ‹ Previous
• 1
• 2
• Next ›
• Page