IrDA INTERFACING TO PCs

PART I

  Copyright© 2002 Eddy Insam

email: edinsam@eix.co.uk

Published In Electronics World:

Printed Copies of this article can be obtained from Electronics World.  Anne Boleyn House. 9-13 Ewell Road, Cheam Surrey SM3 8BZ UK

Abstract Box

Following from the previous articles on Ethernet and USB interfacing, Eddy Insam will show you how the Infrared Protocol works. Next month he will show you how to add a simple IR interface device between your project and a PC.

If you have a laptop computer, and you bring near it one of the latest cell phones, digital cameras or personal organisers, you will notice how the laptop suddenly flashes a little icon on its desktop. Somehow, it has recognised the presence of the device, and is now able to communicate with it. Maybe you have arrived at your office and placed your laptop in front of another. An icon appears on both laptops with the name of the other computer below it. You open one of the icons to display a folder with the contents of the other computer’s desktop. You drag and drop between your desktop and the open folder to move files between the two computers. The magic performing all these tricks is infrared technology. Ever noticed that small red semi-transparent rectangle on the back of your notebook or camera? Well, this is where it is all coming from.

Infrared technology may or may not be replaced by wireless technology in the future. At the moment however, it has many practical uses, especially when it comes to reliable and safe contact between two nearby devices.

What is IrDA?

IrDA stands for Infrared Data Association (www.irda.org). The Association’s job is to coordinate and publish the  protocols, to ensure interoperability between products from different manufacturers, and to guarantee a minimum level of performance. IrDA publishes reference documents covering various aspects ranging from the physical aspects of the infrared beam, wavelength, power, beam angle etc, to definitions of the layered protocol structure required to perform its software functions. Most of the information is freely available from their website. IrDA is now used in computers, printers, keyboards, digital cameras, security modules, toys, and even ATM machines.

One thing IrDA is not. IrDA is not the same, and has nothing to do with the infrared systems used in TV or video recorder remote controls now in common use. The two systems are completely incompatible.

I shall try to explain in these articles how IrDA works, and describe a system you can use to interface your project to an external PC using infrared.

By the way, if you dislike TLAs (three letter acronyms) please stop reading now. IrDA definitions are riddled with these. There is a Glossary at the end of the article that may help a little bit.

And there was Light

IrDA uses infrared light of a wavelength between 850nm and 900nm. This is the same wavelength used by TV remote controls, car door openers, earphones, night illumination for CCTV cameras and so on. The reason is very simple; LEDs and optodetectors for these wavelengths are cheap and readily available. Apart from this, there is no other commonality between IrDA and the systems mentioned.

All IrDA devices communicate by shining modulated beams of IR light at each other at relatively high data rates. This implies that they must be within visual range of each other (a pretty obvious argument). To ensure a level of compatibility between different products, the IrDA standards specify minimum and maximum power levels, beam widths, and mechanical arrangements for the optical components to ensure devices have a “predictable” working range, this is in the order of a metre or so. The technical and optical specifications are straightforward, so I am not going to discuss them in any detail. Please refer to the documentation in the website for any further information.

One interesting point is the way the optical pulses are generated. In order to save power (most IRDA devices will be battery powered) transmitted data is sent as short bursts of optical power, much shorter in time than the data bit rates they represent. IrDA is also a half-duplex protocol. A device is either transmitting or receiving. A full duplex protocol would be very difficult to implement in an optical system where the weak signal arriving from a remote could be obliterated by reflected light from its own transmitter.

Most practical designs will be using ready-made optotransceiver modules available from a number of manufacturers. These will contain an infrared LED transmitter, optodetector, and drive electronics providing TTL compatible interfaces, all in a single encapsulation. Oddly enough, not all of these commercial products meet the full IrDA standards; so do check if you are thinking of adding one into your own product.

I should say one thing at this point. Even though infrared is the main foundation for the standards, it is not necessarily the only transmission method possible. The protocols have been designed in such a way that they can be used with any half duplex format, i.e. wireless radio or even ultrasonics.

Variations on a Theme

IrDA standards are roughly divided into two main sets: “IrDA Data” and “IrDA Control” otherwise known as IrDA-C. IrDA Data protocols deal with interaction with other devices for the exchange of data. IrDA Control protocols deal mainly with Human interface type peripherals such as keyboards, joysticks, mice etc. The protocols are not inter-operable. The differences are shown in Table 1.

