Just a quick one - who's the London based person who is under the care of Guy's Hospital and spoke at their Junior Doctor's education session about OpenAPS? Thought it would be interesting to link up as that was mentioned when I raised the topic at clinic recently. There can't be that many hospitals in the U.K. With multiple openaps users 😀
@tim2000s if you check the github from @SandraK82 there is a setup skript for NS on a pi. I wrote some lines up as a Gitbook, but it is still in German, however I I stole most of my information from https://gist.github.com/johnmales/1b3c927f2a56aae640b4b2cd0298b1e7. If you are on a pi or Edison you will most likely need to update node and npm as far as I remember. I run Mongodb and NS on my Edison with ubilinux
@tim2000s for mongodb on my Edison I downloaded the 3.2.9 tar.gz from mongo.org and extracted that. As this is not a clean installation you will need to run mondod with several arguments. I start with
screen -dmS mongo [path to mongod]/mongod --storageEngine=mmapv1 --rest --dbpath [path to database]
If anyone has it, can you post the link with where I can find information on the Nightscout prediction of bgs that it uses? I know it displays two separate prediction lines which I am guessing are likely outcome depending on next reading into NS in either a +/- of bgs in either direction. I just want to find out more of how it looks at trend, etc to extrapolate that.
Openaps is very clear on the prediction of BGI in the reference, so I understand that. I am just curious as to how/why the NS website gives blue split lines going out from the current bg both up and down.
It seems I've fried my G5 receiver. It was just plugged into my raspi and noticed it was super hot. Hit the button and nada. :weary: Thinking back, I believe I had the code to send more power to usb active in the code. Anyone ever had this happen?
@davidkeddydb AR2 is basically a 95% confidence range for future BG based only on the last couple readings (no knowledge of IOB, COB, or anything else). if you're instead talking about the purple prediction lines, those are from the predBG arrays generated by oref0.
"While we’ve been working closely with the FDA on this product submission for the last several months, the approval did come much earlier than expected. Given this and the novel nature of the technology, we won’t be ready to ship the MiniMed 670G system until spring of 2017."
You think the community will be hack the 670 to make it work for openaps....I can't imagine MM freely opening the door to this possibility anytime soon
@scottleibrand no worries...do let me know if you may be able to test this evening..understand if you dont have time though...always appreciated. ANd let em know, if you'd like me to test anything with your script or otherwise--would love to be able to try and repay the favor.
@scottleibrand Was thinking about a tweak to oref algorithm that would compensate for initial jumpiness of sensor values seen immediately following sensor startup. Might make it less reactionary during this period.
Still thinking about it but.... on the surface was wondering what the impact would be if you modified the way the rate of change is calcualted to be based off of a period further back in history....maybe more of an average...
of course would still need a lot more analysis but it seems that often times you get an erroneous blip in the readings..that probably suggest the cgm was wrong at that time....but it seems oref0 makes an immediate determination based on the data still........
of course...it would seem there is an inherent trade-off.....an d a bit of delay in reposnsiveness...but maybe it would also mute reponses that may have been made on in accurate data.....I guess this presumes that the data proves out over time...which,i think it does
and maybe I'm misunderstanding or just not understanding the inner working of oref0...but I had thought that you are comparing those different period -15 and -30 against the latest BG......in that instance maybe its not comparing against the avg. of say last 2 BGs.....but somehow delaying the enact to confirm what it had predicted---was accurate (within a tolerance) before it is enacted.
@scottleibrand good point new vs. restarted...(I'm sure there are a lot of other things to think through obviously)...I think this part though may be easy enough with the addition of the appropriate field/s in careportal....new sensor...and restart sensor......
@tim2000s that's what has been reported, yes. seems the problem is not so much the target as the fact that the pump often fails to get BG down to target. we'll have to try it out and see if there are any tricks that work well to counteract that. I've heard of lots of people entering fake carbs to make it be a bit more aggressive...
@garykidd yeah, reducing temp basal variation has been a goal of mine, but not at the expense of reduced responsiveness when needed. there are a few other things I need to do around AMA to reduce oscillation. but at the end of the day, bursty insulin delivery doesn't really reduce the effectiveness of the loop, so it's a lower priority than some other things, and not worth adding additional usability burden
@scottleibrand keep in mind it would only be enacted during periods of initial jumpiness and then fall away (in an ideal world). and please do understand that I am only conceptualizing and not actually suggesting that you work to incorporate this or anything like it into your awesome work---which it trul is (and thank you, sincerely) ---just theorizing more or less. but thinking a bit more about this...if you did anything that could smooth basal delivery---no matter what the course---I think a lot of approaches may very well lead to less repressiveness...the question may be is the trade-off worth it. In any case, maybe a simple user toggle may be warranted (especialyl in the case where a trade-off is not avoidable) for a feature like this.
On another FDA note, the Freestyle Libre is making its first foray in the US market with the Libre Pro, a version of the Libre that can only be read by taking it back to the Doctor's office. Wonder if @SandraK82 's BlueReader will be able to work with these US Libres.
@C-Ville In the US Libre is unavailable. The FDA only approved the "Libre Pro" for the US this week. Unfortunately, that device is applied at the doctor's office and can only be read when the device is returned after collecting readings. No readings are available in real time to the person with diabetes. The consumer version, like the one available in Europe, has not yet been approved by the FDA.