I've got some basic js code for simple glucose dynamics on my repo - @bustavo is working on a ui and the graphing - it has the Walsh iob in it and the Scheiner cob curves - it ignores renal and hepatic - basically assumes basal is right - I have the high gi curve in and im working tonight to put in the medium and low gi - but needs testing and a ui - once it's well tested we will knkw more - main goal is to basically visualize the curves from bolus wizard (though you can specify cob which is different)
@kenstack is that in glucodyn? or a branch of cgm-remote-monitor?
ah, found it
I have looked at function predictARDeltas(actual, lookback, tick) and I have ideas of what to do. However, I had to pop some pills that make me like confused so I will be back in 6 hours or so. I am not trying to get out of work.
@kenstack nice graphs!
@cjo20 thanks !! Needs testing but matches my mathematica work. As you can see I am not a professional programmer so hopefully @bustavo will make it look a lot better :) The iob is the same in both
I like showing the bounds of carbs and insulin - sort of bounds it
In my ihawk repo I show a compare of Walsh to mdt's iob curve for the 3 hour curve
where are those formulas from?
I curve fit them from the graphs in Walsh et al
They are really close to mdt
Walsh's pumping insulin - also in a lot of papers
"Insulin activity for various pump DIAs"?
Like cob my plan is to put a user defined option in too - there is so much variability between people it would be good for those where the curve doesn't work to use their own
It's in one of his books too sorry I'm not near them
just went and got the book myself :P The one in that paper is a little easier to see though
He makes an interesting point about kinetic vs dynamic insulin action in his book though
Yes - the iob curves really are a general guess by him and others looking over large numbers of patients - I think the shape is right - how exact - hard to say - one of the keys with any modeling effort is to figure out how accurate we are trying to be - with the simple glucose stuff I think the errors in sensitivity factor, carb ratio, basal rate, and the many things going on in the body at any moment make the models useful for direction - actual accuracy to 10-20 mg/Dl ? Unlikely - my goal is to really see in real life how well the basic math can be used to determine - say 2 hours after a bolus - am i trending high or low and alarm for a check - can we intercede earlier when we are off the expected bg curve based on carb amount, type and bolus timing - will be interesting
I might have to steal some of that glucodyn code for the program I'm writing :P
@kenstack yup, that was the initial premise for diyps predictions!
Go for it - but it's frankencode :) expect some improved versions
@danalewis as you know the curves etc Really need to fit the individual - hopefully people understand that as they use diyps, this stuff or anything else - the model needs to be tested for the person
@danamlewis missed an m :)
Exactly, @kenstack. Everyone needs to tailor it based on their ratios etc. Any tool will always require setup. Good data in, good outcomes out
Hopefully :)
I wonder how hard it would be to reverse engineer insulin curves from CGM readings. If someone did, say, 3 tests where they did a bolus with 0 carbs and tracked the results for 4-5 hours on the CGM, average the shapes and then work out the activity curve based on BG change, and then work out the insulin curve based on that
It starts with the latency of the insulin defined. That is, the time it takes for an X unit dose of insulin to directly have affect on blood glucose.
Anyways, I feel better now. I had really bad nausea, body cramps, and a headache (from the cramps) and the drugs that make me dumb are wearing off.
@cjo20 very achievable. We changed my DIA from 4 to 3 based on that
What would be awesome if the system prompts a notification for ppl to review theirs if its deviating a lot
Yeah - I think if your basals are well set you simply eat carbs, let bg flatten after absorbtion, then dose and look at the curve - hard part is making sure basal is perfect - never is - at least in my house :)
Walsh talks a lot about it
Id like to add an interpolation routine - the mdt pumps force iob duration by the hour - Id swear Ryan's (my t1d son) is 3.5 :)
Key is basals and waiting it out
I've done a lot of testing this week. Still got a couple of gaps in my basal testing though. Need to do an evening basal test and an insulin duration test.
Get close - all we can do
@scottleibrand - I looked in client.js in the iob branch - where is the iob curve?
yeah. Overnight / morning is pretty flat. Afternoon drops a little, but not by much
Sorry it may be way easier for me to give you a function and have someone impliment it
Maybe wake up at night and do it if that's the most stable basal
Closed loop may be the new basal test :)
Wouldn't that be awesome :)
(Easier for overnight obviously but still doable for daytime too)
@kenstack try looking for iobContrib
line 1505
You can simulate basal rates in the steady state, just FYI.
This message was deleted
@kenstack although I think it bases things more on the 'acitivity' curve than the 'iob' curve. Not 100% sure though as I haven't traced all the way through the code yet
@cjo20 there is no 1505 in client.js am I in the wrong place ?
Thanks ! I just have wrong branch ...
I've done that a few times over the last few days :P
Yeah -/
and I suck at GitHub :)
if you don't mind me asking, what do you do for a job?
As little as possible :) im semi retired - I was in digital printing for many years, now I run a small boutique m&a/vc business but I only do it part time. So my code convinced you im not a programmer huh :) my last commercial code was in fortran 77 in the 90s :)
it was a lot better than some of the 'programmers' I've seen :P
Wow ... That really scares me - but thanks :)
I was a technical guy for years - but not in the last 15 or so
Got my first autoregression function done, for determining the coefficients. It's not 100% JavaScript though. I am not fluent in JavaScript,but I know Java.
I also have to test it and refine it, but in theory it should work.
https://gist.github.com/diabeticgonewild/9c0eb4b2e4781f2635cb
I have to substitute in variables and stuff...
@diabeticgonewild Not had a chance to try and read the code yet (and it's 4am here...), is it ok if I make a suggestion in terms of formatting?
yeah, please :)
Personally I wouldn't comment beginnings / ends of loops, unless they started getting big enough to not fit on one screen, it just takes up more space, you can use indentation to make that easier to see too
OK, thank you. I will remove them. I just have my strange habits.
oh, and something that can turn in to a really annoying bug that gets hard to track down is not using braces for if/for statements. It's very easy to try and add a new line to an if statement and not notice the lack of braces
yeah, that's true. But I always follow a convention, but I guess everyone else doesn't so I will change it
I don't know what you think of this: https://gist.github.com/cjo20/d05f6907d9b0bf7e7cbe of course, if you're happier doing it another way, stick with that :)
It
It's perfectly fine except that you missed the first comment which says "opening brace..."...LOL!
Thank you!
heh, as I said its 4am :P
yeah, it's all good :clap:
so what exactly does that calculate?
Like the coefficients, for a particular set of CGM data, needed to calculate an autoregressive fit for CGM prediction.
The coefficients are completely dependent on the CGM data.
so they'll be passed to another function that actually tries to predict what comes next?
yep....and there's more functions to come...just have to figure it out.
heh. Good start then :) I think I'm going to get some sleep in before it's time for work :P Night
Yeah, that's important! Take care and good night!
yeah, good start
yeah I know. That's why I try to stay organized and read up on it before I implement anything.
Thanks, everyone
@kenstack in glucodyn could you avoid having to do numerical integration by actually integrating the walsh equations? Or would you not want to take out that method in case someone wants to use a curve that you can't integrate?
@cjo20 absolutely - look at the file basicmath on the repo - I left it in case we want to use temp basals (fluxes) that are not constant - will impliment that at some point
@kenstack I'll give that a read later :) Hadn't refreshed the repo since that last commit :P
Also right now I make the assumption that sf and cr are constant during the time period - Id also like them to be functions of t
why would they be functions of t?
@cjo20 because many people feel they change based on time of day
@sulkaharo cool!
@sulkaharo yay!
@sulkaharo Is this what you said you were getting really good range out of? How many meters again?
@TC2013 I've not used it myself but I think I heard people talking about 7 meters or so
Does anyone know why the carelink stick has such poor range?
@kenstack , are you going to use differential equations? That would be the best representation of that, as a function of time. For solving the DE as a system--in the steady-state (good for everything except the kind of updated models from Hovorka), I personally would use globally convergent Newton's method or globally convergent Broyden's method (preferrable) as the model is nonlinear.
If you are not solving for things as a system, use some variant of Runge-Kutta, with PI (preportional, integrating) controls.
@TC2013 , I wouldn't know. However, I do know that those really cruddy BD Link meters could communicate long-range. I had my pump downstairs >20 feet and it would transmit from upstairs and my pump would receive it, which is crazy.
Although the antenna would be have to be designed a certain way, power is probably the most limiting factor for range and transmission.
I take that back, as @cjo20 said 7 meters (as a distance quantity--I thought he was talking about glucose meters for a minute), which I basically restated with the BD Link meters. :P
@kenstack , the way the Hovorka models are described and used, it would be difficult to solve for anything reliably besides in the steady-state, which has limitations.
However, in Stochastic Virtual Population of Subjects With Type 1 Diabetes for the Assessment of Closed-Loop Glucose Controllers and the doctoral thesis, if you search in Google for "External Artificial Pancreas for Type 1 Diabetes: Modeling and Control", I am pretty sure things can be solved for in 15 minute intervals, with the time-varying piecewise linear functions, but that is something I have to test out. However, I have a feeling I am right on with that.
Solved for in 15 minute intervals, in simulations, that is.
*fluxes, not functions
@diabeticgonewild exactly - his models are looking at steady state - glucodyn simply models short term dynamics - if basal is correct, what do perturbations do it boluses and temp basals - think of it as the bolus calculator being graphed
I'm looking to model what happened in the time frame of iob and cob which for any given event is 3-4 hours. The steady models are cool and give insights for ap but this is a short term predictor based on glucose dynamics outside of basal
There's nothing wrong with the steady-state if you are using it in real-time as an "artificial pancreas". In that respect, the steady-state is perfectly fine.
Glucodyn looks very nice for corrective action that cannot be taken seemingly instantaneously or automatically.
Yes exactly
Havorka models are more system models - im looking to alarm for a bg that is running higher or lower then I expect from a carb / bolus event
I put the basic math on the repo
I think I might have to get back to you (eventually) on the model(s) you want. I don't know how that would be covered. I am working on something semi-related, for BG prediction right now.
I am probably going to get flamed but I am not really a fan of COB and I don't even know how those concepts are modeled. Keep in mind that I have severe gastroparesis (not diabetes-related), and I have reasons not to trust such models. That doesn't mean that I don't think they are important. ;)
@TC2013 I haven't measured super accurately but right now the stick and the dude are on the opposite corners of the apartment at ~8 meters away and it works perfectly.
@diabeticgonewild no flaming :) it's just a model - if it's useful becuase it predicts behavior and csn help bg control that's great - if not we try something else :)
@kenstack , the newer AP models from Hovorka may be able to model the short-term effects of IOB and COB (if the equations are rewritten in terms of CHO--maybe), given time varying piecewise linear fluxes, in 15 minute intervals, for both basal rates and meals. However, this would be something that would have to be "tested out". I am fairly confident that it can be modeled mathematically (although some of the math still looks scary to me), and I am not nervous about implementing the math. But, who knows how beneficial those 15 minute intervals are until it is tested out.
- basal rates, as in insulin dose (corrections and everything else) through the basal
I would be surprised if things could be projected beyond 15 minutes though, if not using a real-time AP.
Think of your bolus wizard - it's the same math basically but we account for carb absorbtion rate
Got it. :D
@diabeticgonewild the 'basic' carb model in nightscout wip branch basically models it as a delay and then a period of absorbtion. If the gastroparesis is somewhat predictable with the delay, you'd just set it up to have a larger delay at the start
I think we can make the cob stuff really generic - we can allow a user defined model - it's on my list
For delays in glucodyn just set the start time of the carb event after the bolus - it's like your body's pre bolus
When you guys are talking about 7-8m range, is that from Enlite or bidirectional with the pump?
@sulkaharo @tc2013 ^^
I'm not sure, but that would be awesome if it is bidirectional!
the 7-8 meters is when listening to the enline, the bidirectional pump range is somewhere around 3-4 meters. Both depend highly on what's between the stick and the device
The uploader just did bidirectional comms when the dude was running around the room. I assumed it'd fail but didn't.
@scottleibrand ^^ :)
The Enlite passive listening range is basically so good, I'm just assuming it'll work everywhere regardless of phone placement in our our 800 square foot flat. The pump transfers require some attention but the range is way better than with CareLink, so there's much less stress on having the transfer break all of a sudden, which I've had happen with the official stick.
Ok just did a highly scientific test and distance measured as ~4 meters by step estimation worked for bidirectional pump comms.
@sulkaharo that's cool :-)
@sulkaharo when I was testing ihawk I intentionally broke the comms during command sends to see if I could cause the pump to execute an incorrect command - I could not(which is a good thing). I'm intersted in if you have seen the same
@sulkaharo @kenstack I break all the time, doesn't fire incorrect commands, just re-picks up when you're back on.
Good :)
I tried reasonably hard to break it and I never got it to fire a wrong bolus - but - this needs a lot of testing prior to general release
Ya. I didn't try, but after first day I gave up trying to stay in range. I've bounced back and forth between two pi/Carelink setups on either side of my apartment and that doesn't cause issues either.
math.js is included in the NS library, right?
I wouldn't think that it doesn't exist there, but I am just asking. I am not an expert at GitHub, either.
it can be if needed
got it
I've used Jesus' thing for three months and the pump has crashed 0 times.
nice :)
that's great start
@sulkaharo congrats to you and @jberian for getting that out
Awesome
Yup. It's not perfect though, but the best thing for Enlite users. :)
what about getting the status updates?
I see in the code he implemented many of the same status stuff I did
getting temp basal rates, etc
current status
does that also work everywhere?
The extra information is currently fetched but not logged - needs more hands and people who actively use the software
Or rather, there's some logging but not in a particularly useful manner.
AFAIK the MedTronic RF protocol has CRC for all transmissions and the pump just won't execute anything where the CRC fails. So it's unlikely it'd bolus wrong.
yes, that's true
not worried so much about errors
I should ask jesus about those bytes
how did he figure this out?
I was unable to tell what some of these bytes mean
Trial and error? I did some speculation on some of the bytes but it's his masterpiece. :)
yeah, he's been a lot more facile with this than me
The raw enlite data to ISIG to BG needs work - the also isn't producing exactly the same figures as the pump and there's something off on how it treats some particular sensors, where if the sensor starts to go bad, the mmcommander values seem to larger variance on the isig than the pump
I suspect that's partly the pump filtering out crap values but also the pump knowing something this doesn't
Effectively, if a sensor is going bust, mmcommander starts to show jitter in BG values reported, while the pump doesn't
Oh and what could be interesting is the software now listens to the glucometer and reports those values directly as the mbg value to Mongo
Being able to detect the glucometer transmission opens some possibilities for being smart about loading treatment data for uses who always check before a meal
Couldn't you just use an Medtronic Paradigm Remote, with like Lego Mindstorms set up to press the remote several times via LabVIEW, and have a piece of hardware that sniffs the signal interfaced with a computer?
Isn't that the basic concept (although it's a lot more complex than that)?
@diabeticgonewild yes, except the Remote supports very small subset of all the commands, and there's no reference point to what the enlite CGM data means, aside from capturing the bytes and figuring out how to produce the ISIG from those based on what the pump says
well the calibration algorithm is propriatary. Some students at the University of British Columbia made their own CGM intefaced with their own calibration algorithm using SofSensors
There are calibration algorithms posted in like journal articles and stuff, that might be superior to Medtronic's, but the programming gets extremely complicated
I'd LOVE if someone actually solves the algo. The uploader can totally made to upload all the raw data.
Well, that's embedded in the pump. Obviously there are superior algorithms than Medtronic's as there is a delay due to FDA approval. The problem is with the Enlites is that there is a 3 day drop in ISIG. However, there is more data than the ISIG included, as there are three prongs on the transmitter, so that may not be as much of an issue. ISIG, Vcc, and Ground...I think
This is what I was talking about, for designing an entire CGM, minus the sensor (which cannot be DIY, as the manufacturing process is complicated). http://www.mina.ubc.ca/files/474/su2006/Team%2010%20-%20Final%20Report.pdf
2006 (!)
They posted a lot of the code, too...
@sulkaharo: awesome news on the MMCommander to pump range! Need to order one. :-)
MMComander looks awesome! It can send boluses, correct? Does it make sounds when a bolus is delivered (i hope not...)?
I've ordered mine from Farnell. Excellent service and cheap prices.
Monica: depends which pump you have, and which MMCommander firmware you use. @jberian's instructions use the listen-only version by default, but you can compile a transmit-capable version.
It doesn't load bolus data from the pump yet. However it does upload glucometer data even if it wasn't synched to the pump.
Looks like there's still a fair bit of work to do to implement the full suite of pump upload capabilities we have in decocare, but with the basic structure in place that should be much easier.
yeah, it sounds awesome! But I have to work on the AR stuff...for now. I am bound to make some JS errors due to differences in library, but my programming is going to be clean. You have to be clean when dealing with math or it just gets nasty... :P
So - given the actual RF protocol is the same regardless of whether one uses CareLink stick or mmcommander, it'd be pretty awesome if the Medtronic protocol implementation was made in such a way that the stick specific wrapper code was separate from the actual protocol implementation, for as much code reuse between the two as possible.
yeah
well, once you get the payload, decoding the payload is always the same
so there's that at least
Would love to see someone integrate @ktind's kl.minimed with @jberian's code.
No reason we couldn't make all of @jberian's stuff work on Dreamsicle with either MMCommander or Carelink USB
also need to get the bayer nextlink figured out
apparently that device doubles range of the carelink
@scottleibrand so you are in town tonight?
Nice. Yep.
@scottleibrand surprisingly, I don't have rehearsal
usually I do monday nights, but nothing tonight
so I've been looking at building tool to help visualize health of community based on facebook api
wondering if any twitter folk might have ideas on that kind of thing
Hey stupid question: what's the BGI value in iob-cob. Been ignoring it for now. :P
Sorry, what's BGI again?
Some delta next to the bg delta
Oh, that was a @jasoncalabrese abbreviation. I call it BG impact.
It's the expected current impact of carb and insulin activity
so, for example, you "should" be dropping right now by 6 mg/dL, but in fact you're dropping by 12, might be reason to watch out and possibly low-temp
also gives you a better idea when SGV readings are anomalous.
nice, maybe I use that to create shadow on dot
impact over next 5 min?
So in ideal world they'd be the same?
so prediction of next delta?
right on both counts
it doesn't differentiate between last/next. It's "now" impact.
Actually maybe it was @jimsiff who coined that. Can't recall.
So it's the slope of the iob curve assuming carbs are absorbed ?
Ya
Slope times magnitude sorry