Skip to content

RC5 / RC6 toggle-bit, repeat and debouncing behaviour #765

Description

@Jason-R1

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!

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions