A post about how #languagematters:

Recently I had an situation in where a comment was raised about how I shouldn’t be having sugary things because I have Diabetes.

These rather broad, sweeping comments have been usual since my diagnosis, however the way they can be interpreted can differ allot from person to person.

T1D is one of those auto-immune diseases that if well controlled (and for the most part automated 😉) will not have any negative health impact at all.

Type 1 Diabetes (T1D) is not the same as Type 2 Diabetes (T2D), infact they should be seen as completely different conditions despite having similar names.

T1D is when the pancreas no longer produces insulin to regulate blood glucose and needs an external source of insulin instead to do the same thing. T1D is an autoimmune condition that cannot be reversed or prevented.

T2D is when the pancreas can not produce enough insulin to keep blood glucose in control. This condition can often be reversed by the reduction of high sugar/calorie foods. However this is not always the case. Genetics can have a big role to play in causation and treatment of T2D.

So regardless of the Type of Diabetes that someone may have, it is not always safe to assume that sugary food is causation of someone with either type of Diabetes.

Be kind and dont judge!

Recently while the new 2.7 beta has been running, we have seen some reports stating that Autosens value has not moved much since using it.

I thought I would discuss this in a little greater detail and the background why people are experiencing these changes.

Autosens in AAPS versions pre 2.6

The Autosens implementation in these versions is out of scope and is not in-line with the reference design.

In these versions you will see 2 sensitivity options in the config builder. One for 8 hours and one for 24 hours. Only the 8 hour option (called oref1 sensitivity) is able to calculate or distinguish between a positive deviation from UAM.

The reference design was not designed this way.

So changes were needed to bring AAPS into line with the reference design.

Autosens in AAPS versions 2.7 beta+

The 8 hour option was removed, and in place implemented the reference design to use 24 hours of sensitivity, if sensitivity was detected over 8 hours it used the sensitivity from that period instead.

This approach is more conservative than the the Autosens implementation in pre 2.6 versions. Reason: Safety, The reference design has been built this way for a reason.

Possible outcomes from upgrading

It is normal that you may experience less positive Autosens changes (when resistant) and it may take a little longer for Autosens to respond to resistance.

In my experience since using the Autosens upgrade, it responds just like my previous OpenAPS rig did, so this change was normal and expected.

For users who have never ran OpenAPS before, this will come as a change.

Digging a bit deeper into the deviations

To get a little more understanding on what Autosens is seeing, look at the deviations on the main screen.

Grey Deviations - Carbs on board / Decaying
Green Deviations - Positive Deviations (Resistance)
Red Deviations - Negative Deviations (Sensitivity)
Yellow Deviations - UAM Detected

Tap and hold on the main BG and zoom out to the 24 hour period.

How much of the graph is Grey or yellow? If a good portion is filled with grey or yellow it means Autosens is running on very little data to calculate its deviations. Only Red and Green Deviations are used. Hence why your getting a value that doesn’t move much.

Fixing a seemly fixed Autosens value

This is comes down to how your using the system, but it also comes down to your settings.

Revising carb absorption, IC, ISF ratios, Basal etc may be needed to shorten these periods down so AS can get back to work more quickly.

Look a bit deeper into the 8 hour, and 24 hour autosens data.
Under the OpenAPS SMB screen, scroll down and view the sensResult.
2 ratios will be listed. One for 24 hour and the other 8 hour.
Any value above 1 will indicate resistance, less than 1 will indicate sensitivity.
The period in the bracket is the sensitivity period chosen (8 hours or 24 hours) Based on the reasons above.

Remember: the reference design in AndroidAPS lacks automatic autotune integration like on OpenAPS, this effectively feature helps adjust profile settings for you automatically in the reference design.

With this in mind and this feature not being in AAPS, regular Autotune runs should be conducted to make sure your settings are on point to make the most out of the reference design as possible.

Conclusion

Regular settings revision remains best practice for running a DIY APS system.

