JP1 Remotes

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

jyll wrote:The thing is I'm getting a repeat on one key press, and the toggle bit doesn't change.

If my code were to depend on the toggle bit for catching this repeat, it will fail, but if it is aware of the timeout/gap it will see the repeat just (timeout/gap value)µs after the first signal and can safely discard it as the toggle bit hasn't changed.

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 you have a way to identify repeats whether the toggle bit is set or not.

WinLIRC's option to discard x numbers of repeats works fine because it allows you to discard the first repeat on this remote independently of the toggle bit. Even if you hold down a button, discarding the first repeat (or first few repeats) won't make much of a difference.

If you're getting a repeat on one keypress and the toggle bit is not changing, then that is perfect. You see that the toggle bit didn't change and you ignore the repeats. The fact that the remote seems to send repeats on what is perceived as a single keypress is not uncommon. The RCx protocols were designed to be more robust in that respect by sending more than one and letting the toggle bit sort out what is a single keypress vs multiple keypresses. If they had used leadout time as a way to figure out what is a repeat, then you get into a problem where sketchy reception of IR can cause unintended repeats. Imagine that you press the "3" key meaning to enter the first digit of a channel number and the receiver sees one copy of the IR for "3" and then the next copy gets garbled because of some local interference or whatever, but it sees the next one after that. Then the receiver, if it doesn't pay attention to the toggle bit, will think that you pressed "3" a second time and you go to channel 33 and you get frustrated that you keep getting these unintended repeats.

You said that if your code were to depend on the toggle bit to catch this, it would fail, but I don't see why. Your code needs to track the state of the last received toggle bit and ignore new receptions with the same toggle bit and accept new receptions with a different toggle bit. This is how devices using RCx protocol work. If your code doesn't emulate that, then you can't really complain. Trying to do it with leadout times could work, but why go to the trouble unless you're trying to make something universal that applies to other protocols?

A.A.

jyll wrote:It will be an option for remotes like mine that send a repeat for each key press without changing the toggle bit.

You see the same signal twice with no way of knowing if it was a repeat (no toggle bit change), unless you check the timeout/gap (this is mainly for controlling a media PC).

If there's no change in the toggle bit, it's a repeat. If there is a change in the toggle bit, it's not a repeat. If you have an RCx remote that doesn't behave that way, then it's a violation of RCx protocol.

A.A.

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

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 general decoder (similar to WinLIRC), or I make a decoder for each protocol I'm going to support.

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

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 general decoder (similar to WinLIRC), or I make a decoder for each protocol I'm going to support.

Ok, now it makes sense why you're asking for leadout times for various protocols. The RC5 stuff is a special case in how repeats are normally handled, but you should be able to handle it using leadout times instead.

So, if you want to deal with repeats solely on the basis of leadout time, then you should look at the IRP definitions for the various protocols, as the leadout time is clearly indicated for each protocol. I should point out that there are some protocols that make use of "dittos" to indicate repeats. Dittos are usually a fairly short transmission compared to the initial first transmission on a button press and they follow the initial transmission as long as the user is holding the button down. It's another way of solving the repeat issue compared to what Philips did with RCx protocols. I don't know what the rules are for dittos with respect to leadout etc. For all I know, it may vary from protocol to protocol.

A.A.

The vast majority of protocols repeat the whole signal "as is" without dittos or toggles.

The main "ditto" protocol is NEC1 where the repeating portion of the signal contains no data, just a leadin and a leadout. For NEC, the leadout is calculated based on the total time of the signal, so the more "1"s in the data, the shorter the leadout time.

For your program to accurately handle all possible signals, you're going to have to write code to handle all the signals that have special handling, and then try to write some universal code to handle the regular protocols. And even then, as the leadout times vary a lot, you may need to add more special handling for those that fall outside of the normal times.

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.

Sure, here ya go...
http://www.hifi-remote.com/johnsfine/