Re: iio: dht11 Updates

[Richard Weinberger <richard@nod.at>]

Harald,

Am 04.12.2014 um 14:45 schrieb Harald Geyer:
> Richard Weinberger writes:
>> Am 03.12.2014 um 15:08 schrieb Harald Geyer:
>>>> 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.
>>>
>>> I guess we should include timeres into the warning message.
>>>
>>> Also I guess now is the time to think about a smarter decoder.
> 
> I was wrong.
>  
>> Another question. Your driver defines:
>> #define DHT11_DATA_BIT_LOW      27000
>> #define DHT11_DATA_BIT_HIGH     70000
>>
>> If I read the manual [0] correctly these constants are T_h0/1.
>> Why did you use 27000 for T_h0?
>>
>> [0] http://meteobox.tk/files/AM2302.pdf
> 
> It's a compromise between data sheets for various slightly different
> sensors. In particular the data sheet for AM2303 specifies
> 26-28us, so it's just in the middle. But note that DHT11_DATA_BIT_LOW
> isn't used in the actual decoding. Just for printing the warning.
> 
> But looking at your data sheet I see the we currently use a start
> command that's outside the specified range... I will have to look
> up where the current 80ms value was suggested.
> 
>> Setting it to 26000 (the typical value as stated by the manual),
>> I get the "decoding ambiguous" warning *always*. Setting it higher
>> makes the message go away.
> 
> If you misstyped "always" and "go away" then this is to be expected.

Nope, a lower value is bad and a higher makes the warning go away.

> Also I think I now understand what is going on:
> Your board most probably has a clock much faster then 32kH and when
> we calculate timeres, we don't actually calculate the timestamp
> resolution but the length of the shortest pulse. The decoding
> algorithm is robust in such cases, but it generates wrong warnings.
> 
> The proper fix is to drop messages about clock speed from the
> decoding functin. If we want to keep such diagnostics, we should
> have them at probe() time. - This will also resolve our disagreement
> about proper formatting of log messages about clock issues. :)

Sounds sane.

> Optionally we can drop the calculation of timeres and just use a
> constant threshold.

Same here.

Thanks,
//richard