lkml.org 
[lkml]   [2021]   [Nov]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectKernel driver: W1 DALLAS’S 1-WIRE BUS invalid c alculation
Dear kernel-driver developers,

I believe there is a mistake in calculation of the fine part of the
temperature value as received from 1-Wire DS18x20-family sensors.

The current implementation does indeed follow the official datasheet,
but exactly the datasheet seems to be incorrect in this place.

Datasheet: https://datasheets.maximintegrated.com/en/ds/DS18S20.pdf
says two different things on Page 6:

- First:
"Resolutions greater than 9 bits can be calculated using the data from
the temperature, COUNT REMAIN and COUNT PER °C registers in the
scratchpad. Note that the COUNT PER °C register is hard-wired to
16 (10h). After reading the scratchpad, the TEMP_READ value is
obtained by truncating the 0.5°C bit (bit 0) from the
temperature data (see Figure 4)."

- And then:
"The extended resolution temperature can then be calculated using
the following equation:
TEMPERATURE = TEMP_READ - 0.25 + (COUNT_PER_C - COUNT_REMAIN) / COUNT_PER_C"

I have performed live tests with DS18S20 sensors to verify it, how they
behave. I was lowering the temperature in slow steps to see individual
transitions. Below is the result.

Columns:
- 00, 01, 06, 07 = response bytes 0 (value), 1 (sign), 6 (count remain)
and 7 (count per degC)
- 01-bin = response byte 0 again as binary
- 7-min-6 = response byte 7 minus response byte 6
- -0- = bits 7..1 of response byte 0
- -76- = bits 3..0 of the (byte 7 - byte 6 subtraction)
- hex = the value as hex
- degreesC = the value multiplied by 1/16°C

00 01 06 07 --01-bin- -7-min-6- --0---- -76- hex degreesC
37:00::04:10 0011 0111 0C = 1100 0011011.1100 1BC -> 27.75
37:00::05:10 0011 0111 0B = 1011 0011011.1011 1BB -> 27.6875
37:00::06:10 0011 0111 0A = 1010 0011011.1010 1BA -> 27.625
37:00::07:10 0011 0111 09 = 1001 0011011.1001 1B9 -> 27.5625
37:00::08:10 0011 0111 08 = 1000 0011011.1000 1B8 -> 27.5
36:00::09:10 0011 0110 07 = 0111 0011011.0111 1B7 -> 27.4375
36:00::0A:10 0011 0110 06 = 0110 0011011.0110 1B6 -> 27.375
36:00::0B:10 0011 0110 05 = 0101 0011011.0101 1B5 -> 27.3125
36:00::0C:10 0011 0110 04 = 0100 0011011.0100 1B4 -> 27.25
36:00::0D:10 0011 0110 03 = 0011 0011011.0011 1B3 -> 27.1875
36:00::0E:10 0011 0110 02 = 0010 0011011.0010 1B2 -> 27.125
36:00::0F:10 0011 0110 01 = 0001 0011011.0001 1B1 -> 27.0625
36:00::10:10 0011 0110 00 = 0000 0011011.0000 1B0 -> 27
35:00::01:10 0011 0101 0F = 1111 0011010.1111 1AF -> 26.9375
35:00::02:10 0011 0101 0E = 1110 0011010.1110 1AE -> 26.875
35:00::03:10 0011 0101 0D = 1101 0011010.1101 1AD -> 26.8125
35:00::04:10 0011 0101 0C = 1100 0011010.1100 1AC -> 26.75
35:00::05:10 0011 0101 0B = 1011 0011010.1011 1AB -> 26.6875
35:00::06:10 0011 0101 0A = 1010 0011010.1010 1AA -> 26.625

for temperature(s) below zero (u2 coding):

00 01 06 07 --01-bin- -7-min-6- --0---- -76- hex degreesC
00:00::0E:10 0000 0000 02 = 0010 0.0010 0.125
00:00::0F:10 0000 0000 01 = 0001 0.0001 0.0625
00:00::10:10 0000 0000 00 = 0000 0.0000 0
FF:FF::01:10 1111 1111 0F = 1111 1111111.1111 -0.0625
FF:FF::02:10 1111 1111 0E = 1110 1111111.1110 -0.125
...
FC:FF::0F:10 1111 1100 01 = 0001 1111110.0001 -1.9375
FC:FF::10:10 1111 1100 00 = 0000 1111110.0000 -2.0000
FB:FF::01:10 1111 1011 0F = 1111 1111101.1111 -2.0625

My findings are confirmed by other people, e.g. here:
https://www.electro-tech-online.com/threads/expanding-ds18s20-output-from-9-bit-to-12-bit.128569/post-1070629

The only unclear thing for me is the byte[7]. The datasheet says it is
hard wired to 10h. The guy here says, he has seen devices with other
dividers:
https://www.electro-tech-online.com/threads/expanding-ds18s20-output-from-9-bit-to-12-bit.128569/post-1084824
"I noticed that the count divisor was not equal to 16 as the data sheet
indicated it would be. In fact, as the temperature was raised and
lowered, the count divisor would increase and decrease in value (not
fixed)."

Assuming the guy did not make any mistake, it would be interesting to
know, whether the divisor is always a power of 2 (which would make the
conversion easy) or can be of any value.

For your info: I have contacted Evgeniy P. as an author of the driver,
but according to the response, he is not maintaining the driver anymore.
That's why a question to all of you, if anyone could take a look at this
please.

Thank you very much and best regards
K.

\
 
 \ /
  Last update: 2021-11-29 20:36    [W:0.119 / U:0.276 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site