IrDA Control uses a simple monolithic three level protocol stack. It also allows for some compatibility with equivalent USB based devices. The modulation scheme used converts nibbles of four data bits in the original data into eight data bursts symbols using a two out of eight, or a four out of eight code. The resulting data is then modulated with a 1.5MHz carrier and fed to the transmit LED resulting in an overall data rate of about 75Kb/s. This modulation scheme was designed to minimise interference with co-existent 40KHz TV remote control type systems.

IrDA Data uses a more complex protocol stack as it needs to allow for different types of application such as point-to-point communications, file transfer and LAN access. I am going to concentrate on IrDA Data formats as they are the most likely candidates for interfacing external devices to a PC. From Table 1, we can se that there are two main transmission formats defined for IrDA at the “optical” level:

The SIR asynchronous format, this resembles a standard UART (one start bit, 8 data bits and one stop bit). Data rates supported on the optical link are  9600bps to 115200bps half duplex. During the discovery stage, transactions start at the lowest bit rate, then the software negotiates its way up to whatever the peripherals can handle. Data “zeros” are transmitted as short optical pulses of a few uS in duration, Data “ones” do not generate output Fig 1.

The FIR “synchronous” format uses synchronous data streams. The optical transceiver pairs two source bits, and outputs LED bursts in a one out of four code Fig 2.

What IRDA Does

Table 2 shows the layered protocol structure for IrDA. The top layers provide services and interfaces to host application programs and to the operating system to enable point-to-point data communications, file transfers, and for networking services. Not all of the top layers need to be implemented for a particular application. If your device is a digital camera for example, only the IrTran-P protocol will be needed. The middle layers manage things such as error correction, addressing, and automatically maintaining lists of all the devices in range. The bottom layer is just involved in the physical transfer of the data between the devices. If you imagine a telephone made out of two tin cans and a piece of string, this is the string.

I shall now describe in simple terms what these layers do. The full documentation can be downloaded from the IrDA website.

IrCOMM provides a stream byte-by-byte communications link between two devices; it was develop to emulate and support the legacy serial and parallel ports found in your computer. A feature of IrCOMM is “virtual” ports. When irCOMM is installed on your PC, an extra COM or LPT “virtual” port will appear in your control panel hardware interface list. To all extents, the host and the application sees this virtual port as a standard serial or parallel interface. The IrCOMM specifications include emulation for standard Centronics LPT, serial 3 wire (data in and data out), and serial 9 wire (data in and out, plus emulation of RS232 control lines such as RTS, DTR etc).

IrTran-P is used mainly to transfer images from digital cameras. It stands for Infrared Transfer Picture Protocol. Apparently, this format was developed by NTT during the Nagano Olympics for use in internet kiosks for transferring images from digital cameras to the web. IrTranP uses the basic IrCOMM layer to open a reliable channel, then uses a simple command execution protocol SCEP to manage the communication session, and uses a simple binary ftp to exchange the images. To find out more, visit the website at www.mabikai.mbc.ntt.co.jp.

IrLAN is a protocol used to support IR wireless access to local area networks. This enables LAN type communications to be established across an infrared link. IrLAN effectively emulates a low level Ethernet (802.3) link with its nominal 1500 byte frames and addressing mechanism. It also supports Token Ring (802.5). IrLAN could be used to provide low-level facilities for infrared TCP/IP communications.

IrObex provides object exchange services similar to HTTP. It is intended as an operating system independent method of transferring objects. If you want to send a file from one device to another, IrObex defines the means of identifying and converting the file into a universal object that both devices can understand and interpret.

IrMC stands for Infrared Mobile communications, this defines the exchanges between a computer and a mobile device such as a cell phone. This also includes phonebook, calendar, message data and how call control and real-time voice are handled.

Other protocols under development will cover interfaces to dongles, wristwatches and transceivers.

The middle irLMP and Tiny-TP layers perform multiple session support. In theory, this support exists to allow multiple connections active at the same time to multiple devices. Often, only one application will be active at any one time, and the protocols are mainly used in practice to provide dual access, i.e. Control and Data connection, to and from a single device. When implemented in larger computers, such as PCs, IrLMP and TinyP may also be used to add per-connection flow control in addition to the flow control provided by the IrLAP connection. This may appear wasteful, but allows a user application, say in a PC, to use standard ReadFile and WriteFile commands to exchange large blocks of data and allow the stack to operate at the optimal speed. The IrLMP layer also includes a simple Directory Services Protocol IAS, which runs on top. IAS is commonly used to map an ASCII service name to a user application. Host applications are simply given lists of what devices are in the neighbourhood, and allowed to select and open one for communications.

