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.
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.
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 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)
Dexcom G5 and G6
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."
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.
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.
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?