Documentation

[andyrozman]

Hi !

At first I must say you have all done a wonderful job with this project, there is quite a lot of data available, but for someone who has to do this again in some other language (java) and from zero so to speak, it's not so easy...

If I haven't "bugged" @bewest whole weekend I would have a really hard time making it...

What needs to be in documentation (at least what helped me):

• how data needs to be decoded (sequentaly, delimited with opCodes, and each response package/message for itself)
• how dates are encoded
• special entries like UnabsorbedInsulin
• list of opcodes for Pump History Data and for CGMS History Data. I used file history.csv in doc, problem is that that list is not correct (different sizes for different pump types), at least not for all types of devices (which I learned at later time) and there is no such list for CGMS entries..
• how analysis data can be converted back into binary packages, for testing...

Take care,
Andy

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[erobinson]

Hi @andyrozman,

Props to you for trying to build the project in java. I took a look into doing that sometime ago and know that it is not easy :) . I can help you out with listing / decoding the CGM data if you would like. How far have you been able to get with porting it to java?

Edward

[andyrozman]

Hi @erobinson !
My application (GNU Gluco Control) has been around for a long time (10+ years). Sometime ago I started working on Minimed communication and had it down, it downloaded data from Pump, but then I encountered History data, which was encoded in some "weird" format, which stopped my implementation... At about same time this project was born... I think that my test data was one of the first around...
So I am not porting this to java, I am just using what you discovered in my project (decoding part not communication part)...

Like I said before, you "guys" did a great job... And any more help you can give is greatly appreciated. Minimed is the one of the last "big" Pumps that need to be supported.

Andy

[bewest]

Re differences between pump models:

There are several constants littered throughout my decoding history functions, these are often related to differences between pump models.
The right way to do this is to have a matrix of models, with their associated differences.

New models generally:

• have different stroke sizes
• have bigger record sizes, especially the size of head or body segments
• introduce new records - eg 523 introduces a new basal-schedule-changed-as-programmed record

In practice, for quick hacking this project simply distinguishes between --larger and "default" sizes. It would be vastly preferable to suss out matrix of differences.

[andyrozman]

Hi @erobinson !
Could you please contact me... I tried to contact you, but it's little hard for github newbie... My email is andy(dot)rozman(at)gmail(dot).com

I have question about CGMS decoding...

Thanks
Andy

[bewest]

Howdy Andy, was wondering if you could update this with something to do or help me close it somehow. :-)

[andyrozman]

If you look on first entry there is everything written, what I think could be relevant for someone trying to decode Pump History Data... You described most of that in your many emails to me... So you need to create this document page and this is done... Perhaps one extra for Pump Data and one for CGMS data, since that one uses other methods for combining data....