Search by:
Wireless & IrSimple (TM) Connectivity!

Home Price Quote About Us Contact Us Order








 
-- IrDA Tutorial --

"IrDA-1.1 Protocol, System Integration and Testing"

ABSTRACT In 1996, IrDA-1.0

(SIR, 115.2K bps) standards were widely adopted after only two-and-half years of the formation of IrDA Association. A short one year later, we see the full range of products for IrDA-1.1 (FIR, 4M bps) standards appearing; components, adapters, software and mobile devices. The faster transfer rate (4M bps) and more complex bus interfaces make the FIR controller and system implementation more difficult. The integration of the IrDA-1.1 protocol stack into embedded-controller devices is also more complex and sensitive than IrDA-1.0. Additionally, the IrDA-1.1 feature designed into these devices may not easily meet the error rate and distance specifications. Effective and comprehensive testing software is needed for debugging and production testing.

IrDA STANDARDS

The Infra-Red Data Association (IrDA) was founded in 1993 to promote an industrial standard for Infra-red communications.

Currently, IrDA standard consists of three mandatory and many optional components. The three mandatory components are: Physical Layer, IrLAP Layer, and IrLMP Layer. The optional components are: TinyTP, IrCOMM, and many more.

PHYSICAL LAYER

The IrDA Physical Layer Specification sets a standard for the IR transceiver, the modulation or encoding and decoding method, as well as other physical parameters.

IrDA uses IR with peak wavelength of 0.85 to 0.90 m m. The transmitter's minimum and maximum intensity are 40 and 500 mW/Sr within a 30 degree cone. The receiver's minimum and maximum sensitivity is 4 m W/ (cm.cm) and 500 mW/(cm.cm) within a similar 30 degree cone. The link length is 0 m to 1 m.

There are three different modulation or encoding/decoding methods. The first one is mandatory, whereas the other two are optional.

For transfer rate of 9.6, 19.2, 38.4, 57.6 or 115.2 kbps operations, a start (0) bit and a stop (1) bit is added before and after each byte of data. This is the same format as used in a traditional UART. However, instead of NRZ, a method similar to RZ is used, where a (0) is encoded as a single pulse of 1.6 m sec to 3/16 of a bit cell, and a (1) is encoded as the absence of such a pulse. In order to have unique byte patterns to mark beginning and ending of a frame and yet allow any binary data bytes, byte stuffing (escape sequence) is used in the body of the frame. A 16-bit CRC is used for error detection. This asynchronous modulation method is sometimes referred to as SIR. The 9.6 kbps SIR operation is mandatory. Before any other optional data rates are used, the mandatory 9.6 kbps SIR must be used first to negotiate those options.

For transfer rate of 0.576 or 1.152 Mbps, no start or stop bits are used and the same synchronous format as HDLC is used. Again, a (0) is encoded as a single pulse (1/4 the bit cell) whereas a (1) is encoded as the absence of such a pulse. In order to ensure clock recovery, bit stuffing is used (same as in HDLC). The same 16-bit CRC is also used. This modulation method is sometimes referred to as MIR. MIR operation is optional, but before this option is used, the mandatory 9.6 kbps SIR must be used first to negotiate this option.

For transfer rate of 4.0 Mbps, a 4-PPM method is used. Like MIR, no start or stop bits are used. In addition, bit and byte stuffing are not needed either. A 32-bit CRC is used in this case. This modulation method is sometimes referred to as FIR. FIR operation is optional, but before this option is used, the mandatory 9.6 kbps SIR must be used first to negotiate this option.

Details of the physical layer are specified in IrDA publication: "Serial Infrared Physical Layer Link Specification". Current version is Version 1.1 dated Oct 17, 1995.

IrLAP LAYER

The IrDA Link Access Protocol (IrLAP) establishes the IR media access rules and various procedures for discovery, negotiation, information exchange, etc. IrLAP is a mandatory layer of the IrDA standard but not all the features are mandatory.

