Comments (9)
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.
from xdrip-experimental.
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)
.
from xdrip-experimental.
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)
.
from xdrip-experimental.
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
TzachiOn 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
<.
—
Reply to this email directly or view it on GitHub
<
#259 (comment).
—
Reply to this email directly or view it on GitHub
#259 (comment)
.
from xdrip-experimental.
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
TzachiOn 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
<.
—
Reply to this email directly or view it on GitHub
<.
—
Reply to this email directly or view it on GitHub
<
#259 (comment).
—
Reply to this email directly or view it on GitHub
#259 (comment)
.
from xdrip-experimental.
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
from xdrip-experimental.
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.jpgCurrently, 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."
from xdrip-experimental.
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.
CheersOn 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.jpgCurrently, 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)
.
from xdrip-experimental.
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,
-AdamOn 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.
CheersOn Mon, Jan 25, 2016 at 10:24 AM, ajsdexgithub <[email protected]
wrote:
Here...
[image: screenshot_2016-01-24-15-18-37-1]
<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
<.
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."
from xdrip-experimental.
Related Issues (20)
- Default Slopes HOT 9
- [G5] Beta -Transmitter Batter: Not available - Need 2 readings, no option to do so HOT 1
- Import Fails on Marshmallow and above HOT 16
- Red text on black background
- overriden calibrations used in slopeOOBHandler ? HOT 3
- DataBase Import Fails on Nougat (and marshmallow) HOT 1
- Delete Calibration Request HOT 2
- time issue for values HOT 6
- storing bg low level alert times in treatments profile
- Beta5 v2.0.5_2 update 2 - Parsing Issue After Download when I try to Install
- xdrip - current beta version shows ?AD HOT 2
- MongoLab not receiving data HOT 5
- Can't set TXID on xbridge HOT 2
- DexShareCollectionService got the status 133 bug bad news! HOT 6
- Feature Suggestion - xBridge tracker
- Snooze alarm if treatment was already entered
- Alarm raises volume to 100% while media is playing through earbuds (hurts eardrums) HOT 4
- Xdrip+ and missed alarm problem
- double measurements?
- How to extract raw trend arrows data HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from xdrip-experimental.