Building IR Transceivers for Media Center Michelle Niethammer Program Manager Windows eHome Division microsoft.com Microsoft Corporation Bert Kleewein Software Design Engineer Windows eHome Division microsoft.com Microsoft Corporation

Session Outline Brief overview Overview of IR Hardware requirements Protocol 101 Driver architecture Driver interfaces Building non IR remotes and receivers Certification Development support options

Brief Overview Media Center experience is closely integrated with the remote control and the IR transceiver We want every PC to ship with a full function IR transceiver Where we are today What we are enabling Exposing driver interfaces so that anyone can build IR transceivers and integrate them into the PC design Publishing the hardware specification for the devices so that a new standard is established for IR transceivers Why the change Simplify integration into other components Reduce costs Speed Innovation

Components of the IR Transceiver Remote Control Input – 10ft Receives commands from Remote Control Enables “Parse and Match” – ability to identify remote control based on IR data sample Learning – 2-3 inches Captures IR from Set-Top Box Remote Controls to Retransmit Emitting Sends IR commands from PC to set top box for changing channels. Key scenario is ability to change channels when user is not home Second scenario is ability to use single remote to control experience System Resume from Standby

Hardware Requirements for Media Center Receiving IR Data (Input) Support carrier frequencies from 32kHZ to 56kHZ Receive and Send IR Simultaneously Relay raw IR timing data Learning IR Data Support carrier frequencies from 32kHZ to 455kHZ Ability to capture raw IR data stream Ability to capture IR carrier frequency Transmitting IR Data (Emitting) Support carrier frequencies from 32kHZ to 455kHZ Support independent IR Transmitter jacks (2 minimum) Send and receive IR simultaneously IR Emitters can be placed 5 meters from PC IR emitters are stick on IR emitters use visible LED System Resume from Standby S1 or S3 required, S4 or S5 optional Blink Receiver Device Store and return wake identifier

Protocol for IR Input Determine IR protocol you are going to receive Microsoft recommends the Microsoft-Philips IR protocol (based on RC6) You can become a licensee at no charge to you Support for Microsoft-Philips IR protocol included in the box Extremely reliable in high interference environments Great range 10+ meters Not sensitive to line of sight issues Driver Model Supports other IR protocols Legacy Device support for other protocols deprecated How to license RC6 Contact microsoft.com for license agreement

Talking about “Consumer IR”, not IrDA Pulses of light Important information in pulses: Raw wave form (represented as RLC – Run Length Coding): we use “bit banged” IR. It is encoded/decoded in software, not hardware Carrier frequency: in kHz range. Encoding scheme (protocol) Payload Delay and repeat IR Protocol 101 Consumer IRIRDA Signal Range 0-50 feet line of sight3-6 feet Transmission Low speed one-way (typically) High speed – 9600 – 4mbs bi- directional Discoverable by other like devices of site NoYes Cost Inexpensive10x costs in a remote control

Driver Architecture User Interface Software (Shell, etc) HIDIR IRBUS User Mode Kernel Mode Device Port Driver Device Driver Stack IR Hardware Provided by: Microsoft IHV Port driver deals in Bit Banged IR (raw waveform) IRBUS converts waveform into payload HIDIR converts payload into keypress

Typical IR packet Carrier Frequency: 36kHz RLC: Protocol = RC-6, payload = 0x800F8400 Idealized waveform as seen by hardware Run Length Coded data passed up to IRBUS Payload decoded by IRBUS Final keypress Key = channel up

Hardware/Port Driver Requirements WDF required Windows Logo Program qualification You build the hardware. You write the port driver Handle PNP and power states as appropriate Port driver provide 7 services (implemented as IOCTLs) What are your capabilities? What emitters are connected? Flash an LED that the user can see Transmit this IR Listen for IR Wake from lower power state Did you wake the system? You decide how the port driver talks to the hardware Published in future version of the DDK Details/parameters may change

1. What are Your Capabilities? IOCTL_IR_GETDEVCAPS User Scenario Identifies Device Capabilities used in first run to determine hardware configuration and setup Number of Transmit ports (IR emitter jacks) Number of Receivers (both 10’ and 2”) Which receivers are 10’ and which are 2” User will get error message if device is not capable of supporting hardware configuration Example: User is configuring TV tuner with a satellite set top box but their IR receiver has 0 transmit ports User would get error in first run stating their IR transceiver is not capable of supporting a set top box User could plug in new hardware or cancel

2. What Emitters Are Connected? IOCTL_IR_GETEMITTERS User Scenario Determine what IR emitter ports have emitters plugged into the receiver Used in first run to configure set top boxes Used when channel changing to determine if IR emitter is plugged in before a scheduled recording is started. If no emitter is plugged in then the recording is rescheduled for a later time Possible to emit IR to multiple devices Returned as bitmask (32 emitters max)

