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:
hpg-grey-ir-pulses.txt.gz
Description: GNU Zip compressed data
