From: lirc@bartelmus.de (Christoph Bartelmus) To: jonsmirl@gmail.com Cc: awalls@md.metrocast.net Cc: linux-input@vger.kernel.org Cc: linux-media@vger.kernel.org Cc: lirc-list@lists.sourceforge.net Cc: mchehab@redhat.com Subject: Re: [PATCH 13/13] IR: Port ene driver to new IR subsystem and enable it. Date: 01 Aug 2010 17:13:00 +0200 [thread overview] Message-ID: <BU0OmdJJjFB@christoph> (raw) In-Reply-To: AANLkTi=c4pNtjPQ9OYL-uxXFFnPUJStUjU26TgpzpL+a@mail.gmail.com Hi! Jon Smirl "jonsmirl@gmail.com" wrote: > On Sun, Aug 1, 2010 at 5:50 AM, Christoph Bartelmus <lirc@bartelmus.de> > 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@bartelmus.de> >>> 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@md.metrocast.net> >>>>> 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. I'm not talking about raw mode here. lircd will happily decode the signals 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 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 function f(x) = 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
WARNING: multiple messages have this Message-ID (diff)
From: lirc@bartelmus.de (Christoph Bartelmus) 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 Subject: Re: [PATCH 13/13] IR: Port ene driver to new IR subsystem and enable it. Date: 01 Aug 2010 17:13:00 +0200 [thread overview] Message-ID: <BU0OmdJJjFB@christoph> (raw) In-Reply-To: AANLkTi=c4pNtjPQ9OYL-uxXFFnPUJStUjU26TgpzpL+a@mail.gmail.com Hi! Jon Smirl "jonsmirl@gmail.com" wrote: > On Sun, Aug 1, 2010 at 5:50 AM, Christoph Bartelmus <lirc@bartelmus.de> > 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@bartelmus.de> >>> 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@md.metrocast.net> >>>>> 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. I'm not talking about raw mode here. lircd will happily decode the signals 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 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 function f(x) = 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
next prev parent reply other threads:[~2010-08-01 15:14 UTC|newest] Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top 2010-07-30 2:17 [PATCH 0/9 v2] IR: few fixes, additions and ENE driver Maxim Levitsky 2010-07-30 2:17 ` [PATCH 01/13] IR: Kconfig fixes Maxim Levitsky 2010-07-30 2:17 ` [PATCH 02/13] IR: minor fixes: Maxim Levitsky 2010-07-30 2:17 ` [PATCH 03/13] IR: replace spinlock with mutex Maxim Levitsky 2010-07-30 2:17 ` [PATCH 04/13] IR: fix locking in ir_raw_event_work Maxim Levitsky 2010-07-30 2:42 ` Andy Walls 2010-07-30 11:02 ` Maxim Levitsky 2010-07-30 2:17 ` [PATCH 05/13] IR: JVC: make repeat work Maxim Levitsky 2010-07-30 2:17 ` [PATCH 06/13] IR: nec decoder: fix repeat Maxim Levitsky 2010-07-30 2:50 ` Andy Walls 2010-07-30 2:17 ` [PATCH 07/13] IR: NECX: support repeat Maxim Levitsky 2010-07-30 2:17 ` [PATCH 08/13] IR: Allow not to compile keymaps in Maxim Levitsky 2010-07-30 2:17 ` [PATCH 09/13] IR: add helper function for hardware with small o/b buffer Maxim Levitsky 2010-07-30 2:17 ` [PATCH 10/13] IR: extend interfaces to support more device settings LIRC: add new IOCTL that enables learning mode (wide band receiver) Maxim Levitsky 2010-07-30 2:17 ` [PATCH 11/13] IR: report unknown scancodes the in-kernel decoders found Maxim Levitsky 2010-07-30 2:17 ` [PATCH 12/13] STAGING: remove lirc_ene0100 driver Maxim Levitsky 2010-07-30 2:17 ` [PATCH 13/13] IR: Port ene driver to new IR subsystem and enable it Maxim Levitsky 2010-07-30 2:39 ` Jon Smirl 2010-07-30 3:46 ` Andy Walls 2010-07-30 11:36 ` Maxim Levitsky 2010-07-30 11:51 ` Jon Smirl 2010-07-30 11:51 ` Jon Smirl 2010-07-30 11:54 ` Maxim Levitsky 2010-07-30 12:02 ` Jon Smirl 2010-07-30 12:07 ` Jon Smirl 2010-07-30 12:45 ` Maxim Levitsky 2010-07-31 13:55 ` Andy Walls 2010-07-31 14:28 ` Maxim Levitsky 2010-07-31 14:37 ` Jon Smirl 2010-07-31 14:37 ` Jon Smirl 2010-07-31 14:51 ` Maxim Levitsky 2010-07-31 15:12 ` Andy Walls 2010-07-31 16:25 ` Jon Smirl 2010-07-31 16:25 ` Jon Smirl 2010-07-31 16:44 ` Maxim Levitsky 2010-07-31 16:51 ` Maxim Levitsky 2010-07-31 17:47 ` Christoph Bartelmus 2010-07-31 17:47 ` Christoph Bartelmus 2010-07-31 18:14 ` Jon Smirl 2010-07-31 18:14 ` Jon Smirl 2010-07-31 18:33 ` Jon Smirl 2010-07-31 18:51 ` Andy Walls 2010-07-31 21:53 ` Jon Smirl 2010-07-31 21:53 ` Jon Smirl 2010-07-31 23:26 ` Maxim Levitsky 2010-08-01 9:43 ` Christoph Bartelmus 2010-08-01 9:43 ` Christoph Bartelmus 2010-08-02 15:12 ` Remote that breaks current system (was: IR: Port ene driver...) it Jarod Wilson 2010-08-02 15:12 ` Jarod Wilson 2010-08-02 16:11 ` Jon Smirl 2010-08-02 16:42 ` Remote that breaks current system Christoph Bartelmus 2010-08-02 16:42 ` Christoph Bartelmus 2010-08-02 17:13 ` Jon Smirl 2010-08-02 18:09 ` Jarod Wilson 2010-08-02 18:09 ` Jarod Wilson 2010-08-02 20:42 ` Jon Smirl 2010-08-02 20:42 ` Jon Smirl 2010-08-11 14:38 ` Jarod Wilson 2010-08-11 14:38 ` Jarod Wilson 2010-08-12 6:46 ` Christoph Bartelmus 2010-08-12 6:46 ` Christoph Bartelmus 2010-08-16 4:04 ` Jarod Wilson 2010-08-16 20:41 ` Maxim Levitsky 2010-08-17 0:14 ` Jarod Wilson 2010-08-17 3:30 ` Mauro Carvalho Chehab 2010-08-17 3:40 ` Jarod Wilson 2010-08-02 17:51 ` Jarod Wilson 2010-08-01 9:50 ` [PATCH 13/13] IR: Port ene driver to new IR subsystem and enable it Christoph Bartelmus 2010-08-01 9:50 ` Christoph Bartelmus 2010-08-01 14:00 ` Jon Smirl 2010-08-01 14:00 ` Jon Smirl 2010-08-01 14:05 ` Jon Smirl 2010-08-01 15:13 ` Christoph Bartelmus [this message] 2010-08-01 15:13 ` Christoph Bartelmus 2010-07-30 11:38 [PATCH 0/9 v3] IR: few fixes, additions and ENE driver Maxim Levitsky 2010-07-30 11:38 ` [PATCH 13/13] IR: Port ene driver to new IR subsystem and enable it Maxim Levitsky 2010-07-31 14:59 [PATCH 0/9 v4] IR: few fixes, additions and ENE driver Maxim Levitsky 2010-07-31 14:59 ` [PATCH 13/13] IR: Port ene driver to new IR subsystem and enable it Maxim Levitsky
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=BU0OmdJJjFB@christoph \ --to=lirc@bartelmus.de \ --cc=awalls@md.metrocast.net \ --cc=jonsmirl@gmail.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.