Closed philipgo closed 6 years ago
Nightscout expects the following values to be encoded into the CGM entry objects:
rawbg.noiseCodeToDisplay = function noiseCodeToDisplay(mgdl, noise) {
var display;
switch (parseInt(noise)) {
case 0: display = '---'; break;
case 1: display = translate('Clean'); break;
case 2: display = translate('Light'); break;
case 3: display = translate('Medium'); break;
case 4: display = translate('Heavy'); break;
default:
if (mgdl < 40) {
display = translate('Heavy');
} else {
display = '~~~';
}
break;
}
return display;
};
I plan to add support to translate the calculated noise values within xDrip to ones to match the Nightscout noise scale.
This would equate the xDrip:
> NOISE_TRIGGER
threshold => "2"
> NOISE_TOO_HIGH_FOR_PREDICT
=> "3"
> NOISE_HIGH
=> "4"
I will encode the value "0"
to mean unknown noise or other error.
For looping I would say to disregard anything containing a noise value other than "1" and also be aware that at present the xDrip Nightscout uploader also does not include the noise smoothing overlay or calibration plugin overlay.
I am hopeful that this commit will go some way to resolving this:
https://github.com/NightscoutFoundation/xDrip/commit/b4b632fa993ccda71e45d2c2dc3b2794560275c5
This change will be available in the Oct 4th xDrip Nightly.
Not all data sources have a true "raw" value so I would prefer not to try to exclude sgv and provide just raw as a fallback as I think this could be misleading.
@jamorham Thank you for implementing this, it works great with the G5! I think this issue can be closed.
We are currently discussing how to make use of the noise data without breaking the way OpenAPS treats original Dexcom data. Maybe you have some useful input? https://github.com/openaps/oref0/pull/735
Thanks to @jamorham for reporting the noise values. They are now used by OpenAPS dev to be less aggressive with noisy CGM values.
Currently, entries uploaded to Nightscout do not take noise levels into account when using the Dexcom G5. The noise level is available locally, but the MongoDB entries all contain
"noise": 1
and report BG values as SGV. Many people use XDrip as BG source for their artificial pancreas systems. The current behavior makes it impossible for loop systems to recognize unreliable BG data.This led to a potentially critical incident for us while using OpenAPS. A sensor failed and all of a sudden reported BG values of >300 with noise levels of 1000 while true BG was around 90 (day 6, transmitter with original batteries, sensor super-reliable until then, no acetaminophen involved, no visible damage to the wire). This caused OpenAPS to give insulin. As this was during the day, we noticed the error immediately and no harm was caused.
Incidents like this could easily be avoided if XDrip only reported low-noise values as "SGV" and high-noise values as "raw". This would still allow XDrip to almost always display BG values, but AP systems could simply decide to trust only "SGV" values.
(The current low BG is caused by the sensor being removed, the values did not come down before removal)