NightscoutFoundation / xDrip

Nightscout version of xDrip+
https://jamorham.github.io/#xdrip-plus
GNU General Public License v3.0
1.42k stars 1.15k forks source link

shift of calibration point in graph #1453

Closed Nyan-Korea closed 3 years ago

Nyan-Korea commented 4 years ago

Hello. I have a question in using Xdrip.

I use Miao Miao 2 with libre. So my sugar data indicates on the Xdrip screen every 5 minutes.

When I put the calibration data just after measuring my sugar data with my real blood, I can see that the red dot(calibration data on Xdrip graph) locates about 10minutes later. But it show the current time when I click it and see the time information. Only looks like for the gragh location.

As I know, libre shows me the sugar data for 10 or 15 minutes ago actually. So is it the caluation for the 10 or 15minutes delay time? or just a interface bug?

tolot27 commented 4 years ago

I discovered this, too.

Nyan-Korea commented 4 years ago

Sorry. I did not get it. Can you reply me the detail for my question please..?

Have a good day.

tzachi-dar commented 4 years ago

The delay is intentional.

On Tue, 29 Sep 2020 at 08:09, Nyan-Korea notifications@github.com wrote:

Sorry. I did not get it. Can you reply me the detail for my question please..?

Have a good day.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/NightscoutFoundation/xDrip/issues/1453#issuecomment-700429753, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB4TBZFTUQAU4CUE4JU57A3SIFT2BANCNFSM4R3HG4KQ .

tolot27 commented 4 years ago

The delay is intentional.

Please can you explain the rational behind it?

Even if the bg value is not used for calibration, it is shifted in the graph.

simonpickering commented 4 years ago

The UI presents the data from the Libre or other glucose monitoring device at the time it was sensed. There is a lag between blood glucose level and that measured in the interstitial fluid (by the Libre, etc.).

That means that the calibration data you measure now from your blood sugar represents what you should see from the Libre in 10-15min time (assuming the rate of change of blood glucose doesn't vary too much).

The other way to present the data (i.e. the one which isn't used here), would be to "back date" the Libre values by 10-15min and use a projected value to tell you what's happening right now (and to also put blood glucose readings at their measurement time), there might be some merit to that, but I imagine that's a non-inconsequential code change.

tolot27 commented 4 years ago

Okay, but if the BG value is not used for calibration, it is still shifted. That does not make sense, IMHO.

simonpickering commented 4 years ago

Consistency.

Everything that is displayed is in terms of the delayed interstitial fluid response (i.e. Libre readings), so all blood glucose readings need to be shifted - even if a point isn't used for calibration you can still see whether it lines up (or not!) with the Libre readings.

I also had this problem when I first started using the system, thought I'd entered something wrongly, etc. At the very least I guess a tutorial screen might be in order to tell people what to expect.

What might be better, though I don't have time to volunteer to do it right now, is to allow the main screen to be shown either in terms of the delayed interstitial/Libre values as it currently is, or in terms of current/estimated BG values (which would push all the Libre readings back in time and place finger prick tests at the time at which they occur). There may already be an issue open for this latter idea, if not it will need a new one.

tolot27 commented 4 years ago

so all blood glucose readings need to be shifted - even if a point isn't used for calibration you can still see whether it lines up (or not!) with the Libre readings.

I do not fully agree with this behavior. If someone just use a glucometer without a CGM/FGM, the values should be displayed at the point of measurement. It is also not dependent on the type of CGM/FGM; it depends more on the activity/meal intake whether it should be shifted or not.

Nevertheless, this issue was about shifting of calibration points not BG measurements in general. Hence, we should distinguish this and maybe create a separate issue for BG points.

simonpickering commented 4 years ago

Let's take it to another issue - I think there's something to be said for all values being the current blood glucose (or estimates thereof), which would allow use by those only doing finger prick tests as well as multiple interstitial devices in different locations (with different lags), and it would perhaps make it more understandable for users too.

I'd be interested to understand your comment about dependence on meal/activity - I agree there are different blood glucose responses (GI/GL & IS related) which I think are separate (and part of the prediction algorithm) vs changes in lag for the interstitial sensors based on temperature, muscle blood flow, etc. (which I think are directly relevant here)

Navid200 commented 3 years ago

I use Dexcom G6. I experience a similar behavior and I have heard from others in the facebook group, using Dexcom G6 experiencing the same thing, which is unexpected. I know this issue is about Libre and not Dexcom. But, please hear me out.

I have attached an image. I calibrated at 8:28. The two readings I have circled (orange oval) existed when I entered the calibration. But, they were in line with the previous reading. They both moved up, by xDrip, because of the calibration.

What makes no sense is that this is a G6 with an 8Q serial number. Meaning it is running in native mode. This transmitter does not transmit any raw data. Therefore, xDrip does not do the calibration as it has no idea what the raw values are. It is the transmitter that does the calibration. I can see in the xDrip logs that my calibration has been queued to be sent to the transmitter at 8:28.

So, at 8:28, the transmitter still has no idea that we are calibrating. Yet, xDrip has made a change to the graph as soon as I entered the calibration. This suggests that xDrip manipulates the readings even in Native mode.

I have disabled "Rewrite History" under Settings -> xDrip+ Display Settings -> Graph Settings. It was disabled when I did this calibration. Yet, xDrip seems to manipulate history. And it is xDrip doing it, not the transmitter!

xDrip's behavior makes no sense to me here. 2

Navid200 commented 3 years ago

This must have been the commit that introduced this behavior.

Screenshot 2021-05-02 224307

Navid200 commented 3 years ago

I would like to close this issue. The following is my thinking. please let me know if anyone disagrees.

Any blood glucose measurement, whether used for calibration or not, leads any interstitial fluid glucose measurement. How long the delay is depends on many factors and so is not a constant.

The blood glucose measurements entered, are entered and used for calibration with no delay other than the imposed delay (< 5 minutes for Dexcom and <1 minute for Libre?) due to the sampling nature of the system.

However, on the graph only, any blood glucose measurement is intentionally delayed to account for the relative delay. So, if you perform a measurement when your glucose is rising rapidly, without this delay, you would see a significant error between the CGM and your entered blood glucose. If the trend is flat, this should not make any difference as far as the visual error is concerned.

This seems to be an intended behavior added by the (current) main xDrip developer.
It is perfectly understandable if anyone disagrees with his thinking.

If you agree with my thinking and don't mind this issue to be closed, you can either let us know by posting or just forget about it. On the other hand, if you disagree, and would like this behavior to be changed, please respond and let me know so that I know to keep this open and see if I can ask him to respond.

Navid200 commented 3 years ago

We can open this if needed. But, please let me know why and let me know what you think about my explanation above. Thanks