JP1 Remotes

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

What are inter-gap numbers?

The gap between an IR signal and its repetition.

I think this is one of those situations where we could spend ages trying to figure out what the OP is really asking, whereas a much better idea would be to try and find out what his real goal is.

In other words jyll, let's say we figured out what you really mean by "Inter Gap Table" and we gave you such a list, what would you do with it?

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 113792µs gap between signals in RC-5.

The table not only helps to confirm what I should see as a gap for other protocols, but would also let me see if there's a magic number for most protocols (a cutoff number) that signals the end of a signal and beggining of a repetition.

Oh, you're the LIRC person.

The lead-out times vary a great deal. Get the lead-out time too long, and it looks like a new signal. Too short and the equipment isn't ready for them.

Sometimes the lead-out time is calculated as total, sometimes its a fixed length.

There isn't any magic number, but you could look at decodeIR and figure out what the various lead-out times are for the various protocols.

You'll see they are all over the place.

If your device responds to the RC-5 protocol, how would knowing the leadout times (the real name for your Inter Gap thing) of other protocols help you?

If you had a JP1 remote, we could easily customize the RC-5 protocol so that it didn't repeat, or would repeat more slowly if that would work better.

How were you planning on using whatever information we were to give you with your remote? Just out of curiosity, what remote are you trying to program?

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.

jyll wrote:Signal hex code looks like a bunch of "00xxh", but the repetition starts with "10xxh", which when decoded comes close (~90000µs) to the 113792µs gap between signals in RC-5.

DecodeIR says that RC5 protocol looks like this

RC5
IRP notation: {36k,msb,889}<1,-1|-1,1>(1:1,~F:1:6,T:1,D:5,F:6,^114m)+


When the timeout is writen ^114m, it means that this is the total frame length including the leadout time.
114000 - (1+6+1+5+6)*889 = 98,870

It sounds like you are trying to figure out how to decode signals like decodeIR does.

You might want to study decodeIR.htm to see how the various protocols are put together, and if the IRP notation is giving you trouble, you can read my documentation, Infrared Protocol Primer on how to read IRP notation.

It might be better to look for a toggle bit to see if its a new signal or a repeat. I know that's what my TV does. Quite often my TV requires me to push a button twice in order for the TV to respond, because the toggle bit on the TV gets out of synch with the toggle on the remote.

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 don't remember seeing the toggle bit change.

I'm looking at the basic data I need to decode a signal taking the LIRC config file as an example. The first thing I need to tackle is the repetitions cause my remote is repeating the signal after a button press (no holding of the button).

jyll wrote:'ll take a look at the toggle bit cause the signal from the remote is repeated and I don't remember seeing the toggle bit change.

The RC5 toggle bit changes between key presses, not between frames.

Other protocols change the toggle between frames.

I'm looking at the basic data I need to decode a signal taking the LIRC config file as an example. The first thing I need to tackle is the repetitions cause my remote is repeating the signal after a button press (no holding of the button).

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).



The "1" above tells WinLIRC to ignore the first repeat, apparently, it uses the timeout/gap value to identify repeats.

Just my .02 here, but the RCx toggle bit was specifically designed to deal with repeats. If the receiver sees the same toggle bit on two consecutive receptions, then it assumes that it is just a repeat, even if there has been a 10 minute gap between receptions. If the receiver sees a different toggle on 2 consecutive receptions, it assumes that this is caused by 2 discrete button presses by the user.

This behavior causes problems as Vicky mentioned because sometimes the remote and receiver get out of sync as to what the next toggle bit should be and so the receiver ends up ignoring a button press. This makes it difficult to reliably automate things with macros.

A.A.

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 RC5 toggle bit is designed to let you know when a signal is a repeat vs. a new button press, it's not designed to let you know that a button is repeating, at least not in the way that you're thinking.

If you want your device to truly replicate what the user is doing, then you need to capture exactly what gets sent and replicate it, regardless of whether the signal contains any repeating portions or not.

For example, if the original signal included 4 repeats, then you should send 4 repeats. Not 3 and not 5, but exactly 4.