The IrLAP layer provides a single reliable connection between exactly two devices. IrLAP also controls discovery of devices within range, uniquely identifies those devices, and establishes the error free channel. You can think of it as a glorified point-to-point wire link. IrLAP is roughly based on its equivalent LAP HDLC IBM protocol, modified to take into account the ad-hoc nature of wireless connectivity.

The PHY hardware layer, I have already described some aspects of this. This layer is just concerned in getting the individual data bits from one point to another with no concern for error correction or reliability. Having a clean definition and separation between layers can be very useful. For example, it allows different physical data bit formats to be used, e.g. SIR, FIR, which use different optical encoding methods. It also allows the possibility of using other transmission methods such as wireless radio. The use of standard asynchronous UART formats also allows the use of compatible hardware e.g. modems.

A Day in the Life

It would be extremely boring for me to explain in full detail how each of these layers work, apart from me falling asleep while writing this part of the article. Rather, I shall describe a fly-by through a typical transaction, and explain in general terms how each of the layers gets involved.

As soon as you switch your laptop on, and it boots its operating system, it will start polling for other IR enabled devices within range (this of course assumes your laptop has been IR enabled). This polling will happen continuously and will be repeated ever few seconds. You will not need to worry about CPU time, as most of the thinking time will be happening inside the IR controller chip running the IrLAP protocol software in firmware.

As a “sniffer” your laptop is defined as a “Primary” device. Primary devices start transactions and poll for other devices. Secondary devices, such as printers, just sit there waiting to be polled. I am going to confuse this simple logic by saying that a Primary device can also act as a Secondary device, so that one laptop can recognise another.

If a Secondary device is within range (and switched on), it will return a response. A System State Table shown in Fig 3 is used to define these states as the two devices progress through their mutual recognition procedure. 

The starting point is the NDM state (Normal Disconnect Mode), where the Primary, having generated an internal 32 bit device recognition address, starts to regularly send out broadcast requests. The Primary divides these requests into time slots. A Primary will make a slot enquiry, and listen during the remainder of the time for Secondary devices to reply, the system of “timeslots” is used to identify the responses and to sort out possible collisions.

Having sensed a Secondary device, the Primary will want to know of its capabilities. The Primary sends an information packet indicating what kind of device it is, its nickname, and other useful information. The Secondary responds with information about itself such as type of product, maximum data rate etc. This temporary state of affairs is known as the “discovery” state. During this discovery time, the Primary will allocate a 7-bit session address to both parties, and add the new device’s name to a list of “available” devices. At the same time, the firmware may send a notification of this event to the operating system. On your laptop, this will be shown as an Icon appearing on the desktop telling you a printer is now within range.

The basic polling procedure will continue regardless, even when a device has been opened and data is being exchanged. When the Secondary goes out of range, the lack of link communications will prompt the controller to terminate the session and to remove the device from the list. When a device has finished, it transmits a close link command, the other device will confirm the command, and both devices will go back into the NDM state.

Secondary devices make up their own 32 bit addresses during setup. If by some coincidence, two devices come up with the same 32-bit address, The Primary will send a request to instruct the Secondary to choose a new one.

All of the above is handled completely in the background within the controller running IrLAP-IrLMP software. The host application only sees the list of available devices, and whether it can open a communications channel or not.

IrDA support in Microsoft Operating Systems

Not all versions of Windows provide for full IR software support, see Table 3. Notably, Windows 2000 offers full LAN access via infrared devices. Previously, special file transfer programs had to be run to move files across.

Your PC (or notebook) must of course also support IR hardware. Many new PCs motherboards already come with some sort of IR transceiver device built-in. In practice, these will be automatically detected by the Plug and Play mechanism. SIR emulation is supported in Windows by the driver IRSIR.SYS. This uses the services of the Windows standard serial drivers SERIAL.SYS. Any built in SIR hardware is usually exposed through the system BIOS as PnP IDs PNP0510 or PNP0511.  Fig 4 shows the protocol layer structure in Windows 2000.

