widget display issues

[ajsdexgithub]

Currently running/using; Dex G4 platinum Android 5.0 XDRIP Beta v2.0.5_1 update 1

There seems to be some issues with the widgets data plotting. Screen grabs attached.

Also, I've been wondering if we will ever include raw data in the widget as well.

Thanks in advance for any help/ideas! -Adam

[AdrianLxM]

Hi Adam, t be the the widget stretches all values on the y-Axis. Might that be the case here as all your values are quite similar? I will have a version where the widget shows the high and low line soon.

[ajsdexgithub]

Thanks Adrian! I do notice that the data is skewed quite a bit more at the beginning of the sensor collection, the closer it is to filling the default time view window(90 min - 3 hours), the graph/data begins aligning with the main app view.

Thanks again! On Jan 24, 2016 2:53 PM, "AdrianLxM" notifications@github.com wrote:

Hi Adam, t be the the widget stretches all values on the y-Axis. Might that be the case here as all your values are quite similar? I will have a version where the widget shows the high and low line soon.

— Reply to this email directly or view it on GitHub https://github.com/StephenBlackWasAlreadyTaken/xDrip-Experimental/issues/259#issuecomment-174349996 .

[tzachi-dar]

What do you mean by raw data? prediction of next data?

Thanks Tzachi

On Mon, Jan 25, 2016 at 1:01 AM, ajsdexgithub notifications@github.com wrote:

Thanks Adrian! I do notice that the data is skewed quite a bit more at the beginning of the sensor collection, the closer it is to filling the default time view window(90 min - 3 hours), the graph/data begins aligning with the main app view.

Thanks again! On Jan 24, 2016 2:53 PM, "AdrianLxM" notifications@github.com wrote:

Hi Adam, t be the the widget stretches all values on the y-Axis. Might that be the case here as all your values are quite similar? I will have a version where the widget shows the high and low line soon.

— Reply to this email directly or view it on GitHub < https://github.com/StephenBlackWasAlreadyTaken/xDrip-Experimental/issues/259#issuecomment-174349996

.

— Reply to this email directly or view it on GitHub https://github.com/StephenBlackWasAlreadyTaken/xDrip-Experimental/issues/259#issuecomment-174350509 .

[ajsdexgithub]

Hi Tzachi,

I am referring to the 'raw data' from the dexcom....that appear as white dots in the main app....most typically seen during the 2 hour calibration wait time when starting/restarting a sensor.

I completely understand the reason why it can't be "shared" using the dexcom share server (it would require a seperate DB entry), but being able to see it in the widget locally, would be an added benefit.

Hope that makes sense. ;-)

Thanks, Adam On Jan 24, 2016 3:06 PM, "tzachi-dar" notifications@github.com wrote:

What do you mean by raw data? prediction of next data?

Thanks Tzachi

On Mon, Jan 25, 2016 at 1:01 AM, ajsdexgithub notifications@github.com wrote:

Thanks Adrian! I do notice that the data is skewed quite a bit more at the beginning of the sensor collection, the closer it is to filling the default time view window(90 min - 3 hours), the graph/data begins aligning with the main app view.

Thanks again! On Jan 24, 2016 2:53 PM, "AdrianLxM" notifications@github.com wrote:

Hi Adam, t be the the widget stretches all values on the y-Axis. Might that be the case here as all your values are quite similar? I will have a version where the widget shows the high and low line soon.

— Reply to this email directly or view it on GitHub <

https://github.com/StephenBlackWasAlreadyTaken/xDrip-Experimental/issues/259#issuecomment-174349996

.

— Reply to this email directly or view it on GitHub < https://github.com/StephenBlackWasAlreadyTaken/xDrip-Experimental/issues/259#issuecomment-174350509

.

— Reply to this email directly or view it on GitHub https://github.com/StephenBlackWasAlreadyTaken/xDrip-Experimental/issues/259#issuecomment-174350822 .

[tzachi-dar]

Well, if you will use xBridge or xDrip you will definitely have this important information. I don't know how this works with the share.

On Mon, Jan 25, 2016 at 1:15 AM, ajsdexgithub notifications@github.com wrote:

Hi Tzachi,

I am referring to the 'raw data' from the dexcom....that appear as white dots in the main app....most typically seen during the 2 hour calibration wait time when starting/restarting a sensor.

