I'm trying to understand how RC5/RC6 protocols represent button press, repeat and held-key behaviour, particularly when using Pronto Hex and IRPlus.
Although my immediate application is a Microsoft eHome receiver, I suspect the underlying question is really about RC5/RC6 protocol behaviour, so I'm hoping someone with knowledge of RC5/RC6, Pronto Hex or IRPlus may be able to help.
Background
I've been comparing RC6 commands from three different sources:
- the built-in IRPlus Microsoft MediaCentre library
- IrScrutinizer generated Pronto Hex
- learned IR captures
One thing I noticed is that many of the original IRPlus library entries consist of two Pronto Hex sequences separated by |.
The two sequences are similar, but not identical.
This raised a number of questions about how RC5/RC6 repeat behaviour is intended to work.
What I've observed
Using IrScrutinizer's Windows Keyboard JP1 definitions I've generated valid RC6 keyboard commands.
Discrete commands work correctly. For example:
- Alt+F4
- Alt+Tab
- Ctrl+Alt+Del
- Windows-key combinations
However, commands that rely on a genuine press-and-hold do not behave like the original hardware.
For example:
- Holding Esc on the original keyboard exits full-screen in many applications.
- Repeatedly transmitting the Esc IR command behaves only as repeated presses.
- Holding Alt while repeatedly pressing Tab cycles through all open windows.
- Repeating the Alt+Tab IR command simply toggles between the two most recently used windows.
I've experimented with:
- different repeat counts
- repeat frequencies
- hybrid Pronto sequences
- repeated transmissions
but haven't yet reproduced true held-key behaviour.
Questions
For RC5 / RC6 protocols in general:
- How are press, repeat and release normally represented?
- Is there any concept of a "key held" state within the protocol?
- Is the toggle bit involved in generating held-key behaviour, or is it intended only to distinguish successive button presses?
- When using Pronto Hex, should a held key normally be represented by:
- repeated identical frames,
- alternating toggle-bit frames,
- different repeat frames,
- or simply transmitter timing?
IRPlus question
Does anyone know how IRPlus implements repeated transmission?
Specifically:
- What does the
| separator actually mean internally?
- Does IRPlus insert any special timing between the two Pronto sequences?
- During a button hold, does IRPlus repeatedly transmit:
- the complete sequence,
- only the second sequence,
- or something else?
Debouncing / Toggle
I've also read that the RC5/RC6 toggle mechanism is used not only to distinguish successive button presses, but also as part of preventing multiple detections caused by:
- mechanical switch bounce,
- repeated IR transmissions,
- or reflections of the IR signal around the room.
If that's correct, could this also explain why simply repeating the same Pronto frame does not produce the same behaviour as holding a button on the original remote or keyboard?
Looking for protocol-level understanding
I'm really interested in understanding the protocol itself rather than just solving one application.
Any information on:
- RC5 / RC6 repeat behaviour
- toggle-bit implementation
- held-key semantics
- Pronto Hex repeat structure
- IRPlus transmission behaviour
or links to protocol documentation or previous reverse-engineering work would be greatly appreciated.
Thanks!
I'm trying to understand how RC5/RC6 protocols represent button press, repeat and held-key behaviour, particularly when using Pronto Hex and IRPlus.
Although my immediate application is a Microsoft eHome receiver, I suspect the underlying question is really about RC5/RC6 protocol behaviour, so I'm hoping someone with knowledge of RC5/RC6, Pronto Hex or IRPlus may be able to help.
Background
I've been comparing RC6 commands from three different sources:
One thing I noticed is that many of the original IRPlus library entries consist of two Pronto Hex sequences separated by
|.The two sequences are similar, but not identical.
This raised a number of questions about how RC5/RC6 repeat behaviour is intended to work.
What I've observed
Using IrScrutinizer's Windows Keyboard JP1 definitions I've generated valid RC6 keyboard commands.
Discrete commands work correctly. For example:
However, commands that rely on a genuine press-and-hold do not behave like the original hardware.
For example:
I've experimented with:
but haven't yet reproduced true held-key behaviour.
Questions
For RC5 / RC6 protocols in general:
IRPlus question
Does anyone know how IRPlus implements repeated transmission?
Specifically:
|separator actually mean internally?Debouncing / Toggle
I've also read that the RC5/RC6 toggle mechanism is used not only to distinguish successive button presses, but also as part of preventing multiple detections caused by:
If that's correct, could this also explain why simply repeating the same Pronto frame does not produce the same behaviour as holding a button on the original remote or keyboard?
Looking for protocol-level understanding
I'm really interested in understanding the protocol itself rather than just solving one application.
Any information on:
or links to protocol documentation or previous reverse-engineering work would be greatly appreciated.
Thanks!