This document describes how to understand and interpret raw Dexcom data on your Nightscout website. Raw data can provide additional useful information, but only when properly understood. Make sure you understand what you are looking at before you incorporate raw data into your decisions. As with anything Nightscout-related, the performance relies solely with the user. Dexcom will not provide any support for the explicit display or use of raw data.
The Dexcom G4 CGM sensor generates raw data by estimating the glucose concentration in interstitial fluid. Glucose levels in interstitial fluid always lag behind real blood glucose values by several minutes. The Dexcom receiver classifies the raw sensor data as being clean when values are stable or relatively predictable. When sensor data is less predictable or more variable, Dexcom classifies the data as having light, moderate or heavy noise. Light, moderate and heavy noise levels can be induced by a number of factors. These factors include real rises or drops in blood sugar, sensor compression, dehydration, excessive moisture around the sensor and transmitter, a poorly secured or failing sensor, and other factors.
When the Dexcom receiver believes sensor data is clean, the glucose numbers and dots on the trend line are based on unfiltered raw data. When sensor data has light or moderate noise, the receiver applies filters to “smooth” the raw sensor data. This filtering adds delay to the values shown on the receiver, potentially causing the receiver to display numbers that are lower or higher than would be shown with clean data. The receiver does not notify you when it switches between clean and non-clean noise levels but there are visual clues in the Dexcom trend line that indicate when a switch occurs. When the receiver believes sensor data has heavy noise, it does not trust the raw data and will display an hourglass or “???”
A major difference between the original (and pediatric) Dexcom G4 software and the newer “505 software” is how often and when the receiver switches from clean to noisy data. The newer software trusts the unfiltered or clean data a much larger percentage of the time, allowing it to more quickly react to and display rapid changes in real glucose levels. Displaying raw data on your Nightscout website will allow you to see these rapid changes more quickly, whether your receiver runs the latest software or not.
Raw Data in Nightscout
Your Nightscout website displays raw data as a separate trend line using small white dots. You can choose to never display raw data (default), display raw data all the time, or display raw data when noise is present. The website does not currently display a raw BG number, however the raw data is plotted on the trend line at the estimated raw BG value.
If raw data is shown all of the time, you will always see two trend lines, with raw shown in white. When raw data differs from Dexcom data, it will show above or below Dexcom data at the same time intervals.
If raw data is only shown when noise is present, any time noise level is clean, you will see a single trend line that always tracks the data from your Dexcom receiver. When the noise level is light or moderate you will see two trend lines, with raw data shown in white. When raw data differs from Dexcom data, it will show above or below Dexcom data at the same time intervals. You can hover over a CGM BG reading to see which noise level Dexcom is reporting.
Enabling raw data in Nightscout has a few side effects you should be aware of.
- First, uploading raw data will moderately increase your uploader data usage, potentially affecting mobile data charges for Ting Wireless and other metered services. It may be a good idea to monitor data charges for any cost increases.
- Second, if you are uploading raw data, your website’s “data out” usage will moderately increase for each client web browser viewing your website. This may affect whether or not you reach the Azure data cap for users on the “Pay as you Go” tier. Nightscout websites hosted on the “Shared” Azure pay tier or running on Heroku are not affected by this potential limitation.
- Third, because each client web browser is rendering more data, it may be slightly slower when viewing the website or scrolling through retrospective data. Any sluggishness would be most noticeable on older or less powerful devices.
Enabling Raw Data
Your Nightscout setup must meet several prerequisites before you can view raw data on your website:
- Your Nightscout uploader app must be running version 0.1.13 (Dreamsicle) or newer. Version 0.1.10 (Cookie Monster) uploads raw data, but does not upload the Dexcom noise data. Noise data is required to display raw data when noise is present.
- Your Nightscout uploader app must be configured to send raw data and calibration records.
- Your Nightscout website must be running 0.6.4 (Dreamsicle) or newer.
- Your Nightscout website configuration must have the ENABLE variable set with a value that includes “rawbg.”
- Each web browser session used to view your Nightscout website must have the “Show Raw BG” option set to either “Always” or “When there is noise” (or the option in Azure or Heroku settings to always show raw data must be configured).
- You must be using an Android uploader. (Raw data is not available with a “bridge” setup from iOS/Share.)
Nightscout uploader App
If your Nightscout uploader app is not current, please follow the setup guide instructions to update your app.
Once your app is updated, open the app Preferences window, scroll down to “Data to Upload” and make sure all five boxes are checked. You must make sure that “Sensor data” and “Calibration data” are both enabled.
Nightscout website configuration
Your website must be running 0.6.4 or newer in order to see raw data. If you haven’t updated yet, follow the instructions in the update guide to update your website.
You must add or modify the “ENABLE” variable in your website configuration to include the text “rawbg” This change adds the ability to display raw BG values for your website. If you do not currently have “ENABLE” set, simply add the “ENABLE” variable with a value of “rawbg” If you already use Care Portal, change the value for your existing “ENABLE” variable to be “careportal rawbg” **If you had ENABLE already in your “Connection Strings”, please remove the line before adding it to the “App Settings”
- If your website is hosted on Azure, the “ENABLE” variable should be listed in the “App Settings” section of the “Configure” tab for your website in the Azure Management Portal.
- If your website is hosted on Heroku, the “ENABLE” variable will be listed in the “Config Variables” section of the “Settings” tab for your website in the Heroku Dashboard.
Nightscout web browser configuration
Open your Nightscout website in a web browser. Then, open the Settings panel for your website, and change the option “Show Raw BG Data” from “Never” to “Always” or “When there is noise” This change enables Raw BG data for the web browser session. This must be done for each web browser session used to view your website.
We recommend that you choose “When there is noise” as a default setting when viewing raw data. First, when noise is clean, Dexcom bases the BG reading on unfiltered raw data, so Nightscout’s interpretation of raw data is not necessarily more accurate, just different. You will also minimize the extra data rendered by your web browser which will speed up refreshes and viewing retrospective data. In addition, you can mouse over each BG reading to see what noise level Dexcom is reporting.
Raw “Always on” vs “When noise is present”
Here is an example comparing the behavior of the Raw BG trend line when “Show Raw BG Data” is set to “Always” vs “When there is noise”.
With raw data “Always on”, you see that raw data (white) shows a sharper drop earlier than the Dexcom data (color). The raw trend line is Nightscout’s estimation of BG based on raw data. It is not necessarily “correct” but offers a different interpretation of the data than the Dexcom trend.
With raw data set to “When noise is present”, the only time the raw data (white) shows up is during periods where the Dexcom receiver reports noise levels other than clean.
Raw Data Usage Examples
Here are some scenarios where raw data can be beneficial when interpreted properly. Nearly all examples show raw data “always on” rather than “when noise is present.” There is a section at the end specifically showing examples where “noise is present.”
Dexcom outages due to an hourglass or “???”
One bad data point causes a 50-minute hourglass outage. Raw data tracks cleanly otherwise.
One bad data point causes a 45-minute hourglass outage. Raw data tracks cleanly otherwise.
Slow receiver recovery from heavy sensor data noise. Possible root causes include dehydration, sensor compression, and aging sensor
Slow receiver recovery from heavy sensor data noise. Possible root causes include dehydration, compression, and aging sensor.
Slow receiver recovery from heavy sensor data noise causing a 30 and 45 minute outage. Possible root causes include dehydration, compression, and aging sensor.
This is an example of solid receiver recovery from a long period of heavy noise. In this case, the receiver has stopped displaying values, so you should treat raw data with an element of suspicion. Over the long term however, the raw data is still usable, just not up to the standards Dexcom is willing to display.
Here is another example of heavy noise. Dexcom would show this period as an hourglass, and then “???” Possible remedies might be drinking water or re-taping the sensor if it’s loose. If the data variability continues, the Dexcom receiver will report that the sensor has failed.
The following picture shows very long period of heavy noise. The receiver recovers twice for a single BG reading, then goes back to hourglass and then “???” This sensor was replaced a short time later.
Data continuity during the two-hour sensor warm-up
Raw data can remove the blind spot during the two-hour sensor warm-up, however the numbers are to be used for basic trend information only.
This example is a new sensor start. Notice the raw data does NOT track real BG cleanly from left to right. With a new sensor placement, the raw data calculations presented by your Nightscout website are using the last calibration record from the PREVIOUS sensor. That data is not valid for the new sensor, but is used to provide a VERY rough estimate for BG trending information ONLY. Do not treat this data with the same confidence as a calibrated sensor.
This next example is a sensor re-start sequence. Notice the raw data tracks cleanly from left to right. This occurs because the sensor has not changed, and the previous calibration record is still valid for the active sensor. This example is not representative of the accuracy of raw data during new sensor warm-up. See the previous example for a new sensor start.
Identifying false compression-induced lows, hourglass and “???” events
Here are four examples of big compression lows in an active, sleeping toddler. Dexcom initially tries to keep up with the rapid BG drop, then quickly switches to an hourglass or “???”.
Here is a slight compression induced drop on a new sensor. There was no new insulin or activity for close to 10 hours prior to the event. After rolling the PWD off the sensor, BG was tested, then Dexcom calibrated after raw BG rebounded.
Identifying rapid BG rise and fall rates
Here, raw data shows the true BG rise of high glycemic breakfast cereal. Note how this pediatric (non-505) receiver initially tracks raw data, and then artificially drops BG when it switches to filtered data. Filtered data doesn’t catch up to raw data until the peak of the rise.
Here is an example showing how raw data more accurately tracks the true BG rises and falls. At various points, raw data is 30 mg/dL “ahead” of the Dexcom values.
Understanding why Dexcom sometimes shows a dash rather than a trend arrow
This is a great example showing why Dexcom sometimes filters sensor data. Raw data is fluctuating too rapidly between readings for the Dexcom receiver to accurately determine a trend. If Dexcom used the raw data to determine a trend in this situation, the trend arrow might go from flat to single arrow up, and back to flat again in the span of three readings. Instead, they filter the data to “smooth out” what the user sees.
Here is the Dexcom filtered data “catching up” to the raw data 20 minutes later. The underlying lesson here is to not take too much stock in a single raw sensor reading. Context matters. Interpreting raw data is a skill, like anything else related to managing diabetes.
Here are examples of raw data only shown when noise is present.
Light noise after a meal bolus.
Clean data with no noise. With no noise, only the main trend line is visible.
Light noise after a correction.
Light noise after a meal.