The ds18b20 one wire temperature sensor conversion routine is
returning the units in degrees C while the ds1820 (ds18s20) is
returning it in .001 degrees C. 20C vs 20312C. Once you know the
units I'm liking the latter as it gives a higher precision. Time to
break user applications so the driver can give the temperature in the
same units for both sensors.
I only have the ds18b20 sensor model. Here is the current output from
the sys file for this sensor.
/sys/devices/w1_bus_master1/28-0000000e84a2/w1_slave
45 01 4b 46 7f ff 0b 10 84 : crc=84 YES
45 01 4b 46 7f ff 0b 10 84 t=20
I ran the example data from the specification for the ds1820 through
it's conversion routine and found that t= was 1000 times the value.
What should the displayed units be?
This is the same ds18b20 conversion *1000. Is everyone ok or is any
objecting to .001 degrees C for the units? Patch will follow. The
.001 C does truncate one bit of precision from the ds18b20 by the way.
45 01 4b 46 7f ff 0b 10 84 : crc=84 YES
45 01 4b 46 7f ff 0b 10 84 t=20312
--
David Fries <[email protected]>
http://fries.net/~david/ (PGP encryption key available)
David Fries wrote:
> The ds18b20 one wire temperature sensor conversion routine is
> returning the units in degrees C while the ds1820 (ds18s20) is
> returning it in .001 degrees C. 20C vs 20312C. Once you know the
> units I'm liking the latter as it gives a higher precision. Time to
> break user applications so the driver can give the temperature in the
> same units for both sensors.
>
> I only have the ds18b20 sensor model. Here is the current output from
> the sys file for this sensor.
> /sys/devices/w1_bus_master1/28-0000000e84a2/w1_slave
> 45 01 4b 46 7f ff 0b 10 84 : crc=84 YES
> 45 01 4b 46 7f ff 0b 10 84 t=20
>
> I ran the example data from the specification for the ds1820 through
> it's conversion routine and found that t= was 1000 times the value.
> What should the displayed units be?
>
> This is the same ds18b20 conversion *1000. Is everyone ok or is any
> objecting to .001 degrees C for the units? Patch will follow. The
> .001 C does truncate one bit of precision from the ds18b20 by the way.
>
Millikelvins would have the nice property of never being negative. :)
-hpa
H. Peter Anvin wrote:
> David Fries wrote:
>> The ds18b20 one wire temperature sensor conversion routine is
>> returning the units in degrees C while the ds1820 (ds18s20) is
>> returning it in .001 degrees C. 20C vs 20312C. Once you know the
>> units I'm liking the latter as it gives a higher precision. Time to
>> break user applications so the driver can give the temperature in the
>> same units for both sensors.
>>
>> I only have the ds18b20 sensor model. Here is the current output from
>> the sys file for this sensor.
>> /sys/devices/w1_bus_master1/28-0000000e84a2/w1_slave
>> 45 01 4b 46 7f ff 0b 10 84 : crc=84 YES
>> 45 01 4b 46 7f ff 0b 10 84 t=20
>>
>> I ran the example data from the specification for the ds1820 through
>> it's conversion routine and found that t= was 1000 times the value.
>> What should the displayed units be?
>> This is the same ds18b20 conversion *1000. Is everyone ok or is any
>> objecting to .001 degrees C for the units? Patch will follow. The
>> .001 C does truncate one bit of precision from the ds18b20 by the way.
>>
>
> Millikelvins would have the nice property of never being negative. :)
>
Alternatively, centikelvins would fit nicely in 16 bits if anyone cares...
655.35 K = 382.20 ?C = 719.96 ?F
-hpa
Hi David.
On Mon, Jan 21, 2008 at 05:15:57PM -0600, David Fries ([email protected]) wrote:
> The ds18b20 one wire temperature sensor conversion routine is
> returning the units in degrees C while the ds1820 (ds18s20) is
> returning it in .001 degrees C. 20C vs 20312C. Once you know the
> units I'm liking the latter as it gives a higher precision. Time to
> break user applications so the driver can give the temperature in the
> same units for both sensors.
What about instead of breaking application just add new sysfs file,
which will only return temperature instead of full rom content.
It can be millidegrees Centigrade, another one can be millikelvins :)
Actually it is already posible for applications to decode whatever
precision they like from the rom content displayed, although that can be
not very convenient.
--
Evgeniy Polyakov
On Mon, Jan 21, 2008 at 07:11:07PM -0800, H. Peter Anvin ([email protected]) wrote:
> >Millikelvins would have the nice property of never being negative. :)
> >
>
> Alternatively, centikelvins would fit nicely in 16 bits if anyone cares...
>
> 655.35 K = 382.20 ?C = 719.96 ?F
I have no objection on adding new sysfs files which will return
temperature relative to one on Mars or Venus :)
--
Evgeniy Polyakov
On Wed, Jan 23, 2008 at 12:07:41AM +0300, Evgeniy Polyakov ([email protected]) wrote:
> On Mon, Jan 21, 2008 at 07:11:07PM -0800, H. Peter Anvin ([email protected]) wrote:
> > >Millikelvins would have the nice property of never being negative. :)
> > >
> >
> > Alternatively, centikelvins would fit nicely in 16 bits if anyone cares...
> >
> > 655.35 K = 382.20 ?C = 719.96 ?F
>
> I have no objection on adding new sysfs files which will return
> temperature relative to one on Mars or Venus :)
Even more, what about possibility of changing of the base, relative to
which temperature is displayed? By default I vote for centigrades,
those, who live behind the oceans, can setup Fahrenheit, Kelvin or anything
else, but please in a new file :)
David will this work for you?
--
Evgeniy Polyakov
On Mon, Jan 21, 2008 at 07:11:07PM -0800, H. Peter Anvin wrote:
> H. Peter Anvin wrote:
> >Millikelvins would have the nice property of never being negative. :)
True, but the sensor returns the value as a signed integer in C. That
is where the earlier negative number problem was, it would have to do
yet another conversion to go to Kelvin, and it would be just one more
potential for error. Everyone knows that a bad conversion doomed at
least one space craft, let's stick to Centigrade.
> Alternatively, centikelvins would fit nicely in 16 bits if anyone cares...
>
> 655.35 K = 382.20 ?C = 719.96 ?F
The range for the sensor is -55 to 125 C, if an application didn't
care about precision they could store it in a signed 8 bit value just
fine.
--
David Fries <[email protected]>
http://fries.net/~david/ (PGP encryption key available)
On Wed, Jan 23, 2008 at 12:06:27AM +0300, Evgeniy Polyakov wrote:
>
> What about instead of breaking application just add new sysfs file,
> which will only return temperature instead of full rom content.
> It can be millidegrees Centigrade, another one can be millikelvins :)
If someone wrote their application to read degrees C because they have
an ds18b20, the application will break anyway if they run it with an
ds1820 sensor. Or the opposite way around. Yes it would be better
not to break a program, but I think having a consistent interface for
both sensors to be a better option.
> Actually it is already posible for applications to decode whatever
> precision they like from the rom content displayed, although that can be
> not very convenient.
I was first surprised then glad that the raw data was included in the
user available data. I was wanting the full precision, so that was my
plan.
> Even more, what about possibility of changing of the base, relative to
> which temperature is displayed? By default I vote for centigrades,
> those, who live behind the oceans, can setup Fahrenheit, Kelvin or anything
> else, but please in a new file :)
> David will this work for you?
I'm biased toward Fehrenheit, against Kelvin, but I think continuing
to keep Centigrade is the correct choice here. I don't like the idea
of selecting the base the kernel displays by a userland option, too
easy to make assumptions, give it one interface and let the
application do the conversion, C/1000.0*9/5+32 is pretty easy (for
millidegrees C that is).
I'll get the trivial patch to change the ds18b20 output in
millidegrees C to make things consistent. I'm out of time tonight.
It does sound like a good idea to have a sysfs file that just returns
the millidegrees C in ASCII without any other text. It would be
easier to parse. If the conversion fails return 0 bytes. Just an
idea, but if someone wants it they can write the patch.
--
David Fries <[email protected]>
http://fries.net/~david/ (PGP encryption key available)
David Fries wrote:
> On Mon, Jan 21, 2008 at 07:11:07PM -0800, H. Peter Anvin wrote:
>> H. Peter Anvin wrote:
>>> Millikelvins would have the nice property of never being negative. :)
>
> True, but the sensor returns the value as a signed integer in C. That
> is where the earlier negative number problem was, it would have to do
> yet another conversion to go to Kelvin, and it would be just one more
> potential for error. Everyone knows that a bad conversion doomed at
> least one space craft, let's stick to Centigrade.
>
Uhm... the conversion is exact as long as you have at least centikelvin
precision (0 ?C = 273.15 K by definition, and the multiplier is 1.)
>> Alternatively, centikelvins would fit nicely in 16 bits if anyone cares...
>>
>> 655.35 K = 382.20 ?C = 719.96 ?F
>
> The range for the sensor is -55 to 125 C, if an application didn't
> care about precision they could store it in a signed 8 bit value just
> fine.
This was more a comment as to it possibly being a convenient format for
more than this particular sensor.
The nice thing with kelvins is no need to worry about negative numbers
and something misparsing them, that's all.
I certainly did not imply that we should even consider use ?F. That's
obviously ridiculous.
-hpa