3. Flash an LED That the User Can See IOCTL_IR_FLASHRECEIVER User scenario Identify active receiver Helpful for consumer to know which receiver is active so they can change if necessary Used in IR learning to tell the user where to point the remote Active receiver may not have learning capability No parameters. Device should flash LED for 5 seconds.

4. Transmit This IR IOCTL_IR_TRANSMIT User Scenario Sending IR commands to change the channel on the set top box Scheduled Recordings when the user is not present Support Extender sessions where set top box is used for TV service Allows user to use one remote control for Media Center experience IRBUS gives the port driver: Bitmask of emitters to use (could be more than one) Carrier frequency RLC with raw IR Entire transaction – complete channel change in one block of RLC Multiple key presses separated by silence Port driver/hardware responsible for enforcing timing 50 ms pause cannot become 250 ms pause

5. Listen for IR IOCTL_IR_RECEIVE User Scenario Listening for keypresses during normal operation Identification of set top box remote (parse and match) Remote learning IRBus asks the port driver: Please listen on receiver # n. Here is a buffer to fill. Return any IR that you see If using learning receiver, port driver returns carrier frequency Hardware doesn’t have to listen for IR unless IRBUS asks for it Port driver returns RLC data. IRBUS decodes it Only listen on one receiver at a time

6. Wake from Lower Power State User Scenario Create consumer electronics experience by enabling the remote to wake the PC Required to wake from S1, S3 Waking from S4 & S5 optional (but nice) Hardware needs to recognize IR stream for wake key (driver is not running when system is asleep) Hardware fires interrupt when wake key signature is seen Wake key information is stored in registry in two formats: RLC for wake key Protocol, payload pairs (e.g. RC6, 0x800F8400) Toggle bit remotes send more than one pattern for each key – up to 8 patterns possible

6. Wake from Lower Power State (con’t) Hardware needs to draw current when PC is asleep or off Hardware needs to fire hardware interrupt to wake system Hardware needs to actually decode IR instead of just returning RLC data It only needs to decode one key, so it can be fairly inefficient But information about that key is in the registry so it needs to be software configurable No IOCTL to enable this Users enable/disable this in device manager

7. Did You Wake the System? IOCTL_IR_GETWAKESOURCE User Scenario User presses power button on remote to wake system System wakes, but we don’t know why If power button woke system, we turn on the monitor. If the system woke to record a show, we don’t turn on the monitor Heuristic When hardware fires interrupt, it sets a flag When IRBUS sends this command, port driver responds and resets flag Optional: Flag resets itself after timeout (10 minutes, not 10 seconds)

Building Non-IR Remotes and Receivers What about RF or Bluetooth instead of IR for input? Media center supports standard HID usages Either of these protocols will work if you write a driver Things to remember RF or Bluetooth add cost Does not eliminate need for IR receiver Still need all functions in receiver to support set-top box control Exceptions are TV tuner solutions not requiring IR blasting DVB-t, HDTV RF may require a dongle Likely to be too much interference to integrate into PC Setup is more difficult Teach devices Have to worry about neighbors Different channels Encryption/security Write HID drivers for your device Plenty of HID driver samples are available (DDK) HID usages for remote control part of DDK

Qualification Driver IR Transceivers will follow standard Windows Logo Program qualification Depending on device class your driver may be subject to additional tests USB integrated TV tuner and IR transceiver USB Device TV Tuner Device IR Transceiver Hardware IR Transceivers tested and certified under Longhorn logo program.

Engineering Services Mission: “To accelerate & enhance our partners’ delivery of products, hardware, and services with Microsoft technologies” Single point of contact within Microsoft Technical Design Review Facilitation Logo/Device Qualification Assistance Beta Program Nomination & Support Post Release Support (Driver Development, OEM Preinstall Kit) MSDN Annual Subscription PSS Product Specific Issue Reporting Development Support Options For further information, please contact: Carey Morgan: microsoft.com

Call To Action Make sure you understand hardware and driver requirements Start planning your specific hardware implementation OEMs will want to test hardware during Longhorn Beta 2 Contact microsoft.com to signup for more information and to get started

Community Resources Windows Hardware & Driver Central (WHDC) Technical Communities Non-Microsoft Community Sites Microsoft Public Newsgroups Technical Chats and Webcasts Microsoft Blogs

Additional Resources Web Resources:

© 2005 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

Appendix slides that will be hidden during the presentation but included in the CD follow:

Driver Architecture EH*.exe IRUser.exeKBDHID HIDIR IRBUS USB Stack User Mode Kernel Mode TBD IR #1TBD IR Device IR Stack IR Transceiver V1 LPC Chipset IR Hardware Provided by: Microsoft IHV IR Transceiver V2 IR Transceiver V3

