From mboxrd@z Thu Jan 1 00:00:00 1970 From: lirc@bartelmus.de (Christoph Bartelmus) Subject: Re: [PATCH 13/13] IR: Port ene driver to new IR subsystem and enable it. Date: 01 Aug 2010 17:13:00 +0200 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: Received: from moutng.kundenserver.de ([212.227.126.171]:55663 "EHLO moutng.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756289Ab0HAPOZ convert rfc822-to-8bit (ORCPT ); Sun, 1 Aug 2010 11:14:25 -0400 Sender: linux-input-owner@vger.kernel.org List-Id: linux-input@vger.kernel.org To: jonsmirl@gmail.com Cc: awalls@md.metrocast.net, linux-input@vger.kernel.org, linux-media@vger.kernel.org, lirc-list@lists.sourceforge.net, mchehab@redhat.com Hi! Jon Smirl "jonsmirl@gmail.com" wrote: > On Sun, Aug 1, 2010 at 5:50 AM, Christoph Bartelmus > wrote: >> Hi Jon, >> >> on 31 Jul 10 at 14:14, Jon Smirl wrote: >>> On Sat, Jul 31, 2010 at 1:47 PM, Christoph Bartelmus >>> wrote: >>>> Hi Jon, >>>> >>>> on 31 Jul 10 at 12:25, Jon Smirl wrote: >>>>> On Sat, Jul 31, 2010 at 11:12 AM, Andy Walls >>>>> wrote: >>>>>> I think you won't be able to fix the problem conclusively either= way. >>>>>> =A0A lot of how the chip's clocks should be programmed depends o= n how the >>>>>> GPIOs are used and what crystal is used. >>>>>> >>>>>> I suspect many designers will use some reference design layout f= rom >>>>>> ENE, but it won't be good in every case. =A0The wire-up of the E= NE of >>>>>> various motherboards is likely something you'll have to live wit= h 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 fudg= e >>>>>> 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%). =A0The crystals used in electronics are accurate to >>>>> 0.0001%+. >>>> >>>> But the standard IR receivers are far from being accurate enough t= o allow >>>> tolerance windows of only 2%. >>>> I'm surprised that this works for you. LIRC uses a standard tolera= nce of >>>> 30% / 100 us and even this is not enough sometimes. >>>> >>>> For the NEC protocol one signal consists of 22 individual pulses a= t >>>> 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 con= fuse >> JVC with NEC signals? >> >> LIRC will work if there is a 4% or 40% or 400% error. Because irreco= rd >> 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. I'm not talking about raw mode here. lircd will happily decode the sign= als =20 despite of any timing error as long it's consistent. I'm still interested how JVC can be confused with NEC codes. >> 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 l= ike >> 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 function f(x) =3D 50 is not bijective. No way to compensate. Missing bits cannot be magically regenerated by the driver. > The > IgorPlug people might find it easier to fix their firmware. There is a firmware patch available? Do you have a pointer? 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