Closed gir0034 closed 1 year ago
Hi, this may sound a bit weird or even silly, but it works as intended. However, the explanation is not simple.
If you wait a bit, you'll notice that the smaller digits (be it min or max) will start to get closer to the large-digit (real-time) value you saw earlier. This is because large digits show values obtained using coarser filtering process, therefore have less delay than the smaller digits which come from a finer, higher delay filter.
As a consequence, we can say that it is wrong to directly compare large and small values in real time. Sometimes it can even happen that the real-time value exceeds any value that is later displayed as a minimum or maximum in small digits. In this sense, small digits are regarded as "more accurate" values in this implementation. But they are not as real-time as the large digits, and when min or max is changing, you should wait a bit before using the values for comparisons.
I guess it was only a matter of time before someone noticed this 🙂. We can try to mitigate this somehow. For example, we could change the min/max values also in real time, so that they always follow large digits in the extremes, but then converge them to the more accurate values later, when the extremes are no longer changing. Would that be less upsetting?
Thanks for the feedback!
In the end, the mitigation was carried out as mentioned in the last paragraph. Thanks again!
Hi, I noticed that from some weeks is not recorded correctly the maximum and minimum values of slope and altitude. The value in real time is different from the max or min recorded, for example if I cycle in a slope of 7,9% the max recorded is 3,1%. I attach some screenshot. Thanks