Resolution of the Temperature Sensors on the GEM

[guessed]

To track temperature in the Attic, I built a small Arduino device and attached it to the same type of DS18B20 sensor I have attached to my GEM in the Garage, and I'm running it side-by-side to validate the results.

From the attached graphs, I'm finding a great difference in the data resolution produced by each, even though the sensors are the same. The attached [SEG] charts cover approximately the same period of time for a visual comparison of the difference (same type of 1-Wire sensor)

According to the GEM Spec sheet, each temperature sensor is read every 64 seconds (8x sensors, 8 seconds each) at 0.5deg C resolution. What I can't tell is whether the resolution is a limit of the GEM, or a reference to the [typical] limits of the 1-Wire Sensor itself.

Questions:
a) Does the GEM run the Temperature sensor in it's high (12bit) resolution?
b) What would account for the significantly different resolution of the GEM vs the home-grown soln?
c) Any chance of getting more resolution in the values presented by the GEM?

For reference, the graphs are generated by SEG. GEM Data is pushed to SEG using btmon.py, Arduino Data is pushed using custom code running on a Spark Core.

[Teken]

From personal experience some of the variation is from sensor to sensor. While the gradient is also affected by the send interval from the GEM.

Decreasing the send interval will allow more data captured per minute and thus allow more granular reading.

I don't recall off the top of my head if the system is programmed for 12 bit.

[guessed]

Both are set to sample and send the current reading to SEG every 90seconds...and in both cases they're using the same make/model of sensor (from the same batch I originally purchased for the GEM).

They even have the same length of cable (since they came pre-wired)

btmon.py is set to poll the GEM every 90 seconds (ip_poll_interval=90, ip_mode=client) so I might get some idiosyncrasies due to the GEM sampling every 64 seconds, but they shouldn't affect overall precision of the result. You can also see that the temperature doesn't change that rapidly anyhow.

Environmentally, they're about 4meters apart, within the confines of the garage, so I'd expect only minor variations in temperature readings (over time) and/or due to the sensor itself.

ie. slightly higher/lower at any time point in time, based upon location and sensor anomalies.

The GEM is black-box as to the #bits being used, and the precision of any internal C->F calculations, but otherwise I think the test I've put together is about as apples-apples as I can get.


What I'm trying to get is data to support the nearly, but not quite, "square-wave" that I'm seeing in the GEM results at these lower temperature differentials.

[ben]

What firmware versions are you running? The data coming from the GEM doesn't look like it has 0.5C intervals.

a) Does the GEM run the Temperature sensor in it's high (12bit) resolution?
b) What would account for the significantly different resolution of the GEM vs the home-grown soln?
c) Any chance of getting more resolution in the values presented by the GEM?

a) I'm pretty sure we use 12bit resolution but trim the values.
b) It looks like you aren't getting the full 0.5C resolution from the GEM.
c) We don't have any plans to increase the resolution currently.

Ben

[guessed]

I'm on 2.58/1.47

I do occasionally get 0.5 level values, and 0.33/0.66/0.75 levels, as the attached graph shows. But overall it's fairly rough, and I wanted to see if others were getting better resolution in their GEM's or whether this is expected.

If it's what's expected, then I'll swap it out (for temp measurement) for my home-grown option.

[ben]

I'm on 2.58/1.47

I do occasionally get 0.5 level values, and 0.33/0.66/0.75 levels, as the attached graph shows. But overall it's fairly rough, and I wanted to see if others were getting better resolution in their GEM's or whether this is expected.

If it's what's expected, then I'll swap it out (for temp measurement) for my home-grown option.

I would think it would be a bit more granular then that it terms of jumping from 0.5 intervals, but if you want full accuracy you're better off going with a home-grown option.

Ben