XMP™ Software Developer Kit Station XMP- 1 Work Order: 5100645 Release 1
26 August 2002
Software Developer Kit
rev. 1v0 UEI Confidential
26- August- 2002
XMP™ Station Software Developer Kit XMP- 1
page 1
Revision History Date 12 Sep 2001 26 Aug 2002
revision A 1
Software Developer Kit
Description First release all XMP specification in one doc Change all references to XMP- 1 and condensed
rev. 1v0 UEI Confidential
26- August- 2002
XMP™ Station Software Developer Kit XMP- 1
page 2
Table of Contents 1
PURPOSE AND SCOPE ................................................................................. 4 1.1 1.2 1.3 1.4
2
CHAPTER NAMES AND D ESCRIPTIONS ................................................................. 4 SUGGESTED ORDER OF REVIEW ....................................................................... 4 ADDITIONAL I NFORMATION ............................................................................. 4 TECHNICAL ASSISTANCE ................................................................................ 4
XMP™ INTEGRATION REQUIREMENTS ......................................................... 5 2.1 OVERVIEW OF I MPLEMENTATION LEVELS .............................................................. 5 2.1.1 XMP Condensed ™ ............................................................................... 5 2.1.2 XMP- 1 ™ ............................................................................................ 5 2.1.3 XMP- 2 ™ ............................................................................................ 5 2.1.4 XMP- 4 ™ ............................................................................................ 6 2.2 FUNCTIONAL ORGANIZATION ........................................................................... 6 2.3 FUNCTIONAL BLOCK D ESCRIPTIONS ................................................................... 6 2.3.1 38 KHz Demodulation ......................................................................... 6 2.3.2 Pulse Capture and PPM/PWM Decode .................................................... 7 2.3.3 Checksum Validation .......................................................................... 7 2.3.4 Owner Validation ............................................................................... 7 2.3.5 Tag Validation ................................................................................... 7 2.3.6 Slot Validation ................................................................................... 8 2.3.7 End- of- Cycle Synthesis ....................................................................... 8 2.3.8 PPM/PWM Encode............................................................................... 8 2.3.9 Pulse Generation................................................................................ 8 2.3.10 38 KHz Modulation .......................................................................... 8 2.3.11 Payload Extraction........................................................................... 8 2.3.12 Registry Determination .................................................................... 9 2.3.13 Direction to Driver........................................................................... 9 2.4 AUTOMATIC D ETECTION OF PROTOCOL LEVEL ........................................................ 9
3
XMP- 1 IR LAYER SPECIFICATION ............................................................. 10 3.1 3.2 3.3 3.4 3.5 3.6
4
UNITS AND TOLERANCES ............................................................................. 10 SPECTRAL REQUIREMENTS ............................................................................ 10 CARRIER CYCLE ........................................................................................ 10 PULSE FORMATS ....................................................................................... 10 D ATA PULSE POSITION MODULATION ............................................................... 11 PERIPHERAL- TO- STATION PACKET FORMAT......................................................... 11
XMP- 1 PACKET LAYER SPECIFICATIONS ................................................... 12 4.1 PACKET LAYER – IR INBOUND ....................................................................... 12 4.2 EXAMPLE PERIPHERAL D ATA PACKET FORMATS: ................................................... 14 4.3 STATION TRANSCEIVER (TS CONTROLLER) – IR PROTOCOL POLICIES ......................... 17 4.3.1 Inter- packet Spacing ........................................................................ 17 4.3.2 Peripheral Ownership........................................................................ 17 4.3.3 Peripheral Addressing ....................................................................... 17 4.3.4 Unidirectional Tagging ...................................................................... 17 4.3.5 XMP- Condensed Packets ................................................................... 17
5
XMP™ DEVICE DRIVER POLICIES .............................................................. 18 5.1 5.2 5.3 5.4 5.5
OVERVIEW .............................................................................................. 18 KEY STATE CHANGE ................................................................................... 18 KEY ACTIVITY .......................................................................................... 18 KEY ACTIVE/BREAK ................................................................................... 18 TIMING POLICIES ...................................................................................... 19
Software Developer Kit
rev. 1v0 UEI Confidential
26- August- 2002
XMP™ Station Software Developer Kit XMP- 1
page 3
5.5.1 Key Down Timeout ........................................................................... 19 5.5.2 Peripheral Key Repetition .................................................................. 19 5.5.3 Character Repetition (“Typematic Rate”) ............................................. 19 5.6 RESEND PACKET FILTERING ........................................................................ 20 5.7 TRUTH TABLES FOR PACKET VALIDATION (KEY ACTIVITY SCHEME) ............................. 20 APPENDIX 1 - IR Reception Requirements APPENDIX 2 – Timing Diagram APPENDIX 3 – XMP™ Protocol Formulas APPENDIX 4 – Peripheral Registration Policies
Software Developer Kit
rev. 1v0 UEI Confidential
26- August- 2002
XMP™ Station Software Developer Kit XMP- 1
page 4
1 Purpose and Scope 1.1
Chapter Names and Descriptions
XMP Integration Requirements Explanation of XMP integration options. XMP- 1 IR Layer Specification Specifications for the infrared layer. XMP- 1 Packet Layer Specification Specifications for the packet layer. XMP™ Device Driver Policies Guidelines for device driver implementation. Appendix; XMP- 1
IR Timing Diagram Diagram of infrared pulse timings.
Annex; XMP- 1
Device Driver Pseudo Code .C Sample pseudo code for device driver.
1.2
Suggested Order of Review
The “Integration Requirements” should be reviewed first to confirm (a) that “XMP- 1” is the appropriate level of implementation for reader’s project and (b) that the platform architecture is able to support integration of the XMP codec. Review of the “Timing Diagram” (Appendix) should be next. This will familiarize the reader with basic organization and sequencing of infrared pulses arriving at the photodetector. The “Decoder Source Code” is used to extract the data payload from arriving infrared packets. These payload structures, illustrated in the “Packet Layer Specification”, are presented to the appropriate device driver for mapping of peripheral events to the platform’s OS queues for alphanumeric input, mouse movement, and multimedia commands. Device drivers should be implemented from the “Driver Pseudo Code” or at least with reference to the “Driver Policies”. Assuming use of UEI standard link controllers or direct use of UEI source code, the reader may omit review of the “IR Layer Specification” and “Timing Diagram”. NOTE: Provision for installation of the additional components required for quad device operation may be appropriate to facilitate future protocol upgrades.
1.3
Additional Information
Payload specifications are available for all XMP compatible devices. These documents describe the definition and organization of bits in the packet payload from each respective device.
1.4
Technical Assistance
Questions are expected. You may request assistance in several ways: By telephone: Call Universal Electronics at +1 714 820 1000 By email: Email your questions to
[email protected]. Thanks for choosing the XMP technology for your project.
Software Developer Kit
rev. 1v0 UEI Confidential
26- August- 2002
XMP™ Station Software Developer Kit XMP- 1
page 5
2 XMP™ Integration Requirements This chapter introduces the various levels of XMP implementation and the respective requirements for transceiver design. Presentation is from the perspective of the platform, or "fixed", end of the link “Station”, but this subject material is also appropriate background reading for designers of peripherals to operate at the "mobile" end of the link. Notes; All times are in microseconds unless otherwise noted.
2.1
Overview of Implementation Levels
The XMP Protocol IR Layer may currently be implemented at four different levels. Lowest cost implementation employs a unidirectional link, handling (30) packets per second from one peripheral at a time, and configured for either Condensed (combined registry and data packet) or Standard (separate registry and data packets) reporting. Recovery from errors is added by implementing the infrared return path for a bidirectional link between the peripheral and platform. The most comprehensive implementation of XMP again employs a bidirectional link but increases reporting rate to (120) packets per second, (30) per second from each of up to four peripherals operating simultaneously. The two unidirectional levels are referred to as XMP Condensed and XMP- 1 respectively. The two bidirectional levels are referred to as XMP- 2 and XMP- 4.
2.1.1 XMP Condensed ™ One- way (unidirectional) link. Lowest cost implementation. Standard LED in the mobile unit. Standard photodetector in the fixed unit. Long- range, wide- angle operation on 50 mW/sr of optical power. Lowest power consumption in the mobile unit. Reporting rate up to (80) packets per second. 32- bit packet format combines both registry and payload data. Payload size of 12 bits per packet.
2.1.2 XMP-1™ Separate 32- bit packets respectively for registry and payload data. Reporting rate up to (80) packets per second. Payload size of 20 bits per data packet.
2.1.3 XMP-2™ Two- way (bidirectional) link. Provides recovery from link errors. Adds standard photodetector in the mobile unit and LED in the fixed unit. Reporting and acknowledgement of up to (80) packets per second.
Software Developer Kit
rev. 1v0 UEI Confidential
26- August- 2002
XMP™ Station Software Developer Kit XMP- 1
page 6
2.1.4 XMP-4™ Two- way (bidirectional) link. Allows simultaneous operation of four peripherals. Requires specific photodetectors in both fixed and mobile units. Separate 30- bit packets respectively for registry and payload data. Reporting rate up to (120) packets per second. Payload of 22 bits per data packet. XMP- Condensed is recommended for simple remote control applications. XMP- 1 and XMP- 2 are recommended for keyboard applications. XMP- 4 is only required when simultaneous multiplayer operation is necessary, such as during game play.
2.2
Functional Organization
Transception of XMP can be divided into functional blocks as illustrated. Respective realization of particular blocks in software, firmware, and/or hardware varies for each implementation.
XMP- Condensed, XMP- 1, and XMP- 2 handle one device at a time. The response stack from "End- of- Cycle Synthesis" down thru "38 KHz Modulation", required for XMP- 2 and XMP- 4, is executed after each incoming packet. XMP- 4 handles simultaneous operation of four peripherals. After each incoming XMP- 4 packet, an acknowledgement pulse is generated following "Slot Validation". After every fourth XMP- 4 slot, the entire response stack is executed. No response stack implementation is required for decoding of XMPCondensed or XMP- 1.
2.3
Functional Block Descriptions
2.3.1 38 KHz Demodulation All pulses of infrared light are modulated on the industry- standard 38 KHz carrier frequency. Demodulation of this carrier at receiving nodes is generally realized in a discrete photodetector that comprises photodiode, amplifier with gain control, bandpass filter, and demodulator.
Software Developer Kit
rev. 1v0 UEI Confidential
26- August- 2002
XMP™ Station Software Developer Kit XMP- 1
page 7
2.3.2 Pulse Capture and PPM/PWM Decode The XMP specifications include tolerances for pulse length and spacing. Validation of incoming pulses against these tolerances is important to ensure rejection of non- XMP infrared activity. PPM decoding for XMP- Condensed, XMP- 1, and XMP- 2 packets, or PPM plus PWM for XMP- 4 packets, is performed after the pulses have been validated. Implementation may either provide for capture of multiple pulses before validation and decode, or may validate and decode each incoming pulse upon arrival. Systems that validate each pulse upon arrival are able to sooner reject non- XMP activity and restart the listening process. Conversely, systems, which delay validation and decode until after reception of multiple pulses, may miss a valid packet while attempting to process spurious infrared light. It should be noted that the ambient lighting in a typical home includes several “glitches” per second in the infrared spectrum. Processing one pulse at a time allows instantaneous recovery from these events, usually without loss of any XMP packets. Pulse processing burdens may be estimated by reference to the following criteria: XMP Condensed XMP 1 XMP 2 XMP- 4 Pulses per Incoming Packet: Minimum Duration of Incoming Packet: Typical Duration of Incoming Packet: Maximum Duration of Incoming Packet: Average Number of Incoming Packets per Second: Maximum Number of Incoming Packets per Second: Required Timing Accuracy for Leading Edge to Leading Edge: Required Timing Accuracy for Pulse Width:
9 8.7 16.4 25.1 45 80 ±5 - 25/+50
7 2.2 6.6 9.7 124 160 ±2 ±10
Units
msec msec msec
usec usec
2.3.3 Checksum Validation Each XMP packet contains a checksum of its contents. Packets that contain invalid checksums either are ignored or cause the response stack to transmit an exception packet to the peripheral.
2.3.4 Owner Validation1 XMP- 1 and XMP- 2 peripherals include an owner code in each packet to designate the fixed transceiver (box) to which the peripheral belongs. Packets whose owner code does not match the owner code of the receiving station are ignored.
2.3.5 Tag Validation XMP- 1 and XMP- 2 peripherals issue a registration packet before sending any data packets. Registration packets may be uniquely identified by reference to the packet contents. Upon registration, these peripherals are assigned a tag for purposes of directing the payload of subsequent data packets to the appropriate OS event handler (Driver), thus allowing multiple reporting channels to be alternatively active. Data packets that contain unregistered tags cause the response stack to transmit an exception packet to the peripheral.
1
XMP- Condensed does not support Owner and Tag.
Software Developer Kit
rev. 1v0 UEI Confidential
26- August- 2002
XMP™ Station Software Developer Kit XMP- 1
page 8
2.3.6 Slot Validation2 Upon registration, XMP- 4 peripherals are assigned to one of four inbound transmission slots. Packets received in unregistered slots cause the response stack to include exception flags in the next End- of- Cycle packet.
2.3.7 End-of-Cycle Synthesis3 XMP transceivers are required to transmit an end- of- cycle packet after reception of every packet or four slots respectively during XMP- 2 or XMP- 4 operations. EOC packet transmission must start within four milliseconds after the end of incoming XMP- 1 packets. For XMP- 4, transmission must start within four milliseconds after the end of the packet in the fourth slot, or within 16 milliseconds after the end of the third slot if the fourth slot is empty.
2.3.8 PPM/PWM Encode PPM encoding for XMP- 2 packets, or PPM and PWM for XMP- 4 packets, are required on outbound EOC packets. Eight bits of synthesized response data are represented in two 16PPM values for XMP- 2. Twenty bits of synthesized response data are represented in five 8PPM values and five 2PWM values for XMP- 4. During simultaneous registration of peripherals, XMP- 4 responses include up to thirty additional bits represented by up to ten additional PPM values. During download of payload data to any peripheral, XMP- 4 responses include up to (207) additional bits represented by up to (69) additional 8PPM values.
2.3.9 Pulse Generation Pulse generation burdens may be estimated by reference to the following criteria: XMP- 2 Pulses per Outbound Packet (normal): Maximum Pulses per Outbound Packet (registrations): Maximum Pulses per Outbound Packet (download): Maximum Duration of Outbound Packet: Average Number of Outbound Packets per Second: Maximum Number of Outbound Packets per Second: Required Timing Accuracy for Leading Edge to Leading Edge: Required Timing Accuracy for Pulse Width:
3 NA NA 8 45 80 ±5 - 25/+50
XMP- 4 5 15 84 6 31 40 ±2 ±10
Units
msec
usec usec
2.3.10 38 KHz Modulation Modulation of outbound pulses onto a 38 KHz carrier is required.
2.3.11 Payload Extraction After tag or slot validation, the transceiver may extract 12, 20, or 22 bits of payload from XMP- Condensed, XMP- 1 and XMP- 2, or XMP- 4 packets, respectively, for propagation to the OS and/or application software. For dongles, this is the step at which reformatting occurs for the upstream data link.
2
Applicable to XMP- 4 only. End- of- Cycle Synthesis, PPM/PWM Encode, Pulse Generation, and 38 KHz Modulation are not applicable to XMP- Condensed and XMP- 1. 3
Software Developer Kit
rev. 1v0 UEI Confidential
26- August- 2002
XMP™ Station Software Developer Kit XMP- 1
page 9
2.3.12 Registry Determination Upon reception of registration packets, the platform software examines a Registry Number included in the payload. Using the Registry Number as an index, any required information including driver association is extracted from a resident or remote database. The appropriate driver is loaded and the incoming tag value is remembered for driver association for subsequent data packets containing the same tag value.
2.3.13 Direction to Driver Payload from data packets is steered to the appropriate driver by reference to the tag value for XMP- 1 and XMP- 2, or Slot number for XMP- 4.
2.4
Automatic Detection of Protocol Level
XMP transceivers operate in a specific mode at any given point in time. Mode is asserted at start- up, and then only changed upon command from the application software, and/or upon recognition of XMP activity only valid in a non- active mode. The modes are distinguished by examination of the checksum value.
Software Developer Kit
rev. 1v0 UEI Confidential
26- August- 2002
XMP™ Station Software Developer Kit XMP- 1
page 10
3 XMP-1 IR Layer Specification 3.1
Units and Tolerances
All times are in microseconds unless otherwise specified. All tolerances are ±0% unless otherwise specified.
3.2
Spectral Requirements
Light Wavelength: 940 nm Optical Intensity: 50 mW/sr for 10- meter linear operating range.
3.3
Carrier Cycle
Nominal Carrier Frequency: 38KHz Nominal Duty Cycle: 33%
LED ON 8.77 +0.5/-0.0
26.31 ± 0.5
3.4
Pulse Formats
Encoding:
Peripheral Header and Data
8 Carrier Cycles
Decoding:
535.98 max width Peripheral Header and Data
Software Developer Kit
131.55 min
rev. 1v0 UEI Confidential
26- August- 2002
XMP™ Station Software Developer Kit XMP- 1
3.5
page 11
Data Pulse Position Modulation
Encoding:
(969.98 + (n x 136.71)) ± 2.7
Peripheral PPM Bit 0 ≤ Data Value (n) ≤ 15
Decoding:
1038.33 + (n x 136.71) - 13.02 max
Peripheral PPM Bit 0 ≤ Data Value (n) ≤ 15
3.6
901.63 + (n x 136.71) + 13.02 min
Peripheral-to-Station Packet Format
Nibble 0
Nibble 1
Header Pulse
Software Developer Kit
Nibble 2
Nibble 3
Nibble 4
Nibble 5
Nibble 6
Nibble 7
8 Data Pulses
rev. 1v0 UEI Confidential
26- August- 2002
XMP™ Station Software Developer Kit XMP- 1
page 12
4 XMP-1 Packet Layer Specifications This chapter describes the packet formats utilized by the XMP- 1 infrared protocol. Both general packet formats and specific examples are provided. Presentation is from the perspective of the Station Transceiver, or “fixed”, end of the link.
4.1
Packet Layer – IR Inbound
General Packet Format:
0 1 2 3
7 6 5 4 3 2 D23 D22 D21 D20 S3 S2 D19 D18 D17 D16 T3 T2 D15 D14 D13 D12 D11 D10 D7 D6 D5 D4 D3 D2
S3- S0 T3- T0 D23- D0
1 S1 T1 D9 D1
0 S0 T0 D8 D0
Checksum4 Peripheral’s Tag or Special Command5 Peripheral/Command specific data
General Registration Packet or Data Packet Format:
0 1 2 3
7 6 5 4 3 2 N3 N2 N1 N0 S3 S2 D19 D18 D17 D16 T3 T2 D15 D14 D13 D12 D11 D10 D7 D6 D5 D4 D3 D2
1 S1 T1 D9 D1
0 S0 T0 D8 D0
N3- N0 Owner (setup by user) (default = 0)6 S3- S0 Checksum7 T3- T0 Peripheral’s Tag or Special Command8 D19- D0 Peripheral/Command specific data Peripheral Registration Packet Formats: Peripheral Identification for Basic Registry
0 1 2 3
7 N3 T3 0 R7
N3- N0 S3- S0 T3- T0 R14- R0
6 5 4 3 2 N2 N1 N0 S3 S2 T2 T1 T0 1 1 R14 R13 R12 R11 R10 R6 R5 R4 R3 R2
1 S1 1 R9 R1
0 S0 1 R8 R0
Owner (setup by user) (default = 0) Checksum Tag from Peripheral Basic Registry Number9
4
Checksum is that number which causes the mod- 16 addition of the eight nibbles to equal the appropriate Checksum Result. For Registration Packets and Data Packets the Checksum Result is zero (0). For Condensed (Registration & Data) Packets the Checksum Result is seven (7). 5 Peripheral Tags range from 0000 to 1101. Special commands range from 1110 to 1111. 6 Peripherals will respond to Acknowledge packets matching their own Owner as well as packets containing Owner = 0000. 7 Checksum is that number which causes the mod- 16 addition of the eight nibbles to equal zero. 8 Peripheral Tags range from 0000 to 1101. Special commands range from 1110 to 1111.
Software Developer Kit
rev. 1v0 UEI Confidential
26- August- 2002
XMP™ Station Software Developer Kit XMP- 1
page 13
General Peripheral Data Packet Format:
0 1 2 3
7 6 5 4 3 2 N3 N2 N1 N0 S3 S2 D19 D18 D17 D16 T3 T2 D15 D14 D13 D12 D11 D10 D7 D6 D5 D4 D3 D2
N3- N0 S3- S0 T3- T0 D19- D0
1 S1 T1 D9 D1
0 S0 T0 D8 D0
Owner (setup by user) (default = 0)10 Checksum Tag (as returned with Acknowledge Packet) Peripheral specific data
9
Registry numbers are assigned by UEI. The registry number is used as a pointer into a table whose contents identify the peripheral’s manufacturer, product name, model number, product type, revision, A/B channel and packet format. 10 Peripherals will respond to Acknowledge packets matching their own Owner Value as well as packets containing Owner Value = 0000.
Software Developer Kit
rev. 1v0 UEI Confidential
26- August- 2002
XMP™ Station Software Developer Kit XMP- 1
4.2
page 14
Example Peripheral Data Packet Formats:
Keyboard
0 1 2 3
7 6 N3 N2 RPT RSN K7 K6 CNTL SHIFT
N3- N0 S3- S0 RPT RSN TBD T3- T0 K7- K0 CNTL SHIFT ALT M1 M2
5 4 N1 N0 TBD TBD K5 K4 ALT M1
3 S3 T3 K3 M2
2 1 0 S2 S1 S0 T2 T1 T0 K2 K1 K0 TBD TBD TBD
Owner (setup by user) (default = 0) Checksum Key Repeat Flag (repeat of last key = 1) Resending due to lack of Acknowledgement11 Reserved (default = 0) Tag (as returned with Acknowledge Packet) Key Scan Code Control Key (active = 1) Shift Key (active = 1) Alt Key (active = 1) Reserved Modifier Key 1 Reserved Modifier Key 2
Absolute Pointer and Buttons
0 1 2 3
7 N3 X8 X7 Y7
N3- N0 S3- S0 X8- X0 Y8- Y0 B1 B2 T3- T0 X7- X0 Y7- Y0
6 N2 Y8 X6 Y6
5 N1 B1 X5 Y5
4 N0 B2 X4 Y4
3 S3 T3 X3 Y3
2 S2 T2 X2 Y2
1 S1 T1 X1 Y1
0 S0 T0 X0 Y0
Owner (setup by user) (default = 0) Checksum X Coordinate MSB Y Coordinate MSB Button 1 (left) (active = 1) Button 2 (right) (active = 1) Tag (as returned with Acknowledge Packet) X Coordinate (0..511, origin = left edge) Y Coordinate (0..511, origin = lower edge)
Relative Pointer and Buttons
0 1 2 3 N3- N0 S3- S0 RSN
7 N3 B3 X7 Y7
6 N2 RSN X6 Y6
5 N1 B1 X5 Y5
4 N0 B2 X4 Y4
3 S3 T3 X3 Y3
2 S2 T2 X2 Y2
1 S1 T1 X1 Y1
0 S0 T0 X0 Y0
Owner (setup by user) (default = 0) Checksum Resending due to lack of Acknowledgement12
11
Used to avoid duplicate packets due to loss of Acknowledgment. Support for this bit isn’t mandatory.
Software Developer Kit
rev. 1v0 UEI Confidential
26- August- 2002
XMP™ Station Software Developer Kit XMP- 1 B1 B2 B3 T3- T0 X7- X0 Y7- Y0 TBD
page 15
Button 1 (left) (active = 1) Button 2 (right) (active = 1) Button 3 (middle) (active = 1) Tag (as returned with Acknowledge Packet) X Delta (- 128..127, right is positive) 2s complement Y Delta (- 128..127, up is positive) 2s complement Reserved (default = 0)
Data Uplink
0 1 2 3
7 6 5 4 3 2 N3 N2 N1 N0 S3 S2 TBD RSN C1 C0 T3 T2 D15 D14 D13 D12 D11 D10 D7 D6 D5 D4 D3 D2
N3- N0 S3- S0 TBD RSN C1- C0
T3- T0 D15- D0
1 S1 T1 D9 D1
0 S0 T0 D8 D0
Owner (setup by user) (default = 0) Checksum Reserved (default = 0) Resending due to lack of Acknowledgement13 Cycle Type: 00 = use data as starting address 01 = single byte of data in D7- D0 10 = word of data 11 = single last byte Tag (as returned with Acknowledge Packet) Data Byte(s)
Keyboard (Extended Modifier Handling) 7 6 5 4 3 2 1 0 0 N3 N2 N1 N0 S3 S2 S1 S0 1 RPT RSN TBD TBD T3 T2 T1 T0 2 K7 K6 K5 K4 K3 K2 K1 K0 3 CNTL SHIFT ALT M1 M2 CNTL SHIFT ALT (Left) (Left) (Left) (Right) (Right) (Right) N3- N0 S3- S0 RPT RSN TBD T3- T0 K7- K0 CNTL SHIFT ALT M1 M2
Owner (setup by user) (default = 0) Checksum Key Repeat Flag (repeat of last key = 1) Resending due to lack of Acknowledgement14 Reserved (default = 0) Tag (as returned with Acknowledge Packet) Key Scan Code Control Key (active = 1) Shift Key (active = 1) Alt Key (active = 1) Reserved Modifier Key 1 (active = 1) Reserved Modifier Key 2 (active = 1)
12
Used to avoid duplicate packets due to loss of Acknowledgment. Support for this bit isn’t mandatory. 13 Used to avoid duplicate packets due to loss of Acknowledgment. Support for this bit isn’t mandatory. 14 Used to avoid duplicate packets due to loss of Acknowledgment. Support for this bit isn’t mandatory.
Software Developer Kit
rev. 1v0 UEI Confidential
26- August- 2002
XMP™ Station Software Developer Kit XMP- 1
page 16
If there is an active key that doesn’t have an associated modifier flag then its scan code will be reported. All active modifier keys will have their respective modifier flags set. The left and right keys for a specific modifier are independently selectable. If there aren’t any active keys that don’t have an associated modifier flag then one of the active modifier keys will have its scan code reported and its associated modifier flag cleared. All other active modifier keys will be reported at the same time by having their respective modifier flags set. The order of precedence when determining which modifier scan code to send is as follows, Left CONTROL, Right CONTROL, Left SHIFT, Right SHIFT, Left ALT, Right ALT, Modifier 1, Modifier 2.
General Peripheral Condensed (Registration & Data) Packet Format:
0 1 2 3
7 R7 R3 1 D7
S3- S0 R9- R0 D11- D0 TBD
6 R6 R2 TBD D6
5 R5 R1 R9 D5
4 R4 R0 R8 D4
3 2 S3 S2 1 1 D11 D10 D3 D2
1 S1 1 D9 D1
0 S0 1 D8 D0
Checksum15 Basic Registry Number16 – 16,384 Peripheral specific data Reserved (default = 0)
Example Peripheral Condensed Packet Formats: Remote Control
0 1 2 3 S3- S0 R9- R0 RPT CNTL SHIFT ALT K7- K0 TBD
7 R7 R3 1 K7
6 R6 R2 TBD K6
5 R5 R1 R9 K5
4 R4 R0 R8 K4
3 2 1 0 S3 S2 S1 S0 1 1 1 1 RPT CNTL SHIFT ALT K3 K2 K1 K0
Checksum Basic Registry Number – 16,384 Key Repeat Flag (repeat of last key = 1) Control Key (active = 1) Shift Key (active = 1) Alt Key (active = 1) Key Scan Code Reserved (default = 0)
15
Checksum is that number which causes the mod- 16 addition of the eight nibbles to equal seven (0x07). 16 Registry numbers are assigned by UEI. The registry number is used as a pointer into a table whose contents identify the peripheral’s manufacturer, product name, model number, product type, revision, A/B channel and packet format. The range of Registry Numbers from 16,384 to 17,407 are reserved for peripherals employing Condensed Packets.
Software Developer Kit
rev. 1v0 UEI Confidential
26- August- 2002
XMP™ Station Software Developer Kit XMP- 1
4.3
page 17
Station Transceiver (TS Controller) – IR Protocol Policies
4.3.1 Inter-packet Spacing All XMP- 1 packets from a given peripheral must be separated by a minimum of 12 milliseconds. This minimum inter- packet separation is required for compatibility during interoperation with bi- directional XMP- 2 Station Transceivers and peripherals.
4.3.2 Peripheral Ownership XMP™ provides for up to 15 active Station Transceivers. Peripherals may be assigned to a particular “Owner”, or allowed to address all stations. Any Station Transceiver may listen to all peripherals, or just those matching its owner. If the Station Transceiver’s owner is set to zero, all incoming IR packets will be accepted; if set to a non- zero code, only packets matching that non- zero code will be accepted (non- matching packets will generate an unsolicited Completion Status Report).
4.3.3 Peripheral Addressing XMP™ provides for up to 14 active peripherals for each active station. Each packet contains an address “Tag” in the 0 to 13 range. Tags 0 to 3 are reserved for unidirectional peripherals. Such peripherals will typically either have a tag number “hardwired”, or the tag number will be selected via DIP switch or button sequence on the peripheral. This circumstance is referred to as “static unidirectional tagging”. Tags are made active for use as a result of Peripheral Identification Packets.
4.3.4 Unidirectional Tagging Tag activation for unidirectional peripherals is generally intended for onetime use. A unidirectional tag will remain active indefinitely until a data packet is received with the specified tag. Once an activated unidirectional tag has been used it will be retired as soon as there is a delay of at least thirty- two milliseconds between successive packets. Thus, although each unidirectional Data Packet is usually preceded by a Peripheral Identification Packet, pointers and other hi- fidelity peripherals can utilize the full bandwidth without the need to reregister between each Data Packet. Peripheral Identification Packet requests for a currently active unidirectional tag are valid and will be accepted.
4.3.5 XMP-Condensed Packets For peripherals that don’t require the full capabilities available by utilizing separate Registration Packets and Data Packets, there is the option of employing a single Condensed Packet. This packet format allows for specifying a limited range of Registration Numbers as well as a small amount of data in a single packet. This mode utilizes a different checksum algorithm and doesn’t support Tags or Owner Codes.
Software Developer Kit
rev. 1v0 UEI Confidential
26- August- 2002
XMP™ Station Software Developer Kit XMP- 1
5
page 18
XMP™ Device Driver Policies
This chapter the policies and behaviors that need to be considered when implementing device drivers for XMP- 1 and/or XMP- 2 peripherals.
5.1
Overview
In general, there have been two paradigms employed in wireless peripheral protocols. Many older protocols utilize a scheme based on reporting Key State Changes. XMP™ peripherals have traditionally been based on reporting Key Activity. Newer XMP- 4 peripherals however utilize Key Active/Break reporting.
5.2
Key State Change
Protocols based on reporting Key State Changes usually concern themselves with reporting events such as “Key Up” and “Key Down”. For example, a peripheral would report a “Key Down” when a key was initially pressed, and a “Key Up” when it was released. If the “Key Down” were lost then the keypress would never occur. If the “Key Up” were lost then the key would repeat indefinitely.
5.3
Key Activity
The XMP™ Protocol has often been used on peripherals based on the concept of reporting Key Activity. For example, a peripheral would report a “Key Down” when a key was initially pressed, and would continue to periodically report a “Key Repeat” as long as the key was depressed. When a device driver receives a “Key Down” report it will set the appropriate key’s state as active (Make). The key will continue to be considered active until either a subsequent “Key Down” report arrives specifying a different key as being active, or until a sufficient period of time has elapsed without reception of a “Key Repeat” report which would maintain the key’s active state. Although modifier keys can be reported as explicit scan codes, the state of all modifiers is reported in each keyboard packet with a reserved bit for each modifier. One limitation of this method is that multiple modifiers and only a single non- modifier key can be active at one time.
5.4
Key Active/Break
The XMP™ Protocol can also support peripherals based on the concept of Key Active/Break reporting. This scheme is an extension of Key Activity reporting which allows for maintaining multiple active keys and modifiers. Peripherals report a “Key Down” when a key is initially pressed, and continue to periodically report a “Key Repeat” as long as the key is still depressed and hasn’t been rolled by a subsequent key. Subsequent concurrently active keys are reported with an initial “Key Down” and, should they persist, with periodic “Key Repeat” reports. When a device driver receives a “Key Down” report it will set the appropriate key’s state as active (Make). The key will continue to be considered active until either a key report arrives which causes the key to be considered inactive (Break), or until a sufficient period of time has elapsed without reception of any key report, which causes all currently active keys to be set inactive. Active keys can be Broken through the use of the Keyboard State(KS) field common to all Active/Break keyboard packets. A Keyboard State of RESET indicates that all currently active keys and modifiers must be Broken before Making the newly specified scan code and modifiers. A Keyboard State of EXCLUSIVE indicates that the specified scan code is exclusive and that therefore that no other non- modifier keys are currently active. Finally, a Keyboard State of BREAK can be used to request a Break for the specified scan code while leaving all other non- modifier keys unaffected. Although
Software Developer Kit
rev. 1v0 UEI Confidential
26- August- 2002
XMP™ Station Software Developer Kit XMP- 1
page 19
modifier keys can be reported as explicit scan codes, the state of all modifiers is reported in each keyboard packet with a reserved bit for each modifier. A properly optimized peripheral will attempt to utilize the Keyboard States of RESET and EXCLUSIVE as well as implicit Breaks on timeout in order to minimize the number of explicit BREAK reports sent. Whenever a keyboard reports activity after transitioning from a state in which there were no active keys or modifiers it will always specify the first key report with a Key State of RESET.
5.5
Timing Policies
5.5.1 Key Down Timeout Once set active by a “Key Down” report, a key will remain active (“Down”) until superceded/Broken by a subsequent key report, or until the Key Down Timeout period has elapsed without reception of a “Key Repeat” report. The Key Down Timeout for XMP drivers is 250 +/- 10% milliseconds.
5.5.2 Peripheral Key Repetition The delay between transmissions of “Key Repeat” packets by XMP peripherals must not exceed 200 milliseconds. In no case can this delay exceed the Key Down Timeout.
5.5.3 Character Repetition (“Typematic Rate”) The actual high- level Character Repeat behavior is governed by device drivers and is independent of the peripheral’s protocol report rate. This behavior includes the Delay Before Repetition as well as the Repetition Rate. Delay Before Repetition: The length of time that a key must be active before its generated character will begin to repeat. The Delay Before Repetition for XMP drivers must be at least 300 milliseconds, and in no case less than the Key Down Timeout. Typical values for this delay range from 500- 1,000 milliseconds. Repetition Rate: The rate at which an active key’s generated character will repeat once Character Repetition has begun. XMP does not impose any constraints on this rate. Rolled Keys: In general, once a key has been superceded by a subsequent key it will never again generate repetition characters until it has first been released and then reactivated. Thus the key sequence of “A”(Down) “B”(Down) “B”(Up) ending with “A” still depressed wouldn’t generate any repetitions of “A”.
Software Developer Kit
rev. 1v0 UEI Confidential
26- August- 2002
XMP™ Station Software Developer Kit XMP- 1
5.6
page 20
RESEND Packet Filtering
In the XMP- 2 protocol most data packet formats contain the RESEND flag RSN. This flag signifies that the peripheral either received a NACK in response to its last packet, or didn’t receive any response at all, and is thus re- transmitting the packet. This flag allows a device driver to avoid the “stutter” that would occur when receiving a RESEND packet in addition to the original packet. The general rule is to discard a RESEND packet if, disregarding the RSN flag, it is identical to the previously received packet from the same peripheral. XMP- 1 peripherals will usually never transmit a packet with the RESEND flag set.
5.7
Truth Tables for Packet Validation (Key Activity Scheme)
Unidirectional Peripherals Data Packet Driver State Driver Action Key(s) Set Key(s) Set Key(s) RESEND REPEAT Key(s) same as Inactive Active Key(s) still Bit Bit Active last (if needed) (if needed) Active report N Y Y Y Y N Y Y N Y Y N Y N Y Y N Y N N Y N N Y Y Y Y N N Y N Y Y N N N Y Y N N N N Y
Notes
Note 1: Upon exhaustion of the Key Down Timeout, the Driver should set all keys inactive. Note 2: Upon taking any action, the Driver should restart the Key Down Timeout.
Software Developer Kit
rev. 1v0 UEI Confidential
26- August- 2002
XMP™ Station Software Developer Kit XMP- 1
page 21
APPENDIX 1 - IR Reception Requirements Unidirectional Single Device inbound IR packets consist of 9 pulses of modulated IR light. On average there will be between 30 and 45 packets per second during full bandwidth utilization. However, the theoretical maximum throughput allows for up to 79 packets per second. Any system attempting to support inbound packet reception must be able to deal with the 9 IR Detector interrupts generated by the leading edges of the pulses comprising each packet, and capture the resulting timestamps with no more than +/- 5 microseconds of error between consecutive timestamps. For example, during a second in which 30 packets were received the system would have to process 270 IR Detector interrupts. Pulse widths must also be captured in order to validate pulses. However, the trailing edges of pulses as reported by IR Detectors are relatively inaccurate and their timestamps don’t require as much accuracy. Full details regarding the IR Transport Layer timings, tolerances, and modulation formulas are available as needed.
Software Developer Kit
rev. 1v0 UEI Confidential
26- August- 2002
XMP™
rev. 1v0 UEI Confidential
APPENDIX 2 – Timing Diagram
Station Software Developer Kit XMP- 1
Software Developer Kit
page 22
26- August- 2002
XMP™ Station Software Developer Kit XMP- 1
page 23
APPENDIX 3 – XMP™ Protocol Formulas Example Inbound PPM calculations Edge1 = ((OnTime1 - OnTime0 ) - (HEADER + SETTLING)) + (PPM_CELL / 2) EdgeN>1 = ((OnTimeN - OnTimeN- 1 ) - (PULSE + SETTLING)) + (PPM_CELL / 2) PPM_ValueN = EdgeN / PPM_CELL
Software Developer Kit
rev. 1v0 UEI Confidential
26- August- 2002
XMP™ Station Software Developer Kit XMP- 1
page 24
APPENDIX 4 – PERIPHERAL REGISTRATION POLICIES Persistent Registration Persistent Registration is one method of reducing XMP- 4 Protocol latencies during periods of continuous peripheral activity in which the reporting rate would be low enough to require registration prior to each data report. By specifying Persistent Registration a peripheral can maintain its slot allocation between key repeats, rapid keying, etc. •
When a device specifies persistent registration its slot allocation will remain active for up to 200ms of empty protocol cycles following a protocol cycle in which a packet was successfully transmitted in the allocated slot. The default behavior for nonpersistent slot allocation is to de- allocate a slot following a single empty protocol cycle.
•
When a peripheral wishes to quickly send a new packet within 200ms of its previous packet it must listen for an End- of- Cycle Packet and confirm that its previous slot is still reserved under Persistent Registration. If so, then it can simply send its data packet in the appropriate slot. Otherwise it would simply have to register as usual.
•
Persistent Registration is only an option within Standard Registration sessions. Extended Registration sessions are intended for environments with many devices and persistent slot allocations would cause unacceptable traffic jams.
•
Whenever the peripheral goes to sleep and looses track of the time it must forget its persistent Registration.
•
In order to avoid Slot exhaustion during rapid keying a peripheral must not go to sleep until it has been inactive long enough that its Persistent Registration Tag would have expired by the time it awoke from a new user event and tried to establish a new session.
•
In order to avoid Slot exhaustion during a marginal IR Link, the allocation of a slot to Persistent Registration isn’t actually confirmed or “Locked” until a data packet is received in the allocated slot from the registering device. Reception of a data packet provides confirmation that the peripheral successfully received the Cycle Completion Packet granting slot registration and allocation.
•
In order to avoid excessive “Tag Roll”, when a Persistent Registration Packet is received with the same Tag that is already active in another Persistently Registered Slot, the prior Slot Registration is cancelled. Thus the new Registration Packet can be accepted without a duplicate Tag conflict.
•
One possible refinement of this method would be to allow the cancellation of the Persistent Registration allocation of a slot by sending a new registry packet that specified normal registration behavior. Currently, once a slot has been registered and “Locked” by successfully sending a data packet, then all subsequent registration packets are rejected until the slot is once again empty.
•
One optimization policy for this method would be for peripherals to only request Persistent Registration mode during actual key repetition. Thus a single key press wouldn’t result in Persistent Registration.
Software Developer Kit
rev. 1v0 UEI Confidential
26- August- 2002