I completely understand the reason why it can't be "shared" using the dexcom share server (it would require a seperate DB entry), but being able to see it in the widget locally, would be an added benefit.

Hope that makes sense. ;-)

Thanks, Adam On Jan 24, 2016 3:06 PM, "tzachi-dar" notifications@github.com wrote:

What do you mean by raw data? prediction of next data?

Thanks Tzachi

On Mon, Jan 25, 2016 at 1:01 AM, ajsdexgithub notifications@github.com wrote:

Thanks Adrian! I do notice that the data is skewed quite a bit more at the beginning of the sensor collection, the closer it is to filling the default time view window(90 min - 3 hours), the graph/data begins aligning with the main app view.

Thanks again! On Jan 24, 2016 2:53 PM, "AdrianLxM" notifications@github.com wrote:

Hi Adam, t be the the widget stretches all values on the y-Axis. Might that be the case here as all your values are quite similar? I will have a version where the widget shows the high and low line soon.

— Reply to this email directly or view it on GitHub <

https://github.com/StephenBlackWasAlreadyTaken/xDrip-Experimental/issues/259#issuecomment-174349996

.

— Reply to this email directly or view it on GitHub <

https://github.com/StephenBlackWasAlreadyTaken/xDrip-Experimental/issues/259#issuecomment-174350509

.

— Reply to this email directly or view it on GitHub < https://github.com/StephenBlackWasAlreadyTaken/xDrip-Experimental/issues/259#issuecomment-174350822

.

— Reply to this email directly or view it on GitHub https://github.com/StephenBlackWasAlreadyTaken/xDrip-Experimental/issues/259#issuecomment-174351358 .

[ajsdexgithub]

Here...

Currently, that data is not visible in the widget.

I use my phone primarily as a phone...so as much info that can be gathered and displayed via the widget, the better.

:-) Adam

[jstevensog]

Ok, I have to weigh in here. Firstly, I am unsure if you are using bridge to a G4 transmitter, a G4 Share or a G5, as there are significant differences in what data we can get and display. There is not a one-size-fits-all.

Everyone thinks the "raw data" is the same in xDrip with bridges as in Nightscout using G4 receivers, and it isn't.

In Nightscout with USB uploading data from a receiver (and therefore I assume with share as well, but we don't have it here for me to really know) includes the BG values the receiver "shows" on it's display, and the BGL calculated from the two values the dexcom transmitter sends. The Receiver makes a choice between the two values to display based on how "noisy" or good/bad it thinks the values are. If the value is REALLY bad, it doesn't show it, but it still stores the "raw" and "filtered" (our terms, not Dexcom) values. Nightscout reads these values and uploads them, and calls them "raw data".

With the bridges, xDrip is ALWAYS using (what we called) the raw value from the Transmitter to calculate BGL. So apart from the first 24-48 hours after insertion, when a factor is applied to the "raw" value to account for the sensor bedding in (just like Dexcom), you are effectively seeing the "raw data" in xDrip, and it is transmitting it to your NS site. In NS, you can see this if you turn on "raw data" but it is not as significant if you are uploading from a Dexcom receiver.

While I personally would prefer seeing a trend during the 2 hour warm up period, it could not be accurate. To show it would require xDrip using it's previous sensor slope/intercept to calculate a BGL up upload/display, which could be so far off as to not be even slightly accurate. Something we currently do not do, as once a sensor is stopped, the calibration values no longer count Then there is the whole "bedding in" noise and variability.

My personal experience is that sometimes the values from a new sensor closely match the old, but there really is no guarantee.

I am sure we could make it so, but personally I don't think it should be a priority to us right now, xDrip is mostly used (outside the US where Share receivers are not available) with bridges to G4 transmitters, which is the data we always display. And we cannot (yet) get the "raw/filtered data" from the G5. I have no idea about the G4 Share as I have never seen one.

Hope this explains/clears things a bit. Cheers

On Mon, Jan 25, 2016 at 10:24 AM, ajsdexgithub notifications@github.com wrote:

Here...

[image: screenshot_2016-01-24-15-18-37-1] https://cloud.githubusercontent.com/assets/13719184/12539728/060285e2-c2ae-11e5-81fe-b45cec1dedac.jpg

Currently, that data is not visible in the widget.

I use my phone primarily as a phone...so as much info that can be gathered and displayed via the widget, the better.

:-) Adam

