Hi Jon,

on 31 Jul 10 at 12:25, Jon Smirl wrote:

On Sat, Jul 31, 2010 at 11:12 AM, Andy Walls [off-list ref]
wrote:

quoted

I think you won't be able to fix the problem conclusively either way.  A
lot of how the chip's clocks should be programmed depends on how the
GPIOs are used and what crystal is used.

I suspect many designers will use some reference design layout from ENE,
but it won't be good in every case.  The wire-up of the ENE of various
motherboards is likely something you'll have to live with as unknowns.

This is a case where looser tolerances in the in kernel decoders could
reduce this driver's complexity and/or get rid of arbitrary fudge
factors in the driver.

The tolerances are as loose as they can be. The NEC protocol uses
pulses that are 4% longer than JVC. The decoders allow errors up to 2%
(50% of 4%).  The crystals used in electronics are accurate to
0.0001%+.

But the standard IR receivers are far from being accurate enough to allow
tolerance windows of only 2%.
I'm surprised that this works for you. LIRC uses a standard tolerance of
30% / 100 us and even this is not enough sometimes.

For the NEC protocol one signal consists of 22 individual pulses at 38kHz.
If the receiver just misses one pulse, you already have an error of 1/22

4%.

Christoph
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html