How are you guys feeling about the new Loop insulin model?
They have thrown a recommendation out that I go back to the previous one.
I think that I get better performance on traditional Omnipod, now, because of the flexibility. Maybe I should try to change the Loop algo. IDK. I might get my G5 today.
For us non-loopers, can you tell more about what is new/ different ?
Well, they refer me to the formal documentation here: https://loopkit.github.io/loopdocs/faqs/branch-faqs/#carb-model-changes-in-dev
I installed it in October. They describe is as more aggressive, but thereās an issue with the timing of the delivery for me. Iām not seeing enough upfront and Iām seeing too much late to the races. So, I get a HIGH LOW result.
I really, really liked the other model. That meal bolus was the main thing that I liked about loop. I donāt really care about the basal adjustments. But, the meal bolus was goldā¦for me, anyway. People have different preferences.
I was considering going back to the version from late July to recover it. But, people make different recommendations.
So why not stick with what works?
Well, I can go back to the old version, but they have recommended that I not do that.
I assume because there are 5 months of bugs that have been fixed since July and I, essentially, undo all of that if I pull such an ancient version of the code.
One major hang up is that the new Dexcom transmitters werenāt yet necessarily incorporated into that version. (Although, I would pull from Late July to try and avoid that.)
If I move to a G5, that might not be such an issue. I dont think that Dex is as protective of their G5. Its possible that they havenāt been releasing a bunch of new transmitter models that will cause problems with the code. IDK.
Thereās been so many changes to Dexcom software since then, I feel like there are likely to be problems. They are telling me not to live in the past for a reason.
The only alternative is to add different pieces together kinda piecemeal, maybe. IDK. We have so few loopers on Tuā¦but, it helps to talk through it.
They are recommending that I merge the old algorithm into the new code. I can try. But, its not going to happen today. So, I just returned to Omnipod receiver for now. No problems with that, so far. Its actually kinda refreshing to have so much flexibility again.
Whats nice about Omnipod is the pure, unadulterated flexibility to do whatever you want, whenever you want to. Its so refreshing. I never really had enough appreciation for that before.
There are several loopers on FuD.
Oh crap. That guy sounds like me. I gotta go talk to that guy.
If your over there, help me if a bunch of trolls descend on me. That is a foreign land that I image like this: https://www.youtube.com/watch?v=cUpT6q9XRUs&list=PLZQUyzYaAUYuyud0o75ETlJ4H5oCa1cxG&index=3
Iāll go in. Iāll do it. I know a bunch of you are over there. Iāll treat it like crossing the border into North Dakotaā¦get in, get out quick. Might be ok.
Oh, I know him. Maybe there are more over there. Its a good resource in case I get stuck. I forget everybodys over there, too.
You can check out this before you decide.
Thats actually a really good picture of how it works. I didnāt fully understand this until recently. I thought it worked like other systems, where CGM numbers were collected directly from the packets sent by the sensor, but it collects CGM data off the commercial Dexcom app. Thats why things were bad when the servers went down.
The graphics shown is fine, but the comment āThatās why things were bad when servers went downā is a bit misleading. In the most common configuration, Loop eavesdrops on bluetooth comms between Dexcom transmitter and Dexcom app, which is why the transmitter ID entered in Loop must match the transmitter ID in the Dexcom app, and Dexcom app must be installed on the iPhone where Loop is running. In this most preferred configuration, Loop does not require Internet access or access to Dexcom servers. Dexcom servers going down created problems only for those who (for whatever reason) configured Loop to fetch CGM data from Dexcom servers instead of locally.
I use the most common configuration that @Dragan1 explained above. I had zero problems with Loop during the server outage.
Let me drill you on this to see if I understand.
I thought, originally, that it was pulling data broadcast by the transmitter.
I thought that when I read the original documentation, it sorta implied that local and if local BT failed, it could still pull from the internet (or visa versa - I canāt remember now).
But, then I thought it was pulling data from the app.
Hereās what it says in the Docs (for refresher)
"
If you donāt update your transmitter ID (in Loop) when you change active transmitters, your Loop will be forced to go to your Dexcom Share server to get your CGM data and will not work without cell or wifi connection. When Loop is using data from Dexcom Share servers, a small cloud will appear above the BG reading in Loop and should tip you off that maybe you forgot to update your transmitter ID.
Dexcom G4 users will need the Dexcom G4 Share2 app active on their iPhone and paired to their Dexcom G4 Share receiver.
The Dexcom Share selection is primarily for people who wish to test Loop function without a local CGM source (THE RECEIVER?) and who are not running the Dexcom app on their Loop iPhone. This selection will require login access to a Dexcom Share account with live data and active internet connection in order to work."
What the hell is Dexcom Share? Is this it?
Thereās a Dexcom app (main app for people who want cell phone instead of reciever - LOCAL COMM?)
Dexcom Share and Dexcom Follow (put data on the server and for others to access it)
Dexcom Clarity (no idea)
Dexcom Studio (old software)
I think my main question (I had to write a lot to get around to it) is this:
It seems that local communication or communication through the server is really an Either/Or relationship. Was it always like this?
That wasnāt how I originally understood it.
Did something change or did I misunderstand something?
I used to see the cloud pop up over the summer, and then go away as if I was alternately on BT and cloud. When my internet used to go down, I would leave the house and be able to get CGM, but I was never sure if maybe my phone was providing connection.
Sorry to write soooo much. Even I am sick of my own thoughts.
The answer depends on how you setup your Loop. If you have G4/G5/G6 and you have Dexcom app running on same iPhone as Loop, the best approach is to have Loop work exclusively with CGM data obtained locally at all times. As an example, these are Loop-CGM screenshots for G6: Dexcom Transmitter ID must be entered correctly, and Dexcom Share should show āTap to setā - no need to do anything there.
OMG, thank you, Dragan1. Let me go over thisā¦
I very much like the new algorithm in the Loop Dev branch, I believe courtesy of @Dragan1 
It took me a while before I moved to it from Jojo, only a couple of weeks ago now, but I must say, I notice improvements in TiR already and just as important, fewer lows, which I tend to struggle with even on Loop. I like the more aggressive strategy. At least it works well for me. That being said, you donāt have to accept the bolus suggested by Loop. You could do trial and error and see if a different bolus might work better. I do not always accept the suggested bolus myself.
Good to hear feedback. Iāve been using it a couple of months.
I bet thatās why they changed it - people must have been complaining about lows.
Makes sense that if I was running perfect before, now Iām running high.
Iām a freak, lol. I am just different, maybe. Darn it. Thats the worst case scenario!
I thought that maybe it was something changed inside me. But, behavior/dosages look pretty normal on Omnipod. The only other strange variable might be the G6. Its not detecting highs very consistently. So, perhaps that made all the data look fantastic on the original algorithmā¦before I started finger checking like crazy, I didnāt notice how common they were.
Too many variables!!!
I changed back to the .linear model for carb absorption.
But, it was the āretroactive correctionā function that really made that version shine, for me. So, weāll see if this is good enough for now. Its anybodyās guess. Maybe Iāll just set it to deliver as much insulin as is typical for Omnipod. That might cut it.
Most of the people Iāve helped that have late rise issues with the new carb model are from having basal too low and loop was covering it with the linear model. Many were using longer absorption times than should be used.
What absorption times are you using most often?
Do you set the time of the carb entry for when you are eating instead of when you are entering it for your prebolus?
