When Autotune is discussed in public forums, there are often concerns about how it adjusts values and the tendency to move everything in one direction, consistently, rather than create variation on a day by day basis. In general, Autotune shouldn’t be doing this, and it raises questions as to what’s happening when people see this type of behaviour.
Recalling that if you’re an AndroidAPS user, regular profile switching causes issues with Autotune, and failure to record carbohydrate correctly, including for meals, can also cause issues, this post looks at what happens when carbs are recorded and Autotune is run nightly on an OpenAPS rig as per its default configuration. If further information is required about Autotune, it can be found at https://openaps.readthedocs.io/en/latest/docs/Customize-Iterate/autotune.html in the OpenAPS documentation.
If you know about Autotune, you know that it adjusts basal rates where it can calculate differences where there are no carbs on board (COB) and no unannounced meals (UAM) having an effect. Where there are COB or UAM, then the period in which this is found is adjusted by a value based on the last valid calculation pre- and post- these periods.
Taking this data, over the last two months, the basal rates that are produced from my daily use rig looks like this:
There are clearly a range of adjustments being made and there is, a circadian profile involved. Due to the number of variations, this is not a particularly clear view of the world, so taking this a step further we can look at the data differently.
This box and whisker chart shows that there is a wide variation in the range of values that Autotune is producing during the periods it has run, with the greatest variation showing in the late evening. It’s worth noting that in general, there are COB from 7.30-10.30, 12.30-16.30 and 19.00-23.00 on a daily basis, so in these periods, there is unlikely to be any specific tuning of the hour-by-hour values taking place.
If we look at the average basal rates throughout the day, it’s possible to see that Autotune hasn’t removed or really flattened out the circadian profile.
Sensitivity Factor and Carb Ratio
Autotune isn’t only adjusting basal rates. It also adjusts Carb Ratio (CR) and Sensitivity Factor (ISF). Details of these are available in the link to the OpenAPS documents provided earlier.
Whilst it is well known that Autotune doesn’t adjust for more than one ISF and CR per day, this works well enough for some of us. Again, taking the output from July and August calculated on a daily basis, we can see that this is not a one directional process.
As the chart shows, it’s possible to see that during the periods highlighted, where I was away on vacation with lower stress levels, and when I was trying out Lyumjev and seeing it not work all that effectively, Autotune has picked up the improving and worsening sensitivities and carb ratio, as it ran on a day by day basis. In fact, without it, it’s likely that during the vacation period, I’d have spent a lot of time fighting low glucose levels due to ISF and CR being too strong.
FIgure 5, looking at the 10 month data that’s available appears to show a substantial break between ISF and CR, and during January its possible to see that Autotune has calculated a much larger CR number during a perdod of low carbing. What’s also interesting to note from these two figures is that CR and ISF calculations from Autotune don’t always move in tandem.
This raises questions as to whether Autotune is correct, and if it is, what the linkage is between these two factors, as the data here suggests that it is a lot less direct than is often considered.
While we know that for some, Autotune doesn’t work particularly well, whether that’s due to the issues with multiple CR and ISF values, or due to the way that they use the particular DIY AID system that they have, when it’s used in the context of OpenAPS, on a day by day basis for adjustment, it does seem to work reasonably well in managing adjustments of all the relevant factors.
The data shown in this post simply highlights that the calculated variables in this context do not simply approach one single value or tend in a specific direction, but vary quite widely over time, as should be expected.
If Autotune users are seeing behaviours where the outcomes don’t appear to make sense, they should raise an issue in the Github repo for OpenAPS and highlight factors such as the system in use, the time period over which the analysis has been run and importantly, the quality of the data in the analysis, including factors such as whether carb capture is of good quality and frequency of profile switching or overriding. Without this, it’s extremely hard to make progress on figuring out why various phenomenon are happening.