If you have further queries in regards to this change or have found a legit bug with the implementation of the change, I am happy to review.

Hope your enjoying the beta so far, keep the bug reports coming in!

Regards

Tim

Version 2.7 of AndroidAPS is coming along nicely with the first beta release being launched.

If you are beta testing this, thanks for your comments and feedback and most importantly bug reports (these help us allot!).

I wanted to share some algorithm and feature highlights of the upcoming version 2.7 and the changes that impact the way you will interacting with AndroidAPS. This is a very small insight into the massive development push behind this revision.

One area of we wanted to focus allot on was the algorithm powering AAPS. (oref from OpenAPS). We also wanted having more of a deeper interaction and to standardize it, so you can use more functionality of this incredibly powerful algorithm. We have now brought the “OpenAPS SMB” algorithm up to the 0.7.0 version of the reference design algorithm.

As part of this process:

Autosens

Autosens has got an overhaul, we have removed the option to have a sole 24 or 8 hours of sensitivity. Instead we have followed the reference design from OpenAPS where the sensitivity window is elastic and changes as you change.

Autosens will now pick 24 hours of sensitivity deviations or 8 hours and will choose which ever one is more sensitive.

If you are using the current oref1 sensitivity model (sole 8 hour), this means you may find on occasions autosens a little slower to respond. This is normal and expected.

Carbohydrates Required

As part of the reference design, these alerts were given out by the algorithm but not used, now they are. So now you can be notified when APS states it cannot rescue you by zero temping, therefor needing carbs.

Carbs Required notifications can be enabled locally (only shown in AAPS) or to Android.

When Carbs are required: The main screen carb icon will pulse red and it will show how many grams of carbs are required. After responding to carbs required by adding more carbs, the required amount will be removed. The carb icon will remain pulsing red until oref (the algorithm) is satisfied no more carbs are needed.
Screenshot below of it in action:

Native Android Carbs Required Notifications can be snoozed for 5,15 and 30 min.
Notifications are automatically suspended for 15 min post any treatment (Bolus or Carb Entry)

Note: Carb suggestions/notifications require the SMB algorithm to be enabled.

Dynamic Target Adjustment:

We have enabled a cool feature that you can turn on if you wish for people running the OpenAPS SMB algorithm, this is dynamic target adjustment.
When either “Sensitivity Raises Target” and or “Resistance lowers Target” is enabled, the target glucose from your profile will then start to dynamically change in relation to your sensitivity changes. This can help stop the need to set Temp Targets when experiencing insulin sensitivity or resistance.
When your target has been adjusted dynamically the Target Glucose Box will turn Green to state your target differs from your base profile.

Thats all I will cover for now, more will be coming as we advance towards a RC and Final version.

Thanks

Tim and the AAPS Dev Team

If you are using Nightscout to do remote surveillance and reporting on interstitial glucose, you may not be aware of a very cool feature.

This feature can show and monitor values which are hidden from view in a typical CGM application.

This is the RAW data which comes back from CGM (Dexcom G4,G5 and some G6 transmitters).

You can use this data while the CGM is warming up and not providing a SGV value.

But the way I often look at the raw data, is determining what is happening with my glucose values before the SGV values start to change.

Raw data changes more quickly and can fluctuate more than the SGV so it cannot always be relied upon. When the sensor is noisy is an example when to disregard raw readings. However if you have a CGM reporting “???” you can check on the raw data to see how jumpy the readings are and to give yourself a little more insight on the state of your sensor and or glucose values during that time.

Another thing raw data is good for is checking whats going on with your glucose before it changes the SGV value.

Example below: white dots indicating the raw values.
It shows that my glucose was falling quicker than what the SGV values after a pre-bolus and that means I need to commence eating sooner than thought.
The subsequent glucose rise was also more rapid than what is shown by the SGV values.

So by using raw data appropriately you can gain a little more insight and start to get a more quicker insight into your values with less “lag” as well.

By default in Nightscout, raw data is turned off, and needs enabling.

