Serial (RS232) and IRDemonstration system for

the CommandFusion

iViewer

Copyright © 2012Barry V. Gordon

1

Purpose:

The purpose of this system is to demonstrate a way in which to develop CommandFusion (CF) systems. It is the methodology I use for my own personal projects. It is oriented towards a person who has a basic understanding of the CommandFusion model (using guiDesigner and iViewer) and has some familiarity with programming in Javascaript or at least some modern (object oriented) computer programming language. I have attempted to make it easy to understand by annotating the code and providing in this document a description of how the system operates. The system consists of Javascript code modules and display pages.

The display pages are for the control of a single device e.g. a DVR, and include buttons for the control of some of the device's functions. The device control pages are incomplete but just serve to provide a mechanism to exercise the Javascript code. I did not spend much time developing quality graphics but chose rather to concentrate on the code and making it easy to understand.

In all there are seven Javascript modules. There is a Javascript module for each major function,

1) The discovery of Global Cache devices and the assigning of a global cache device/module/zone to a specific device.

2) The control of devices that use the Sony protocol for serial RS232 Communications

3) The control of devices that use bidirectional RS232 serial protocol but not Sony's

4) The control of devices that use IR for control with no feedback

In addition there is a utility module, DemoMain.js, that supplies some common functions, contains the userMain functions and several useful subroutines for the editing and display of communication oriented data (Text strings). There is also a module, DeviceDriver.js which coordinates the specific device modules for IR, RS232, and Sony serial communications.

Note: The Sony RS232 protocol is broken out from all other RS232 protocols due to its complexity and the degree of feedback it provides.

Disclaimer:

The system has not been rigorously tested. I have some devices I am able to test with but do not wish to rip apart my Theater to test each of the devices I use. I take no responsibility for how the system is used or what effect it may have on your components/devices if mis-used.

The program is provided as is. No warranties of any type expressed or implied are provided. I will provide reasonable support as my schedule permits and answer question posted to my personal eMail account (barry@the-gordons.net). I am retired and I do this for fun so I generally have time to play. Unfortunately I do not own every piece of gear so there may be many

2

instances where I cannot tell you what is going wrong. The whole purpose of the program is so that you can figure it out!

Feedback is appreciated. Criticism with explanation is accepted and appreciated.

3

A Little About Me

I am a retired 72 year old widower. I had been in the digital world (hardware and software) for my entire career. I have always been technically oriented but recognized that the money was in management. I ended up in management at an early age, but always managing technical things.

During my college years (I have a Masters degree in EE) I was an electrician and member of the powerful IBEW union of New York. I worked part time and was in charge (foreman) on many of my jobs by my junior year.

I started my career as a programmer in 1960 working for the Sperry Rand corporation. A corporation, unfortunately, known for snatching "defeat out of the jaws of victory" (IBM vs. Univac mainframes).

I have been programming longer than many of the people I deal with have been alive. I started my career as a programmer in 1960. After learning the rudiments of the craft I started reading books , actually journals since books were not yet being written, on the subject. I became interested in what was then called Systems Programming which was the construction of tools to aid in the development of programmed systems. We now take these tools for granted, but in the early sixties they did not exists as commercially available entities. I wrote assemblers, compilers and emulation systems for about 5 years. The work was done on an IBM mainframe which had 64 kilobytes of main memory (36 bit words IIRC) so to be technically correct I was developing cross assemblers and cross compilers. Object oriented programming had not yet come about but all the good programmers understood the principles of data encapsulation, subroutine usage, and shielding innards from view. We referred to things being "architected" meaning the inner workings and data structures were exposed and documented. If a thing was not architected it was merely described as a closed system; an "object"; and documented only at the interface level.

In the early 1960's I was a member of the team that developed GPS for the Atomic Submarines. The first GPS system's equipment suite cost over $3,000,000 and was contained in two cabinets each 2' by 2' by 6'. We've come a long way baby!

My hobbies include Home Automation, and woodworking. I have a full woodworking shop in my home and the house has its own separately air conditioned "Server Room". I have consulted to several of the firms in the A/V business among them being DVDO (iScan video processors) and Philips (the Pronto line of remote controls).

The house was designed by my late wife and myself. We then acted as the General Contractors using a real GC to handle the license issue. If you are interested, browse the web site you got this from to learn more.

4

Getting Started and my Coding Style:

