
In the first part of these two sections dedicated to Libre’s minute by minute data, we looked at how the data presented and what that meant for variation and differences to what we’re used to with five minute data.
In this section we’ll take a look at the impact of using the more frequent data, and how it affects Open Source AID systems.
A parallel AndroidAPS experiment
I ran two AndroidAPS systems that were intended to be identical with one taking in minute-by-minute data from Libre via Juggluco and the other from Dexcom G6 every five minutes. They both used identical preferences and automations. The Libre version used no smoothing to understand the effect of raw one minute data. The Dexcom version used the average smoothing setting.
Both were connected to real pumps delivering real insulin. Only the Dexcom connected system was delivering insulin directly to me. The other was releasing liquid out into the wild. The one difference between the two was that profile shifts created in the connected system didn’t propagate to the unconnected one.
Both were configured to allow SMBs every three minutes. The results of this experiment are described here.
How insulin delivery was affected
The two following images show how, over the the first week of use, receiving data every minutes and being allowed to SMB every three minutes resulted in a significant uplift in delivered insulin, and how it skewed the delivery very heavily towards bolusing.
It’s worth commenting at this point that as the Libre based system was delivering insulin every three minutes, compared to every five for the Dexcom based system, we might expect that had it been connected to a human, it would have affected the glucose levels earlier, so it’s an open question as to whether the change in timing really results in overdelivery, or whether, by relying on the five minute delivery, we get incorrect results from the Libre-based system.
Aside from the 29th, when both systems were delivering based on Dexcom data, the average TDD of the Libre based system was 63.8u compared to 45.2u on the Dexcom driven system. This is roughly 40% more insulin delivered, which ties in with the frequency increase of the SMB interval.
The other notable difference is the doubling of the proportion of insulin delivered as boluses. This is understandable given the increased frequency of SMBs. It creates a different set of challenges though, as once an SMB is given it can’t be removed, whereas a TBR can be reduced or zeroed if the glucose data suggests that is the desired state.
In this case, it’s not clear that more data is really better.
Insulin Dosing

This is harder to see in the image, as it’s a view of two NightScout instances running side by side. On the left hand side you have both Dexcom G6 and Libre one minute data superimposed on top of each other. On the right, only the G6 data.
The left hand side shows dosing from the Libre based system and the right hand side from the Dexcom based system. Close ups of the same time frame show some interesting characteristics.
As we mentioned earlier, this isn’t clean data, as there’s a missing profile switch in the Libre-based system that would lower the profile by 15%.
Having said that, there are 15% more boluses in the minute by minute data, and they appear to be proportionally outsized larger than the boluses being delivered in the five minute data, even accounting for the reduced profile in the five minute case.
Obviously, we can’t read anything into this, due to the difference in the configuration, but it looks like something worthy of greater investigation.
If we review the data with a slightly different view, we can see the that in the five minute data, there tend to be fewer larger boluses, where with the one minute there are large boluses and more frequent mid and small sized ones.
The clustering is easy to see in the graphs above. This also demonstrates how the variability in the one-minute data interacts withe the oref1 algorithm, if shorter SMB intervals are allowed.
How battery life was affected
Another key part of delivering minute-by-minute data to AAPS is the effect on battery drain.
The two graphs show battery drain on the trial phone using direct one minute data from Juggluco and indirect five minute data via xDrip.
With the one minute data, AAPS uses significantly more battery, and the overall battery drain is significantly greater over the same time period.
In discussions with developers, this is put down to the significant increase in load on AAPS, both in recalculating five times as frequently, but also in the increased database interaction that the more frequent data requires.
However you view it, the faster battery drain, on a phone that was being used as a dedicated AAPS handset, is not desirable, and in this case, more data is definitely not better.
In Summary
There have been plenty of discussionsnin various user groups about the benefits and otherwise of using more frequent data for Automated Insulin Delivery. The data I’ve captured and presented here suggests that there’s definitely some tuning needed around how open source tools should be configured for using that data.
Firstly, from a treatment perspective, I’m not convinced that more frequent SMBs are desirable, indeed, if you look at some of the commercial models, they only make treatment decisions every 8 minutes or so. In the case described here, I think that 5 minute intervals for SMBs is small enough. It allows for variation in basal rates in the interim, which can always be switched off to reduce insulin delivery as needed, and allows for early downtick data to be taken into account.
It’s worth noting that if you use one minute data with the exponential smoothing in AAPS, it only acts every five minutes, and while this helps to ameliorate the variability and dosing frequency, it tends to eliminate any benefits that might be seen from earlier downturns.
The other major issue with one minute data is the battery consumption. All the processing, storage read/write and additional data transmission to cloud storage significantly impacted battery life, bringing it down to well under a day. This isn’t ideal either.
So to sum it all up, using minute data requires care and customisation, either of settings or of the algorithm. There are circumstances where the data itself (as shown in the first part of this pair on Libre) gives readings that aren’t necessarily valid. These points are often shown as data unavailable in the Abbott apps and need to be recognised in open source tools. Additionally, if you want a device that lasts a decent length of time, then the minute by minute data really doesn’t help.
For the second time, is more data better? And for the second time, in its current incarnation, I’m not convinced that it is.
Some of your findings have been discussed since minute values were available and are just not true. N=1 is sadly just not viable in this context.
For example Juggluco does not use more battery. The standard apps use a lot thou.
autoIFS and other features need get as much info as possible and as soon as possible.
Hi Edgar, thanks for your feedback.
I have never stated that Juggluco uses more battery, in fact I’m certain that it doesn’t.
What was unusual about this experiment is that it was run for a week using 1 minute data direct from Juggluco into AAPS and then another week with Juggluco feeding xDrip which fed AAPSnat five minutes intervals.
Everything else remained the same.
The switch to five minute data significantly reduced the battery drain.
With an extra app operating in the middle, it would suggest that the drain was caused by AAPS and nothing else.
Subsequent conversations also point to this.
With respect to AutoISF and other functions needing as much data as possible as soon as possible, that holds true if, and only if, the data is good enough quality. As I showed in section one of this review of Libre data, that isn’t always the case, and as a result, mitigation is required.