Looks like I have a 722 and a 723. The 723 is worthless though because the escape and act buttons aren’t working properly. I forgot that this was the reason I chose to try MDI for awhile- probably because I could’ve just gone back to the 722 if I’d really wanted. The 723 also has firmware 2.5b too, so it’s not useful in any way.
The 722 is in good condition. I think I ended up getting a replacement right before the warranty ran out. I only got a new pump (723) because it was covered in full by my insurance at the time. I’m a little hesitant to sell the 722 now that I know the 723 isn’t working though. I feel like a hoarder!
I’m still figuring out how to work with the LOOP algorithms. I had been gradually tightening the insulin sensitivity factor, the carb factor, and making sure I had sufficient basal in an effort to blunt spikes after eating when I incorrectly estimate carbs or don’t prebolus early enough. I had my max basal set at 2.7 times my highest basal requirement to give the algorithm headroom to give extra corrections when needed. (The LOOP documents mention that experienced loopers generally set it somewhere between 2 and 3 times.) My settings seemed to be helping control spikes until a few days ago. My body had a sudden decrease in overnight basal requirement, about 10%. My somewhat aggressive dosing settings drove LOOP into oscillations. Because my basal requirement had dropped, LOOP saw my BG dropping steadily, and cut off the basal to try to ward off a low. It wasn’t enough, and when I got a low alert I took glucose (and told LOOP I was taking 8g of candy). The glucose caused my BG to rise strongly, after which LOOP predicted a significant high was unfolding, so it ramped up a temp basal to try to blunt the spike. This extra insulin caused my BG to start plummeting, so LOOP cut off the basal and the process recurred. I reduced my scheduled basal about 10%, reduced my max basal to 2.5x, reduced the strength of the ISF and CF a little, and everything calmed down. But of course now LOOP is less able to handle post-meal spikes, and tends to linger in multi-hour plateaus around 150 to 175 when I incorrectly underestimate the amount or speed of the carbs when I run the bolus wizard.
For now I’ve gone back to mild surfing after meals on top of what LOOP is doing. Sometimes I correct by asking LOOP to deliver a correction that is a unit or two above what it thinks I need. And sometimes I use a quite nice feature of LOOP: I can go back in history and change the numbers I had put into the bolus wizard. If I eat and see a spike developing, I can go back to my wizard entry and change it to be a larger amount of carbs, or if I am pretty sure of the number of grams I ate, I can change it to say it was a faster carb. Then the LOOP algorithm recalculates its predictions of where I’m headed and adjusts its dosing accordingly. I still need more experience with this before I learn to do it well, but things are generally heading in a good direction.
For those who experience a change in basal requirements, my experience suggests it will be necessary to adjust the basal schedule right away, because if the scheduled basal is too far off, LOOP can’t compensate for it.
A fundamental limitation is that LOOP is predicting the future evolution of the BG curve based on the insulin action and the carb action, and if this prediction says the BG will return to a normal level, it is impossible for the automatic algorithm to increase the insulin dosing because LOOP can’t recover from an insulin overdose (until we get dual-hormone pumps.) Even if the BG rise seems to be accelerating in the short term, and even if the predicted downturn in BG keeps being pushed off further and further in the future at a higher and higher BG levels, if the long-term prediction is a return to normal BG, LOOP can’t act to blunt the spike. The algorithm does factor in the “momentum” of a BG rise and the difference between BG predictions and what actually happens, but for me and my settings it’s not enough to solve the spike. As far as I know, the current LOOP algorithm doesn’t consider the possibility that a multi-hour moderate high (160 or so) could cause significant insulin resistance and require corrections that are 2x or 4x larger than what the insulin sensitivity factor says. So I think that after meals some degree of surfing will continue to be necessary. For now, LOOPing will not be fully automatic when carbs and boluses are active. In the future, a dual-hormone pump could enable LOOP to be more aggressive with corrections without risking sending us into hypos.
The lack of a “temp basal” setting likely will inconvenience people who like to set a temp basal as an easy way to compensate for an apparent change in insulin requirement (stress, hormones, illness, …) You can’t just globally “decrease basal 10%.” You will need to make individual changes in each line in the basal schedule, or you can try changing CF and ISF but the latter approach may cause an overcontrol that simply drives LOOP into oscillations rather than solving the problem.
I wanted to show BG graphs before LOOP and for my first week of LOOPing because the latter was flatter and had essentially no lows. But then I noticed that the “before” graph was with a fresh sensor, and the “first week of LOOPing” was with a restarted sensor. For me, old sensors are less responsive and give flatter graphs, so the visible difference between the “before” and “after” didn’t necessarily say anything about the effectiveness of LOOP, it was confounded by the effect of sensor age. More recently I’ve been fiddling with LOOP settings and surfing approaches to help with post-meal spikes, and I also experienced a sudden decrease in basal requirements, so the current BG graph while LOOPing looks worse than my experienced surfing technique gave before. I’m sure that I’ll get things dialed in, I just need more experience in learning how to cooperate with the algorithm.
My current impression is that LOOP right now makes my diabetes much easier to live with: away from meals LOOP does a really good job of tweaking my insulin to keep my BG in range, so glancing at the CGM has become much less frequent, and manual interventions practically non-existent. In particular, I get few sleep interruptions from the CGM saying my BG has drifted too far. I recommend trying any of the open-source closed loop software to ambitious pumpers who are prepared to tweak the settings over time to find out what works for them.
@bkh thanks for the detailed account of your early Loop experience. I can confirm that it indeed may take some time to transition from manual surfing to Looping. The key point for me was to realize that I no longer needed to think about how to dose insulin, but instead focus on how best to tell Loop what I am going to eat and when. To this end, I find the Loop’s “Carbohydrates” screen tremendously useful, as it gives real-time feedback of how food is actually absorbed, as well as whether “carbs” entered were over or underestimated. If I see that I’ve made a gross error in a meal entry, I just go back and edit the meal entry, or enter another one, and let Loop do its dosing. That’s the only remnant of “manual surfing” I do these days, and even that does not happen very often, since I already know pretty well how to enter meals for the stuff I like to eat. It’s been long time since I did a manual bolus correction, or even a manual carb correction, staples of manual surfing.
That’s is a good recommendation, but still pretty conservative, for safety reasons . As comfort level and experience with Loop increase, one may consider bumping that limit up.
Oscillations typically mean that your ISF number is too low. I’d recommend returning settings to your pre-Loop values (as long as you are reasonably confident you had them reasonably well set), and instead focus on meal entries: amounts and duration. Also, I recommend using a pre-set insulin model (most likely rapid-acting adult, unless you are using Fiasp), and not the Walsh model with possibly too short DIA.
In such situations, it is best to edit the entry based on bg response and carb absorption feedback provided, and let Loop do corrections based on better inputs.
Not the best approach. As you may have noticed, entering a manual extra bolus will cause Loop to follow-up with low-temping, partially negating the intended correction. As mentioned above, it’s better to correct the offending meal entry or enter another one if need be.
Yes, IMO, that’s exactly the way to go! If you continue working on that approach, I think you will more quickly get to the point where the need for any manual surfing vanishes. Well, I should say that’s been my experience, YDMV of course.
Correct on both of these. Well, it will do better than open-loop system, but still not as well as one would hope for. There is some work in progress on improving Loop’s ability to better mitigate such disturbances.
That is correct, there is no such provision in the Loop algorithm. We do not know how to model any such increase in insulin resistance. and there are different theories on that topic. In my experience, it is protein+fat that cause sticky bg’s, not “resistance”. On that note, I should say that I do take into account protein+fat when I enter meal entries. Entering just carbs would not work well for me at all, unless it’s really a carb-dominated meal.
Multiple basal profiles will be coming in a future Loop release, already available for early testing, so not too far out.
Exactly. One should resist the urge to alter these settings too much or too soon.
Yes, that’s where things should go! I honestly do not remember the last time I was woken up by any Dex alarm
This information is quite helpful, because it corrects a faulty conclusion that I had been developing. Based on my brief experience with oscillations, likely because I pushed my ISF too low, I surmised that a higher basal limit promoted system instability, and I incorrectly generalized that. Based on your comment, my revised conclusion is that a high basal limit does not inherently promote system instability, it merely magnifies the effect of other incorrect inputs.
I am unconcerned about possible safety implications of a high basal limit because my previous surfing approach often had me catch a rapidly falling BG: I always have a roll of glucose tabs in my pocket, and the CGM alerts me at 85 so there’s plenty of time to stop a plunging BG, and the CGM reliably wakes me.
I was thinking of it as a cousin of the superbolus, pulling future basal into the present for a quicker effect, but with additional insulin. My mental model was that of surfing in cooperation with LOOP. I do understand your point that there likely is a better way.
I am aware of TAG bolusing but never tried it. So far I’ve done reasonably well with carb-only bolusing for my relatively high-carb diet. (A low-carb day for me is 130g, typical 180-220, occasionally more.) Fundamentally, I lack the discipline to carefully analyze my inputs when it is so much easier merely to surf the results as they unfold.
I had come to the “resistance” explanation because I think I observe a huge difference in the amount of insulin required based on how quickly I treat a developing high. Here’s an example of the kind of experiences that shaped my thinking. I like to have wine and cheese as an introduction to dinner. Think of the following scenario (dietitians please avert your eyes.) Let’s have 8 scandinavian multigrain rye crackers (40g carb) with, say, 3 oz of a nice double-cream brie and a pleasant merlot. If I take my usual insulin dose (a little less than 8u) as a 20-minute prebolus, I expect to see a BG rise to around 160 and then it comes back down. If, on the other hand, I realize 10 or 15 minutes into the meal that I forgot to prebolus, and so I take my regular bolus, I expect that I will soon see BG 170 and rocketing up. If I see this and hit that rise promptly with a 6u correction it will turn back down and all is well. But if I’m not quick enough and let the BG reach 225, I fully expect that I will need the 6u, followed 25 minutes later by 8u IM, followed an hour later by another 8u IM (which turns the BG graph down, but will require additional fast carbs to catch the resulting fall). Same meal, but vastly different insulin requirement, so I attribute it to insulin resistance that resulted from too-high BG. I recognize that this is a suspect conclusion from the anecdotal experience of one individual. (Actually that makes me want to search to see whether the literature has anything to say on this topic.)
That addresses a different issue than the percentage temp basal. With the percentage temp basal, there is a single knob (1 single number) that proportionally adjusts the entire basal schedule by any amount required to suit any irregular circumstances. This is hugely different from the feature of multiple basal profiles. The latter may be well-suited to something routine like work-day schedule vs weekend schedule, but it quickly becomes tedious to maintain as the number of schedules multiplies. Think of (summer | winter) X (workday | weekend | exercise day) X (normal | sick | hormoneSpike | corticosteroidTreatment | motherInLawVisiting) and I’m already up to 30 schedules to maintain. Too hard.
That gives me two tips with very high potential utility. The first tip is to watch the carb screen. I am accustomed to surfing on CGM graph and although I had looked a couple times at the glucose-change graph I really didn’t grasp it’s utility. The second tip is that when surfing the glucose-change graph, the knob to turn isn’t the insulin amount I enter as a manual bolus in the bolus wizard, it is the carb quantity and duration values that are in the history below the glucose-change graph.
Here’s a question. Is there any utility to separating the carb entries that are eaten together? For instance, would I want to enter a 2-hour peach separately from the 3-hour yogurt for a bi-modal absorption curve, or do I get the same result in LOOP with a single entry that has a suitable intermediate absorption time? Aside: I just made up those times, I don’t yet actually know the proper times for a peach and a full-fat yogurt so I’ve simply called it all a medium (3-hour) carb.
Correct. 1/ISF is the system gain. Instability in the closed-loop system is triggered by too large gain, i.e. too low ISF. Of course, too high ISF means that corrections will be weaker and will take longer time. I just keep ISF at whatever value best approximates reality of insulin action for me.
The safety concern scenario is as follows: suppose Loop calculates and sets a very high temp based on Its current forecast, but just after that it loses connectivity with the pump for whatever reason. That high temp will remain enacted for next 30 minutes, which could turn out to be too much insulin if bg dynamics changed dramatically after the high temp was set. This has never happened to me in about 1.5 years of Looping but could happen.
Sure, that’s ok, but I really prefer to let Loop make dosing decisions instead of me guessing (can’t believe I am saying this, I used to think a machine would never be better than me in dosing insulin ). In fact, there is an experimental version of Loop that calculates such super-bolus-style corrections, but I am not sure if that’s ever going to be officially released.
Same here. I am not that good at even carb counting let alone protein or fat. I do not measure or count anything - just enter carbs roughly based on past experience or what Loop told me for similar meals in the past. I am not really low-carbing either, yet there is no question in my mind that protein+fat effects are real and that I can do so much better if I enter some carb equivalents with long absorption times for protein+fat. This turns out to be much easier that it sounds. For example, for the stuff and amounts I typically like to eat, a good lunch or dinner is roughly 100g of “carbs” with 4-5h absorption time (cheese, fish or poultry) or 5-6h (beef or pork). I think around 50-60% of that are real carbs, typically, but I do not really know.
Yeah, would be good to research this some more. As mentioned above I see very large differences between carb-only and same carb+protein+fat meals, so I tend to ascribe almost all bg mysteries to protein+fat. I’m probably wrong. Then there is also YDMV.
Oh, I see. Wonder why no one brought that up as a feature request yet. You may just file a Loop issue, someone may pick it up to implement.
Yes! Let Loop do the dosing - just give it good inputs to work with.
Yes, there is value in splitting entries, especially if absorption times are substantially different. Again, the better the inputs are the better the responses will be. As a side note, I’ve customized the default absorption times to 1.5, 2.5 and 4 hours. You may look into that once you gain more feedback from Loop about how you are actually absorbing food.
Here is an annotated lunch example. Had a busy day at work yesterday, had to meet with some visitors and take them for a late work lunch in a local cafeteria. In other words, huge uncertainties in timing, food, and no time to focus on any manual surfing. I made a total of 3 manual actions with Loop (yellow arrows), all three being just meal entries, and did absolutely nothing else D-related - did not even glance at my bg. This has become fairly routine for me.
I’d say you are just moving the guessing. Rather than guessing insulin dose and adjusting based on outcome, you are guessing the carb parameters (amount and duration) and adjusting them based on outcome. But I value the guidance from your experience that guessing the carb parameters works better, and this is the approach I will take for now.
This does not concern me because too much insulin is a routine event when surfing. In case of too much insulin the CGM will alert me (if I didn’t already notice) and I’ll take some glucose.
But your safety concern scenario does suggest a way to set a bold max basal rate with quantified risk. Suppose I’m willing to take a maximum of 10 glucose tabs in case of dosing error. That’s 40 g carb, so I calculate my normal bolus for 40 g carb: that amount of insulin is the largest basal rate per hour that I should be willing to accept. (Actually I could tolerate twice that amount if I’m correctly inferring that LOOP sets temp basals for at most 30 minutes.) I may prefer to use a smaller amount, but this estimation may serve as a reasonable upper bound, and may be a more principled way to determine a limit than the rule of thumb “2x to 3x the largest rate in the current basal schedule.”
Many thanks for all your explanations. They are helping me.
You could say that. But, given that system is dosing insulin up to 288 times a day (plus a few boluses), and given that insulin absorption tends to be more predictable than food absorption, I think it is fundamentally better to have insulin dosing (together with many other aspects) delegated to the algorithm.
That is correct. This is a pump limitation, not a design choice in Loop.
First, I like LOOP and would be very unhappy to be without it. The reason is that it requires much less effort than surfing to get about the same result.
Here’s 10 days of surfing, starting on day 2 of the sensor:
I’m still learning how to work with LOOP: when to let it do its work at its own rate in the way it thinks is best, and when to intervene to force a change. I’m perceiving some similarity to my experience when starting to use CGM, in that I am learning when to believe what it tells me, and when I should disregard what it thinks. Now in the case of LOOP, the algorithm is deterministic, so LOOP’s predictions of the future are a direct consequence of whatever I typed in when I entered carb amount and absorption time. So if LOOP is mispredicting the future path of my BG, that’s because I gave it bad data. On the other hand, I will rarely be able to say exactly how much carb I ate and exactly how long it will take to be digested. So what to do? One good tip from dm61 is to watch for differences between the predicted and observed values in the glucose change graph that is accessed by tapping through the active carbohydrates graph. But I am finding that it is still quite valuable to use my surfing experience to recognize accellerations in the CGM graph that suggest that LOOP’s graphical prediction of the future BG is not to be trusted, so I need to intervene. Sometimes the intervention takes the form of adjusting the carb history to change the amount of carbs or their duration. Sometimes it takes the form of entering “phantom carbs” that I will not actually eat but LOOP will give insulin as if I did. And sometimes I simply enter an extra bolus and let LOOP set a zero basal as if I were doing a superbolus.
The only issue I’ve had so far with looping is with the communication from LOOP on the phone via RileyLink to the pump. For instance, it happens once or twice a day that I enter a bolus, the LOOP algorithm tries to start the bolus, but then chimes an alert that the bolus failed and it is safe to retry. (Usually the second or third try makes it work.) When I’m having this problem, typically I now go into LOOP > Settings > RileyLink > Send button press. When it shows “success” that means the pump is listening properly and a bolus will now work. If I don’t get the “success” response, the second step is in LOOP > Settings > RileyLink > Commands and tap on the first line which shows something like 916.70 MHz. This will cause RileyLink to tune its radio for pump interaction, and that tends to restore the communication.
But three times in the past week, these recovery techniques have failed. I’ll wake up to an alarm from LOOP on the phone, saying that LOOP is not running. I tell it to send a button press and get something like CommandRileyLinkKit.PumpComsError.rileyLinkTimeout. And I tell it to tune the radio and get something like rfCommsFailure(“No pump responses during scan”). The only fix I have found for this is to power cycle the RileyLink device. That is a nuisance because it requires a small tool to reach the tiny recessed power switch. I’m using what I believe is the current firmware for the RileyLink (that I ordered 12/29/17) and I’m starting to wonder if maybe there is some hardware issue. Anyway I just ordered a back-up RileyLink in case mine is dying, because I really don’t want to do without LOOP. But I also really don’t like it when LOOP falls over while I’m asleep, and wish it had some way to auto recover (i.e., LOOP on the phone to instruct the RileyLink device to reboot itself in case of pump communication failure.)
This is not an indication of comm problems, and there is no need to do any troubleshooting steps - just press on the alert message and give bolus another try - it should succeed shortly. The alert shows up when a bolus command is issued at the time when Loop is reading pump history, typically when you see “4 min ago” under the green Loop icon.
These cases do require some troubleshooting. There are three types of comm problems: 1. RL to pump radio, 2. iPhone to RL bluetooth, and 3. Loop not receiving bg data even though Dex app seems to be working just fine. Here are some hints on how to deal with each one of these:
RL to pump: in the arrangement you prefer during day or during night, tap on “Tune Radio Frequency” RL command, and look at the results: the negative numbers shown on the right are RSSI (received signal strength indication) - an indication of how strong the RL-to-pump signal is. For robust comm you want that number to be at least -80, -70 or higher is better. If you are getting less than -80, try to position RL closer to the pump. Once this is checked, there should be very few RL-to-pump comm issues, and if they do show up they are intermittent and require no troubleshooting.
iPhone-to-RL bluetooth: fist check the Signal Strength on the RL screen: this is RSSI for iPhone-to-RL bluetooth. The number may vary every few seconds, but should generally be higher than -100. If it is below -100, try moving iPhone closer to RL. Unfortunately, in spite of good signal strength, there are cases when bluetooth comm gets stuck (“rileyLinkTimeout” typically indicates such problem). The first troubleshooting step is to turn bluetooth on and off in iPhone settings. Then check if RL is Connected, and check if Send Button Press works. If bluetooth reset does not help, try restarting the Loop app. If that does not help, then you probably need to reboot Rileylink using the on/off switch. To me this happens rarely, maybe once a month or so. Some people are reporting that rebooting iPhone and running only Loop and Dex overnight also helps. I’d also check if removing any other bluetooth devices from iPhone may help.
Missing bg data: some people are reporting cases when Loop seems to be unable to fetch bg values while Dex app seems to be working just fine. I do not have any such issues, but I’ve seen people report problems of this type. The causes behind this problem are not understood at this time. Workarounds reported by people include: (a) rebooting iPhone and running only Loop and Dex before going to sleep, (b) pointing Loop to a non-existent CGM, e.g. using G5 but switching Loop to G4, which forces Loop to fetch bg from Dex server instead of locally. Not so great workaround, because then Loop becomes dependent on internet connection, but apparently this works for some people, or (c) using Spike, a DIY alternative for Dex app, which has been reported to work more reliably.
That’s highly unlikely (unless there is some physical damage to RL)
By the way, I don’t have a command labeled “Tune Radio Frequency,” instead in the RL page the first line in the COMMANDS section currently is “916.75 MHz Mar 24, 2018 at 12:1… >” but if I tap this it does tune the RL pump radio. I’ll have to look at the time of a failure to see the numbers then, but the process of looking will re-tune the radio before displaying any signal strength, so I may not get a clear diagnosis there. Is there some log that will show me the RL signal strength at the time of a failure? At present I’ve got -58 on the selected frequency, which is nice and strong, and I don’t think I’ve ever seen below -72 on the best frequency. My bluetooth signal strength typically is around -50 to -70 which should be fine; again I’ll have to look at the time of a failure (but picking up the phone to unlock it would change the number, wouldn’t it, or is there some hysteresis in the phone display of this value that will enable me to see what it was?)
I haven’t experienced an issue with missing bg data, but I routinely close the applications other than LOOP and Dex so maybe that’s the reason. The LOOP and Dex apps seem to run for days, although the eventual sign that LOOP is starting to break is that it becomes unable to switch from portrait to landscape mode. Restarting the app doesn’t fix this, but a phone reboot does.
That’s the same command. If tuning has been performed recently, it shows the selected frequency. After some time, it goes back to just Tune Radio Frequency.
No, I do not think there is at the moment. In past Loop versions more extensive reports used to be logged in mLab (see under Services in Settings). Right now, I can only see a record an error occurred, but there is no RSSI or even date associate with the error, so mLab logging is not particularly useful. I’ve setup Amplitude logging (also under Service), which lets me see frequency and timing of errors (but not the cause). Somewhat useful to occasionally take a look at.
Picking up the phone would almost instantaneously change bluetooth signal strength, so that’s not particularly useful. Your signals seem to be fine. The problems you are seeing are likely related to iPhone-to-RL bluetooth comm getting stuck for some reason. You may try softer troubleshooting (restart BT, restart Loop) before resorting to RL power on/off step.
Restarting LOOP has never solved it for me. I’ll try restarting BT next time. Or, equally likely, all this discussion has scared off the gremlins and the issue will never recur.
Again last night, LOOP became unable to communicate with the pump. Toggling blutooth off and back on in settings didn’t fix it (by which I mean that subsequent “send button press” and “tune radio” commands errored out despite the RileyLink and phone within 15" of the pump with the no other bluetooth devices in the area and the WiFi router 55’ and 2 rooms away.) Similarly, rebooting the phone didn’t fix the issue. Fortunately, power cycling the RileyLink restored correct operation.
Bah, seems the gremlins were not impressed by the discussion. The need to reboot RL so often is definitely not the norm. Maybe there is indeed something wrong with your RL hardware. Is there any correlation between the charge state of RL and the loss of comm events? Does this always happen when RL is plugged in? Or, many hours after it’s been charged up? Is anything getting hot on RL? Which RL box are you using? I’d consider taking it out of the box overnight to make it easier to check status of the RL lights, check for any temperature rise, or just scare the gremlins away.
Usually (maybe always) it does happen at night when the RL and phone are both charging on the nightstand within about 3’ of the pump. Last night it probably was 60 to 90 minutes in, so the devices likely were in a middle-high state of charge. I haven’t noticed any significant warmth to the RL when I pick it up for the reboot. (Ambient is around 60 F.)
Now wait a minute. The phone is on a Qi charger within 12" of the RL. Could that somehow induce a delayed RL failure that is completely resolved by a reboot? (I.e., after the reboot it seems to run through the rest of the night without further issue.) That does suggest a simple experiment: I’ll switch to hard-wired charging of the phone to see if that solves the issue. Thanks for the helpful discussion; we’ll see how this goes. If this doesn’t solve it, we’ll see what happens with the backup RL I ordered (currently still on backorder.)
It isn’t simply an issue caused by interference from the Qi charger: this morning I experienced the same issue while standing in the kitchen, with the RL and phone in my shirt pocket and the pump on my belt within 8". And again, rebooting the RL fixed the problem.
). In fact, there is an experimental version of Loop that calculates such super-bolus-style corrections, but I am not sure if that’s ever going to be officially released.
