Building IR Transceivers for Media Center

Michelle NiethammerProgram ManagerWindows eHome DivisionMichni @ microsoft.comMicrosoft Corporation

Bert KleeweinSoftware Design EngineerWindows eHome Division bertk @ microsoft.comMicrosoft Corporation

Session OutlineSession 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 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 enablingExposing 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 changeSimplify integration into other components

Reduce costs

Speed Innovation

Components of the IR TransceiverComponents of the IR Transceiver

Remote Control Input – 10ftReceives commands from Remote Control

Enables “Parse and Match” – ability to identify remote control based on IR data sample

Learning – 2-3 inchesCaptures IR from Set-Top Box Remote Controls to Retransmit

EmittingSends 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

SystemResume from Standby

Hardware Requirements for Media Center Hardware Requirements for Media Center

Receiving IR Data (Input)Support carrier frequencies from 32kHZ to 56kHZ Receive and Send IR SimultaneouslyRelay raw IR timing data

Learning IR DataSupport carrier frequencies from 32kHZ to 455kHZAbility to capture raw IR data streamAbility to capture IR carrier frequency

Transmitting IR Data (Emitting)Support carrier frequencies from 32kHZ to 455kHZSupport independent IR Transmitter jacks (2 minimum)Send and receive IR simultaneouslyIR Emitters can be placed 5 meters from PCIR emitters are stick onIR emitters use visible LED

System Resume from Standby

S1 or S3 required, S4 or S5 optionalBlink Receiver DeviceStore and return wake identifier

Protocol for IR InputProtocol for IR Input

Determine IR protocol you are going to receiveMicrosoft 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 RC6Contact RemoteMC @ 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 101IR Protocol 101

Consumer IR IRDA

Signal Range 0-50 feet line of sight 3-6 feet

Transmission Low speed one-way (typically)

High speed – 9600 – 4mbs bi-directional

Discoverable by other like devices of site

No Yes

Cost Inexpensive 10x 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:Provided by:

MicrosoftMicrosoft

IHVIHV

Port driver deals in Bit Banged IR (raw waveform)

IRBUS converts waveform into payload

HIDIR converts payload into keypress

Typical IR packetTypical IR packet

Carrier Frequency: 36kHzRLC: 2656 -888 444 -444 444 -444 444 -888 444 -888 1332 -888 444 -444 444 -444 444 -444 444 -444 444 -444 444 -444 444 -444 444 -444 444 -444 444 -444 888 -444 444 -444 444 -444 444 -888 444 -444 444 -444 444 -444 444 -444 888 -888 444 -444 444 -444 444 -444 444 -444 444 -444 444 -444 444 -444 444 -444 444 -444 444

Protocol = RC-6, payload = 0x800F8400

Idealized waveform as seen by hardware

Run Length Coded data passed up to IRBUS

Payload decoded by IRBUS

Final keypressKey = channel up

Hardware/Port Driver Requirements Hardware/Port Driver Requirements

WDF requiredWindows Logo Program qualificationYou build the hardware. You write the port driverHandle PNP and power states as appropriatePort driver provide 7 services (implemented as IOCTLs)

What are your capabilities?What emitters are connected?Flash an LED that the user can seeTransmit this IRListen for IRWake from lower power stateDid you wake the system?

You decide how the port driver talks to the hardwarePublished in future version of the DDKDetails/parameters may change

1. What are Your Capabilities? 1. What are Your Capabilities?

IOCTL_IR_GETDEVCAPS

User ScenarioIdentifies 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? 2. What Emitters Are Connected?

IOCTL_IR_GETEMITTERS

User ScenarioDetermine 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 See3. Flash an LED That the User Can See

IOCTL_IR_FLASHRECEIVER

User scenarioIdentify 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 remoteActive receiver may not have learning capability

No parameters. Device should flash LED for 5 seconds.

4. Transmit This IR4. Transmit This IR

IOCTL_IR_TRANSMIT

User ScenarioSending 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 RLCMultiple key presses separated by silence

Port driver/hardware responsible for enforcing timing50 ms pause cannot become 250 ms pause

5. Listen for IR5. Listen for IR

IOCTL_IR_RECEIVE

User ScenarioListening 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 State6. Wake from Lower Power State

User ScenarioCreate 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)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?7. Did You Wake the System?

IOCTL_IR_GETWAKESOURCE

User ScenarioUser 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

HeuristicWhen 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 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 rememberRF or Bluetooth add cost

Does not eliminate need for IR receiverStill need all functions in receiver to support set-top box control

Exceptions are TV tuner solutions not requiring IR blastingDVB-t, HDTV

RF may require a dongle

Likely to be too much interference to integrate into PC

Setup is more difficultTeach devices

Have to worry about neighborsDifferent channels

Encryption/security

Write HID drivers for your devicePlenty of HID driver samples are available (DDK)

HID usages for remote control part of DDK

Qualification Qualification

DriverIR 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 transceiverUSB Device

TV Tuner Device

IR Transceiver

HardwareIR 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 MicrosoftTechnical Design Review FacilitationLogo/Device Qualification AssistanceBeta Program Nomination & SupportPost Release Support (Driver Development,OEM Preinstall Kit)

MSDNAnnual Subscription

PSSProduct Specific Issue Reporting

Development Support OptionsDevelopment Support Options

For further information, please contact:Carey Morgan: cmorgan @ microsoft.com

Call To ActionCall To Action

Make sure you understand hardware and driver requirements

Start planning your specific hardware implementation

OEMs will want to test hardware duringLonghorn Beta 2

Contact remotemc @ microsoft.com to signup for more information and to get started

Community ResourcesCommunity Resources

Windows Hardware & Driver Central (WHDC)www.microsoft.com/whdc/default.mspx

Technical Communitieswww.microsoft.com/communities/products/default.mspx

Non-Microsoft Community Siteswww.microsoft.com/communities/related/default.mspx

Microsoft Public Newsgroupswww.microsoft.com/communities/newsgroups

Technical Chats and Webcastswww.microsoft.com/communities/chats/default.mspx

www.microsoft.com/webcasts

Microsoft Blogswww.microsoft.com/communities/blogs

Additional ResourcesAdditional Resources

Web Resources:http://www.microsoft.com/whdc/system/platform/mediacenter

http://www.microsoft.com/whdc/driver/wdf/default.mspx

© 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 ModeKernel Mode

TBD IR #1 TBD IR

Device IR Stack Device IR Stack

IR Transceiver

V1

LPC Chipset IR Hardware

Provided by:

Microsoft

IHV

IR Transceiver

V2

IR Transceiver

V3

IOCTL_IR_GETDEVCAPS 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-32OUT 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, etcOUT 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 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 TransmissionBuilding 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 2656 -888 444 -444

IRBUS translates to stream of bytes

Port Driver interprets stream and emits IRSample 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 ExampleIR Data Stream for Transmission Example

2656 -888 444 -444 444 -444 444 -888 444 -888 1332 -888 444 -444 444 -444 444 -444 444 -444 444 -444 444 -444 444 -444 444 -444 444 -444 444 -444 888 -444 444 -444 444 -444 444 -888 444 -444 444 -444 444 -444 444 -444 888 -888 444 -444 444 -444 444 -444 444 -444 444 -444 444 -444 444 -444 444 -444 444 -444 444

0x35 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_RECEIVEIOCTL_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 ScenarioProcessing 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.