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.
I guess we should include timeres into the warning message.
Also I guess now is the time to think about a smarter decoder.
Thanks a lot for your effort.
Harald
--
To unsubscribe from this list: send the line "unsubscribe linux-iio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
