View
217
Download
3
Category
Tags:
Preview:
Citation preview
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.
Recommended