You can enable this by adding
SHOW_RAWBG=always
into your NS Config. Alternatively if you are using Heroku to host Nightscout use SHOW_RAWBG and always in the Heroku Application settings.

Preface, the following breaks from my typical blog entries from Diabetes and tech, but thought it might be good time to write about this.

New Zealand is in lock-down (at time of writing), in fact most of the world is in lockdown to contain the spread of Covid-19, this is history in the making.

Lockdown was announced on Monday the 23rd of March in NZ with a 48 hour window to migrate from a then effective stage 3 to stage 4. All gyms started to close around the country within hours of the announcement. Some gyms like the ones that my flatmates and myself frequent started to offer loaning out of equipment.

This certainly helped cushioned the blow for many people who would classify the gym “a second home” but did not have equipment at home to do workouts.
If you are gym owner/operator and you offered this to your members, you are to be commended!

My flatmates and I then proceeded to pickup equipment that was on loan, and placed it in the living room floor, now what? Then you might have been like me, I don’t have space or location for it to live!
Time ticked, the living room floor turned into a maze of where to put your feet to walk, but my flatmates and I were kind of trying to ignore this obvious maze we had given ourselves.

The very next day waking up and seeing the equipment all on the floor, the issue really needed to be dealt with and a space needed to be made.

Up until this moment I was dreading thinking about working out at home as the things I had become accustomed to where no longer there. I would suddenly need to adjust to the change.

I started to look around the property and house, saw an area outside under the eves of a covered deck, that looked good but was full of stuff. We then committed to the idea that we all needed to workout over the 4 week period, allot of cleaning and sweeping and tidying up the area ensued.

The area then was ready for use! Once we saw the tidied up area, we were instantly ready and motivated to get into a workout.

Strange isn’t it, that feeling of reluctance and dread turned on its head by simply removing a blocker.

Realising we had an “Gym” so to speak, I then remembered feeling this way before. I had this exact feeling when I switched gyms just over a year ago. Just as the change happened then, it’s happening again. Whether I liked it or not this would be my gym for at least for the next 4 weeks.

This meant treating the area as any one of the gyms I frequent, a place to sweat it out, scrape shins and collapse after a good WOD.

That means getting out of the usual lazy day boxer and t-shirt combo and into some apparel more fitting for the “gym”.

When doing this without realising I was giving myself the typical non-verbal cues and prepping myself and headspace for working out, exactly as I would feel if I would rock up to my usual gyms.

The walk to the “gym” provided the same cues as driving to my normal gym. Knowing that work needed to be done, and this was the place to do it really helped.

First workouts were done in the “gym” on that day and felt exactly the same if not better than my usual gym sessions. I have less than 1/5 of the equipment that a gym provides, yet I got a sesh done with the same if not more intensity.
Even if I had less or no equipment on hand, it wouldn’t stop me from accomplishing a thorough and strenuous workout, with similar muscle groups from being targeted.

This leads me to this point, its all about headspace. Make room in your place,but most importantly your head. Identify blockers or things are dragging you away from doing your best both physically and mentally, especially during this time.

A lack of equipment will not deter an athlete to do his/her best during difficult times with the correct mindspace.

Lockdown and the ramifications of it will no doubt be a challenge, but we have the opportunity to overcome this hurdle and fight Covid-19 in more ways than one.

Keep strong everyone.

Tim

Some abbreviations used:

WOD = Workout of the Day

BOX = Crossfit Gym

Automation is relatively recent addition to AndroidAPS.
It came to fruition in AndroidAPS v2.5 and since then we have seen some great examples on how it can be used. Gaining further control and guidance the APS system in certain situations.

If you are considering to use it, be aware of the following caveats:

• Profile switching renders Autosens useless for a min of 6 hours.

• Profile switching will not reset the profile back to your base profile (you have to make another rule to set this back or do it manually).

• Increased risk of Hypoglycemia if profile switch does not expire or reset back to base profile.

Some Notes to how Autosens works:

