Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

shift of calibration point in graph #1453

Closed
Nyan-Korea opened this issue Sep 27, 2020 · 13 comments
Closed

shift of calibration point in graph #1453

Nyan-Korea opened this issue Sep 27, 2020 · 13 comments
Labels
question type-documentation An issue or pull request for improving or updating the documentation, wiki or FAQs ui User interface related

Comments

@Nyan-Korea
Copy link

Nyan-Korea commented Sep 27, 2020

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 tolot27 added bug any kind of software error ui User interface related labels Sep 29, 2020
@tolot27
Copy link
Collaborator

tolot27 commented Sep 29, 2020

I discovered this, too.

@Nyan-Korea
Copy link
Author

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

Have a good day.

@tzachi-dar
Copy link
Contributor

tzachi-dar commented Sep 30, 2020 via email

@tolot27
Copy link
Collaborator

tolot27 commented Nov 7, 2020

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.

@tolot27 tolot27 added question and removed bug any kind of software error labels Nov 7, 2020
@tolot27 tolot27 changed the title Question about calculation shift of calibration point in graph Nov 7, 2020
@simonpickering
Copy link

simonpickering commented Nov 26, 2020

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
Copy link
Collaborator

tolot27 commented Nov 26, 2020

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

@simonpickering
Copy link

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
Copy link
Collaborator

tolot27 commented Nov 27, 2020

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
Copy link

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
Copy link
Collaborator

Navid200 commented Jan 11, 2021

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

@tolot27 tolot27 added the type-documentation An issue or pull request for improving or updating the documentation, wiki or FAQs label Feb 7, 2021
@Navid200
Copy link
Collaborator

Navid200 commented May 3, 2021

This must have been the commit that introduced this behavior.

Screenshot 2021-05-02 224307

@Navid200
Copy link
Collaborator

Navid200 commented May 3, 2021

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
Copy link
Collaborator

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question type-documentation An issue or pull request for improving or updating the documentation, wiki or FAQs ui User interface related
Projects
None yet
Development

No branches or pull requests

5 participants