Different Trend Arrow in AAPS then in xDrip

[triplem]

I had several reading reported to AAPS with a different Trend Arrow then shown in XDrip. This is rather Strange, even though most probably explainable. There any way to get this "In Sync"?

[jamorham]

Are you using G5 native mode? If so the trend arrow in xDrip is the one reported by the G5 which is not based on the last 5 minutes delta.

[triplem]

Well, my issue was not that the trend arrow is not as expected from the delta, but there is a different trend transferred to AAPS then shown in xdrip. Yes, I do use the native mode (even though, I expect that it is not working correctly, since the sensor shows, that it is stopped), but this does/should not make a difference on the transferred value, shouldn't it?

[triplem]

There seem to be a difference between the transferred and the shown value.

[triplem]

Could be a rounding issue????

[quizzmaster]

I'm experiencing the same with the Libre. The difference never was bigger than 1 so it is most likely the rounding.

[Cagier]

I see a difference between xDrip and AAPS trend arrow as well. I think this is probably related to #681 and #800

As @jamorham mentions above that the expected behaviour is for the trend arrow in xDrip to be the same one that is reported by the G5 (and presumably G6) in Native Mode then the issue seems to be that this is not the case as the arrow in xDrip can be very different to what I see on my G6 receiver. However, what I see in my G6 receiver tends to match what I see in AAPS.

The natural fix would seem to be to also "correctly" display the G5/G6 reported/Native arrow on xDrip as expected and then everything would be consistent. However, personally I find the one reported by the G5/G6 to be a lot less accurate than the one displayed in xDrip so I would prefer to see that arrow used in AAPS (and NightScout, etc.) - even in Native Mode.

[tolot27]

Looks like the webservice provides a different trend arrow, too (#1165).

[tolot27]

I would prefer to see that arrow used in AAPS (and NightScout, etc.) - even in Native Mode.

That can only be done by AAPS and Nightscout developers. But I assume they won't do that. What about a preference setting allowing to switch between the two trend arrow computation models?

[Navid200]

What about a preference setting allowing to switch between the two trend arrow computation models?

Please, no new settings in xDrip to address inconsistencies caused by other apps.

[Navid200]

@olorinmaia Do you see this issue? Any ideas?

[olorinmaia]

@Navid200 I've seen some other variant of this issue myself, double arrows down in AAPS, I can see if I can get logs for both AAPS and xDrip+ next time. It seem to occur when G6 has some bad readings, maybe a comp low or similar drops, and then the double arrows appear when sensor is getting back on track. It doesn't happen so often, but especially when it comes to double arrows down it can make caregivers abit trigger happy with carbs to "prevent" low ;)

See these two issues reported in AAPS, one is closed, one is open:
nightscout/AndroidAPS#2726
nightscout/AndroidAPS#2581

[olorinmaia]

@MilosKozak is trend arrow in AAPS supposed to reflect what type of arrow thats sent from BG-source or is it "recalculated" within AAPS if smoothing-algo is enabled?

[Navid200]

Based on what I am seeing as the behavior of xDrip and everything I have read in all the issues in this repository, I can make the following conclusions:

• xDrip submits to Nightscout/AAPS/webservice the exact same values it receives from G6 or G7 as the value of delta and as the trend arrow slope.

• xDrip calculates the delta between its current reading and its previous reading and uses that as the delta and trend arow slope that it shows on the xDrip main screen.

Therefore, there is no discrepancy between what you would get from Dexcom app or Dexcom receiver and what xDrip submits to Nightscout or AAPS or webservice.

The only discrepancy is between what G6 or G7 reports as delta or trend arrow and what xDrip shows on its home screen.

If you disagree with any of that, please let me know.

---

If anyone likes to open a PR to add a setting to set xDrip to show the same trend arrow and delta as G6 or G7, please go ahead.
Please add the setting to the home shelf as that is where all the settings related to the trend arrow are.

This is not a bug. This is the behavior of xDrip.
I don't think we ever had to perfectly match the trend arrow and delta of an app that performs smoothing and as a result adds delay.
Yet, I understand if someone does not like the trend arrow to fluctuate so much. So, a new setting could address this.

[Navid200]

When I said please go ahead and open a PR, I never meant that it will be approved. I am not the one who has to approve it. All I mean is that I personally see no problem with it.