widget display issues about xdrip-experimental

[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" [email protected] 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
#259 (comment)
.

[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 [email protected]
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" [email protected] 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
<
#259 (comment)

.

—
Reply to this email directly or view it on GitHub
#259 (comment)
.

[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" [email protected] wrote:

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

Thanks
Tzachi

On Mon, Jan 25, 2016 at 1:01 AM, ajsdexgithub [email protected]
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" [email protected] 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
<

#259 (comment)

.

—
Reply to this email directly or view it on GitHub
<
#259 (comment)

.

—
Reply to this email directly or view it on GitHub
#259 (comment)
.

[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 [email protected]
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" [email protected] wrote:

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

Thanks
Tzachi

On Mon, Jan 25, 2016 at 1:01 AM, ajsdexgithub [email protected]
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" [email protected] 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
<

#259 (comment)

.

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

#259 (comment)

.

—
Reply to this email directly or view it on GitHub
<
#259 (comment)

.

—
Reply to this email directly or view it on GitHub
#259 (comment)
.

[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 [email protected]
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
#259 (comment)
.

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" [email protected] 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 [email protected]
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
<
#259 (comment)

.

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

—
Reply to this email directly or view it on GitHub
#259 (comment)
.

[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 [email protected]
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" [email protected] 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 <[email protected]

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
<

#259 (comment)

.

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

—
Reply to this email directly or view it on GitHub
<
#259 (comment)

.

—
Reply to this email directly or view it on GitHub
#259 (comment)
.

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