I organize my CF projects into one folder per project. The project folder has subfolders called Documentation, Javascript, Resources, and sometimes additional folders for supporting objects. The main project folder contains the .gui module for the project [Note: For some reason guiDesigner wants its JS modules in the same folder it is in. I resolved this issue by editing the projects .gui file and changing the script entries to point to the folder the script modules were located in]. I have been able to resolve and "fix" several issues by dealing with the gui file directly using a simple text editor. I use TextPad, a free editor with many useful features.

I keep my project folders in a master folder on my web server. This folder is not accessible external to my LAN and is where all my iPads go to load their systems.

Each project has one JS module (call it the Main module) that is written in "pure JS" and not as a large object. This causes things in that module which are externally available to be named directly without the need of a prefix representing the module itself, actually the object in which all parts of the module exist. This module normally contains the userMain function, event handlers for page flips, iPad resuming from sleep, and preloading completion. The userMain function sets up "watches" for the three major events mentioned.

The main page defines global debugging variables which control printing to the CF.log.

Lastly, the main page contains many functions I have found to be useful in much of the code I write. Most are simple one liners, but some are more complex e.g. showHEX which displays any text string as a sequence of hex characters. This is very handy for viewing communications messages).

All other modules (call them the Work modules) are written as a single object encapsulating all the functions and data elements used by that module. This means that all functions and data elements defined in that module need to be referenced using the module prefix as the object name. For example, the DeviceDriver module is contained in an object variable named DD [Note: I generally use two capital letters to name the object]. Ergo to access this modules initialization function one would write DD.initialize(). This technique, which is recommended by the CF team, allows each module to have the same functions with no naming conflicts. Following the modules encompassing object definition a single line of code exists which is used by CF to instantiate the module and call its setup function if required.

The work modules supply supporting code to one or several pages. They have certain functions that I provide in every module with well defined operational characteristics. The key functions are:

setup: Called by CF when the module is loaded. This function should perform minimal work as the system is not yet fully loaded. One of the global trace variables in the Main

5

module will enable the single line I always include in this function which merely displays that the modules setup has started in the CF.log.

initialize: Initializes the module. It is normally called when a Page that uses this module is loaded (page flip event).

startup: Used in the same manner as the initialize function. It is there for modules that may require a two step initialization

restart: Similar to the startup function but is normally called by the gui Resumed event when the iPad wakes up after sleep.

feedback: The function that handles feedback from a system that is capable of two way communications. I generally code the feedback regex associated with an external device as (^*) which allows any string of characters and is equivalent I am told to (*) or (.). This presents to the modules feedback function the text received from the device up to that point in time. It should be noted that when dealing with RS232 and interface devices such as Global Cache units or the Xeta server (A single port TCP/IP to RS232 interface) a message may not arrive in a single packet. If the message protocol does not use a terminating sequence (The SONY serial protocols do not) Then code must be used to ascertain when the full message has been received and to validate its content.

actions: The function that handles user actions such as button presses.

timeout: Called when a timer associated with a message transmission times out waiting for a reply (feedback).

reset: Called when the communications system needs to be reset to start looking for another reply.

send: The function to send a command (or possibly resend) a command to an external device. the send function is responsible for enveloping the message in any necessary control characters and starting the transmission timer.

Other functions are included based upon the needs of the pages/devices being supported.

6

Control Tables:

Each of the three Javascript device handlers; IR_Devices.js, Sony_Devices.js, and RS232_Devices.js; must be able to access an array named devices (IRP.devices, RS.devices, SD.devices). In the case of the IR devices I chose to break out the IR tables into a separate module with the Prefix IRP for clarity and to keep the IR device control module simple. These device arrays contain multiple object, one object for each device of that class.

I try to write most of my code to be table driven. This demo system is mostly driven from tables that are external device (component) related. There is a table like that in the device Driver module that defines all of the external devices that the system will control. It is used to set up the discovery page and allow for the configuration of an associated device table used by either a Sony device, an RS232 device, or an IR device. This overarching device table is dynamically built based upon the specific device tables in the other modules.

In each of the modules that support a class of devices (Sony serial, RS232, IR) there is an array of device objects that defines all of the parameters for talking to those devices. A single device object has several items that describe the device and its configuration and an array of commands. The devices items include its model (assuming models are unique among devices) configuration parameters (IP, Port, Zone) and any other needed items such as volume range for a slider. Obviously the items in these objects could be augmented as the needs of the external device and its control pages require.

The commands are kept as an array in the case of IR or as an object in the case of serial devices. In either case the modules code that supports the device understands the device object construction. The device object is initialized when the page is flipped to so that once a particular page is active (visible) the supporting code module knows which device to use at that time.

