pump on the 'net

[Benjamin West]

My pump is running at bewest.io:8080

This is the script I'm using to publish it: https://github.com/bewest/decoding-carelink/blob/master/bin/publish_stick.sh

* https://github.com/bewest/decoding-carelink/blob/master/bin/socat_run_app.sh

I've used this script create something that decocare/stick.py knows how to deal with, and I was able to run it successfully, and watch "on-stick" packet counter increment.

Anyone could use this to try talking to my test pump over the internet.

Happy hacking.  If it goes down, let me know and I'll reset it.

-bewest

[Benjamin West]

Earlier I was able to set up my test pump on the internet, for anyone to access. I've posted a few more details on how to work with the test pump here: https://github.com/bewest/decoding-carelink#demo

Demo

Talk to my test insulin pump over the internet. Requires socat and python 2.7. The script./bin/socat_run_app.sh will connect to my server, bewest.io:8080 where my test insulin pump, serial208850 is waiting to talk to you.

Here's an example using my scripts:

$ git checkout -b tester # create a new branch with just your stuff, please
$ . ./bin/common # import some handy run_* functions
$ ./bin/socat_run_app.sh & # get my test insulin pump from bewest.io:8080
$ ls carelink.ttyUSB0  # creates this thing
carelink.ttyUSB0
$ ./status-quo.sh ./carelink.ttyUSB0
[...]
$ PORT=./carelink.ttyUSB0 SERIAL=208850 run_download 
[...]

• download
• commands

Try figuring out the dosing commands. Is it possible to rewind the pump? Is it possible to enter new profiles and schedules?

https://github.com/bewest/decoding-carelink/blob/tester/logs/commands.log

https://raw.github.com/bewest/decoding-carelink/tester/logs/download.log

In the first log, we can see a bunch of commands/settings downloaded, no problem.

In the second log, we try to download the 17 pages of history available.  We can see on the third stanza or so for downloading the 0'th page, a Bad CRC pops out.  This behavior is more common when forwarding over the 'net; when plugged in directly it happens, but less frequently.  There are probably some relatively easy fixes to make this work perfectly, I'm hoping someone can help suss out the details.  Clearly something about the way I proceed after a BadCRC occurs is not quite right, making data retrieval somewhat deterministic.

To produce these examples, I ran commands listed above.