Treat xDrip noise >= 3 similar to Dexcom showing ???

[sulkaharo]

Check for xDrip CGM noise, issue neutral temps in case of extreme noise (similar to Dexcom ??? CGM state)

[philipgo]

What does XDrip with G4 or G5 report if blood glucose actually is 38? If it reports 38 + noise level, I think this information should be used.

[sulkaharo]

@drnoname82 CGMs don’t report very low glucose levels as a numeric value, as the opposes to just LOW. I suspect this is both due to safety reasons (communicate a rapid treatment is needed right now) but also because super low glucose can’t be measured reliably with the current tech, so the sensor can’t distinguish between a malfunction and low glucose when we go to very low numbers.

[tepidjuice]

Does the xdripAPS script upload noise values to the rig?

[philipgo]

@sulkaharo I was just wondering whether the transmitter transmits "low" or whether it transmits e.g 38 and the receiver turns it into low. We have not had any BG this low since using OpenAPS (amazing), so I cannot check what XDrip reports. I just want to be sure that during a severe low OpenAPS would zero temp when being used with XDrip instead of defaulting to ""CGM is calibrating, in ??? state or noise is high" because reporting behavior of XDrip might differ from Dexcom

@tepidjuice Interesting point! I think XDripAPS could use an overhaul to also upload treatments to the rig.

[tim2000s]

@tepidjuice it just copies the xdrip data across directly.

[philipgo]

@sulkaharo I found a pre-looping entry that seems to show that XDrip reports values < 39

{
    "_id": {
        "$oid": "123456"
    },
    "device": "xDrip-DexcomG5",
    "date": 1497191959611,
    "dateString": "2017-06-11T16:39:19.611+0200",
    "sgv": 38,
    "direction": "NOT COMPUTABLE",
    "type": "sgv",
    "filtered": 0,
    "unfiltered": 0,
    "rssi": 100,
    "noise": 1,
    "delta": -1.75
}

[sulkaharo]

@drnoname82 It does, but that's probably not actionable data. @jamorham might have insight into the data quality at these levels, but I'm pretty sure Dexcom has had a good reason to not give the exact number at this level.

[philipgo]

Just to make sure that I understand: What would OpenAPS do with the entry I posted. Treat it a) as 38 b) as "low" or c) as "no valid data"?

[tim2000s]

@drnoname82 someone in the itb Gitter channel has done the work to have xDrip pass the data over. He’s also written an equivalent to the glucose test to ensure that NightScout null values aren't overwritten.

[scottleibrand]

Dexcom reports all LOW values with a glucose of 39. If xDrip reports glucose < 39, we'll need to do something to ensure that they are converted before use or something to avoid neutral temping when LOW.

[philipgo]

Does Dexcom always provide a "noise" entry? If so, is the < 39check necessary at all? Would noise >= 3 not suffice?

[philipgo]

Any ideas, whether the "< 39" check is still necessary at all?

[scottleibrand]

Dexcom does not provide the "noise" level directly, so we need to infer it by the absence of a glucose value >=39. When reported via the Share bridge and NS, Dexcom reports:

  {
    "direction": "Flat",
    "trend": 4,
    "dateString": "2017-10-26T11:55:35-07:00",
    "sgv": 126,
    "device": "share2",
    "date": 1509044135000,
    "_id": "59f22feabce7a8312aa0a4b5",
    "type": "sgv",
    "glucose": 126
  },

and a plugged in CGM reports:

  {
    "trend_arrow": "NOT_COMPUTABLE",
    "display_time": "2017-10-25T23:40:54-07:00",
    "system_time": "2017-10-26T07:43:42-07:00",
    "direction": "NOT COMPUTABLE",
    "sgv": 10,
    "dateString": "2017-10-25T23:40:54-07:00",
    "date": 1509000054000,
    "unfiltered": 94880,
    "filtered": 106272,
    "device": "openaps://edison-eb3/cgm",
    "rssi": 183,
    "_id": "59f18384bce7a8312aa0a36d",
    "type": "sgv",
    "glucose": 10
  },

[philipgo]

Since it does not seem possible to positively identify "real" Dexcom sources, the most universal solution seems to be to exclude any values where
bg < 39 AND (noise is not reported OR noise >=3)
This solution however still causes neutral temping for a reported BG < 39 for CGM sources other than Dexcom and XDrip-DexcomG5 that do not report noise levels. Any better ideas?

[scottleibrand]

What CGM sources are those, and how low do their readings go? I think Dexcom only uses numbers up to about 12 for error codes, so we could probably change that < 39 to be something more like < 20 if that would help.

[sulkaharo]

I think they main sources for CGM data in NS are xDrip, NS Uploader and the Enlite Uploader. 600-series uploader is probably also gaining traction. @arbox0 / @pazaan might have things to contribute here too. If needed, I can add filtering to the API to disregard invalid data, but given people can directly inject data to Mongo, we can't prevent uploaders that inject values in the error range that's supposed to represent BG values.