The main media access rules are that for any station which is currently not participating in a connection, it must listen for more than 500 msec to make sure that there is no IR traffic before it starts to transmit, and that for any station which is currently participating in a connection, it must transmit a frame within any given 500 msec.

Media access among the stations participating in a connection is controlled by a token-like Poll/Final bit in each frame.

Transmission of user data without first establishing a connection is allowed in IrLAP. 9.6 kbps SIR must be used for this kind of connection-less communication. As far as IrLAP is concerned, connection-less transmissions are broadcast in nature and are not acknowledged and not reliable.

The discovery procedure defines an orderly way to exchange IDs. 9.6 kbps SIR must be used for discovery. The initiator broadcasts its own ID repeatedly for a known number of times and listens between these repeated transmissions (slots). The responders randomly choose one of the slots and send their own IDs. If there is a collision, this procedure can be repeated.

The negotiation procedure is used to establish a connection with operating parameters that both parties can support. Some of these parameters, such as bit rate, must be identical for both sides, thus the "largest common denominator" is used. Some other parameters, such as maximum data size, are the limits of one party which the other party must respect. Like discovery, 9.6 kbps SIR must be used for negotiation.

The ability to respond to discovery and negotiation procedures is mandatory whereas the ability to initiate these procedures is optional. Stations that can respond but not initiate them are called Secondary Stations whereas Primary Stations are those that can both initiate and respond.

After all these operating parameters are known to both parties, a connection can be established. Before this happens, all traffic (connection-less transmission of data, discovery procedure, negotiation procedure, etc.) are carried out at 9.6 kbps SIR with maximum data size 64. Once connection is made, the negotiated data rate can be as high as 4 Mbps, the negotiated maximum data size can be as big as 2048 bytes.

During connection, the information exchange procedures are used. Frames containing user data are sequentially checked in addition to CRC. There are also supervisory frames used for flow control, error recovery, and to pass the token.

Due to the fact that a Secondary Station cannot initiate discovery and negotiation procedures, a Secondary Station cannot make a connection to another Secondary Station.

A Primary Station can connect to a Secondary. It can connect to another Primary too. In such a case, only one of the Primary Station in the connection may play the Primary Role. The other Primary Station will play the role of a secondary.

The station playing the Primary Role is responsible for the recovery of lost token, to maintain the 500 msec heart beat, and, in general, the orderly operation of the connection. Data exchange is always bi-directional, and independent on whether the station is primary or secondary.

In addition to the above major procedures, there are many other procedures, for example: sniffing, address conflict resolution, exchange primary/secondary roles, just to name a few. Collectively, IrLAP provides an orderly and reliable connection between the IR stations.

Details of the IrLAP Layer are specified in IrDA publication: "Serial Infrared Access Protocol (IrLAP)" Current version is Version 1.1 dated June 16, 1996.

IrLMP LAYER

The IrDA Link Management Protocol (IrLMP) consists of two components: the Link Management Information Access Service (LM-IAS), and the Link Management Multiplexer (LM-MUX). IrLMP is a mandatory element of the IrDA standard, but again, not all features of IrLMP are mandatory.

LM-IAS entity maintains an information base so that other IrDA stations can inquire what services are offered. This information is held in a number of objects, each associated with a set of attributes. For example, "Device" is a mandatory object and has attributes "DeviceName" (an ASCII string) and "IrLMPSupport" (IrLMP version number, IAS support, and LM-MUX support).

The other component of IrLMP, LM-MUX, provides multiple data link connections over the single connection provided by IrLAP. Within each IR station, multiple Link Service Access Points (LSAPs) can be defined, each with a unique selector (LSAP-SEL). LM-MUX provides data transfer services between LSAP-SEL end points within the same IR station as well as across the IrLAP connection to other IR stations. The LM-IAS discussed previously uses a pre-defined LSAP-SEL (0) for other IR stations to access over IrLAP and through

LM-MUX

The LM-MUX can be in one of two modes, exclusive or multiplexed. When in exclusive mode, only one LSAP connection may be active. In this case the flow control provided by IrLAP can be used for the only connection. When in multiplexed mode, several LSAP connections may actively share the same underlying IrLAP connection. However, in this case additional flow control must be provided by upper layers or the applications.

