Yes, the quoted text that Andy shows is an accurate description of the purpose of the toggle bit. The bit changes when a new transmission starts and stays constant as long as the same bit remains pressed. It however has more value than just moving your hand in the way of the IR beam. It is not uncommon for an IR detector to "miss" detection of some percentage of the received pulse sequences when a button is being pressed. This can be caused by light interference, IR bounce off the walls, or operating at extended distances from the transmitter. The toggle bit protocol can make the receiver way more insensitive to momentary code dropouts.

Note however that when you design a receiving protocol for an IR controller that there is a need to do more work than just a decoder in order to make a robust design. The next layer of code in the receiver above the decoder level needs to be rather "smart". Several things need to be addressed, such as:

1) Has another code of same value arrived within the nominal repeat time from the control....

2) Has it been a certain minimum length of time since the last same code has been received....

3) Has it been a certain minimum time since there has been a new code received from the control...

These come into play because most IR controls transmit repeats at 10 times per second (and some newer ones that are meant to control a cursor on a computer screen may repeat at rates like 30 or 40 Hz) and this needs to be taken into account in different ways depending upon whether the receiver output is being used as a single shot input function or whether the input function is being used in a repeat manner such as scrolling or volume control.

In the case of the single shot type input, i.e. typing a digit into an entry buffer like say "channel" number, it is desireable for the software to ignore repeats of the same code until it seems that the user has interntionally released and pressed another button (or the same one).

This is important for a scroll function because it is necessary to usually not respond at the full 10 Hz input rate but instead at some slower rate like 2Hz or 1Hz. Unless you watch the input repeats carefully the sub-divided rate for the scroll function may get confused if the user is pressing and releasing the button quickly. (You see in some designs this may want to mean something different). It is also common in a scroll application to take the initial step action when the first detect is made but to then ignore further detects for 0.5 -> 0.6 seconds before then beginning to accept inputs at a faster rate. However it is still desireable to detect properly that the user may be interntionally pressing and releasing the button at say a 0.2 second rate.

Hope this helps.
Michael Karas