I started testing unannounced meals in Android APS on Saturday 30 July 2022. I am a bit of a control freak and really couldn’t believe that a system could manage my diabetes better than I could. I had more information available to me to make more informative decisions “I would tell myself”. But I seem to be wrong, well at least partly. I am using a branch of AAPS that delivers insulin early, but I found that managing protein and fat was more problematic than carbs seemed to be. Stubborn high blood sugar that seemed to take a few hours to correct. So I decided to do a little testing with automatons to try and improve those numbers.
Boost UAM stats (Time in range 3.9-7.8 mmol/l)
Boost UAM stats (Time in range 3.9-10 mmol/l)
Announcing carbs and pre-bolusing
Eerm…what? How is this possible? It seems with accurate carb counting I still cant account for digestion times as well as AAPS can.
Automations
I use two (2) automations to try and manage my readings more closely. These automations are over and above the Boost logic that provides insulin earlier than the standard code.
The first automation simply sets a lower target when my reading is above 7.8 mmol/l AND not dropping. This allows AAPS to bring down my readings more quickly.
The second is to try and compensate for protein and fat in the low carb meals I eat. This automation will activate if
my reading is above 6.5 mmol/l AND
between meal times AND
my reading isn’t dropping AND
there is active resistance detected (not sure if this even matters)
My hypothesis is that the system can detect the resistance post the meal window but I need to test this assertion further.
I decided to purchase the Omnipod Dash trial pack of 10 pods for $30 AUD to see what all the hype was about. It turns out the hype is warranted, as this is an incredible little system. I’m very excited to use the device under a multitude of conditions and I hope that my experience can be informative. My main testing criteria will be connectivity, recovery in the unlikely event a Pod is damaged, robustness during various activity, water resistance and general day-to-day activity including time with my two year old daughter.
Benefits
The pump system operates much the same as any other pump system available, with the main difference being that the pump and cannula are all part of the same physical unit. This is a huge advantage for sports, but can be noticeable while changing clothes, going to the toilet or during sexy time. The unit is so small its presence is barely noticeable.
Omnipod Dash.
Sugar Management stats (So far)
I am very pleased (and surprised to be honest) that I am using 28% less insulin on the Pods with improved (+9.3%) blood sugar control (Time in Range 3.9-7.8 mmol/l). I noticed far fewer super micro boluses (SMBs) being administered than before, but maybe that is due to me letting AAPS do more of the work in managing my sugars through unannounced meals (UAM).
Management Stats from Nightscout for the duration of the experiment so far. TIR = 3.9-7.8 mmol/l
Total daily dose (TDD) and carbs average for the duration of the experiment.
Note: I am not adding in all the carbs I am eating as I am using announced meals in AAPS.
The Ambulatory Glucose Profile (AGP) enables retrospective analysis of dense data, trends and patterns for the duration of the experiment. Management Stats from Nightscout for the week prior to the experiment so far. TIR = 3.9-7.8 mmol/l
Total daily dose (TDD) and carbs average for the week prior to the experiment.
The Ambulatory Glucose Profile (AGP) enables retrospective analysis of dense data, trends and patterns for the week prior to the experiment. Management Stats from Nightscout for the duration of the experiment so far. TIR = 3.9-10 mmol/l
Screenshot from AAPS highlighting the SMB’s.
Android APS Setup
Setup of the Pod system in Android APS (AAPS) Boost Master 3.6.4 was surprisingly easy and intuitive. I just followed the Prompts after going to the configuration builder and selecting Dash as the pump.Its a very similar process for Eros pods, with the added requirement to pair the OrangeLink / RileyLink device.
I had an error starting the pod, but after hitting retry multiple times the pod activated and all was working as expected
Exercise
Exercise has been a lot more enjoyable without all the wires and having to worry about pump placement or damage. If I mountain bike and fall off (which happens every now and again) I lose one pod, and not an entire pump. Having more pocket space and less to carry is an added benefit.
Whats next?
I plan to test the pod while resistance training, mountain biking, running and the most intense sport I play, wrangling my two year old. If she cant destroy them, they are indestructible 🙂
An interesting set of results from my time with Boost. I cant wait to return to AIMI with what I have learned.
I was eating slightly less carbs (118g vs. 136g) than when I was using AIMI, but I would expect that if your profile is setup correctly that the amount of carbs shouldn’t have much of an impact on performance metrics. I was running into a few hypos so I lowered the algorithms insulin required percentage (70% vs. 100%) which resulted in a whopping 1.6% decrease (57 minutes vs. (288 minutes / 4.8 hours)) of time spent in a hypoglycaemic state while using Boost.
My standard deviation was slightly lower (1.3 vs. 1.4) signifying less fluctuations between readings while my time in a hyperglycaemic state went up 0.6% (25.2 hours vs. 26.6 hours)).
I did have to turn off “enable boost percentage scale” as this was providing too much insulin, but more experimenting could remedy this.
Another interesting observation was that my ratio between total daily dose (TDD) and total carbs eaten went down from 4.2 to 4.01 (grams of carbs per unit of insulin) as my average blood sugar lowered.
My exercise seems to have stayed pretty consistent during testing (as per the table below) which leads me to believe the reduced insulin need may be related to requiring less insulin when blood sugar is euglycemic. Its going to be a little more difficult to track that for the next few weeks as I am preparing to ramp up training for the Southern Cross 10km in July. The training has however provided an opportunity to fine tune my running routine as outlined here in my post about predicting blood sugars while running.
I cant wait to do some further testing with AIMI, Boost and Eating now.
Table of performance metrics from when I was MDI to the latest build of Boost.
Boost Stats (70% insulin required)
AIMI Stats (100% insulin required)
Boost TIR stats 3.9 – 10mmol/l
Exercise table (stats derived from Strava and Python scripts)
The below is a list of foods I commonly eat that I decided to analyse. I have listed some lower-carb high protein meals, snacks and a few higher-carb meals. These are all more regular meals so I have had the opportunity to adjust my insulin strategy to better cover the various aspects of the meal.
Part of my strategy is to adjust the insulin timing (pre-bolus), starting BG (using temp targets or exercise) and the amounts of insulin used. The amount of insulin used needs to be adjusted based on the macronutrient composition, the amount of fibre and the amount of sugar alcohol in your meal. Sugar alcohols are often not listed on food labels in Australis and those foods should be avoided. Read my post on injecting for protein and fat for a better understanding of how your insulin dose will need to be adjusted to compensate for protein and fat.
To analyse a meal I use three (3) values, standard deviation, time in range (TIR) and Coefficient of the variation. These three (3) values will assist you in determining how good or bad a meal was for you in terms of blood sugar impact (BGI). You can also use the difference between the 3 hour and 5 hour standard deviations to ascertain if you are covering gluconeogenesis correctly.
Time in Range (TIR): For TIR we are looking for a high percentage of your readings within a normal (I use 3.9-7.8 mmol/l ) range.
Standard Deviation: For standard deviation I look for values under 1 as a meal that has little to no blood glucose impact (BGI).
Coefficient of the variation (CV): Is the standard deviation divided by the average glucose. Its a measure that helps normalise the results by reducing the influence on average glucose. Most studies indicate that anything under 33% is good. The lower the number the better the outcome.
On the 04 February 2022 I decided to switch from FreeAPS (Loop) over to AAPS. At that point I had been successfully looping for 6 months with FreeAPS (Loop) but I wanted to get some experience with the oref1 algorithm in the hopes of fine-tuning my diabetes management during sports and to try out unannounced meals.
I was conflicted in the beginning as I was seeing results consistent with my goals on FreeAPS (Loop), but It was something I wanted to try. I am glad that I did.
The first few weeks on AAPS can be painful as you learn the system and go through the objectives. I had completed as many as I could using a virtual pump so It wasn’t long before I was able to close the loop again this time using AAPS. I expect my numbers will improve once again when automations are available to me.
Setup and Configuration:
For the first few days I was still using the Dexcom IOS app as my collector app sending my BG readings to the King King Mini 2 (KKM2) to be processed by AAPS, this worked well as I was always in areas with reception. I did this because I wanted to be able to switch back to Free-APS quickly if I decided that AAPS wasn’t working for me. The first sensor on the KKM2 I paired with xDrip+. I loved xDrip as it provided heaps of additional data, but I had issues with delayed and missed readings. I have now switched to the the Dexcom BYOD app and this seems to be proving readings more consistently. I am using an Anubis transmitter but I am unable to validate battery level with the Anubis Tool on the KKM2.
Stats:
Last 22 days on Loop (FreeAPS)
…
First 21 days on AAPS
Likes:
Improved Time-in-range (TIR) (+7.7 %), average blood glucose (-0.2 mmol/l), GVI, PGS and A1C even though AAPS was new to me and I was still figuring a few things out. I achieved this exercising less than I usually do due to weather.
Better control with less work.
More flexibility – The ability to scale and tailor your meal or correction dose is awesome (include trend, IOB, COB, correction percentage and your blood glucose readings in the the calculation for increased control and precision).
Fewer (0.2% less) low events.
Quicker to respond to bring high blood sugars down.
Unannounced meal management (UAM) using the Oref1 algorithm (not tested).
No Apple Developer licence fee (I paid less for my KKM2 than I was paying for my annual developer license).
Easier to setup and deploy to the KKM2 than the Free-APS (Loop) app.
Remote (SMS) bolus.
The ability to super bolus (include basal for a specific period with a bolus).
Super micro bolus’ (SMB) are more effective at dealing with gluconeogenesis from high protein meals.
Autosens has been useful by identifying periods of insulin resistance or sensitivity and adjusting basal accordingly.
Dislikes:
My pump (Medtronic 522) is using batteries more frequently (60% quicker on AAPS).
Bluetooth (BT) drop-outs more frequently than loop. In the last 21 days I have had 6 ‘Pump unreachable’ errors and 3 ‘Missed BG readings’. This resulted in elevated blood glucose during the evening.
The KKM2 battery drains faster when I am around multiple other Bluetooth enabled devices than what the iPhone did.
The connection between the Phone (King Kong Mini 2) to the Orangelink and pump seems a little less stable than with the with the iPhone and loop, but I suppose you can expect a far inferior Bluetooth chip on a phone that costs a 10th of the price. This is easily remedied by restarting the Orangelink , turning BT on and off or in some cases, usually with the the pump unreachable error, I had to restart my phone.
I really liked the ICE (Insulin Counteraction effect) data in Loop. It was useful to see where I went wrong with my previous bolus and AAPS doesn’t have this data readily available like Loop did. If you were using UAM it would be unnecessary.
Dick The Diabetic's APS Adventures 