— Reply to this email directly or view it on GitHub https://github.com/StephenBlackWasAlreadyTaken/xDrip-Experimental/issues/259#issuecomment-174351983 .

John Stevens "You are how you live, not what you have."

[ajsdexgithub]

Thank you for the clarification on the terms used.

The unfiltered/raw data I highlighted in my screen grab is extremely useful to me, as I am able to determine the quality/longevity of the sensor/location from that info...regardless of its relevant accuracy.

On a medtronic enlite or sofsensor, this information is called the "ISIG value", and is displayed on the status screen of the sensor.

It is beneficial in that I can tell by the ISIG value....and in this case with the dexcom....if the sensor is going to be accurate, and last it's entire advertised lifespan.

I use a g4 platinum w/share...and xDrip simply for the fact that dexcom doesn't yet (and likely wont) support Android.

I do not use Nightscout or any other services that are essential for this deployment outside of the U.S.

In other words...if you use a dexcom, and an android phone...xDrip is the only game in town.

Sorry to have 'stirred the pot', just offering my observations/suggestions as an end user.

Thanks again, -Adam On Jan 24, 2016 3:55 PM, "John" notifications@github.com wrote:

Ok, I have to weigh in here. Firstly, I am unsure if you are using bridge to a G4 transmitter, a G4 Share or a G5, as there are significant differences in what data we can get and display. There is not a one-size-fits-all.

Everyone thinks the "raw data" is the same in xDrip with bridges as in Nightscout using G4 receivers, and it isn't.

In Nightscout with USB uploading data from a receiver (and therefore I assume with share as well, but we don't have it here for me to really know) includes the BG values the receiver "shows" on it's display, and the BGL calculated from the two values the dexcom transmitter sends. The Receiver makes a choice between the two values to display based on how "noisy" or good/bad it thinks the values are. If the value is REALLY bad, it doesn't show it, but it still stores the "raw" and "filtered" (our terms, not Dexcom) values. Nightscout reads these values and uploads them, and calls them "raw data".

With the bridges, xDrip is ALWAYS using (what we called) the raw value from the Transmitter to calculate BGL. So apart from the first 24-48 hours after insertion, when a factor is applied to the "raw" value to account for the sensor bedding in (just like Dexcom), you are effectively seeing the "raw data" in xDrip, and it is transmitting it to your NS site. In NS, you can see this if you turn on "raw data" but it is not as significant if you are uploading from a Dexcom receiver.

While I personally would prefer seeing a trend during the 2 hour warm up period, it could not be accurate. To show it would require xDrip using it's previous sensor slope/intercept to calculate a BGL up upload/display, which could be so far off as to not be even slightly accurate. Something we currently do not do, as once a sensor is stopped, the calibration values no longer count Then there is the whole "bedding in" noise and variability.

My personal experience is that sometimes the values from a new sensor closely match the old, but there really is no guarantee.

I am sure we could make it so, but personally I don't think it should be a priority to us right now, xDrip is mostly used (outside the US where Share receivers are not available) with bridges to G4 transmitters, which is the data we always display. And we cannot (yet) get the "raw/filtered data" from the G5. I have no idea about the G4 Share as I have never seen one.

Hope this explains/clears things a bit. Cheers

On Mon, Jan 25, 2016 at 10:24 AM, ajsdexgithub notifications@github.com wrote:

Here...

[image: screenshot_2016-01-24-15-18-37-1] < https://cloud.githubusercontent.com/assets/13719184/12539728/060285e2-c2ae-11e5-81fe-b45cec1dedac.jpg

Currently, that data is not visible in the widget.

I use my phone primarily as a phone...so as much info that can be gathered and displayed via the widget, the better.

:-) Adam

— Reply to this email directly or view it on GitHub < https://github.com/StephenBlackWasAlreadyTaken/xDrip-Experimental/issues/259#issuecomment-174351983

.

John Stevens "You are how you live, not what you have."

— Reply to this email directly or view it on GitHub https://github.com/StephenBlackWasAlreadyTaken/xDrip-Experimental/issues/259#issuecomment-174354525 .

[jstevensog]

No need to apologise Adam, There is a lot of misunderstanding about "raw data" and xDrip around. If there is a way to get this information from G4 Share, then I am sure we will try to accommodate. As I said, I would prefer to have some indication during sensor warm up, but after that the signal / trend obtained from a bridge is the best indication of how well a sensor is lasting. xDrip with bridge to G4 hides nothing. Cheers