If you do not have a built in IR transceiver on your motherboard, Windows will allow you to direct the output to the serial port (for use with an external optical transceiver for example). Let me explain this again. Your application is talking to the IrCOMM IR driver using a comms port software interface, the software stack will move your data down the IrCOMM, iRLAP, layers down to the PHY layer, but instead of outputting the resulting serial data into an actual LED, it outputs it to a hardware serial port. Using the serial port by taking the scenic route one may say.

Microsoft are now encouraging the use of Winsock (rather than legacy serial comms port API) to communicate with IR devices. This makes sense, Winsock uses a simple compatible set of API functions that provide fully error corrected data streams (unlike legacy ports). Winsock allows direct access to the Tiny-TP layer, bypassing IrCOMM. IrCOMM has many limitations; operational situations such as data breaks and device disconnection are not communicated to the user. Applications must provide their own data protection layer.

It may be likely that support for IrCOMM and others protocols such as IrTran-P, will be reduced in future versions of Windows. For example, Windows 2000 does not expose IrCOMM as a virtual serial port (only Winsock support is available). This may be important if you are considering extending the use of legacy serial communications when developing a new IR product. 

Next Month

Next month I shall describe some practical implementations and how to make a small interface you can use with your embedded system to allow it to communicate with your PC.

Glossary

BOF                 Beginning of Frame

CRC                 Cyclic Redundancy check

EOF                 End of Frame

ETLA                Extended Three Letter Acronym, e.g. a four letter acronym

FCS                  Frame Check Sequence

FIR                   Fast Serial IrDA, a Physical Layer serial format

HID                   Human Interface Device, generic word for devices such as mice and keyboards

IAS                   Information Advertising Service, a protocol associated with IrLMP to provide directory services

IrDA                  Infrared Data Association

IrDA Lite            Reduced code version of IrDA code while maintaining compatibility

IrCOMM            Provides COM (serial and parallel) port emulation for legacy printing and modem     devices

IrLAN                Protocol used to support IR wireless access to local area networks

IrLPT                 Legacy Centronics LPT emulation

IrMC                 Specifications on how mobile telephony devices can exchange information

IrOBEX              Provides object exchange services similar to HTTP

IrTran-P Provides image exchange protocol used in Digital Image capture devices/cameras

IrXfer                 File transfer protocol

LLA                  Logical Link Control

LSAP-SEL        A protocol used to select one from many applications running on the server

MAC                 Media Access Control

PHY                 Physical layer

SIR                   Serial IrDA (9.6 to 115.2Kbps), a Physical Layer serial format

Tiny-P               Provides flow control on IrLMP connections with optional Segmentation and Reassembly service.

TLA                  Three Letter Acronym

VFIR                 Very Fast Serial IrDA, a Physical Layer serial format

The Author

Dr Eddy Insam is a consultant in innovative applications of telecommunications and specialises in graphics and signal processing. He can be reached on edinsam@eix.co.uk.

For More Information

All IrDA Specifications are available for downloading in PDF format from www.irda.org/standards/specifications

IrDA INTERFACING

PART II

Last Month, Eddy explained the basics of IrDA and how it works, this month he discusses a practical interface between an embedded system and a PC.

You may be wondering how difficult it is to add IrDA capabilities to your project. Maybe you may be thinking of adding a simple communications link to a PC via Infrared (or radio) using the IrDA protocols. Fortunately, there are a number of devices available that make this process simple.

Turning Light into Volts

Fig 1 shows the block diagram of a typical optoelectronics transceiver. Most of these chips are of a “what you see is what you get” type, meaning that light pulses are converted to TTL levels on a one to one basis. That is, resulting in the same pulse width and rate as received. Little signal processing, apart from some pulse stretching and power limiting is provided. Prepackaged IrDA approved transmitter/receiver pairs are available from a number of manufacturers including Agilent, Hewlett Packard, Infineon, Rohm, Vishay and Zilog.

IrDA uses a complex set of protocols. At the lowest levels, it requires a serial NRZ (non return to Zero) bit stream at specific rates. You will need extra logic to convert the raw pulses from the optotransceiver into useable serial logic levels to feed the protocol processor. You also have at least three different formats to choose from.

