Re: iio: dht11 Updates

[Richard Weinberger]

Am 03.12.2014 um 15:08 schrieb Harald Geyer:
> Richard Weinberger writes:
>> Harald,
>>
>> Am 03.12.2014 um 13:18 schrieb Harald Geyer:
>>> Hi Richard,
>>>
>>> thanks for all the work you put into this!
>>>
>>> Richard Weinberger writes:
>>>> I have also a question on your driver. Why you increment
>>>> DHT11_DATA_BIT_LOW/timeres by one in the ambiguity check?
>>>>
>>>>         threshold = DHT11_DATA_BIT_HIGH / timeres;
>>>>         if (DHT11_DATA_BIT_LOW/timeres + 1 >= threshold)
>>>>                 pr_err("dht11: WARNING: decoding ambiguous\n");
>>>
>>> This is to take ambiguity of when the bit started relativ to the
>>> clock ticks into account. For example with common 32kHz clocks:
>>> DHT11_DATA_BIT_LOW / timeres = 0
>>> DHT11_DATA_BIT_HIGH / timeres = 2
>>> but since the bit might not start at a clock tick the actual t of
>>> a low bit can be either 0 or 1 while the actual t of a high bit
>>> can be either 2 or 3.
>>>
>>> This case is fine.
>>>
>>> But if we had a 38kHz clock:
>>> DHT11_DATA_BIT_LOW / timeres = 1    t can be 1 or 2
>>> DHT11_DATA_BIT_HIGH / timeres = 2   t can be 2 or 3
>>> so we have an ambiguity. The ambiguity could be removed by a smarter
>>> decoder, that looks at the t of other bits, but I'm not going to do
>>> that unless somebody is promising to test it on affected hardware.
>>>
>>> Feel free to add some comment about this to the code.
>>
>> Will do, thanks a lot for the explanation.
>>
>> I was asking because I see the "dht11: WARNING: decoding ambiguous"
>> very often. (with and without my patches)
> 
> Yes, your patches shouldn't have any effect on this.
> "very often" in the sense of "not always"? This would be very surprising,
> because this would involve variable length clock ticks, i think.

It happens around 33% of all reads.
BTW: I'm using the DHT22's on my Beaglebone Black.
So the board should be "sane".
But I'll test them on another board too, just to be sure...

> I guess we should include timeres into the warning message.

I'll add some diagnose printk()s to find out.

Thanks,
//richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/