Apparently incorrectly formatted fields in entries table about xdrip-experimental

[AdrianLxM]

Hi, thanks for sharing your findings!

the date string actually looks sound with the T. (https://en.wikipedia.org/wiki/ISO_8601#Combined_date_and_time_representations)

As the BT-wixel does not record the unfiltered data, it is ok, imho that both are the same. There were phantom-raw values in the first two days, but actually they were the same regarding filtered/unfiltered just streched by a factor.

About the missing precision with the filtered/unfiltered data: This I noticed as well while looking at the plan to bring "raw" to Nightwatch/AndroidWear. There are an awful lot of zeros at the end when reading the pebble endpoint. (But the test data I got was generated with Share). I hope someone knows more.

[Cagier]

Thanks Adrian for that insightful response!

OK, so it is a legit timestamp - just looked a but funny. ;)

I never actually realised that the standard BT-wixel only captures the raw values (and not the filtered). So, I agree it's not a real issue if the filtered is the same. (However, it would seem trivial to add in the filtered and send this on for use with Nightscout which would be handy with the new funnel options.)

On the final point, I am still a bit confused. This part of the packet is uInt16 (0-65,535) and formatted as %lu in the printf. In the earlier version where the values were different, the unfiltered value appeared to have 6 decimal places: e.g.
"filtered": 147424,
"unfiltered": 147466.40420201755,

and now that they are the same, there appears to be just zeroes
"filtered": 146976,
"unfiltered": 146976,

The implication is that the "real" value is the 6 digit value and that "phantom raw"/unfiltered values were calculated by a factor and give them some notional decimal places that a real dexcom receiver would never assign. However, as you say, the filtered and unfiltered are now both raw and it does not really matter.

The confusing thing is that even though the entries in the underlying documents appear to have the same format (as per below)

{
"_id": {
"$oid": "5611e4785c5d5bfe2b761aef"
},
"device": "xDrip-WifiWixel",
"date": 1444013167836,
"dateString": "2015-10-05T03:46:07.836+0100",
"sgv": 190,
"direction": "DoubleUp",
"type": "sgv",
"filtered": 80544,
"unfiltered": 168448,
"rssi": 100,
"noise": 1
}

{
"_id": {
"$oid": "5611e44235333daa4cb2a453"
},
"device": "xDrip-BluetoothWixel",
"date": 1444013114966,
"dateString": "2015-10-05T03:45:14.966+0100",
"sgv": 173,
"direction": "Flat",
"type": "sgv",
"filtered": 168448,
"unfiltered": 168448,
"rssi": 100,
"noise": 1
}

The two different sources have different format in mongolab on the default table view.

Date SGV Direction Type Filtered Unfiltered Signal Noise Level

2015-10-05T03:45:14.966+0100 173 Flat sgv 168448 168448 100 1
2015-10-05T03:46:07.836+0100 190 DoubleUp sgv 80544.000000 168448.000000 100 1

Now it really doesn't matter and is probably just a mongo thing depending on the upload method but slightly surprising/confusing. My pebble works fine with either!

Anyway, great answers. Thanks for your help!

I'll close this shortly if no-one else has anything else to add but will leave it open for a day or two just in case...

[jstevensog]

The problem with getting filtered using wixel-xDrip is that it sends the data in text. Adding filtered to it blows the character limit of BLE. Not really a show stopper, as it can be handled in the receiving code. XBridge2 wixel code uses a packed binary protocol and sends filtered, among other things. It isn't perfect either, but you have the choice. I will be adding a couple more data points to the data packet in the next version.
Can't help with the mongo data. ,;)
Cheers

---- Keith Garland wrote ----

Thanks Adrian for that insightful response!

OK, so it is a legit timestamp - just looked a but funny. ;)

I never actually realised that the standard BT-wixel only captures the raw values (and not the filtered). So, I agree it's not a real issue if the filtered is the same. (However, it would seem trivial to add in the filtered and send this on for use with Nightscout which would be handy with the new funnel options.)

On the final point, I am still a bit confused. This part of the packet is uInt16 (0-65,535) and formatted as %lu in the printf. In the earlier version where the values were different, the unfiltered value appeared to have 6 decimal places: e.g.
"filtered": 147424,
"unfiltered": 147466.40420201755,

and now that they are the same, there appears to be just zeroes
"filtered": 146976,
"unfiltered": 146976,

The implication is that the "real" value is the 6 digit value and that "phantom raw"/unfiltered values were calculated by a factor and give them some notional decimal places that a real dexcom receiver would never assign. However, as you say, the filtered and unfiltered are now both raw and it does not really matter.

The confusing thing is that even though the entries in the underlying documents appear to have the same format (as per below)

{
"_id": {
"$oid": "5611e4785c5d5bfe2b761aef"
},
"device": "xDrip-WifiWixel",
"date": 1444013167836,
"dateString": "2015-10-05T03:46:07.836+0100",
"sgv": 190,
"direction": "DoubleUp",
"type": "sgv",
"filtered": 80544,
"unfiltered": 168448,
"rssi": 100,
"noise": 1
}

{
"_id": {
"$oid": "5611e44235333daa4cb2a453"
},
"device": "xDrip-BluetoothWixel",
"date": 1444013114966,
"dateString": "2015-10-05T03:45:14.966+0100",
"sgv": 173,
"direction": "Flat",
"type": "sgv",
"filtered": 168448,
"unfiltered": 168448,
"rssi": 100,
"noise": 1
}

The two different sources have different format in mongolab on the default table view.

Date SGV Direction Type Filtered Unfiltered Signal Noise Level

2015-10-05T03:45:14.966+0100 173 Flat sgv 168448 168448 100 1
2015-10-05T03:46:07.836+0100 190 DoubleUp sgv 80544.000000 168448.000000 100 1

Now it really doesn't matter and is probably just a mongo thing depending on the upload method but slightly surprising/confusing. My pebble works fine with either!

Anyway, great answers. Thanks for your help!

I'll close this shortly if no-one else has anything else to add but will leave it open for a day or two just in case...

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

[Cagier]

OK, thanks for all the informative replies. I'll close this issue now.