[Novalug] Diabetes Software chance

Peter Larsen plarsen@famlarsen.homelinux.com
Mon Jul 23 01:31:28 EDT 2007


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ross Patterson wrote:
> At 11:16 7/22/2007, Nino Pereira wrote:
>>> Here's my plan should I get the communication specs - to initially make
>>> a basic program in Java that will read the meter data, and hold a small
>>> local "database" of meter readings. But I need something to hold the
>> data in;  what suggestions do you have?
>>
>> My suggestion? ascii.
> 
> CSV.  It's the nearest thing to perfect for tabular data, and that's
> what these meter readings always turn out to be.  Not to mention that
> any decent number-manipulation program will ingest a CSV and produce
> graphs, reports, summaries, etc.

I'm sometimes amazed on how a discussion skips the requirements and
design phases and jumps right into implementation. CSV/ASCII - I think
Nino meant the same thing. ASCII is simply the character set; CSV is the
way you separate data. Both methods are pretty outdated and from the
needs I've given here before, not good enough. Maybe it's just me, but
those tools you mention aren't integrated? How would you make one
application out of it?

Character set, change management, flexibility - and speed of coding are
all reasons why ascii/csv shouldn't be used anymore. With XML you simply
click on your XSD and presto, you have code classes that represents the
whole structure. With CSV, you need to know what fields come when, and
make your own reader. If/when the format changes you have to change your
code. That's not (always) the case with XML.

>> What you want from your meter is, presumably,
>> a number, the glucose level in whatever units you want (I'd favor
>> kg/m^3, but I'm sure the medical community uses some weird, non-standard
>> unit like mg/l).
> 
> Close - it's milligrams of glucose per deciliter of whole blood
> (mg/dl).  It's extremely standard in medicine, just not in chemistry
> :-)  All the diabetic meters use this scale, and have since back when it
> took real lab work to determine, not just a few seconds at home.

Right - but most meters can change between the US and European setup.
It's part of the meter setup, and on my old meter this information was
transfered to the PC config.

>> You can call it something like 'glucose.dat'.
>> You can read it with an editor: no further coding necessary, and it's
>> not even necessary to plot it out.
> 
> Although working from CSV, something like OpenOffice Calc or GNUPlot
> will do wonders for you.

How is anyone that's not semi familar with spreadsheets going to be able
to use tools like that? You have to setup filters etc. to make anything
semi automatic, and how would you deal with new data when it comes in?
I'm interested, because reinventing the wheel isn't what I want to do.
Btw. XML can be read into OpenOffice too.

>> You can add a time and date stamp,
> That will be in the meter data already.

Correct. A key aspect of the dataset is the timestamp.

> Generally not.  Most of them now have an ASCII output stream - the
> question is how the data flows between the meter and the computer.  It's
> a lot like the way modems were 25 years ago - everything used the Hayes
> command set (ATDT...), but still lots of minor variation.

Interesting. Do you have any experience with the meter data-stream data?
I would have guessed it was binary, and not ASCII. Not that I've seen it
before; it would certainly make some aspects a little easier compared to
a binary stream. But since the meter talks serial, and most likely 9600
bps, binary would be faster. But if the same people that design the
software for windows designed the interface, I wouldn't be surprised
.... I wouldn't be surprised at all.


- --
  Peter Larsen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFGpD0wHbLDna3OFD0RAgqSAKC3JmUlY4GBL9Z5UIoqlNRjutZt9ACg2q9R
ozlm9VLFpEUX6rKyKpEBRZ4=
=OSHI
-----END PGP SIGNATURE-----



More information about the Novalug mailing list