[philipgo]

Then there are iOSxdripreader and all the numerous Libre solution, Wixels, Parakeets. I think it is impossible to identify and continously follow the reporting behavior of all these solutions. So one (not ideal) solution would be to set the Dexcom bg threshold as low as possible, only consider values below this threshold when an adequate noise level is reported.

Another possible solution would be to make OpenAPS behavior dependent on a preference or a question asked during setup.

[JohanDegraeve]

@drnoname82 I copied actually code from xdrip-experimental a version back in May 2016
It looks like I'm not setting any value (null value)

Do you know what algorithm should be used for the noise ?

[philipgo]

@JohanDegraeve Understanding the XDrip code is far beyond my skills. I can only say that this commit brought noise values to the Nightscout entries:

NightscoutFoundation/xDrip@b4b632f

Before, XDrip would always report "noise": 1

[JohanDegraeve]

@drnoname82 ok looks interesting actually, but quite a long calculation to do. I'll note it down and keep you informed

[AdrianLxM]

38 is an xDrip error state indicating "lower than low".
The actual value calculated would be < 10 mg/dl.

This usually indicates sensor failure of some kind.
I would see it as rather impossible that anyone could have a BG even close to that.

[pazaan]

@sulkaharo Do we need a more thorough data model to describe state? 600-series won't send a CGM value lower than 40 mg/dL. There are flags for calibrating, out of range ("lo" and "hi"), and ISIG. We don't have a value for "noise".

[sulkaharo]

@pazaan Yes sounds like it. A combination of 1) well spec'd abstraction layer on top of device protocol, which unified error messaging, 2) reference implementation for using the data and 3) had open source loops require the CGM source support this format, would probably extremely beneficial for reducing bugs / simplifying logic on the data use side & reduce the amount of unvetted sources of CGM data used for looping. Nightscout would also benefit - looking at the data samples from people, the data is all over the place right now; I'd be happy to eventually update the API to only accept data that had certain required fields present.

[philipgo]

So we are currently looping on noisy values and may be setting neutral basals where a low temp would be safer. It does not seem like a universal solution is easy to find. How about a variable like neutral_temp_on_bg_less_than with a default of 39 - that would preserve the status quo for users of original Dexcom solutions and provide an easy fix for XDrip users.

@sulkaharo Did the change work on your rig? I just manually changed the two lines in my determine-basal.js and found that OpenAPS respects the bg limits, but ignores noise values although provided in glucose.json

[scottleibrand]

I just searched our NS for records with an sgv between 10 and 39, and only found results for those two values, not anything in between. Would neutral temps for sgv == 38 be the proper behavior for xDrip users? It should be safe enough to neutral temp for sgv == 38 and sgv <= 10, and treat all other SGVs as valid readings (therefore zero temping for them). Thoughts?

[AdrianLxM]

To me it seems to be the right behaviour for xDrip as I have seen the "38" cases only with extreme noise, bad calibrations (e.g. settings mg/dl and value mmol/l ) or ripped off sensors/transmitters. So all cases where a neutral temp seems appropriate.

[scottleibrand]

Just updated this branch to neutral temp only for bg <= 10 || bg == 38. Does this now look good to merge from y'all's perspectives?

[alimhassam]

seems like a good solution to me

[philipgo]

Has anyone else tested whether the rig actually respects the noise values after these changes? Since our sensor only provides clean readings ("noise" 1) at the moment, I attempted to test this by changing the code to set neutral temps for noise >= 1, but the rig only seemed to respect the BG limits and ignore the noise limit.

[philipgo]

I just tested this PR again on a new rig and changed the code to set neutral temps for noise >= 1 instead of noise >= 3 for testing purposes. Again, the rig loops happily although it should not. I have no idea why...

[alimhassam]

i just checked this, and i'm wondering if this should be noise >=2 instead of >=3 or configurable. I personally get daily situations with noise of 2 which clear rapidely, after taking a shower, and i'm wondering if loop should be making decision based on these readings which seems a little higher than they should be (non scientific guestimation).

[philipgo]

Does it work at all for you? This change is a bit difficult to test because I cannot artificially generate high noise readings, but I think the rig should stop looping entirely when set to noise>=1, which it does not.

What would you think about different acceptable noise levels for high and low glucose values. I personally would prefer low temping even when the glucose values are somewhat questionable (eg. glucose 60, noise 2) but avoid high temping/SMB on questionable high glucose values (eg. glucose 180, noise 2).

[alimhassam]

Pretty much all my readings have noise >=1 so i think thats' too aggressive. I agree with making a distinction between low temping (acceptable with nosice 2), but avoid high temping unless noise is 1, as that's the issue i've been seeing pretty much everyday.

[scottleibrand]