As you can imagine IR is the simplest class to handle, but time consuming to construct by hand. My web site also contains a program called IRGen which will build a JSON object in precisely the format that this system needs. It will build the IR object from data it has stored in tables in its .ini file. The .ini file is extensible and one of the formats is Pronto Hex

At the current time only the send side is fully table driven. The receive side (feedback) is handled through code. I will be changing this as time permits as I have it with table driven send and receive (feedback parsing and analysis) in other systems I have developed.

[ Note: Commands in the IR device tables are structured as an array since the IR device demonstration page uses lists for the user to select the command thereby providing an integer index for retrieval. In the other device tables the commands are kept as an object using the name of the command (a string) to retrieve the actual command bytes to send. This in effect makes the object an associative array where indexing is by text as opposed to an integer. ]

7

In order to build the overarching device table in the DeviceDriver module, every specific device table must contain the following items:

Class: IR or RS232 or Sony.Manufacturer: The name of the manufacturer of the device.Model: The name of the specific model of the device.Description: A brief description of the device e.g. "A/V Processor".Page: The name of the Page that handles this module.Interface: Either an IP address of the form xxx.xxx.xxx.xxx:port, or the word GlobalCache

if this device will be connected to a global cache interface unit.Connector: A global Cache connector designation if needed, but should be included to avoid

an undefined reference.

In addition the following items should be included as part of the device object:

EOM: An end of message character or sequence for replies IP: The IP address for this device if known Port: The Port address for sending commands to byteCount: Holds the byte count for replies that use a byte count for message parsing Input: Accumulates the text of a reply as it comes in. lastSent: The last command sent to be used if a resend is required Attempts: The number of retransmission attempts made to send this message. Timer: The join number of the timer that is used to time command transmission

e.g."a8813".

There may be other items necessary for a specific protocol. The concept is that all of the working storage needed by a device handler will be placed into the device table for the device being handled.

Revision to IR subsystem:

All IR tables are now in a separate module

IR objects no longer need entries for the page, PGI, or timer

All IR devices are handled from a single page using lists to select the device and the command

It is assumed that all IR devices will be connected to the same TCP/IP to IR converter (e.g. iTach) at the same IR port number. Good practice would be to connect the iTach to an amplifying connecting block to distribute the IR signals if more than two IR devices are being driven. Remember, this is just a demo system

8

RS232 Communications (briefly).

RS232 communications are a mystery to many, but are actually quite simple, especially if you disregard error states. I wrote a paper last year which is basically "Communications 101" for RS232 based work. If you have only slight experience with RS232 communications I strongly suggest your reading it.

Cabling: If you are totally unfamiliar with cabling between devices that communicate using "RS232 protocol" or more correctly called "Serial protocol", please read "Communications 101". It explains it all in one place with diagrams and examples. 50% of all serial communications problems with beginners are related to cabling issues and a bad or poorly understood document describing the protocol (rules) being used to communicate.

Sending: In general sending is not an issue. You just need to construct a proper string based on the requirements (protocol) of the device you are talking to. Constructing a proper string is a more difficult and confusing issue. It is well discussed in the referenced paper. Javascript supplies several mechanisms to assist in this endeavor:

String.fromCharCode(); This method produces a valid string from a set of comma separated arguments. The arguments are the indices of the character desired in the ASCII character set; e.g. a=String.fromCharCode(66,97,114,114,121) sets the variable a to the string value "Barry" (without the quotes naturally).

"\xNN" is the proper Javascript notation for a hex byte where NN are the two hex digits that make up the byte.

As a matter of practice I usually define any fixed sequences of 1-n bytes that may be needed and give it a sensible name. E.g. var STX="\x02"; or var STX=String.fromCharCode(2);

Receiving: This is a much more difficult issue, especially if the Protocol is, IMHO, badly designed (e.g. Sony RS232 protocol). I generally use a feedback regex that passes all received data (^*) to the device handlers feedback processor which I tend to call "feedback". Since the regex captures whatever comes in; the feedback process gets whatever comes in as it arrives. [NOTE: A full message may arrive at the feedback processing function in pieces with arbitrary timing between pieces and all sorts of noise destroying bytes of the message, rare but it does happen, the noise that is].

Many times for simple protocols (those with a valid terminating sequence such as CRLF or CR or just LF) it is just as easy to define a regex that captures all up to the ending sequence and then provides the message as a single complete chunk. CF does the assembling of the chunks