Details of the IrLMP Layer are specified in IrDA publication: "Link Management Protocol (IrLMP)" Current version is Version 1.1 dated Jan 23, 1996.

TinyTP, IrCOMM, AND BEYOND

TinyTP is an optional transport protocol. The main purposes are to provide individual LSAP flow control functions and to segment or reassemble data. The additional flow control is needed when the LM-MUX is in multiplexed mode. The segmentation and reassembly of data is used to match the user buffer size and IrLAP/IrLMP data size.

Details of the TinyTP Layer are specified in IrDA publication: "Tiny TP: A Flow Control Mechanism for use with IrLMP" Current version is Version 1.1, Jan 3, 1997.

IrCOMM is a protocol to emulate pre-existing wired serial and parallel ports. There are four service types. The 3-wire raw service type emulates a 3-wire RS-232 port (with TxD, RxD and Gnd wires with no flow control). It has no control channel and relies on IrLAP for flow control (and hence it must use LM-MUX exclusive mode). The other three service types use TinyTP and have separate control channels. They emulate 3-wire (cooked), 9-wire, and Centronics parallel.

Details of the IrCOMM are specified in IrDA publication: "IrCOMM: Serial and Parallel Port Emulation over IR" Current version is Version 1.0 dated Nov 7, 1995.

Other IrDA optional layers include OBEX (Object exchange), and many others. Most of these optional layer are aiming at facilitating the adoption/development of application programs.

Physical Layer, IrLAP, and IrLMP are the only layers that are mandatory in the IrDA standard. While these three layers provide the bases for an efficient and reliable link, the design is extensible and open-ended. IrDA has defined and is continuously working on other options.

The www.irda.org web-site provides information about the organization, its members, the standards, etc. It also has a resource list about IR components, systems, hardware & software licensing or consulting services provided by its members.

IMPLEMENTATION ISSUES

IrDA standards are aimed at a very broad spectrum of applications. It has a minimal set of mandatory requirements and a wealthy array of options. In practice, there is no device that only implements the minimum requirement. There is also no system that has implemented all the IrDA optional features either. The first step in implementation is to decide what optional features to include. The first two decisions to make are data rate and Primary vs. Secondary.

Data rate obviously has a profound effect on performance. For SIR, or data rate of 9.6 up to 115.2 kbps, the hardware usually consists of an UART, a SIR encoder/decoder, and an

IR-transceiver. For MIR and FIR however, a serial communication controller (SCC) chip specifically designed for IrDA must be used and a faster IR-transceiver is needed.

Furthermore, when MIR or FIR is used, SIR is still needed as mandated by IrDA protocol.

The Primary vs. Secondary decision has nothing to do with direction of data flow. Both Primary and Secondary may and must support bi-directional data transfer. The most prevailing difference between the two is that a Secondary Station cannot make IR connection with another Secondary Station, whereas a Primary Station can make IR connection with either Secondary or Primary Stations. The technical limitation that a Secondary Station cannot "initiate" discovery, negotiation, and connection procedures is often obscured by the application program and user interface. In certain applications, the user must activate both the Primary Station and the Secondary Station, the order of activation does not matter. In some other application, the user only needs to activate one of them, often but not necessarily the Primary.

Some examples of the SIR protocol stacks are the ACT1-Plus for primary station and ACT2-Plus for secondary station; and ACT11-Plus and ACT12-Plus for MIR/FIR respectively from ACTiSYS Corp. These core protocol stacks are usually tailored for the various OEMs to meet their memory, system software interface and CPU speed requirements of their target systems as well as the application models and environments.

IrDA LITE

Aside from data rate and Primary vs. Secondary, there are many other optional features to be considered. For any given application, "more" is not necessary "better". Here are a few examples:

The main feature of LM-MUX is to provide multiple data link connections over the single connection provided by IrLAP. But for some applications, you have to add the "exclusive mode" feature to restrict LM-MUX so that the "multiple data link" is limited to one data link. For these applications, it is better not to have the "multiple data link" capability to begin with, rather than implementing it and use "exclusive mode" to defeat it. Usually, multiple data link over a single connection provided by IrLAP is not very useful unless both ends of the IrLAP connection are capable of multitasking. Even then, it is questionable. For example, to transfer two files at the same time each at less than one half the speed is not necessarily better than transferring them one at a time at full speed.

The multiple window size is another example. When the data rate is 57.6 kbps or less, multiple window size is not useful at all. It may contribute to effective data rate performance only at higher raw data rate. Even then, if the application is interactive or transaction oriented, multiple window size may actually slow down the turnaround time and make the link sluggish.

IrDA publication: "Minimal IrDA Protocol Implementation (IrDA Lite)" provides suggestions of strategies that can substantially simplify the implementation of IrDA standards -- whether it is minimal or not. The current version for "IrDA Lite" is Version 1.1 dated Nov 7, 1996.

Examples of the IrDA Lite protocol stacks are the ACT1-Lite and ACT2-Lite from ACTiSYS Corp. The C code sizes are in the range of 10~15 Kbytes and 3~6 Kbytes for ACT1-Lite and ACT2-Lite respectively.

SYSTEM DESIGN AND INTEGRATION

To implement IrDA standards for up to 115.2 kbps data rate, an UART, a SIR encoder/decoder, and an IR-transceiver are needed. The UART is often part of the on-chip peripherals. Obviously, the UART must be able to handle the mandatory data rate of 9.6 kbps and all the optional data rates intended. In addition, the CPU must be able to handle the UART at those data rates without causing latency problems for both the UART and other peripherals in the system.

Unlike other simpler serial I/O protocols, IrDA protocols also need a timer and a multi-thread operation environment. This is particularly true for the Primary Station which must initiate the discovery procedure and also keep the 500 msec heart beat during connection. Even when the application program is not actively using the IrLAP link for input or output, the IrDA driver must exchange supervisory frames. This cannot be easily accomplished if the IrDA driver can get control of the CPU only when the application program calls it or when an UART interrupts.

It is preferred that UART interrupts be handled at a fairly high priority to avoid UART data overrun error. However, when a complete packet (called a "frame" in IrDA standards) is received, a much lower priority can be used to execute the bulk of the IrDA protocol. Doing so will prevent the lengthy IrDA protocol from blocking other latency sensitive hardware interrupts. Relying on the hardware to change the UART interrupt priority in the middle of the interrupt service routine often cannot produce the desired effect and can cause interrupt priority inversion.

To implement MIR and FIR, a SCC chip specifically designed for IrDA standards and a faster IR-transceiver must be used. In principle, once such a controller is used, the rest is easy. In practice, this is often not the case!

The UART is a standard fixture for PCs as well as many microcontroller based systems whereas the special SCC chip is not. I/O addresses, interrupt vectors, and DMA channels all have to be allocated without generating conflict with other standard and pre-existing peripherals. This is particularly difficult with the vastly popular and diverse "IBM compatible" PCs. Early last year, the IR team at Microsoft sent messages to all IrDA members and urged them not to use interrupt or DMA. It is not clear whether this is practical, but so far all the hardware implementations for MIR and FIR on PC's are still using interrupts and DMAs.

For systems other than IBM compatibles, implementing MIR and FIR is not any easier. Most, if not all, IrDA specific SCC chips currently available are designed with IBM compatibles in mind. Technical data about hardware interface and DMA are often incomplete, inaccurate, and replaced by slogans such as: "Windows-95 compatible". Furthermore, these SCC chips often include the UART function for SIR. If the SIR support is already implemented with the micro-controller's on-chip UART, that portions of the code must be re-written to utilize the different UART on the SCC chip!

IrDA-1.1 HARDWARE SYSTEM TEST SOFTWARE