I have a branch for changing how we loop off raw data that would probably be appropriate to discuss using for high noise data too if y’all can get the noise data being used. If not, we might want to do a prep step to convert sgv to raw and remove glucose when noise is high.

[alimhassam]

i merged this branch to test, and added this log statement after

var noise = glucose_status.noise;
console.error("Noise level: ",noise);

and i only get Noise level: undefined in the logs, so something is missing, even if i do have noise values in my cgm data in mlab

coresponding mlab record:

{
    "_id": "5a1b1e52421c480d4d89250a",
    "direction": "FortyFiveUp",
    "noise": 1,
    "dateString": "2017-11-26T15:02:42.128000-05:00",
    "sgv": 159,
    "device": "xDrip-DexcomG5",
    "unfiltered": 153216,
    "filtered": 146496,
    "date": 1511726562128,
    "rssi": 100,
    "type": "sgv",
    "glucose": 159
}

[alimhassam]

@drnoname82 you can try testing this again, i fixed the bug we found together, which was probably causing the issue you mentioned here: #735 (comment)

[philipgo]

Now that the noise field is propagated, it works when I change

oref0/lib/determine-basal/determine-basal.js

Line 77 in 298d435

if (bg < 39 || minAgo > 12 || minAgo < -5) {

to if (bg < 10 || bg == 38 || noise >= 2 || minAgo > 12 || minAgo < -5) (don't know how to commit this to someone else's PR, though)

Now we only need to agree on the limits for acceptable noise. I personally would prefer a conservative approach by default (only loop when noise = 1, maybe changeable through a hidden preference).

[scottleibrand]

Or maybe we could treat noise == 2 the same way we treat raw data from Dexcom, and noise == 3 as no data? And FWIW, I'm thinking about change the way we loop off of raw data, so that we use a multiplier (default of 0.75) to modify the raw values (to be more conservative and handle uncalibrated new sensors), and further limit us to only looping if the resulting value is <= 150 (aka the raw value is <=200). (There's a branch with these changes, but I haven't yet PR'd them.)

[tim2000s]

I’ve been reviewing the data that xDrip provides to NightScout. There are a few places where the data is showing a noise level of 2 although a visual inspection suggests that there is no issue with the cleanliness of the day. 3 generally represents a significant shift from the previous level. I need to quantify it.

[alimhassam]

How often do you get noise of 2? I personally notice noise 2 almost daily but for a short period of time. We would need more data to confirm what the right behavior should be with more cases.
In my case the BG are mostly correct while noise is 2 in my case but sometimes a bit higher than reality.

We probably need more data but my inclination is for openAps to use the BG but be more conservative when noise is 2, and go to neutral temp with a noise of 3... What do you think?

[tim2000s]

It’s interesting. I’ve been using it for ages with xDrip and for a long time there was no noise data.

Since there has been noise data, I’ve not found “2” to be remotely far enough out to require any difference in behaviour.

I also think we only need to disable SMB with “3” and not neutral temp, as generally this occurs with a failing sensor and you see a lot of jumping around. I’ve run the loop without SMB when it’s been noisy and the jumping up and down has been comfortably smoothed by the look back over the previous 15-30 mins perfectly safely.

[philipgo]

The are good reasons for each argument how noise should be treated. However, since OpenAPS keeps becoming easier to install and use (which is fantastic), there seem to be more and more users who do not have a proper understanding of the safety concept and the potential risks involved.

I would therefore favor a very conservative default behavior treating noise >= 2 like raw values and at the same time make this behavior easily configurable through a (hidden) preference (Only looping on noise=1 is recommended by @jamorham NightscoutFoundation/xDrip#191 (comment) )

[AdrianLxM]

When testing noise-levels and how "loopable" they are, could you please also do the following:

1. Enable engineering mode
2. Switch on untra sensitive mode for work around noisy values
3. Upload the display glucose to Nightscout

(1) To enable the engineering mode, enter "enable engineering mode" as spoken treatment:

• On the main screen press the syringe
• press the microphone button and say "enable engineering mode"
• or: long press the microphone button and write "enable engineering mode"
• -> a toast should appear telling you to be careful.

(2) Settings > xDrip+ Display Settings > Smooth sensor noise and then Settings > xDrip+ Display Settings > Smooth sensor noise ultrasensitive (with engineering mode enabled right below the first one)

(3) Settings > Clout Upload > Nightscout sync (REST-API) > Send Display glucose

This way xDrip+ tries to smooth the values when noise is detected. In AndroidAPS this works quite well even with some noise. I also often use the shortAvgDelta for both the 5min-Delta and the shortAvgDelta.

[scottleibrand]

Just opened #833 - please review and comment.

[tim2000s]

@AdrianLxM - what noise level does xDrip+ report when smoothing, etc. are turned on?

[philipgo]

I think this PR can be closed since #833 was merged.