This section explains the complicated world of IR signalling and how you live in it with Slink-e. We first describe IR signalling itself, without reference to Slink-e. Then we describe how to translate between an IR message and the Slink-e port message data that represents it. Port message data is what you see at the Slink-e programming interface, whereas the IR message itself is what you see at the Slink-e connector/emitter/sensor.
This section is not about Slink-e. It gives you background on how infrared light (IR) signalling works that you need to know in order to understand the Slink-e programming interface. It also introduces terminology essential to our specfication of the Slink-e programming interface.
This section is specifically about the kind of IR signalling used for wireless handheld remote controls, for example for A/V equipment. Infrared light is used for lots of other signalling purposes (example: some wireless headphones), but this section does not apply to them.
I am not aware of any published standards for any part of the IR signalling protocol I describe. So can't refer to the protocols by name or specify exactly what equipment to which this description applies.
We will speak in terms of a "remote," which is essentially a handheld remote control device that transmits IR signals and a "component," which is a piece of remote controlled equipment such as a VCR that received IR signals.
The IR signalling protocol has lots of different layers. We will start at the top and work our way down to the actual photons.
An IR message is a particular sequence of infrared light in time and space. Note that as I've defined it, if you press the Rewind button today and again tomorrow, it's two different IR messages, even though the light generated may be identical.
In its quiescent state, a remote does not send any IR message.
When you press a button, a remote sends a continuous stream of IR messages while you hold the button down. For some components, this is a stream of identical IR messages, for others, the first IR message indicates which button was pressed and each subsequent IR messages is a generic IR message indicating continuation. For details, see Repetition.
There is a component code associated with each component. This component code is a bit string, usually 5-24 bits. The component code is a characteristic of the model of the component, which means it isn't unique to a piece of equipment. Two VCRs of the same or similar model have the same component code. (comment)
Each button on a remote has a command code associated with it. The command code is a bit string, usually 5-24 bits. These codes are not standardized in any way; What means "rewind" for one VCR could mean "power on/off" on another. The command code is usually long enough that there are way more possible command codes than implemented ones. That provides some measure of protection against corruption of IR signals generating unintended commands.
An IR code is a bit string formed by concatenating a component code and a command code. For most components, the component code goes first. But in some components, notably Sony components, the component code goes last.
An IR code gets delivered from a remote to a component by an IR message.
It is highly unfortunate that component codes correspond to models. It is the reason you can't own two VCRs of the same model and place them in the same room. It amazes me that even makers of expensive A/V equipment have never, that I know of, provided a switch to set the component code. It is also an opportunity to use a Slink-e. You can have two identical VCRs next to each other, and glue a local IR emitter to each one. Attach the two local emitters to different Slink-e zones. The computer that's driving the Slink-e now can command the two VCRs independently. Now get a remote for a different VCR model. Place an IR sensor near the VCRs and connect it to the Slink-e. Now you just have to program the computer to accept messages from the remote and relay them to the proper one of the two VCRs. You could define a key on the remote to select one or the other VCR.
An IR message consists of on and off pulses, arranged in segments. An IR message starts with a head segment, then a segment for each bit in the IR code, then a tail segment. The composition of the head and tail segment, and of a segment that represents a 1 bit in the IR code and of a segment that represents a 0 bit in the IR code, is a characteristic of the component. It is the same in all messages defined for the component.
The head segment is an on pulse followed by an off pulse. The durations of the pulses are a characteristic of the component. A segment that encodes a 1 bit of the IR code is an on pulse followed by an off pulse. The durations of the pulses are a characteristic of the component. Ditto for a 0 bit. The tail segment is unusual in that it is just a single on pulse. Its duration is a characteristic of the component. Notice that no segment begins with the same kind of pulse (on/off) as would come directly before it, since there is no such thing as consecutive pulses of the same kind.
The pulses in the head segment are typically much longer than any other on pulse in the code.
With some older components, there is no head segment.
There is an off pulse before and after every IR message to delimit the message (Note above that every IR message starts and ends with an on pulse). Such a pulse is known as an intermessage pause. An intermessage pause is not part of any message and the same off pulse serves as the intermessage pause after one message and the one before the next message. An intermessage pause has a minimum duration, but no maximum. The minimum duration of an intermessage pause is a characteristic of the component. It is longer than any off pulse that would appear within an IR message for that component.
An off pulse is absence of a signal. That's why the encoding is so complicated. Absence of a signal can be caused by lots of things besides a remote trying to transmit an off pulse. Someone could walk in front of the component. The remote could move. The signal might just be really weak and randomly fall below the detection threshold. Requiring a sequence of on and off pulses ensures the component can tell when it receiving a real intended signal.
An on pulse is more complicated. You might think an on pulse would just be the presence of infrared light. The problem with that is that infrared light is present all the time. If there is anything warm in the room, there is infrared light, and it pulses as things turn on and off and obstacles move around the room. So instead, an on pulse is an interval (in time) of infrared light intensity going up and down in a high frequency square wave. The on and off pulses are said to be riding on a carrier wave, and the frequency of the wave is known as the carrier frequency. The carrier frequency is typically 40 KHz.
A message's on and off pulses vary in length. The pulses are defined such that there is no such thing as two consecutive on pulses or two consecutive off pulses. The entire time from when the carrier wave becomes present to when it disappears is one on pulse, and the entire time until it reappears is one off pulse.
The length of a pulse is a multiple of the fundamental period, which is a characteristic of the component. A typical fundamental period is 250 microseconds.
The wavelength of the infrared light is not part of the code. It is a characteristic of the LED that generates the IR signal and the phototransistor that receive it, and is the same for all IR equipment.
The amplitude of the carrier wave is not part of the code. It must be great enough that a component can sense it, and not so great that it saturates sensing equipment, but other than that, it can be anything.
There is some evidence that for some components, an IR message consists of everything described above, repeated a certain number of times with long off pulses in between repetitions. Each repetition goes all the way from head through tail. I've seen a program that does that.
But I think it may be that these are really multiple IR messages and the long off pulses are really intermessage pauses and the program I saw was merely sending the message multiple times for safety.
Some buttons on a remote need to deliver more information than just that the button was pressed. They have to tell the component that they continue to be pressed. Think of a fast forward button on a VCR remote control. Often, the VCR fast forwards while you hold the button down and stops when you let the button up.
There are two ways remotes convey this information: repeated messages and special continuation messages. Some components use one, while other components use the other.
In the simpler case, the remote just sends a continuous stream of IR messages (separated by minimal intermessage pauses) while the button is pressed. Each IR message contains the same IR code. A component distinguishes between a continued press and two separate presses by the time between messages. If it is much more than the minimum intermessage pause period, the component assumes it is a separate button press.
In the other case, the code defines a continuation message. A continuation message is a special IR message. After the remote sends the regular IR message that says you pressed the button, it sends repeated continuation messages until you release the button. It sends them at a regular frequency, for example 10 per second. A continuation message does not contain an IR code. It is merely a head segment and a tail segment. And the head segment code is not the same one used for a regular IR message -- it is one that uniquely identifies the IR message as a continuation message.
As far as I know, all remotes provide continuation function on all buttons. They don't distinguish between a button for which continuation makes sense (e.g. fast forward) and one for which it doesn't (e.g. power on/off).
After IR signalling became popular for simple remote control, where a person sits on the couch and aims a handheld remote at a TV, people started wanting to exploit it for more complex control configurations. One thing they wanted to do was route IR signals in ways other than line-of-sight. A good example of this need is when you put your equipment inside a closed cabinet for looks. When you do that, you lose all ability to point a remote at it. Another example would be where an audio receiver is one room and the speakers and people listening are in another room.
So Xantech invented a means of tunneling IR signals over a wire. With simple IR receiver and transmitter equipment, you could point your remote at a Xantech receiver and press a button. The receiver would transform the IR signal into an equivalent electrical signal and send it out on a wire. The wire would go to another room, or inside a closed cabinet, to a Xantech IR transmitter. The transmitter, with line-of-sight access to the component, would reproduce the exact signal that originally came from the remote.
The Xantech electrical emulation of IR is about as straightforward as you can imagine, and is implemented in simple electronic circuitry. Voltages on the wire correspond to intensities of infrared light.
The Xantech protocol has a bus architecture, which emulates the way real IR works: an IR signal fills the room. So you can connect multiple IR receivers and transmitters to a single Xantech wire.
This wireline transmission of IR messages brought about the concept of IR zones. An IR zone corresponds to one of these Xantech wires. More abstractly, a zone is a domain in which IR messages exist. Every IR message belongs to a zone. Every IR receiver in a zone receives every IR message in the zone, but no IR messages in any other zone. No two IR messages can overlap in time in the same zone, but you can have simultaneous IR messages in separate zones.
Of course, you can perform routing, which means turning an IR message in Zone A to an IR message in Zone B, or multiple IR messages in multiple zones. Slink-e has a built-in routing facility (see Set IR Routing Table, or you can do it directly via the programming interface.
Note that the Slink-e's IR port speaks the Xantech protocol, in Zones 1-6. In Zone 1, it even implements the physical connector specified in the protocol. In Zones 2-6, it is electrically Xantech, but you need additional hardware, for example Nirvis's expansion adapter, to get the Xantech physical connectors.
S-link Control-S is a protocol, like the Xantech one, for representing IR messages on an electrical wire. It is slightly more removed than the Xantech protocol from an actual IR message in that it never uses a carrier: on and off pulses are represented by continuous respective voltages.
Note that the Slink-e's IR port speaks S-link Control-S in Zone 7.
To get true S-link Control-S out of the Slink-e, you must explicitly set the IR port to have no carrier.
The Slink-e can generate or recognize any IR message, within various minimum/maximum constraints, that exists under the protocol specified above. Unfortunately, some of the signalling parameters have to be set in the Slink-e in advance, which means you can't just receive any old IR message. If the message isn't of the kind you programmed the Slink-e to expect, you'll get garbage or nothing.
The Slink-e can also generate and recognize some sequences that aren't valid IR messages as defined above. The programming interface actually controls IR signalling at a level below IR messages. Though we usually say that a single Slink-e port message corresponds to a single IR message, you'll see that that's only true if you drive it right.
The operation of the Slink-e is really very simple. The Slink-e doesn't know anything about IR messages or head sequences or IR codes or anything. It knows how to generate or detect an off pulse and an on pulse. You can tell it to send any sequence of on and off pulses. In its quiescent state, it sends a continuous off pulse. On the receive side, the Slink-e samples the IR ether at regular intervals for the presence or absence of an on or off pulse and reports to you the pulses it detected. It considers prolonged off pulses to be the quiescent state and does not report those to you.
Note: The Slink-e has an internal 20 MHz clock that is the base for all timing it does in the IR port. You don't need to know this; I just thought it might interest you.
The Slink-e sends and receives pulses in sets called "pulse sets." A pulse set is a sequence of consecutive on and off pulses that the Slink-e treats as one unit. One port message on the IR port is one pulse set. As you'll see, you usually want to drive the Slink-e in such a way that one pulse set, and thus one port message, is one IR message. But remember that the Slink-e does not itself conceive of IR messages.
One parameter you have to set is the carrier frequency. You can set it as high as 2.5 MHz or as low as 2441 Hz. Use the Set IR Carrier Frequency command for this. You can specify only certain frequencies in that range, so you probably can't set exactly the frequency you want. But if you can get within a few hundred hertz, you should be OK. Detectors, including the Slink-e's, are not that picky.
If an IR message arrives at the Slink-e IR port with a different carrier frequency than the Slink-e is set for, the Slink-e either won't receive it or will receive it wrong.
You can also turn the carrier off altogether with the Set IR Carrier Frequency command. When you do that, an on pulse is just continuous presence of infrared light. This is pretty useless for true IR signalling (and doesn't implement the IR signalling protocol described above), but is required for S-link Control-S pseudo-IR signalling and may be useful for weird applications of the Xantech bus.
The Slink-e sends and receives pulse sets based on an internal sample clock. You set the period of this clock, known as the IR sampling period, with a Set IR Sampling Period command. You can set it as low as 50 microseconds or as high as 1 millisecond.
On the send side, the sample clock determines the resolution with which you can generate on and off pulse durations. Every on and off pulse the Slink-e generates lasts an integral number of sample clock cycles. An ideal choice of clock cycle would be the fundamental period of the IR message you are sending. But any factor of that would be fine, and if you want to send IR messages that have different fundamental periods without messing around with the sample clock, you have to choose a sample clock period that is a common factor all the fundamental periods.
On the receive side, the Slink-e samples the IR signal at the start of each sample clock cycle to determine whether an on pulse or an off pulse is in progress. It delivers the raw results of these samples to you via the programming interface. So in order for you to know exactly what message was sent, you have to 1) know the fundamental period of the IR message, and 2) set the sample clock period at least as short as the fundamental period. This isn't as onerous as it sounds, because if you set the sample clock period very short, you can usually figure out by looking at the samples what the fundamental period is -- at least close enough that you can correctly extract an IR message from the pulse set and the IR code from the IR message.
So it is common to set the sample clock period very short when learning the IR signalling protocol of a new device, and longer after that. The advantage of a longer period is that there is less port message data to transmit.
How does the Slink-e decide which pulses it receives belong to which pulse set? I.e. where does one pulse set and and the next begin? Answer: the timeout period. When the Slink-e sees a very long off pulse, it makes the previous on pulse the last pulse in the previous pulse set, and the next on pulse the first pulse in the next pulse set. The very long off pulse itself is not in either pulse set. Note that pulse sets always begin and end with an on pulse.
And what does "very long" mean? It means longer than the IR Timeout Period, which is a parameter you set with a Set IR Timeout Period command.
Recall that IR messages are delimited by long off pulses known as intermessage pauses. Obviously, then, you normally want to set the IR Timeout Period so that intermessage pauses also delimit Slink-e pulse sets. That way, each Slink-e pulse set corresponds to one IR message.
On the other hand, if you're trying to analyze an IR signal, it's nice to set the IR Timeout Period exceptionally long, so you can see multiple IR messages and the intermessage pauses all in one pulse set. That is how, for example, you could figure out just how long an intermessage pause is so you know what to set the IR Timeout Period to in the future.
Recall that a remote often sends a stream of IR messages when you hold down a button. If you set the IR Timeout Period very long, everything the remote generates from when you push the button to when you let it up (for a while) is one pulse set.
If you set the IR timeout period too short, the Slink-e can receive a single IR message as multiple pulse sets. And you wouldn't have any information as to how long the off pulses that separate those pulse sets are, so you could not easily figure out the IR message from the pulse sets. So don't do that.
There is an important thing to realize about how the Slink-e determines that a pulse set is in progress. Since the beginning and end of a pulse set are delimited by a long off pulse if there is continuous on pulse, the IR port will be in receive state continuously, receiving a neverending pulse set. And that means you will not be able to receive in any other IR zone or send in any IR zone. It might even make other areas of the Slink-e unresponsive. Now, it's unlikely that some failure could cause a continuous real on pulse (presence of an infrared carrier wave), but if you're working without a carrier, it's not hard. And if you reverse the receive polarity, it's even easier.
Note that there is no equivalent of the timeout period on the send side. The Slink-e does not explicitly generate an off pulse to separate two outgoing pulse sets. It is up to the programming interface user to generate an intermessage pause where necessary, either by specifying the off pulse in port message data or just by waiting between sending pulse sets.
The Slink-e maintains the IR timeout period in IR sample period units. That means when you change the IR sample period, you also change the IR timeout period.
IR noise is common. Apparently, even noise at a proper carrier frequency to fool the Slink-e happens. According to Nirvis, IR receiver modules such as the one in the Slink-e tend to be very sensitive to both optical and electrical noise, causing them to generate false pulses when there is no actual IR signal. I have seen one-pulse phantom pulse sets up to 200 microseconds long. Nirvis engineers apparently believe much longer ones are possible. But they never contain the large number of on and off pulses that a real IR message would have.
So the Slink-e has a facility to cause it to assume that a very short pulse set is just noise and ignore it. You specify this shortness threshold in the number of bytes of port message data it would take to describe the pulse set (see ), using the Set IR Minimum Message Length command.
"ignore" means they don't show up in any reports in the programming interface.
Alternatively, you could set this minimum to 1 and analyze the pulse sets you receive yourself (on the other end of the programming interface) to see if they look like noise.
You can reverse the polarity of the Slink-e's IR pulse receiver with a Set IR Receive Polarity command. That means Slink-e treats an on pulse as an off pulse and an off pulse as an on pulse. This would be crazy for a real IR signal or a Xantech emulation of one, but for the S-link Control-S emulation or some custom application of the Slink-e IR port, it might make sense.
OK, so lets say you know exactly what pulse set you want to come out of your IR emitter. How do you explain that to Slink-e in port message data? Likewise, when Slink-e feeds you a bunch of port message data for a received IR message, how do you know exactly what pulse set the Slink-e saw?
Recall that port message data is the data you send to Slinke via the programming interface's Send Port Message commands. The port message, on the other hand, is what actually comes out of the Slink-e, which means electrical pulses for Zones 1-7 and light for Zone 0 (we consider the plugged in IR emitter to be part of the Slink-e). A port message, therefore, is not just data. It's electrons and photons. For the IR port, a port message corresponds to a pulse set.
Also recall that the port message data for a port message can be spread across multiple Send Port Message commands or Port Message Received reports. Here, we don't care about individual commands and reports. We're just talking about the port message data as a whole.
The port message data is a description of a pulse set. Each byte describes a period, in time sequence, of on time or off time. Consecutive on time is an on pulse and consecutive off time is an off pulse. In a simple case, there is simply one byte per pulse. The only problem with that is that there is a limit to how long a period a single byte of port message data can describe. If a pulse is longer than that, you need multiple bytes of port message data to describe a single pulse.
The first bit of a byte of port message data tells whether the byte describes on time or off time. 1 means on; 0 means off. The remaining 7 bits give the duration. They are a pure binary encoding of the number of Slink-e sample clock periods.
In received port message data, the Slink-e includes part of the long off pulse that marks the end of the pulse set. It includes as much as the Slink-e watched before deciding that the pulse set was over -- i.e. the duration of that long off pulse is the IR Timeout Period.
In port message data for sending, you can include an off pulse as an intermessage pause at the end if you like, or you can implement it just by refraining from sending the next IR message for a while. It has the same effect, since the Slink-e sends a continuous off pulse whenever it is between pulse sets. You'll generally find it more convenient to include the intermessage pause explicitly.