[susoooo]

Hi again everybody out there...

Thanks for the reply. It's always is a pleasure to hear someone that knows more than you do about a topic, so you could learn. And I've learned a lot about diabetics and devices like the US on this forum.

I'm not diabetic, at least by the moment, and never have been in contact with this disease... until now. (luckily in my whole family there's no antecedents on diabetes also).

Here's the story why i came into this (if this could interest someone :

The app i'm trying to develop it's not for me, it's for a friend of mine that it's a linux freak and don't want to go to windows to archive his blood glucose levels.
He knows i like to do things with devices like this (i mean, low level programming: C, assembler, microcontrollers and so) and asked me for a little app to do this automatically. As i owe him a couple of favors i couldn't say no. (like "cosa nostra" you know ;-)
Of course he could write down the measure values by hand, but this is not an option for a freak like him
The app will not be very sofisticated: Just retrieve the value of the blood glucose levels, the date and the time of the measure. Nothing else. ( I mean: no pre- post- info, no exercice info, no diet info... That kind of stuff will be introduced by hand on the electronic diary my friend uses).
I think about this app as a home-made prank P.
I've already finded the way date and time is transmited in the US protocol, and the blood glucose levels (at least on the US my friend passed me). I belive this would be enough for me.

Thanks again for the info on this thread, and to shane for replying to my previous post.

BTW: I get a little scared about what is said about the legal staff, so before releasing any of the program source (except to my friend), i'll wait on the evolution of this thread on the forum to see what is commented at that point.

PD: I'm not a native english speaker so please... excuse myself for my spanglish.

[condensr]

Oh heck, your English is great!

I wish you the best of luck with your project, sounds like you are moving right along. I know it really is a nasty little protocol they have developed for it. I think their main reasoning was that the meters could hold so many memory records, they needed to make them as small as possible, and also increase the baud rate so all the contents could be transferred to a PC in a reasonable time. Thats just guessing though.

Welcome to the forums! You might point your friend here too, there's lots of great information and people here. I know it sure changed things for me when I found this forum.

[glucolog]

Hi. Any updates in the quest for UltraSmart upload capability?

[AirJordan]

Originally Posted by glucolog

Hi. Any updates in the quest for UltraSmart upload capability?

Hi,

I´m a Typ 1 diabetic and I´am writing an diabetic management software. On searching for UltraSmart Data reading I´m finding this site. Very nice forum! Is there any update in the question for data reading from the ultrasmart???

Sorry for my bad school english.

[condensr]

One Touch Ultrasmart support in diabuddies is coming.. soon.

[BriOnH]

Originally Posted by condensr

One Touch Ultrasmart support in diabuddies is coming.. soon.

May 14th = one heck of a release . You the man Shane!
-B

[JediSkipdogg]

Originally Posted by BriOnH

May 14th = one heck of a release . You the man Shane!
-B

The Ultrasmart holds what, 5000 readings? So it will take me how long to upload that? LOL

[Dewey]

Originally Posted by JediSkipdogg

The Ultrasmart holds what, 5000 readings? So it will take me how long to upload that? LOL

LOL...It'll probably still take a while, but I think the UltraSmart holds 3,000 readings.

[condensr]

I've had mine since 2003 (oldest record in it), and stopped using it last fall (when I got my Ultra2) and it has about 2400 readings in it.

The download from the meter takes less than a minute, and the upload to diabuddies shouldn't take too much longer, even on dialup. The meter is downloaded at 38400 baud..

[gettingby]

Originally Posted by BriOnH

May 14th = one heck of a release . You the man Shane!
-B

I agree !!!!!!!!!!!!
------------> Shane !!!!!!!!!!!

[Crepuscular]

Take a look at the hex for your readings. I decoded packets from my ultra smart about a year ago but can't remember the actual format. I could take a look one of these days if you like. I was planning on writing a program for dumping the info but got side tracked.

[Crepuscular]

Sorry about my last post to this thread. I am new to this site and didn't realize that there was more than the first page of replies to the original post. Anyway it looks like condensr has it figured out now.

I only managed to decode the Record#, timestamp, BG and the flags for control tests and the before and after meals. I never got into the few remaining bytes.

[condensr]

Say..

If you could figure out how to extract the number of records to download from where it is returned (either record 0, or the reply from the HS command I think) that would be invaluable..

Also, for future updates, if you could also help in decoding values for meds entries, you'd be my new hero. What I need is - what byte/bits reflects the med types (e.g. long acting, short acting, pill, etc), what the enumeration values are for the med types, and what byte/bits reflects the med amounts.

I just have not had a lot of time to put in known values to the meter and analyze the packets.

[Crepuscular]

From what I have seen in the sniff trace, the HR requests keep incrementing their record count until an empty record is returned. I don't have a full meter so I don't know what would happen if there wasn't an empty record at the end.

Is the last byte of the packet a CRC? It doesn't seem to be a checksum. ( unless I am doing something dumb in my calculation of it). Have you been able to generate requests with the right code? Currently I just use the codes I see in the sniff packets when I want to pull records. The trouble is that the OneTouch software complains that there are 5 bad records but I have no way of telling what ones are bad.

As for the meds thing I could look at it if you like. I have a virgin meter here that I can use so I won't have to wade through so much data.

[condensr]

Indeed, the last HR record is indicated by a 7 byte length. Somehow, though, the software is determining in advance how many records there are. I'd like to know it to show accurate download progress.

The evil last byte is a CRC7. Yes, I have code that is downloading all the records from the meter unassisted, and for all BG records, parsing the timestamp and BG value.