Infrared Networking Basics - Page 2

 By Brien M. Posey
Page 2 of 2   |  Back to Page 1
Print Article

A comparable chip inside the device you're controlling is set up to look for the various patterns of flashing light. If the device detects a flash pattern that it recognizes, the action associated with that pattern is performed. If the flash pattern is unrecognized, it's ignored. This prevents the device from functioning erratically in the presence of other types of devices remotes.

I've given this long explanation of how your television remote works because PC-based infrared communications work on the same basic principal. Figure 2 shows a portable PC's infrared port. The left image shows the infrared emitter in the off position, and the image on the right shows the infrared emitter emitting a pulse of infrared light. As you can see, computing devices tend to emit much brighter bursts of infrared light than remotes.

Figure 2
Figure 2: A computer's infrared port emits the same type of infrared light as an infrared remote control.

As you can see from the two examples I've provided, infrared communications work by sending and receiving pulses of infrared light. These pulses consist of periods of light and darkness. In the case of a TV or stereo, these pulses are nothing more than recognized patterns. However, in the case of computing devices, the pulses are binary code. When the infrared emitter is on, it's essentially sending a binary one. Likewise, when the infrared emitter is dark, it's considered to be sending a binary zero.

This is where the need for infrared-based protocols comes in. The protocol regulates the timing of the infrared signal. It makes sure that the receiving device is checking the on/off status of the emitter at the same frequency the emitter intends. For example, if the emitter sent pulses at 4-millisecond intervals, but the receiver was expecting 2-millisecond pulses, then a single pulse of light could be mistaken for two pulses.

The protocols must also negotiate things such as packet length (where one segment of binary code ends and the next one begins). For example, suppose the sender sent the following two packets: 10101100 00110010. Without proper timing, the receiver might pick up part of both packets and think it was a single packet. For example, if the receiver picked up the last four bits of the first packet and the first four bits of the second packet, it would receive the code as 11000011. As you can see, this is much different from the intended message.

You can get an exclusive new technical article by Windows 2000 expert Brien Posey in your e-mail box every week. Just take a moment to sign up for the CrossNodes Windows Networking Tech Notes newsletter.


In Part 2 ( Installing and Configuring Infrared Support ), I'll continue the discussion by explaining more of the logistics that must be present for infrared communications between two computing devices. I'll then go on to discuss the way that Windows 2000 supports infrared communications. //

Brien M. Posey is an MCSE who works as a freelance writer. His past experience includes working as the director of information systems for a national chain of health care facilities and as a network engineer for the Department of Defense. Because of the extremely high volume of e-mail that Brien receives, it's impossible for him to respond to every message, although he does read them all.

This article was originally published on Nov 9, 2000
Get the Latest Scoop with Networking Update Newsletter