Re: [PATCH 04/15] V4L/DVB: ir-core: Add logic to decode IR protocols at the IR core

From: Andy Walls <awalls@md.metrocast.net>
To: Mauro Carvalho Chehab <mchehab@infradead.org>
Cc: linux-input@vger.kernel.org,
	Linux Media Mailing List <linux-media@vger.kernel.org>
Subject: Re: [PATCH 04/15] V4L/DVB: ir-core: Add logic to decode IR protocols at the IR core
Date: Sun, 04 Apr 2010 21:45:11 -0400	[thread overview]
Message-ID: <1270431911.3506.25.camel@palomino.walls.org> (raw)
In-Reply-To: <4BB8D3D6.5010706@infradead.org>

[-- Attachment #1: Type: text/plain, Size: 4104 bytes --]

On Sun, 2010-04-04 at 15:00 -0300, Mauro Carvalho Chehab wrote:
> Andy Walls wrote:

> > And when you have time:

> > A way to generate random IR
> > glitches is with bright sunlight reflecting off of a basin of water
> > that's surface is being disturbed to make waves.  
> 
> I have a better way: just let my IR sensor to be pointed to the fluorescent
> lamp I have on my room... It produces _lots_ of glitches.

:)

> > Since a glitch filter is probably going to be needed by a number of
> > drivers and since the minimum acceptable pulse depends slightly on the
> > protocol, it probably makes sense for
> > 
> > 1. A driver to indicate if its raw events need glitch filtering
> > 
> > 2. A common glitch filtering library function that can be used by all
> > decoders, and that also can accept a decoder specified minimum
> > acceptable pulse width.
> 
> Seems a nice improvement. I doubt I'll have time for handling it right now,
> since there are still many things to do, but I'll put it on my todo list.
> Of course, patches adding it are wellcome ;)

:)

OK.  When I find time I'll hack something up as a prototype.

> Btw, I added a RC-5 decoder there, at my IR experimental tree:
> 	http://git.linuxtv.org/mchehab/ir.git

I'll try to review it some time this week.  Streaming state machine
decoders do seem to be best way to go with these decoders.

I have an RC-5 decoder in cx23885-input.c that isn't as clean as the NEC
protocol decoder I developed.  The cx23885-input.c RC-5 decoder is not a
very explicit state machine however (it is a bit hack-ish).

> Unfortunately, there's some problem with either my Remote Controller or 
> with the saa7134 driver. After 11 bits received, after the 2 start bits, 
> it receives a pause (see the enclosed sequence).

-ENOATTACHMENT

> I'm starting to suspect that the Hauppauge Grey IR produces a sequence with shorter
> bits, but, as the hardware decoders are capable or receiving IR codes, it may
> also be a hardware problem.

The fundamental unit in RC-5 is 32 cycles / 36 kHz = 888889 ns ~= 889 us.

I turned on the cx23888-ir.c debugging on the HVR-1850 and using a
Hauppague grey remote (address 0x1e IIRC) and got this as just one
example:

cx23885[1]/888-ir: rx read:     802037 ns  mark
cx23885[1]/888-ir: rx read:     852704 ns  space
cx23885[1]/888-ir: rx read:     775370 ns  mark
cx23885[1]/888-ir: rx read:     852407 ns  space
cx23885[1]/888-ir: rx read:     802037 ns  mark
cx23885[1]/888-ir: rx read:     852852 ns  space
cx23885[1]/888-ir: rx read:     775667 ns  mark
cx23885[1]/888-ir: rx read:     852407 ns  space
cx23885[1]/888-ir: rx read:     801741 ns  mark
cx23885[1]/888-ir: rx read:     852852 ns  space
cx23885[1]/888-ir: rx read:     775667 ns  mark
cx23885[1]/888-ir: rx read:     852407 ns  space
cx23885[1]/888-ir: rx read:    1602926 ns  mark
cx23885[1]/888-ir: rx read:     852407 ns  space
cx23885[1]/888-ir: rx read:     801741 ns  mark
cx23885[1]/888-ir: rx read:     852852 ns  space
cx23885[1]/888-ir: rx read:     775074 ns  mark
cx23885[1]/888-ir: rx read:     853148 ns  space
cx23885[1]/888-ir: rx read:     801593 ns  mark
cx23885[1]/888-ir: rx read:     852704 ns  space
cx23885[1]/888-ir: rx read:     775667 ns  mark
cx23885[1]/888-ir: rx read:     852556 ns  space
cx23885[1]/888-ir: rx read:     801741 ns  mark
cx23885[1]/888-ir: rx read:     852259 ns  space
cx23885[1]/888-ir: rx read:     775963 ns  mark
cx23885[1]/888-ir: rx read: end of rx

That should be a press of '0' on the remote.

'end of rx' means the hardware measured a really long space.

I also had the hardware low pass filter on.   I think that would effect
the space measurements by making them shorter, if IR noise caused a
glitch. 

Note that many of the marks are a bit shorter than the ideal 889 us.  In
fact the single marks from the grey remote seem to alternate between 775
us and 802 us.

I have attached a larger capture of (attempted) single presses of the
digits '0' through '9' and then an intentionally held down press of '7'.

With a quick glance, I don't see pauses from the grey remote.

Regards,
Andy

[-- Attachment #2: hpg-grey-ir-pulses.txt.gz --]
[-- Type: application/x-gzip, Size: 2520 bytes --]