Advanced Libre smoothing plz

[justmara]

Hi. Here I have BG data smoothing weighted average algo taken from Tsunami for AndroidAPS. It is very effective for smoothing sensor noise.

But there is always more room for perfection :) I think it can become even more effective if implemented in xDrip where it can be applied to trend per-minute data, instead of final 5-min data. Am I right?
I'm not any good in porting back to java code neither in xDrip internals, but imho it seems to be pretty easy to implement into ReadingData instead of current calculateSmoothDataImproved for example. What do you think?

[Navid200]

Smoothing is done by attenuating the high-frequency content, a low-pass filter.
If you believe that there is never high-frequency content is your glucose and the only high-frequency source is noise (unwanted transients), this (smoothing) would be a harmless action.

However, there are times your glucose may indeed contain high frequency. As an example think of a time you may eat and forget to take insulin. Hopefully, this never happens to you. But, if it does, your glucose will suddenly rise. This sudden change is a high-frequency component, which is a real component and not noise. Attenuating the high-frequency content, in this case, will in fact delay the real rise of your glucose in the graph.
In this case, smoothing will have a negative effect.

We have had this conversation and the consensus has been that any optional smoothing should be done by the controller (AAPS) itself and not the CGM (xDrip).

[justmara]

But there is already a smoothing option (at least for Libre) in xDrip. And the smoothing mechanic I'm talking to gives pretty good balance between dealing with noise and delaying data. I'm using it in AAPS and it protects from noisy spikes, while still providing reliable response time for AAPS to be still effective.
So here I am talking about tuning/optimization of that exactly smoothing for libre. It is pretty local, must be easy to integrate and test, and will provide real efficiency boost.

any optional smoothing should be done by the controller (AAPS) itself and not the CGM (xDrip).

The problem is that AAPS does not have that much data for fine-tuning this smoothing. The trend data is really helpful for this kind of scenario. While AAPS must deal with final BG data over 5 minute-intervals.

[jamorham]

@justmara can you explain what the question exactly is here? thanks

[justmara]

I'll try to :)
Libre 1 is pretty noisy. xDript's built-in smoothing does its job on mitigating noise spikes, but we have to pay with data actuality for it. It is very slow on showing trend changes and actual deltas.
There is another smoothing algorithm made for AAPS, that uses weighted averaging and proven to be more reliable. Its drawback is that it works on the AAPS side - with final BG values. So it has to work with 5-minute data.

Currentlty calculateSmoothDataPerPoint uses simple averaging over all the libreTrend points for BG value smoothed calculation. That gives extremely slow BG curve change and this mode is near unusable for AAPS.
I thought that would be interesting to implement mentioned smoothing over LibreTrend points - that must be giving cleaner and responsive BG curve right from xDrip.

[jamorham]

Thanks for the description, this makes sense. There is some upcoming work on smoothing and I will incorporate your suggestions there.

[tzachi-dar]

@justmara do you have an example (maybe an excel one) of real data and how it looks with simple average compared to the AAPS code? Would be very interesting to see.

[justmara]

sorry, nope. I've tried that xDrip smoothing long time ago and found it unusable for AAPS. And don't want to do such experiments on my kid now :( And I even don't know how to get that trend data out of xDrip for emulation/comparison.

[blaqone]

Is there. Way to disable smoothing in xdrip altogether and rely the smoothing solely to AAPS?

[Navid200]

As far as I know, meaning I could be wrong, the smoothing in xDrip is to smooth out the graph, not the data.