For the Sony RS232 protocol the problem is that there is no ending sequence. The message normally has a fixed starting character and a byte count (there are two exceptions however)

9

which, along with the included checksum, allows one to reasonably determine the message content or reject it as non compliant (garbled by noise).

There are several Javascript aids that make life easier when parsing the content of a message. The two methods charAt() and charCodeAt() each take as arguments an integer which is the position of the character in the string that is to be retrieved [Note strings are indexed starting at zero (0) for the first character position.]. The charAt(n) method returns the single character as a string, while charCodeAt(n) returns the ASCII index of that character as an integer. As an example if var a="Barry"; then var x=a.charAt(0) sets x equal to "B" as a string, while var x=a. CharCodeAt(0) sets x to the integer 66.

The DemoMain.js module has some interesting utility functions that are a great aide in understanding what has been received. The function showHEX(a) when applied to a string will return a new string that contains the value of the hex representation of each character of the string. As an example if var a="\x02Barry" (I actually prefer "\x02"+"Barry" for clarity) then showHEX(a) produces the text string "02 42 61 72 72 7A" while the similar function showCOM(a) would have produced the text string "(STX)Barry"

Strong vs. weak protocols

A strong protocol is robust in the presence of noise and accounts for message duplication and acknowledgement. The following are attributes of a strong protocol (Opinion not fact):

