Incorrect deltas and trending arrows

[sergiotome]

There is something completely off with the calculation of deltas an trending arrows. I've been looking at reading very closely while trying to create a firmware for M5StickC, and have seen in way too many cases scenarios where the deltas and the arrows are a complete mismatch. Maybe they should be, since I don't understand the logic behind those calculations, but the truth is they they don't make any sense at all.

I've been looking at the readings sent via BLE every minute and I still cannot figure out how the deltas are calculated. In majority of the cases they seem to be calculated by comparing the current reading with 4 readings before (about 4 minutes ago) but that is in fact not always the case.

When looking at the trending arrows, the problem becomes bigger. I expect those arrows to somehow match the delta. But I have seen cases where the delta is positive and the arrow is double down (dropping fast). That makes no sense at all!! Here are a few screenshots of what I'm talking about:

This first one shows an arrow trending down but the delta is a positive value (+1) This one shows the arrow trending flat, but the delta is +10!! And this one shows a fast drop (double arrow down) but the delta is again positive (+2)

I can get more examples if needed, but looks like the logic to calculate the arrows and the deltas is completely different which makes the screen very confusing. Take the last screenshot as an example: Is my BG really dropping very fast or is it still increasing more? Should I at this point consider getting more insuline or do I just need to wait since it will go down by itself very fast? (I know my BG levels were not very good when I did this, but hopefully it shows what I'm talking about)

[sergiotome]

Here goes a couple of other examples. Looks like if I look at xDrip for more than 5 minutes I find at least one of these...

[paulplant]

The trend values are calculated over a 5 minute period which was always the way CGM systems worked until Libre 2 BLE appeared with a new reading every 60 seconds.

I'm looking at trying to account for this over the next days and will ask you for feedback @sergiotome .

In your case, the problem is worse as you clearly have quite a lot of sensor noise showing which produces short-term delta changes and exaggerates the issue.

[sergiotome]

As I looked at this a little closer, looks like when those big discrepancies happen are in moments when either BG is raising or reducing fast, and suddenly it changes to a more steady state, or the other way around, when the BG levels are pretty flat and suddenly you do something that rapidly increases or decreases it. My assumption is therefore that deltas are calculated in a period of 5 minutes, while arrows are calculated against the last reading only.

There is a difficult solution to this. While the combination of delta and arrow still looks confusing, I guess it may make sense (i.e. your delta is high/low in the last 5 minutes but as of this exact moment, the trend is this other one).

With this, I still believe that if the trend is calculated the exact same way as the delta (or based on that delta calculation) it will remove the confusion that this can cause. This will probably match what other sensors that provide reading only every 5 minutes show. However, it may bring in a delay in showing what the current state is now that we have readings every minute. Is there any other/better way to calculate deltas now that we have BG readings more often? Any idea whether they do it differently in xDrip+?

[paulplant]

OK, I finally got some time to check this whilst sitting in the airport again.

The trend arrow and delta are completely separate items albeit based on the differences with current and previous BG readings.

The trend arrow is basically calculated from the (delta value between current and previous reading) divided by the (timestamp difference between the current and previous reading). This is then shifted to a value "per minute" and the minute change is what is evaluated to choose which arrow to use.

The delta is basically what you said earlier. It is simply the difference between the current value and the previous value from over 4 minutes ago (so basically from 5 minutes earlier).

So yes... it's entirely possible that you have a general negative delta in the last 5 minutes, but that your last reading has a jump in it (due to sensor noise) and causes a ↑ arrow to be shown. And this is technically correct as the trend is changing.

A 1 minute delta value would be probably quite meaningless for most people as most sensor users are very accustomed to talking about "+4" when talking about rises....

Maybe there's a couple of possible proposals here:

1. Edit the delta text to clearly show that it is over 5 minutes....for example "+3mg/dL / 5 min" (this could probably be left out for 5 minute sensor readings and only included for 1 minute readings such as Libre 2 Direct).
2. Modify the delta value to show between the last two readings irrespective of how close they are (as we do for the trend arrow). This will result in delta showing +1 most of the time even when the user is going up at a noticeable +4 in 5-minute terms. Again, it would require adding an "over time" to the delta text, for example "+1mg/dL / 1 min"
3. Keep the 5 minute delta and also add a 1 minute delta value below if the user is using a transmitter that gives 60 second readings. Maybe the 1 minute delta could be in a smaller font or something (like just for info).

Contras:

1. It takes up a lot of screen space for something that really doesn't add much value (even if we only show it to Libre 2 Direct users.
2. I personally feel that 1 minute deltas don't problem enough information to see what's going on. In fact, I'd personally prefer a 20 minute delta and a 5 minute delta - this would give clearer information on what's really happening
3. See (1) but then double the space we need.

Any thoughts @sergiotome , @JohanDegraeve , @LiroyvH ?

[OliNix]

Having the delta time period user selectable in the settings would be nice and keep the cal text short.

You could opt to sync the trend and delta time periods, or have them separate.

Personally, I would like to have them synced to the same period. Others may not though.

[sergiotome]

@paulplant, I don't think I would add any extra text on the screen. That would just make it harder to read and understand, and putting multiple different delta values would in fact become confusing for way too many people. The suggestion from @OliNix made me think it could be a good solution, but would start overcomplicating the app too much for just one particular sensor, and I'm also not sure if everyone would understand what that exactly means and what the consequences of those settings could be....

Instead of trying to change the delta, we may want to focus on the trend arrow instead. If the trend is calculated as "current reading + last reading / timestamp diff between those two readings", how different would it be if we change it to "current reading + 5 mins ago reading (same one used to calculate delta) / timestamp diff between those two readings". Wouldn't that give the app the exact same arrow you would get with other sensors that have readings every 5 minutes? And wouldn't that always make the delta and trending arrow be always in sync?

[paulplant]

Yes, that would make them be in sync... but then we would get the same issue as you were originally describing here (but in reverse).

People would be confused as to why the trend arrow is showing down, when they can see that the last reading has just gone up... (or vice-versa).

I would also prefer to avoid adding any extra menu items for such a trivial choice (I know Johan is already worried about how many options we have).

I'm really not sure what is the best way to do this... syncing both the trend and delta over the same time period would make sense to reduce confusion as to why they are different, but allowing the trend to go out-of-sync with what the chart is showing could provoke even more confusion.

The good thing is that 5 minutes (even with 1 minute readings) still does not really give enough time for any real change in BG that could confuse things (such as dropping and rising again noticeably) - around 15-20 minutes minimum is still needed for this type of thing to happen.

[jonisaksson]

I feel like i have to chip in here as i went through the same thought process here as sergiotome a couple of years ago when i first moved to xdrip4iOS from Spike. Initially I had the view that of course the 2 need to match but after PaulPlant had spent numerous facebook messages with me explaining what was happening, i started to see the value of keeping them as they are. So now, when ever I look at trends, i look at the graph (what has happened over the last hour or so), latest delta change and the arrow, and all of them together helps me to decide if I need to do a small bolus or have some sugar (with the addition of course of other factors, like exercise, meal etc etc)

I think that the real issue is, that when you as a user first realise there is a discrepancy between the arrow and the delta, it is really hard to find out what the 2 mean and it isnt obvious. Also nowhere (as I far as I know), is it documented that the 2 things are not showing the same thing, so the initial reaction by everyone will be that what they have come across is some sort of bug, So I think this can be resolved by clearly documenting what each one does in the user manual. As I think having the 2 different 'views' that you get from what the arrow shows vs the delta is actually helpful... that is if you know what they mean, hence the documentation suggestion

EDIT: Just to add, if you change them to match, then the value of the arrow really diminishes? As the arrow will then just be a graphical expression of what the delta numbers are showing. As it is now, the arrow is actually adding additional value/data to the decision process beyond what the delta numbers are saying

[sergiotome]

I don't know what else to say. I see the pros and cons of every single option discussed here, and at this point it may make no sense to make any changes at all. I do agree with at least clarifying all of this in the documentation, but we all know that 90% of the users will never read it anyway. I guess we can close this here. Thanks everyone!

[OliNix]

Out of interest...

If we go down the "there could still be a bug route". Does the trend arrow use the raw Libre value or the smoothed Libre value?

From memory - I think the smoothing algorithm is only applied to your penultimate reading. As your latest reading can sometimes change if it is an abnormality to the data trend.

I.e if your trend arrow is being corrupted by noise (and my smoothing assumption is correct), could we defer it to use the latest "smoothed" reading?

On the documentation note: this feels like small (i) icons next to the already existing menu items (on/off switches) with a 1 or 2 line summary would give enough detail to suffice 98% of users.

I agree that the settings can be overwhelming, A single level of sub-pages would make it easier to navigate and understand. I usually fall back to one of the first software lessons I was taught for this "If it doesn't all fit in a single view, you either need fewer items or more folders!"

[paulplant]

Nice discussion guys... I think we'll close the issue and as kind of agreed by all, we'll get a simple explanation added to the documentation that explains it in an easy way.

So we won't make any changes for now and I think we agree that the current way that the delta values and the trend arrow are calculated are the best ways to give the user the information they need.

@OliNix - the values are always calculated using the "Calculated Glucose Value" which means after calibration (even if the calibrator is nil). Smoothed values are only smooth retrospectively - the latest value is always kept the same, so yes... using smoothed values could cause a (very) small discrepancy as the second-to-last reading will be slightly adjusted on the graph after the trend/delta have already been calculated. I think it's safe to just ignore this and we can also add a note to the documentation about this.

[LJWatson]

I realise this issue is closed, but having been pointed here from #431 by @paulplant, it seems better to keep the conversation in the same place.

I seem to be the latest person to think there is a bug. If it takes lots of FB messages or Github discussions to explain it, then arguably the UI is broken for most people. Putting something in the documentation would be good, but as @sergiotome notes, most people don't read the manual anyway.

If I was to rethink this part of the UI, the two things I think I'd find helpful would be the overall recent trend and the difference between this BG reading and the last (whenever that might have been).

Which makes me wonder if the arrows would be a better representation of the general trend over the last few minutes (in other words the delta), and the number as a representation of the incremental change between the current reading and the one before?

That way you'd know how long since the UI was updated, the precise amount your BG had changed since the last reading, and you'd have an idea of the general trend your BG readings were going in over a slightly longer time.