JP1 Remotes

From Wikipedia's RC-5 protocol page:

A field bit, which denotes whether the command sent is in the lower field (logic 1 = 0 to 63 decimal) or the upper field (logic 0 = 64 to 127 decimal). The field bit was added later by Philips when it was realized that 64 commands per device were insufficient ...

Thanks for the info (vicky, Rob, cauer). Rob, could you list some of the "regular" protocols? It helps to have a mental map of which ones can be dealt with as a group.

Yes, I was mixing the toggle bit state, thanks for pointing that out. :D

The way I see it, I have two options, and in both cases I need to work with the timeout/gap value to piece together the data streams coming from the receiver.

Either I use a works-for-many-protocols config file with a ...

It will be an option (user selectable like WinLIRC). For typical use like controlling a PC this is not an issue, again is an option. Remember my last question and the double output I was seeing, this is how I fixed it in WinLIRC ("Disable Repeats = 1").

It seems that signals generated by pressing buttons should be separated by an amount of time longer than the timeout/gap period. Repeats are separated by an amount similar to the timeout/gap period. So it looks like you have a way to identify repeats whether the toggle bit is set or not.

The data arriving from the receiver is broken up into several parts that need to be reconstructed. Having a remote sending an extra signal is not welcomed, and the repetition can be discarded (a repeat on a key press).

http://i36.tinypic.com/j8l8wk.jpg

The "1" above tells WinLIRC to ignore the ...

I'm talking about the timeout (114ms), LIRC's config file for RC-5 doesn't show a leadout of 889us (trailing half-period), only a pulse lead of 889us. Yes, I want to decode the signal like DecodeIR and LIRC does. I'll take a look at the toggle bit cause the signal from the remote is repeated and I ...

My receiver is protocol independent, just like the IR Widget, it measures durations. I working on decoding remote signals, beginning with RC-5. Knowledge of the leadout/gap (among other info) helps in the verification (what is expected) of the fragmetned data coming from the buffer.

With my remote I'm getting a repetition of the signal everytime I press a button (RC-5). I'm looking for a protocol-independent way to deal with repetitions.

Signal hex code looks like a bunch of "00xxh", but the repetition starts with "10xxh", which when decoded comes close (~90000µs) to the ...

The gap between an IR signal and its repetition.

Is there a table with inter-gap numbers for the most common protocols?

The output I was seeing had to do with the repeat count (00, 01, 02, 03, ...), it wasn't related to the toggle bit.

LIRC only sends one hex code for each button pressed, but my remote sends the first repeat too fast so that's why I was getting the hex code twice.

I got this ...

000000000000001169 ...

I can also get RC5/RC5 extended commands using the IR Toy in RC5 mode (default). Taking the output for the VCR Pause button as an example:

{05}{69}{00}{00}{00}{00} {05}{69}{00}{00}{00}{00}

00000101 01101001 00000000 00000000 00000000 00000000

00000101 = 05h = VCR address (device)
01101001 = 69h ...

According to the method previously posted, we should see 1169h and 1969h, but that's not what LIRC outputs.

EDIT: LIRC only outputs one hex code per button pressed, but uses a repeat count.

That's what the image you can't see what's supposed to show. It shows LIRC's TCP output after I pressed the Pause button once.

I reuploaded the image to another server, can you see it?