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. 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. :) Optionally we can drop the calculation of timeres and just use a constant threshold. Thanks, 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
