I have terminal curiosity. I am interested in the technology of looping using Dash pumps.
Dash is designed to connect to a PDM. 1st question, how is Dash connected to a smart phone? 2nd - Android or iPhone or only Android? 3rd - does the software in the phone use CGM data to control pump insulin delivery?
I’m not interested in using Dash/loop systems just want a clearer understanding of the mechanics of it. I can’t help it. I always want to know how things work that grab my attention.
All omnipods are basically the same design. Eros uses an old RF protocol. Dash and 5 use bluetooth. Dash is factory paired only to a PDM (reskinned Android phone). 5 is factory paired to either a PDM, Android or Iphone (as of a few days ago). Dash can be repaired to DIY Android and Iphone applications that can also loop.
One of the main reasons I’m on Dash instead of 5 is the availaability of an Iphone app. So maybe I’ll rethink things in the coming months.
@CarlosLuis Presumably you’re referring to the Loop app vice “looping” in general (the terms get mis-used and mis-understood). If you’re looking more for general looping origins, check out: OpenAPS - Wikipedia, Dana Lewis | DIYPS.org, and The diabetes patients who hacked a pancreas - Experience Magazine. If you’re looking specifically for the Loop app itself, a history is available at: The History of Loop and LoopKit. Reflecting on the past in celebration… | by Nate Racklyeft | Medium. In reality, all the various DIY programs owe gratitude to broad community of T1 people and parents of T1 children in the DIY community around the world, but I think you’ll find most stories trace back to John Costick.
Both Android (OpenAPS/ AAPS) and iPhone (Loop, Trio, iAPS) are supported by several different developers (individuals and groups). In most, if not all, of the apps (Loop is one), the phone app “listen’s” for the CGM bluetooth signal communicating the BG level (timing depends on the CGM in use), then uses that and previous levels in an algorithm on the phone (and other settings the person sets in the app), an the app issues instructions via bluetooth to the pump. The Loop app used to use a Riley Link, Orange Link, or similar to send the Omnipod Eros pods instructions on the correct signal frequency, but with the advent of the Dash pods, it uses a bluetooth signal, making the Riley Link un-necessary. All of this is possible because the Omnipod’s codes and security measures were deciphered by the developers several years ago including Pete Schwamb, Sergei Skorobogatov, Joe Moran, interpreted and translated from the CGM to the app and then to the pod. Of course, various manufacturers use different codes and security mechanisms to protect users from un-authorized people being able to control the pump and dose the user. Additionally, current CGM and pump users report some venues (usually large gatherings with heavy bluetooth use) the apps used for both commercial and DIY apps have difficulty receiving BG levels or sending pump instructions.
I find the back story of these DIY systems fascinating. Deciphering the codes/security is very much a puzzle I wish I had more aptitude at working through. It continues as the system’s develop, I’m not sure if it’s a white hat or black hat issue. The FDA got involved by asking both the public and manufacturer’s for input on the security of medical devices two years ago; the results aren’t clear s yet (that I know of), but manufacturers are obviously not keen to share their IP or processes with the DIY community, at least not openly. Hope this answers your question.
@TomH Thanks your words and the links were so interesting. Even though I hate coding I have a lot of respect for those who do. I think the developers of open source loop did their hard work out of the goodness of their hearts.
Paul showing that string of hexadecimal code brought back memories. The telco switches I worked with used digital (0&1) octal (base 8) and hexadecimal (base 16). I can’t do it anymore but I could convert them to each other and to base 10 in my head.
I know I’m not posting in the right chain, but the heading works for what I’m asking…. For those of you who are looping and specifically for those of you who like to use closed loop, do you enter carbs for treating lows? Or do you treat and let your blood sugar rise back into normal range w/o accounting for the carbs that get you there? If I enter the carbs, loop will often want me to give insulin and I “know” that I won’t need it… this probably means that some ratio of mine is off in the system, or that my lows are tougher to treat than how the system reads my numbers, if that makes any sense? Anyway, what do you all do for lows in loop? Thanks!
It depends on how severe the low was and how many carbs I ingested! I usually do not enter carbs at all. For times when I ingest a lot of carbs (for me, like 15g+), and I see I am rising fast into in-range, I may timidly enter a few carbs, watch the GGM, and decide if I need to enter more carbs (with 0U insulin). I hesitate to enter too many carbs all at once because I don’t want to go on a rollercoaster (via Loop’s autobolus mechanism). There are times when I really do need lots of carbs with 0U insulin (and 0U autobolus), or I will go low again, but these lows are pretty rare for me. So it really depends. I watch the CGM pretty closely to decide.
Just enter 0U in the bolus when you are entering carbs for a low. As long as Loop’s forecast is within your target range, it won’t autobolus for you, so you should be fine. If you are low though (below your target), Loop should not be forecasting you need insulin. If it is recommending a bolus (which you really do not need), you could initiate an Override to temporarily reduce the basal (eg., down to 70% of your scheduled basal). This will also reduce your CR and ISF (raise you insulin sensitivity) by 30% for the duration of your Override. Hence, during the Override, Loop will estimate a smaller or 0 bolus.
For a correction with fast carbs, I first set a temp basal of 0 for 1 hour, then enter the carbs into Loop and eat them. Loop sees the quick rise in BG and incorrectly predicts that I will go way too high, but the temp basal prevents Loop from giving any insulin. After 30-45 minutes the BG stabilizes hopefully near the level I planned, so by the time the temp basal expires Loop is no longer prone to over-reacting.
Loop is looking at everything - What is my current BG, how much insulin do I have on board, what direction is my BG going, how many carbs are on board, etc.
And remember that you have a suspend number for low BG. Anything below this number and it won’t give insulin. No matter what, if your BG is below the suspend threshold, it is not going to give you insulin!! It does not matter how many carbs you enter, you won’t get insulin until you are above the suspend number. Safety net!
So I think it makes sense to give it the carb information to help prevent a big spike later.
If you take carbs and don’t tell it you took the carbs, you might end up spiking later.
BTW. if you are having a problem with it giving you insulin when you are low, you need to change your suspend number!
Adding a little more critical information: my issue arises when my blood sugar starts to rise (usually with straight arrows up), but then will level out quickly within normal range. But the damage will happen when BS is still rising quickly above 90 (before leveling out in low 100s) and Loop gives insulin, which will then drop me again. Maybe I enter some of the carbs but not all of them? Enter what would keep the optics of keeping BS within range with carbs eaten – would that not prompt a bolus even with arrows heading up?
@JessicaD
Is this the order of events you are experiencing?
Is that the general scenario? Or am I missing something?
yes!
For sure, it sounds like you should NOT enter carbs, as that would only make it worse.
If you are rising too much, then you need to adjust your correction factor. The number for how much 1 unit of insulin brings you down. Adjust that number UP.
For example, instead of saying 1 unit of insulin brings you down 70 points, you could say 1 unit of insulin brings you down 80 points.
You can raise your BG target up.
For example, maybe your target is 80-100. If it sees you are going to be over 100 it thinks it needs to give you more insulin. So if you change that to 80-120, then it won’t give insulin unless it predicts you will be over 120.
I think those are the 2 things to look at adjusting.
This is helpful. I raised my correction factor by quite a lot a couple of months ago already; maybe I need to do it again. I did also increase my BG target and make it wider (it’s now 85-125 and suspend is at 80… maybe I should suspend at 85?). I have been very active this summer, which I think affects my BS a lot. I LOVE being able to be on the tennis court and my bike and walking so much, but sometimes I feel like I’m living on the edge. Lots of juice boxes. I wish there was something built into Loop where it would acknowledge that you are working out / have worked out. I know exercise mode is a thing, but Loop doesn’t take into account the many hours after you’ve worked out and are still burning up carbs.
Anyway, at the base, I think I am not going to worry about entering correction carbs for now at least. Thank you!
You can have a different preset for after you are working out too.
It would be in the same place as the exercise mode preset, but you can enter different values for post-workout, and set it for a certain length of time.
Love your curiosity! 
The Omnipod DASH actually talks to its PDM over Bluetooth, not directly to a phone. Loop setups use a bridge device (like RileyLink) so your phone can run the app, pull CGM data, and adjust insulin automatically. Super cool tech even if you’re just learning about it!
@ErinRods Perhaps I’m not understanding fully, but don’t think that’s quite correct, I’ve been using Dash pods for about 4 years along with Loop for about a year, iAPS for about 6 months, and currently Trio the rest of the time. I haven’t used my Dash PDM in ≈3.5 years, though I keep it as a back up and take with me on long travel periods. All the software AID’s mentioned work fine directly with iPhone, receiving the G6/7 CGM data and incorporating with the Dash as an AID to dose for basal and bolus insulin. The various software can use a Riley, Orange, or similar link to talk to the older pods, but don’t need them for the Dash.
Agree with @TomH .
I’ve used no external Bluetooth device since switching to the Dash PODs from the Eros PODs. It was a major reason we switched…to remove that additional device from the equation.
Both; both want those codes though in reality no one cares a damn about messing with Insulet’s codes except the White Hats; why bother, how many T1s use Dash pods and how many do you want to kill. (If it the answer is 1 I don’t care.)
ATM Insulet needs to understand that there is no financial security in obscurity. We (diabetics) desperately need standardization of these protocols so that every manufacturer can compete freely and, side effect, we get better pumps.
It’s not the traditional standardization scenario where every manufacturer of a fire alarm goes around kicking every other manufacturer in the procreative sphere; no one dies when fire alarms don’t work.
So there is mileage for Insulet (aka Omnipod) and Sequel (aka twiist); embrace the standard. Don’t try to create it, you can’t do that because you are incompetent. The OS community can; reach out and help. Or just do it.