On Sun, Aug 1, 2010 at 10:00 AM, Jon Smirl <jonsmirl@xxxxxxxxx> wrote: > On Sun, Aug 1, 2010 at 5:50 AM, Christoph Bartelmus <lirc@xxxxxxxxxxxx> wrote: >> Hi Jon, >> >> on 31 Jul 10 at 14:14, Jon Smirl wrote: >>> On Sat, Jul 31, 2010 at 1:47 PM, Christoph Bartelmus <lirc@xxxxxxxxxxxx> >>> wrote: >>>> Hi Jon, >>>> >>>> on 31 Jul 10 at 12:25, Jon Smirl wrote: >>>>> On Sat, Jul 31, 2010 at 11:12 AM, Andy Walls <awalls@xxxxxxxxxxxxxxxx> >>>>> wrote: >>>>>> 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%. >> >>> There are different types of errors. The decoders can take large >>> variations in bit times. The problem is with cumulative errors. In >>> this case the error had accumulated up to 450us in the lead pulse. >>> That's just too big of an error and caused the JVC code to be >>> misclassified as NEC. >>> >>> I think he said lirc was misclassifying it too. So we both did the same >>> thing. >> >> No way. JVC is a 16 bit code. NEC uses 32 bits. How can you ever confuse >> JVC with NEC signals? >> >> LIRC will work if there is a 4% or 40% or 400% error. Because irrecord >> generates the config file using your receiver it will compensate for any > > At the end of the process we can build a record and match raw mode if > we have to. > >> timing error. It will work with pulses cut down to 50 us like IrDA >> hardware does and it will work when half of the bits are swallowed like >> the IgorPlug USB receiver does. > > The code for fixing IrDA and IgorPLug should live inside their low > level device drivers. The characteristics of the errors produced by > this hardware are known so a fix can be written to compensate. The > IgorPlug people might find it easier to fix their firmware. You don't > have to get the timing exactly right for the protocol engines to work, > you just need to get the big systematic errors out. There is a real benefit to strict protocol engines. If the IgorPlus people had strict protocol engines to test against they would have discovered their firmware bugs during the initial development process. > > Before doing raw the low level IR drivers should be fixed to provide > the most accurate data possible. I don't think it is good design for a > low level driver to be injecting systematic errors and then have the > next layer of code remove them. The source of the systematic errors > should be characterized and fixed in the low level driver. That also > allows the fixed to be constrained to fixing data from only a single > receiver type. > > I have been burnt twice in the past from fixing errors in a low level > driver higher in the stack. I have learned the hard way that it is a > bad thing to do. As the fixes accumulate in the higher layers you will > reach a point where they conflict and no solution is possible. Bugs in > the low level drivers need to be fixed in that driver. > > Show me a case that can't be fixed in the low level driver and we can > explore the options. > >> >> But of course the driver should try to generate timings as accurate as >> possible. >> >> Christoph >> > > > > -- > Jon Smirl > jonsmirl@xxxxxxxxx > -- Jon Smirl jonsmirl@xxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