If you want to implement a FIR link, The National Semiconductors NS87109 supports the full specifications up to 4Mb/s and includes the 4ppm FIR modulation scheme. It also functions as a serial communications controller, handles data integrity, bit stuffing and CRC calculations (at 4Mb/s, these are all too complex to do in software). The chip also supports DMA, and should really be used only with a fast micro controller, namely one that can support DMA transfers.  You must also use this chip with a 4Mb/s capable optocoupler such as the Agilent HSDL1000.

Most likely, you will want to use IrDA for medium rate data transfers between a PC and a small embedded system. In which case, you will be considering the SIR format instead, which has the added advantage of being compatible with standard UART devices.

Fig 2 shows the relationship between actual serial data from the user controller and the pulses generated by the Opto-transceiver. Timing is usually linked to an externally provided clock, usually by the micro controller, at 16 times the baud rate. The specifications state that the opto pulse width should be at least 1.41uS but no more than 18% of the data bit time. Most transceivers use a method based on the 16x clock where the LED is off for the first 7 clocks, on for the next 3, and off for the last 6 of every 16 clock bit period. Light is only transmitted for a logic “0”. No light is transmitted for a logic “1”. We could crudely perform these operations with a simple monostable, although in practice, we would use a dedicated micro controller such as a PIC, or use some ready made devices such as the Texas TIR1000, Vishay TOIM4232 or Microchip MCP2120.

You must remember that the higher layer protocols can negotiate the link speed, so your design must allow for this. In practice, this means controlling the generation of the 16x clock.

Handling the Protocols

At this point, we are still nowhere near providing full functionality. You will have to write all the software required to handle all the protocol layers. Table 1, repeated here from last month’s article shows the layers used in IRDA. Of course, you will not be needing to implement each and every protocol as your device may be performing a single function only.

I am going to concentrate on IrCOMM (serial comms) and Tiny-TP, as the most practical protocols for simple data communications between an embedded system and a PC (other protocols are just variations on these). To implement IrCOMM, you will only need to provide the subset of the layers shown shaded in the table. Within IrCOMM, there are sub-options, namely LPT and 3wire serial that do not require IrLMP or TinyTP support, simplifying matters even further.

Since IrDA is a half duplex system, you can simplify software design by only allowing one thing to happen at a time. There is no need to provide multitasking facilities. For example, if you are developing a Secondary device, it can act purely on interrupts from data sent by the Primary. The IrDA documentation carries pseudo-code description on implementing some of these protocols.

Frame Format

All SIR transactions use the same frame format Fig 3. Data blocks are called frames, each frame starts with one or more BOF bytes, a variable length Payload, two FCS (checksum) bytes, and an End of Frame EOF byte. The value of the BOF is generally 0xC0, but 0xFF may be used if the last BOF character is a 0XC0. The purpose of multiple BOFs is to give the other station some warning that a frame is coming.

The Frame Payload consists of an Address byte, a Control byte, and a variable length Information Field. The Control byte is used to differentiate between different types of frames, also to count frames. Frames can carry status, data or commands. Each protocol, such as IrLAP, can have different command syntax, this is reflected in the contents of the variable length Information field.

The address is a 7 bit (left justified) identifier tagging a particular session between two devices. The least significant bit is a separate command/response bit and is set for a Primary frame, and reset for a Secondary frame. Odd addresses correspond to a Primary frame and even addresses to a Secondary frame.

Integrity of a Frame is ensured with a 16-bit CRC code sent on every frame as a pair of FCS bytes. The Frame ends with a 0xC1 EOF byte.

Other IrDA standards such as IrOBEX use different frame formatting methods. The faster FIR synchronous format uses a different CRC method.

Just add Water

Needless to say, there is no need to write your own stack. Some manufacturers have implemented a number of  protocols handlers in a single encapsulation. Two of Microchip devices, MCP2150 and MCP2155, provide limited IrCOMM services, and include all the supporting layers required for a simple serial interface: Tiny-TP, IrLMP/IAS and IrLAP. Both devices emulate a Secondary device. The Primary device is assumed to be a separate PC or notebook computer.