The design of IrDA-1.1 hardware system and the integration of the IrDA-1.1 protocol stack is much more complex than IrDA-1.0. An engineering debug tool which can also be used for efficient and accurate production-line testing is very desirable! An example of IrDA-1.1 system test software is the ACT-IR9000SW from ACTiSYS Corp.

The design goal of IR9000SW test software is to provide the engineers in hardware design, testing and production a tool that can: 1) support various brands of infrared transceiver modules and digital super I/O controller chips, 2) test quickly the infrared communication error rate with different data transfer patterns and packet sizes under various speeds, 3) verify the functionality of IrDA-enabled hardware systems and also be used as the efficient production-line test tool.

IR9000SW is designed to run on one DUT (Device Under Test, e.g. FIR equipped notebook PC) system and test against a FIR reference system. The program is structured to support mixed hardware configurations. It has two working modes: master and slave. In the master mode, it will try to discover another system running in slave mode at certain speed. In the slave mode, it will scan through different speeds trying to pick up a call from the master.

IR9000SW uses its own IrDA-like protocol instead of using directly the IrDA protocol. This is to quickly focus on testing the performance, reliability and problem of the hardware system, without the complication, delay time and restart problem of the IrDA protocol stack.

In operation, the reference system is configured to be the master. It will loop indefinitely trying to find a slave station or receive a command to quit. The DUT system is the slave. Once master station discovers the slave, it will download the testing parameters to the DUT and start the loop test. The test results are dynamically displayed while testing is in progress.

This includes error rates in the transmission or receiving mode, % of file transferred and received for different speeds, at a fixed distance and half angle.

IR9000SW also has a set-up module to set the testing parameters, sequence and hardware configuration. It can record these new parameter settings into a configuration file for current testing session, or into a default setting file for future continuous use.

Setup parameters include the following:

COM Port: Com 1 to Com 4.

IRQ: 3 to 5, 7, 9, 11, 15.

Data Transfer Method: DMA or PIO.

Tx/Rx DMA Channel: 0, 1, 3.

FIFO Level: 16Bytes or 32Bytes.

Start Up Mode: Master or Slave.

If Master is selected: Speed Choice: FIR or MIR

Packet Number: Any, up to 32,000 packets.

Packet Size: 512, 1K, 2K, 4K, 8K bytes per packet

Test Pattern: #1, #2, #3, #4.

#1 = Special pattern

#2 = Sending all 0’s

#3 = Sending all 1’s

#4 = Sending random numbers

Pass/Fail Error Rate: Any Error Rate: % or BER (bit error rate).

Direction: One way or Two ways.

Beeper: On or Off.

· FIR controller vendor: NS, SMC, Winbond Model # & Base Address: Auto Detection

· DEFAULT.9k file can automatically save the setting parameter as default setting.

· RESULT.9k file can automatically save all the test results and time stamp them.

CONCLUSION

We have described here the IrDA-1.0 and 1.1 physical and protocol specifications, the implementation issues, system integration issues and FIR system test software tool.

In 1996, the issue was the adoption rate of SIR standards in notebook PCs. Now, the SIR has been built into most notebook PCs and also into cellular phone, digital camera, pager, medical device, industrial data terminal and printer, pay phone and others.

1997 will see SIR volume growth, FIR adoption and emerging killer applications. Future new standards include: USB-IrDA, Long-distance Control IR, Mobile Comm. Digital Camera and Faster IrDA.

 

[ Home Page | About Actisys | Contact us | IrDA Products | Tutorials | IrDA Test Center | IrDA Compatibility | Order | Price Quote | Technical Support | Free Downloads | Upcoming Events | Track a Package | Jobs | Feedback | Privacy | Terms ]

ACTiSYS CORP.  | 921 Corporate Way | Fremont, CA 94539 | Tel: (510) 490-8024 |  Fax: (510) 623-7268 |  irda-info@actisys.com

© 1996-2010 ACTiSYS Corporation, All Rights Reserved

    
--------------------------------------------------------------------------------------------------
Member of Infrared Data Association
® (IrDA) Since Its Founding Day!