On Mon, Jan 25, 2016 at 11:14 AM, ajsdexgithub notifications@github.com wrote:

Thank you for the clarification on the terms used.

The unfiltered/raw data I highlighted in my screen grab is extremely useful to me, as I am able to determine the quality/longevity of the sensor/location from that info...regardless of its relevant accuracy.

On a medtronic enlite or sofsensor, this information is called the "ISIG value", and is displayed on the status screen of the sensor.

It is beneficial in that I can tell by the ISIG value....and in this case with the dexcom....if the sensor is going to be accurate, and last it's entire advertised lifespan.

I use a g4 platinum w/share...and xDrip simply for the fact that dexcom doesn't yet (and likely wont) support Android.

I do not use Nightscout or any other services that are essential for this deployment outside of the U.S.

In other words...if you use a dexcom, and an android phone...xDrip is the only game in town.

Sorry to have 'stirred the pot', just offering my observations/suggestions as an end user.

Thanks again, -Adam

On Jan 24, 2016 3:55 PM, "John" notifications@github.com wrote:

Ok, I have to weigh in here. Firstly, I am unsure if you are using bridge to a G4 transmitter, a G4 Share or a G5, as there are significant differences in what data we can get and display. There is not a one-size-fits-all.

Everyone thinks the "raw data" is the same in xDrip with bridges as in Nightscout using G4 receivers, and it isn't.

In Nightscout with USB uploading data from a receiver (and therefore I assume with share as well, but we don't have it here for me to really know) includes the BG values the receiver "shows" on it's display, and the BGL calculated from the two values the dexcom transmitter sends. The Receiver makes a choice between the two values to display based on how "noisy" or good/bad it thinks the values are. If the value is REALLY bad, it doesn't show it, but it still stores the "raw" and "filtered" (our terms, not Dexcom) values. Nightscout reads these values and uploads them, and calls them "raw data".

With the bridges, xDrip is ALWAYS using (what we called) the raw value from the Transmitter to calculate BGL. So apart from the first 24-48 hours after insertion, when a factor is applied to the "raw" value to account for the sensor bedding in (just like Dexcom), you are effectively seeing the "raw data" in xDrip, and it is transmitting it to your NS site. In NS, you can see this if you turn on "raw data" but it is not as significant if you are uploading from a Dexcom receiver.

While I personally would prefer seeing a trend during the 2 hour warm up period, it could not be accurate. To show it would require xDrip using it's previous sensor slope/intercept to calculate a BGL up upload/display, which could be so far off as to not be even slightly accurate. Something we currently do not do, as once a sensor is stopped, the calibration values no longer count Then there is the whole "bedding in" noise and variability.

My personal experience is that sometimes the values from a new sensor closely match the old, but there really is no guarantee.

I am sure we could make it so, but personally I don't think it should be a priority to us right now, xDrip is mostly used (outside the US where Share receivers are not available) with bridges to G4 transmitters, which is the data we always display. And we cannot (yet) get the "raw/filtered data" from the G5. I have no idea about the G4 Share as I have never seen one.

Hope this explains/clears things a bit. Cheers

On Mon, Jan 25, 2016 at 10:24 AM, ajsdexgithub <notifications@github.com

wrote:

Here...

[image: screenshot_2016-01-24-15-18-37-1] <

https://cloud.githubusercontent.com/assets/13719184/12539728/060285e2-c2ae-11e5-81fe-b45cec1dedac.jpg

Currently, that data is not visible in the widget.

I use my phone primarily as a phone...so as much info that can be gathered and displayed via the widget, the better.

:-) Adam

— Reply to this email directly or view it on GitHub <

https://github.com/StephenBlackWasAlreadyTaken/xDrip-Experimental/issues/259#issuecomment-174351983

.

John Stevens "You are how you live, not what you have."

— Reply to this email directly or view it on GitHub < https://github.com/StephenBlackWasAlreadyTaken/xDrip-Experimental/issues/259#issuecomment-174354525

.

— Reply to this email directly or view it on GitHub https://github.com/StephenBlackWasAlreadyTaken/xDrip-Experimental/issues/259#issuecomment-174355536 .

John Stevens "You are how you live, not what you have."