A uniquely recognizable starting sequence e.g. the STX character ("\x02")A uniquely recognizable ending sequence e.g. a CRLF sequence ("\r\n" or \x0D\x0A")A way of sending binary data that prevents aliasing to the starting or ending sequencesAn identification field that marks a message and its associated reply so they can be correlatedA checksum to detect the majority of errors introduced by a noisy channel

The ASCII code set reserves the first thirty two character definitions for control codes. If only ASCII text is to be sent then the start and end sequences may be chosen from this control set with no aliasing. If binary data is also to be sent then there are control codes to allow for marking the start of binary data (codes arbitrarily in the range of 0-255 (\x00 to \xFF) and the end of binary data. It is strongly recommended that in protocols which transmit binary data that a byte count be included along with a checksum.

If the protocol allows for unsolicited messages, that is, data from the device that is not a reply to a command, the feedback processor becomes a little more complex. A reasonable approach in that case is to assume all replies are "unsolicited" and after validation determine if a reply was in satisfaction or acknowledgement of a command, that is a reply was expected and it is received..

10

Handling Communications:

In what follows a "Command" is a message to a piece of external equipment while a "Reply" is a message from the external equipment. A reply is sometimes referred to as "feedback".

What makes a communications protocol strong? By strong I mean the ability to detect valid messages, reject messages that may be garbled (noise) and ignore duplicate transmissions that are unintentional. Unfortunately very few protocols used in serial (RS232) communications are strong; On the other hand the RS232 communications media (wires) is fairly error free.

I break feedback into two main classes; those that are terminated with some fixed sequence of characters and those that are not.

If a feedback (reply) is terminated with a fixed sequence of characters such as carriage return ("\r") or line feed ("\n") or some combination of characters such as CRLF ("\r\n") then I use a regex that matches all characters strings terminating with that sequence. The Anthem AVP50v protocol states that all messages from the Anthem to a host controller will end with a line feed so the regex would be (\n$).

If the reply does not end with a specified sequence but rather uses other methods such as a byte count then a different approach must be used. The Sony protocol is of that type. Fortunately the first byte of a reply in the Sony protocol is always a unique character; except for two special cases of single byte messages. The second byte of the message is the byte count and the last byte of the message is a checksum to allow detection of many errors introduced by noise. In this case the system just accepts all characters that arrive using the regex (^*), or using the regex (^[\x02\xFD\xFE]) which matches all strings that start with one of the 3 possible legal start characters.

In either case, a regex of (^*) may always be used. Since that regex accepts all characters that arrive, all of the logic for message assembly and the detection/validation of a message must exist in the function that processes the feedback (reply) string. The logic must accumulate characters as they are passed by the CF system to the designated feedback process as defined by a "CF.feedbackMatchedEvent()" command. Doing so in the case of a regex that itself detects an end of message sequence does no harm. That is, assuming a message arrives in packets is the safe case. I do that for all of the feedback processes in this system.

The Sony device handler (SonyDevice.js) has a feedback process that is quite complex. It assembles the message as chunks/packets arrive. It detects the start of a message, isolates the byte count and collects characters until the byte count has been satisfied. It then validates the checksum and if correct, declares that a message has been received. If the checksum is incorrect it retransmits the command assuming that the reply was garbled. This is not always an acceptable methodology since for some commands the repeating of a command might produce undesired results. For example a Mute command which toggles the Mute state does nothing if it is repeated due to a garbled reply. A stronger protocol methodology would include an identifier byte (a

11

monotonic increasing integer modulo some number) in all commands so that duplicate transmissions could be identified and ignored. The Global Cache series of devices use this technique.

The Sony feedback processor is built as a finite state machine with only 3 states:

1. Looking for the start of a message (\x02, \xFE, \xFD). In the case of \xFE or \xFD the message is complete (ACK or NACK of a simple command). and the state does not change since we are looking for the next message

2. Waiting for and processing the byte count which is the byte after the \x02 (STX) in a normal message.

3. Accumulating characters until the byte count has been satisfied

There is logic associated with each state and the next character or some message condition that determines the next state and/or any processing to be performed.

In addition to handling the replies, the system times the transmission of every command that is sent while waiting for a reply. The system uses use a 2 second timer although one second should be more than enough. If a valid message is received the timer is aborted. If the timer expires then the assumption is that the command sent was not received and the command is sent again with a maximum retry of 4 attempts. This is not always a safe assumption in that a reply may be garbled in such a way as not to be recognized although the initiating command was accepted, acted upon and a proper reply was sent. hence a duplicate command may be sent.

12

Operational Flow:

The system starts by bringing up the Splash page.

The page is visible but nothing will take place until the preloading of cache images is complete. When preloading is complete, a 10 second countdown timer is started to allow the viewer to finish reading the splash page. A button is provided on the splash page to abort the timer and immediately bring up the discovery page.

The splash page is supported by the Javascript "DemoMain" module. This Javascript module is the "Home" module of the system. It contains functions used by all the other modules plus a set of subroutines that I have found useful in the work I do. It handles a simple userMain function. The userMain function sets up watches for the preloadingComplete event, the pageFlip event and the guiResumed event. It then clears the list that holds logged messages. This list is in a subpage that is visible on every page of the system except the Splash Page. Finally it runs the initialization process for the "DeviceDriver" Module. If you are a beginner to CF and JS, I strongly suggest you study this module as it is the simplest of all the modules.

13

The next logical page in the operational flow is the Discovery or "MainPage" .

The discovery page and its associated modules ("GlobalCache.js") purpose is to allow for the configuring of user components which are to be connected to interface devices that will provide a translation of media from TCP/IP (Wi-Fi) which the iPad uses; to RS232 or IR as needed by the selected component. The process starts by discovering any Global Cache devices that are present on the same network as the iPad. It uses the Beacon capability of the GC devices [Note: GC devices in the GC-100 family have to be of a recent firmware revision to do the Beacon operation. Global Cache will perform the upgrade for free but requires the unit to be sent to them]. The Beacon capability sends out UDP broadcast messages periodically. The discovery page listens for these transmissions for an elapsed time of 90 seconds maximum, or until a specified number of GC units have been discovered. The user should adjust this number (GC.count) to reflect the number of GC devices on their network. The user may stop this process at any time by touching the "Stop Discovery" button. Any preconfigured devices (e.g. Sony 7000ES) will show the information about the IP address that they were configured on, and have page selection buttons for each of them visible.

14

Once the GC devices are discovered a GC device may be connected to a component.

This done by first selecting the GC device, then selecting the specific module/zone of the selected GC device to be used, and finally selecting the external component. This selection must match the way the component is connected to a specific interface unit. Once the selection process is completed, a new button will appear on every page to transfer to the appropriate display page for the selected component. A maximum of 8 components may be selected/configured at one time as this is a demonstration system not a production system.

Once a GC device has been selected it can bet "Set" to any number of physical devices, or deselected as the active connection point using the "De-Select button.

Multiple devices may be "Set" to the same GC connection point as in the case of a multi-headed IR emitter. Touching "Set" on a device that has already had its connection defined will erase that connection and allow for a new connection to be made.

15

Here we see the selection process completed

The "All IR Devices" entry has been selected. Note the new button at the bottom of the page. Prior to selecting the IR Devices this button was missing. the other buttons were there because the devices the represent were pre configured with regard to IP address and Port information for the Interface units they were connected to.

16

A typical device page for a Sony class device using the Sony proprietary protocol for communications might look as follows:

Once a button is touched or the slider moved and released, a call is made to the supporting JS module's action routine SD.actions(arg1,arg2,arg3,arg4). Arg1 is the name of the command to be executed and is related to what has been pressed. Arguments 2-4 are as required by the specific action and are optional but must be included for those actions that need them.

The four text display frames are there merely to demonstrate the code. They are handy however when testing with any of the devices using an RS232 protocol as they show what is going on. The frames labeled "Send Data" shows what was sent and is in HEX notation. The frames labeled COM and HEX are the received reply to the sent command. The COM frame shows the data as follows:

Characters below 33 - shows the Mnemonic for the ASCII control code (e.g. "(NUL)"),Characters above 127- show as the characters index in parenthesis (e.g. "(158)",All others - show as the character themselves (e.g. Barry. . . )

17

The following page depicts a test and demo page for a device using RS232 (Serial) protocol of a simple nature. Usually with a fixed end of message sequence to make incoming replies much easier to parse:

It is very similar in layout to the Sony device page with the major difference being in the supporting modules function that handles feedback (replies). In general a feedback function would have to be tailored for a specific device, but using Javascript makes the parsing of a text string fairly simple.

Similarly the send function generally needs to be tailored specifically for the device and how it expects messages to arrive.

18

The device page for all IR controlled devices is as follows:

This is not a production system but rather a demo system to illustrate how things may be accomplished. In the case of IR, the system reads all the IR device tables located in the IR_Tables module and builds two lists. The first, "IR Devices" lists information about each device in the IRP.devices array. One a specific device is selected by touching its name (actually releasing the touch), the second list, the "IR Commands" is populated. If a command name is touched/released that command will be sent.

If the system is "Live", that is, there is an interface device on the network and the external device is capable of receiving IR streams from it; then the command should actually be executed by the external device.

The only reply will be from the Global Cache device itself not from the external system. IR is a one directional protocol from controller (e.g. IR Remote) to the device. The Global Cache reply is shown along with any specific issues encountered .

If there is a problem with the transmission to the Global Cache unit a message regarding that will be placed into the log file.

19

Log File: As the system is running key information is placed into a log file. Any page may display the log file by touching the "Show Log" button in the bottom left corner. A page with the log file displayed looks as follows:

The above page is merely reflective of what the log file looks like when I snapped a photo of the page. Things will change depending on what I choose to add or remove from the log file.

The log file is a subpage, as is the row of buttons on the bottom of each page and the middle frames showing the command that was sent with the received replies. . These subpages are assigned to every main page except the Splash page. The Button subpage is stated to be "always visible" in its subpage reference, while the Log file subpage's visibility is controlled by its digital join. The main page has the subroutines for controlling the log subpage (see the adjustLog function).

20

IR Based Control Systems:

Since I have chosen the CommandFusion system for the iPad as one of my control solutions I decided to look into what is required to do IR from the iPad. [Note: I do not actually need this capability since I always place a control system (PC) in the loop to do the "heavy lifting" be it bi-directional RS232 or transmit only IR].

I had developed a program known as IRGEN which will produce IR timing patterns and output them in various formats. The input to IRGEN is either a description of the IR protocol to be produced in a Meta-language that I developed with John Fine many years ago; or as Pronto HEX text strings which are IR Timing patterns in HEX format. Pronto HEX has become a sort of de-facto standard for the interchange of IR timing information.

A general IR Timing pattern, not targeted to a particular IR receiver must be able to state the frequency of the IR carrier and the timings (On/Off) necessary to modulate the carrier to provide the desired information.

In the vast majority of cases the information is coded as binary numbers, often represented in documents as decimal or hexadecimal integers. The information itself is almost always (for A/V devices as opposed to HVAC or fan and shade controllers) two numbers. The first identifies the specific external device or a generic class of device (e.g. Sony Generic TV, Pioneer VSX-1120-k) while the second provides a mapping to a function. A function is a key on a hand held remote normally supplied with the equipment being controlled.

The system is best thought of in terms of the original IR remote. The message sent indicates for which device it is for (the first of the two numbers) and which button was pressed (the second of the two numbers). The message is encoded in binary using the flashing of an IR emitter to indicate a one or a zero. Different IR protocols use different rules for what defines a "one" and what defines a "zero".

Sony for example uses an on-time of a fixed duration and one of two off-times to represent either a one or a zero. The entire message is "enveloped" in a special sequence that indicates the message is starting and ends in such a way that the message always takes a physical amount of time to transmit (45 milliseconds) .

The major drawback of IR is that it is unidirectional. There is no reply or feedback. If what is expected from a user sense does not occur, the button on the remote is merely pressed again.

21