IOCTL_IR_GETDEVCAPS Structures: typedef struct _IrDevCaps { OUT ULONG ulProtocolVersion;// Protocol version. Currently must be 100 (1.0) OUT USHORT cNumTransmitPorts;// Number of transmit ports – 0-32 OUT USHORT cNumReceivePorts;// Number of receive ports – 0-32 (For beanbag, this is // two (one for learning, one for normal) OUT ULONG LearningReceiverMask;// Bitmask identifying which receivers are // learning receivers – low bit is the first // receiver, second-low bit is the second receiver, etc OUT ULONG grfFlags;// Device flags (see below) } IrDevCaps; Values for IrDevCaps::grfFlags #define fSupportsLegacySigning 0x0001;// Hardware supports legacy key signing #define fHasUniqueSerialNumber 0x0002;// Hardware has unique serial number #define fCanFlashReceiverLed 0x0004;// Can hardware flash LED to identify // receiver? #define fIsLegacy 0x0008;// Is this a legacy device? #define fWakeFromS1 0x0010;// device can wake from S1 #define fWakeFromS2 0x0020; // device can wake from S2 #define fWakeFromS3 0x0040; // device can wake from S3 #define fWakeFromS4 0x0080; // device can wake from S4 #define fWakeFromS5 0x0100; // device can wake from S5 IRBus allocates IrDevCaps structure, passes in lpInBuffer. Port driver sets structure values based on device capabilities.

IOCTL_IR_TRANSMIT Parameters: lpInBuffer – pointer to caller-allocated IrTransmitParms structure nInBufferSize – sizeof(IrTransmitParms) lpOutBuffer – pointer to caller-allocated buffer with IR. nOutBufferSize – size of caller-allocated buffer. Used to figure out the number of IR lpBytesReturned – returns 0 if non-null Structures: typedef struct _IrTransmitParms { IN ULONG ulTransmitPortMask;// Bitmask containing ports to transmit on. IN ULONG ulCarrierFrequency;// Carrier frequency to use in Hz. If zero, grfFlags // needs to define DC mode or pulse mode. IN ULONG grfFlags;// Flags – see below IN ULONG ulPulseSize;// If pulse mode is set, this contains the length of pulse // to use. OUT ULONG SamplePeriod;// Sample period to use. } IrTransmitParms; Values for IrTransmitParms::grfFlags #define fPulseMode 0x0001// Use pulse mode #define fDCMode 0x0002// Use DC mode IRBus allocates and fills IRTransmitParms structure Port driver emits this IR.

Building IR Data Stream for Transmission Media Center reads IR database and builds RLC for channel change Includes – number of digits, spacing, repeat patterns, enter key Format = string of numbers IRBUS translates to stream of bytes Port Driver interprets stream and emits IR Sample Period defines translation. Typically 50 μSec. Also defines resolution. High bit clear = pulse high. High bit set = pulse low Low 7 bits = time in “sample period” increments If byte stream = “0x35 0x91 0x08 0x88 ….” this means. 0x35 = high for 2650 μSec (=0x35 * 50 μSec) 0x91 = low for 850 μSec (high bit set, 0x11 * 50 μSec = 850) 0x08 = high for 400 μSec 0x88 = low for 400 μSec And so on…

IR Data Stream for Transmission Example x35 0x91 0x08 0x88 0x08 0x88 0x08 0x91 0x08 0x91 0x1A 0x91 0x08 0x88 0x08 0x88 0x08 0x88 0x08 0x88 0x08 0x88 0x08 0x88 0x08 0x88 0x08 0x88 0x08 0x88 0x08 0x88 0x11 0x88 0x08 0x88 0x08 0x88 0x08 0x91 0x08 0x88 0x08 0x88 0x08 0x88 0x08 0x88 0x11 0x91 0x08 0x88 0x08 0x88 0x08 0x88 0x08 0x88 0x08 0x88 0x08 0x88 0x08 0x88 0x08 0x88 0x08 0x88 0x08 IRBUS gives the following data stream to Port Driver In RLC this means…. Hardware emits the following IR stream

IOCTL_IR_RECEIVE Parameters: lpInBuffer – pointer to caller-allocated IrReceiveParms structure nInBufferSize – sizeof(IrReceiveParms) lpOutBuffer – pointer to caller-allocated buffer to receive IR. nOutBufferSize – sizeof buffer in bytes lpBytesReturned – returns number of bytes in buffer after reception. Structures: typedef struct _IrReceiveParms { IN ULONG iReceiver;// Index of the receiver to use IN ULONG ulTimeOut;// Timeout value, in μsec. Used to define // the end of a given sample. OUT BOOL fFirst;// Is this the first buffer of a given sample? OUT BOOL fMore;// Is there more IR data waiting. OUT ULONG ulCarrierFrequency;// Carrier frequency received OUT ULONG SamplePeriod;// Sample period used to construct buffer } IrReceiveParms; User Scenario Processing RLC IR input from the remote control Used during first run to identify set top box remote control IRBUS allocates & fills IRReceiveParms, allocates IR buffer. Port driver fills IR buffer.