Looking at the MCP2150 pin out and data sheet, it suspiciously resembles a custom programmed but otherwise standard PIC 16F84. The chip operates from a single 11.052MHz crystal, and requires no other special components. It also interfaces directly to an Opto-transceiver, eliminating the need for an intermediate device to stretch and reshape the pulses.  Communications with the user micro controller is via two serial transmit and receive lines and a handful of handshake lines. The handshake lines are required to control the data flow, and to tell the external micro processor when data is available from the remote device. Fig 4 shows a complete circuit using this device, this is all you will need to add IrDA capability to your embedded system, which will need to have a spare serial port, and a few I/O lines. All the sniffing, device discovery, error correction etc, are handled internally within the MCP2150. The external micro only sees the control lines and the data flow.

In the diagram, the jumpers select the data speed between the MCP2150 and the user device. Note that this is not necessarily the same speed as the Opto link speed. The four speeds available are 9600,19200,57600 and 115200bps. The handshake lines are required to ensure consistent data flow. Remember that IrDA is essentially a half duplex protocol, and the host must be constrained from sending data when the channel is not ready to receive it. The MCP2150 includes an internal 64 byte FIFO and emulates a NULL DTE modem connection. A similar device, the MCP2155, is equivalent in most respects to the MCP2150, and uses the handshake lines in a slightly different way to emulate a DCE terminal.

The Carrier Detect (CD) signal is used to indicate if a valid IrDA infrared link has been established between the MCP2150 and the external Primary device (remember, all protocol manipulation is done in the background within the MCP2150). The CD signal should be monitored at all times by the user device; this is to ensure that the communications link has not been broken. The DSR signal from the MCP2150 indicates that the device has powered up successfully and is ready for service. In other words, this signal is valid most of the time after turn on.

The MCP2150 uses a 64 buffer for incoming data, and another for outgoing data. When IR data is being received, the buffers are not available, so the MCP2150 uses the CTS line to notify the host that it cannot receive data via its serial port. That is, no data should be sent from the host if the CTS line is invalid.

Although the maximum datasheet throughput is defined as 115,200 bps, the actual line throughput is less than this. This is partly because of the IrDA standard overheads (extra framing and error correcting bytes), but also the limitations of the MCP2150 regarding internal buffering. There is also a latency time required between the transmission of a frame ad the reception of the next to allow the optocoupler amplifiers to settle down. When all is considered together, the maximum theoretical throughput with this device is about 63% of the IR data rate. This does not include any extra delays added by the user micro controller during polling and processing.

If you are considering building a project around the MCP family, please ensure you download all the data sheets and application notes for the Microchip website. They contain more detailed information on things like setting up and interfacing.

Setting Up IrDA on your PC

The following applies mainly to Windows 98, but can be easily extrapolated to other Windows Operating systems. When the standard IrDA drivers are installed, a Virtual Serial port is available to your system. This virtual serial port is reported to the user at the time the drivers are installed. Windows 98 reports this COM port assignment under the Options tab of the IR monitor, available from the Control Panel. At this point you can choose to change the COM port number assigned to the virtual IR device, the time between polls and so on. In Windows 2000, a similar Dialog will be found under the Wireless Link in the Control Panel. Windows applications, such as HyperTerminal or MSCOMM, can select the virtual port by clicking on the newly assigned COM port number. Windows Basic or C programmers can use the standard CreateFile(), ReadFile() and WriteFile() API functions to open a comms port in the normal way.  Windows CE and 2000 developers should use the Winsock IR facilities instead (dubbed IrSock). These use the standard socket connect and data flow facilities, and include new ones for enumerating the devices available for connection.

The Author

Dr Eddy Insam is a consultant in innovative applications of telecommunications and specialises in graphics and signal processing. He can be reached on edinsam@eix.co.uk.

For More Information

Infrared data transceivers and interfaces are available from

Agilent www.semiconductor.agilent.com   and search under infrared and barcodes

Infineon Technologies www.infineon.com/us/opto/irdt

Rohm Co, Ltd.  www.rohm.com

Vishay Semiconductors www.vishay.com/products/optoelectronics search for TOIM4232 or TFDS4500

Zilog Inc, www.zilog.com/products and search for part ZHX1810

Agilent Co www.agilent.com devices HSDL7001/1001/1100

Texas Instruments www.ti.com and search for TI1000

National Semiconductors www.National.com search for NS87109UIR

Sharp Electronics www.sharpmed.com search under IrDA

Microchip Technology www.microchip.com search for MCP2120, MCP2150,MCP2155

Information on Microsoft Winsock from the online Microsoft MSDN library

ENDS