• Autosens is a algorithm which looks at Blood Glucose Deviations (Positive/Negative/Neutral. It will try and figure out how sensitive/resistant you are based on these deviations.

• The oref implementation in OpenAPS runs off a combination of 24 and 8 hours worth of data. It uses either one which is more sensitive.

• AndroidAPS only runs off 8 (to enable UAM) or 24 hour as a user option.

• Changing a cannula or changing a profile will reset Autosens ratio back to 0%.

• Autosens adjusts your basal and ISF for you (ie: mimicking what a Profile shift does).

• if continuously eating carbs over an extended period, autosens will be less effective during that period. (Carbs are excluded from BG delta calculations)

So some basic guidelines:

1) Make sure Profile switches are made sparingly and preferably at a last resort. Profile switches should have a reset condition so the profile can return to normal again to minimize risk of hypoglycemia.

2) Try not make conditions too easy (for example: if bg > 80 mgdl and bg < 180mgdl) ) doubly important if the action is a profile switch*

3) Try and use Temp Targets instead of Profile Switches. Temp Targets do not reset Autosens back to 0.

Moving into developing AndroidAPS versions 2.6 to 2.7 we will bring the Autosens to more closely follow the Openaps implementation.

Watch this space and enjoy automation!

To those who have experienced looping on a smartphone, the experience is fantastic is it not? Carrying around a device that can also double as your artificial pancreas, makes so much sense.

We have started seeing an overwhelming push from smartphone manufacturers to make sure that your battery lasts as long as long as it can.

iOS and Android versions from 8+ will now proactively sleep apps that sip battery and have background processes running.

This is great for most people, as they get more battery life and who doesn’t want that eh? But what about the people who use a smartphone as medical device? What about us “Loopers”?

This is where it can get complex, and this is where most looping setups will fail, it all comes down to CGM data collection.

In particular CGM Bluetooth devices that spend most of the time ‘sleeping’.

On the Dexcom CGM system, the transmitter stays awake for less than 15 seconds every 5 minutes. Then during that window your phone will try to connect to your transmitter, open the connection up, provide a reading and then close the connection.

These small windows of opportunity to get CGM data are consistent and there is no way to make these windows bigger without sacrificing battery life on the transmitter itself. Any small hiccup in the chain can stop a cellphone from getting a CGM reading, so developers will always try and make sure the code executes to connect and get the reading done in time. Not all phones are equal and setting on each phone are not equal either.

The most common setting which prevents CGM collection is battery saving, it does this by a combination of factors, sleeping sections of hardware on the phone that are not used (ie: Bluetooth), and sleeping processes that run in the background. In some cases when the hardware has been slept by the above manner it can take setting a fake alarm to wake the hardware up in a timely manner!

How do make sure battery saving is turned off?

Android:

Settings > Battery > Standby intelligent power saving = off

Settings > Battery > Adaptive Battery = off

Some Android Phones will have some other battery saving settings, turn those off.

In AndroidAPS and xDrip, the apps are whitelisted from stock Android Battery Saving, but this will not stop other battery saving applications from sleeping them.

Ensure that all other battery saving tech is turned off, esp if running a Huawei/Oppo/Honor/Xiaomi phone.

iPhone

iOS with the Dexcom App and Loop should run fine on a tested/supported version of iOS. Do not enable Low-Power Mode or turn off Bluetooth while using your phone.

So what phones are best to collect CGM data on?

Android:

Any Android One handset (or Android at stock); Manfucturers such as Nokia, Motorola’s One devision and Google’s Pixel.

iPhone:

Any iPhone should be suitable for CGM collection.

If you loop with a smartphone, you should treat your phone as a medical device.

What do I mean by that? Be cautious before proceeding with anything that is making changes to your phone, installing apps, software updates etc. The last thing you want is a broken loop!

Operating system updates can break your loop so, check on social media, github issues etc for postings about new updates etc. Also keep your CGM/APS apps up to date.

Hope this helps.