WO2002049314A2 - Etablissement et mise en oeuvre d'un protocole de communication pour le transfert de signaux a debit binaire eleve - Google Patents

Etablissement et mise en oeuvre d'un protocole de communication pour le transfert de signaux a debit binaire eleve Download PDF

Info

Publication number
WO2002049314A2
WO2002049314A2 PCT/US2001/047807 US0147807W WO0249314A2 WO 2002049314 A2 WO2002049314 A2 WO 2002049314A2 US 0147807 W US0147807 W US 0147807W WO 0249314 A2 WO0249314 A2 WO 0249314A2
Authority
WO
WIPO (PCT)
Prior art keywords
data
host
client
packets
packet
Prior art date
Application number
PCT/US2001/047807
Other languages
English (en)
Other versions
WO2002049314A3 (fr
Inventor
Qiuzhen Zou
George A. Wiley
Brian Steele
Original Assignee
Qualcomm Incorporated
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority to AU2735902A priority Critical patent/AU2735902A/xx
Application filed by Qualcomm Incorporated filed Critical Qualcomm Incorporated
Priority to IL15638501A priority patent/IL156385A0/xx
Priority to AU2002227359A priority patent/AU2002227359B2/en
Priority to JP2002550691A priority patent/JP2004531916A/ja
Priority to BRPI0116157A priority patent/BRPI0116157B1/pt
Priority to KR1020037008002A priority patent/KR100944843B1/ko
Priority to MXPA03005310A priority patent/MXPA03005310A/es
Priority to EP01996216A priority patent/EP1342352A2/fr
Priority to CA2431492A priority patent/CA2431492C/fr
Publication of WO2002049314A2 publication Critical patent/WO2002049314A2/fr
Publication of WO2002049314A3 publication Critical patent/WO2002049314A3/fr
Priority to HK04110331.3A priority patent/HK1067477A1/xx
Priority to IL196247A priority patent/IL196247A/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/75—Indicating network or usage conditions on the user display
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B82—NANOTECHNOLOGY
    • B82Y—SPECIFIC USES OR APPLICATIONS OF NANOSTRUCTURES; MEASUREMENT OR ANALYSIS OF NANOSTRUCTURES; MANUFACTURE OR TREATMENT OF NANOSTRUCTURES
    • B82Y10/00—Nanotechnology for information processing, storage or transmission, e.g. quantum computing or single electron logic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/54—Store-and-forward switching systems 
    • H04L12/56—Packet switching systems
    • H04L12/5601—Transfer mode dependent, e.g. ATM
    • H04L2012/5603—Access techniques
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M1/00—Substation equipment, e.g. for use by subscribers
    • H04M1/72—Mobile telephones; Cordless telephones, i.e. devices for establishing wireless links to base stations without route selection
    • H04M1/724—User interfaces specially adapted for cordless or mobile telephones
    • H04M1/72403—User interfaces specially adapted for cordless or mobile telephones with means for local support of applications that increase the functionality
    • H04M1/72409—User interfaces specially adapted for cordless or mobile telephones with means for local support of applications that increase the functionality by interfacing with external accessories
    • H04M1/724094—Interfacing with a device worn on the user's body to provide access to telephonic functionalities, e.g. accepting a call, reading or composing a message
    • H04M1/724097—Worn on the head
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D30/00—Reducing energy consumption in communication networks
    • Y02D30/70—Reducing energy consumption in communication networks in wireless communication networks

Definitions

  • the present invention relates to a digital signal protocol and process for communicating signals between a host communications device and a client audio/visual presentation device at high data rates. More specifically, the present invention relates to a technique for transferring multimedia and other types of digital signals from a wireless device to a micro-display unit or other presentation device using a low power high data rate transfer mechanism.
  • Computers, electronic game related products, and various video technologies have advanced significantly over the last few years to provide for presentation of increasingly higher resolution still, video, video- on-demand, and graphics images, even when including some types of text, to end users of such equipment.
  • These advances in turn mandated the use of higher resolution electronic viewing devices such as high definition video monitors, HDTV monitors, or specialized image projection elements.
  • Combining such visual images with high-definition or -quality audio data such as when using CD type sound reproduction, DVDs, and other devices also having associated audio signal outputs, is used to create a more realistic, content rich, or true multimedia experience for an end user.
  • highly mobile, high quality sound systems and music transport mechanisms such as MP3 players, have been developed for audio only presentations to end users.
  • video data is typically transferred using current techniques at a rate that could be best termed as slow or medium, being on the order of one to tens of kilobits per second.
  • This data is then either buffered or stored in transient or longer term memory devices, for delayed (later) play out on a desired viewing device.
  • images may be transferred "across" or using the Internet using a program resident on a computer having a modem or internet connection device, to receive or transmit data useful in digitally representing an image.
  • a similar transfer can take place using wireless devices such as portable computers equipped with wireless modems, or wireless Personal Data Assistants (PDAs), or wireless telephones.
  • PDAs Personal Data Assistants
  • the data is stored locally in memory elements, circuits, or devices, such as RAM or flash memory, including external storage devices, for playback.
  • the playback might begin relatively quickly, or be presented with longer term delay. That is, in some instances, image presentation allows for a certain degree of real time playback for very small or low resolution images not requiring much data, or using some type of buffering, so that after a small delay, some material is presented while more material is being transferred. Provided there are no interruptions in the transfer link, once the presentation begins the transfer is reasonably transparent to the end user of the viewing device.
  • JPEG Joint Photographic Experts Group
  • MPEG Motion Picture Experts Group
  • a typical computer video resolution in terms of a screen resolution of Xby Y pixels typically ranges from as low as 480x640, through 600x800 to 1024x1024, although a variety of other resolutions are generally possible, either as desired or needed.
  • Image presentation is also affected by the image content and the ability of given video controllers to manipulate the image in terms of certain predefined color levels or color depth (bits per pixel used to generate colors) and intensities, and any additional overhead bits being employed.
  • bits per pixel used to generate colors
  • intensities for example, a typical computer presentation would anticipate anywhere from around 8 to 32, or more, bits per pixel to represent various colors (shades and hues), although other values are encountered.
  • Mb Megabits
  • the amount of data required is around 73.7 to 1,006 Megabits of data per second (Mbps), or around 9.21 to 125.75 Megabytes per second (MBps).
  • Mbps Megabits of data per second
  • MBps Megabytes per second
  • a high data transfer rate link is required between presentation elements and the source or host device that is configured to provide such types of data.
  • VGA Video Interactive
  • DVI Digital Video Interactive
  • GVJE Gigabit Video Interface
  • Embodiments for the invention are directed to a Mobile Digital Data Interface
  • MDDI digital data transfer protocol
  • the signal communications protocol or link layer is used by a physical layer of host or client link controllers.
  • At least one link controller residing in the host device is coupled to the client device through the communications path or link, and is configured to generate, transmit, and receive packets forming the communications protocol, and to form digital presentation data into one or more types of data packets.
  • the interface provides for bi-directional transfer of information between the host and client.
  • At least one client link controller is disposed in the client device and is coupled to the host device through the communications path or link.
  • the client link controller is also configured to generate, transmit, and receive packets forming the communications protocol, and to form digital presentation data into one or more types of data packets.
  • the host or link controller employs a state machine for processing data packets used in commands or certain types of signal preparation and inquiry processing, but can use a slower general purpose processor to manipulate data and some of the less complex packets used in the communication protocol.
  • the host controller comprises one or more differential line drivers; while the client receiver comprises one or more differential line receivers coupled to the communication path.
  • the packets are grouped together within media frames that are communicated between the host and client devices having a pre-defined fixed length with a predetermined number of packets having different variable lengths.
  • the packets each comprise a packet length field, one or more packet data fields, and a cyclic redundancy check field.
  • a Sub-frame Header Packet is transferred or positioned at the beginning of transfers of other packets from the host link controller.
  • One or more Video Stream type packets and Audio Stream type packets are used by the communications protocol to transfer video type data and audio type data, respectively, from the host to the client over a forward link for presentation to a client device user.
  • One or more Reverse Link Encapsulation type packets are used by the communications protocol to transfer data from the client device to the host link controller.
  • Filler type packets are generated by the host link controller to occupy periods of forward link transmission that do not have data.
  • a plurality of other packets are used by the communications protocol to transfer video information. Such packets include Color Map, Bit Block Transfer, Bitmap Area Fill, Bitmap Pattern Fill, and Transparent Color Enable type packets.
  • User-Defined Stream type packets are used by the communications protocol to transfer interface-user defined data.
  • Keyboard Data and Pointing Device Data type packets are used by the communications protocol to transfer data to or from user input devices associated with said client device.
  • a Link Shutdown type packet is used by the communications protocol to terminate the transfer of data in either direction over said communication path.
  • the communication path generally comprises or employs a cable having a series of four or more conductors and a shield.
  • the link controllers comprise a USB data interface and the cable uses a USB type interface along with the other conductors.
  • printed wires or flexible conductors can be used, as desired.
  • the host link controller requests display capabilities information from the client device in order to determine what type of data and data rates said client is capable of accommodating through said interface.
  • the client link controller communicates display or presentation capabilities to the host link controller using at least one Display Capability type packet.
  • Multiple transfer modes are used by the communications protocol with each allowing the transfer of different maximum numbers of bits of data in parallel over a given time period, with each mode selectable by negotiation between the host and client link controllers. These transfer modes are dynamically adjustable during transfer of data, and the same mode need not be used on the reverse link as is used on the forward link.
  • the host device comprises a wireless communications device, such as a wireless telephone, a wireless PDA, or a portable computer having a wireless modem disposed therein.
  • a typical client device comprises a portable video display such as a micro-display device, and/or a portable audio presentation system.
  • the host may use storage means or elements to store presentation or multimedia data to be transferred to be presented to a client device user.
  • FIG. la illustrates a basic environment in which the present invention might operate including the use of a micro-display device used in conjunction with a portable computer.
  • FIG. lb illustrates a basic environment in which the present invention might operate including the use of a micro-display device and audio presentation elements used in conjunction with a wireless transceiver.
  • FIG. lb illustrates a basic environment in which the present invention might operate including the use of a micro-display device and audio presentation elements used in conjunction with a wireless transceiver.
  • FIG. 2 illustrates the overall concept of a Mobile Digital Data Interface with a host and client interconnection.
  • FIG. 3 illustrates the structure of a packet useful for realizing data transfers from a client device to a host device.
  • FIG. 4 illustrates the use of an MDDI link controller and the types of signals passed between a host and a client over the physical data link conductors for Type I and
  • FIG. 5 illustrates the use of an MDDI link controller and the types of signals passed between a host and a client over the physical data link conductors for Types ⁇ , It, and IV interfaces.
  • FIG. 6 illustrates the structure of frames and sub-frames used to implement the interface protocol.
  • FIG. 7 illustrates the general structure of packets used to implement the interface protocol.
  • FIG. 8 illustrates the format of a Sub-frame Header Packet.
  • FIG. 9 illustrates the format and contents of a Filler Packet
  • FIG. 10 illustrates the format of a Video Stream Packet.
  • FIG. 11 illustrates the format and contents for the Video Data Format Descriptor of FIG. 10.
  • FIG. 12 illustrates the use of packed and unpacked formats for data.
  • FIG. 13 illustrates the format of an Audio Stream Packet.
  • FIG. 14 illustrates the use of byte-aligned and packed PCM formats for data.
  • FIG. 15 illustrates the format of a User-Defined Stream Packet.
  • FIG. 16 illustrates the format of a Color Map Packet.
  • FIG. 17 illustrates the format of a Reverse Link Encapsulation Packet.
  • FIG. 18 illustrates the format of a Display Capability Packet.
  • FIG. 19 illustrates the format of a Keyboard Data Packet.
  • FIG. 20 illustrates the format of a Pointing Device Data Packet.
  • FIG. 21 illustrates the format of a Link Shutdown Packet.
  • FIG. 22 illustrates the format of a Display Request and Status Packet.
  • FIG. 23 illustrates the format of a Bit Block Transfer Packet.
  • FIG. 24 illustrates the format of a Bitmap Area Fill Packet.
  • FIG. 25 illustrates the format of a Bitmap Pattern Fill Packet.
  • FIG. 26 illustrates the format of a Communication Link Data Channel Packet.
  • FIG. 27 illustrates the format of a Interface Type Handoff Request Packet.
  • FIG. 28 illustrates the format of an Interface Type Acknowledge Packet.
  • FIG. 29 illustrates the format of a Perform Type Handoff Packet.
  • FIG. 30 illustrates the format of a Forward Audio Channel Enable Packet.
  • FIG. 31 illustrates the format of a Reverse Audio Sample Rate Packet.
  • FIG. 32 illustrates the format of a Digital Content Protection Overhead Packet.
  • FIG. 33 illustrates the format of a Transparent Color Enable Packet.
  • FIG. 34 illustrates the format of a Round Trip Delay Measurement Packet.
  • FIG. 35 illustrates the timing of events during the Round Trip Delay
  • FIG. 36 illustrates a sample implementation of a CRC generator and checker useful for the invention.
  • FIG. 37a illustrates the timing of CRC signals for the apparatus of FIG. 36 when sending data packets.
  • FIG. 37b illustrates the timing of CRC signals for the apparatus of FIG. 36 when receiving data packets.
  • FIG. 38 illustrates processing steps for a typical service request with no contention.
  • FIG. 39 illustrates processing steps for a typical service request asserted after the link restart sequence has begun, contending with link start.
  • FIG. 40 illustrates how a data sequence can be transmitted using DATA-STB encoding.
  • FIG. 41 illustrates circuitry useful for generating the DATA and STB signals from input data at the host, and then recovering the data at the client. [0067] FIG.
  • FIG. 42 illustrates drivers and terminating resistors useful for implementing an embodiment of the invention.
  • FIG. 43 illustrates steps and signal levels employed by a client to secure service from the host and by the host to provide such service.
  • FIG. 44 illustrates relative spacing between transitions on the DataO, other data lines (DataX), and the strobe lines (Stb).
  • FIG. 45 illustrates the presence of a delay in response that can occur when a host disables the host driver after transferring a packet.
  • FIG. 46 illustrates the presence of a delay in response that can occur when a host enables the host driver to transfer a packet.
  • FIG. 43 illustrates steps and signal levels employed by a client to secure service from the host and by the host to provide such service.
  • FIG. 44 illustrates relative spacing between transitions on the DataO, other data lines (DataX), and the strobe lines (Stb).
  • FIG. 45 illustrates the presence of a delay in response that can occur when a host disables the host driver after transferring a packet
  • FIG. 47 illustrates the relationship at the host receiver input between the timing of the data being transferred and the leading and trailing edges ofthe strobe pulses.
  • FIG. 48 illustrates switching characteristics and corresponding client output delay developed by the reverse data timing.
  • FIG. 49 illustrates a high level diagram of signal processing steps by which synchronization can be implemented for the present invention using a state machine.
  • FIG. 50 illustrates typical amounts of delay encountered for signal processing on the forward and reverse paths in a system employing the MDDI.
  • FIG. 51 illustrates marginal round trip delay measurement.
  • FIG. 52 illustrates Reverse Link data rate changes.
  • FIG. 53 illustrates a graphical representation of values of the Reverse Rate
  • FIGS. 54a and 54b illustrate steps undertaken in the operation of an interface.
  • FIG. 55 illustrates an overview of drivers, receivers, processors, and a state machine for implementing embodiments of the invention.
  • a general intent of the invention is to provide a Mobile Display Digital Interface
  • MDDI machine-to-media data transfer
  • This mechanism lends itself to implementation with miniature connectors and thin flexible cables which are especially useful in connecting display elements or devices such as wearable micro-displays (goggles or projectors) to portable computers, wireless communication devices, or entertainment devices.
  • the present invention can be used in a variety of situations to communicate or transfer large quantities of data, generally for audio, video, or multimedia applications from a host or source device where such data is generated or stored, to a client display or presentation device at a high rate.
  • a typical application which is discussed below, is the transfer of data from either a portable computer or a wireless telephone or modem to a visual display device such as a small video screen or a wearable micro-display appliance, such as in the form of goggles or helmets containing small projection lenses and screens.
  • the characteristics or attributes of the MDDI are such that they are independent of specific display technology. This is a highly flexible mechanism for transferring data at a high rate without regards to the internal structure of that data, nor the functional aspects of the data or commands it implements. This allows the timing of data packets being transferred to be adjusted to adapt to the idiosyncrasies of particular display devices, or unique display desires for certain devices, or to meet the requirements of combined audio and video for some A-V systems.
  • the interface is very display element or client device agnostic, as long as the selected protocol is followed.
  • the aggregate serial link data or data rate can vary over several orders of magnitude which allows a communication system or host device designer to optimize the cost, power requirements, client device complexity, and display device update rates.
  • the data interface is presented primarily for use in transferring large amounts of high rate data over a "wired" signal link or small cable.
  • some applications may take advantage of a wireless link as well, including optical based links, provided it is configured to use the same packet and data structures developed for the interface protocol, and can sustain the desired level of transfer at low enough power consumption or complexity to remain practical.
  • FIGS, la and lb A typical application can be seen in FIGS, la and lb where a portable or laptop computer 100 and wireless telephone or PDA device 102 are shown communicating data with display devices 104 and 106, respectively, along with audio reproduction system 108 and 110.
  • the wireless device can be currently receiving data or have previously stored a certain amount of multimedia type data in a memory element or device for later presentation for viewing and/or hearing by an end user of the wireless device. Since a typical wireless device is used for voice and simple text communications most of the time, it has a rather small display screen and simple audio system (speakers) for communicating information to the device 102 user.
  • Computer 100 has a much larger screen, but still inadequate external sound system, and still falls short of other multimedia presentation devices such as a high definition television, or movie screens.
  • Computer 100 is used for purposes of illustration and other types of processors, interactive video games, or consumer electronics devices can also be used with the invention.
  • Computer 100 can employ, but is not limited to or by, a wireless modem or other built in device for wireless communications, or be connected to such devices using a cable or wireless link, as desired.
  • wireless device 102 or computer 100 may also be additional elements connected to or associated with the use of wireless device 102 or computer 100 for presenting an output to another user, or to another device which in turn transfers the signals elsewhere or stores them.
  • data may be stored in flash memory, in optical form, for example using a writeable CD media or on magnetic media such as in a magnetic tape recorder and similar devices, for later use.
  • external speakers 108 are shown in FIG. la, which could also be accompanied by addition elements such as sub-woofers, or "surround-sound" speakers for front and rear sound projection.
  • speakers or earphones 110 are indicated as built-in to the support frame or mechanism of micro-display device 106 of FIG. lb.
  • other audio or sound reproduction elements can be used including power amplification or sound shaping devices.
  • transfer link 112 is clearly a potential bottleneck in the communication of data as discussed earlier and is limiting system performance, since current transfer mechanisms do not achieve the high data rates typically desired.
  • the data rates can approach rates in excess of 336 Mbps or more.
  • images may be presented as part of a multimedia presentation which includes audio data and potentially additional signals dealing with interactive gaming or communications, or various commands, controls, or signals, further increasing the quantity or data and the data rate.
  • a signal protocol and system architecture has been formulated that provides a very high data transfer rate using low power signals.
  • the protocol is based on a packet and common frame structure, or structures linked together to form a protocol for communicating a pre-selected set of data or data types along with a command or operational structure imposed on the interface.
  • the devices connected by or communicating over the MDDI link are called the host and client, with the client typically being a display device of some type.
  • Data from the host to the display travels in the forward direction (referred to as forward traffic or link), and data from the display to the host travels in the reverse direction (reverse traffic or link), as enabled by the host.
  • forward traffic or link Data from the host to the display travels in the forward direction
  • reverse traffic or link reverse traffic or link
  • FIG. 2 a host 202 is connected to a client 204 using a bi-directional communication channel 206 which is illustrated as comprising a forward link 208 and a reverse link 210.
  • these channels are formed by a common set of conductors whose data transfer is effectively switched between the forward or reverse link operations.
  • the host comprises one of several types of devices that can benefit from using the present invention.
  • host 202 could be a portable computer in the form of a handheld, laptop, or similar mobile computing device, it could be a PDA, a paging device, or one of many wireless telephones or modems.
  • client 204 could comprise a variety of devices useful for presenting information to an end user. For example, a micro-display incorporated in goggles or glasses, a projection device built into a hat or helmet, a small screen or even holographic element built into a vehicle, such as in a window or windshield, or various speaker, headphone, or sound systems for presenting high quality sound or music.
  • the MDD Interface is contemplated as addressing five or more somewhat distinct physical types of interfaces found in the communications and computer industries. These are labeled at this point simply as Type-I, Type-II, Type-Ill, Type-IV and Type-U.
  • the Type-I interface is configured as a 6-wire (conductor) interface which makes it suitable for mobile or wireless telephones, PDAs, e-Books, electronic games, and portable media players, such as CD players, or MP3 players, and devices on similar types of electronic consumer technology.
  • the Type-U interface is configured as an 8-wire (conductor) interface which is more suitable for laptop, notebook, or desktop personal computers and similar devices or applications, that do not require the display to be updated rapidly and do not have a built-in MDDI link controller.
  • This interface type is also distinguishable by the use of an additional two-wire Universal Serial Bus (USB) interface, which is extremely useful in accommodating existing operating systems or software support found on most personal computers.
  • Type-U interfaces can also be used in a USB-only mode where the display simply has a USB connector that connects to a standard USB port on a computer or similar device, for example.
  • Type-U, Type-UI, and Type-IN interfaces are suitable for high performance displays or devices and use larger more complex cabling with additional twisted-pair type conductors to provide the appropriate shielding and low loss transfers for data signals.
  • the Type-I interface passes signals which can comprise both the display, audio, control, and limited signaling information, and is typically used for devices that do not require high-resolution full-rate video data.
  • This type of interface is primarily intended for devices, such as mobile wireless devices, where a USB host is typically not available within the device for connection and transfer of signals.
  • the mobile device is a MDDI host device, and acts as the "master" that controls the communication link from the host, which generally sends display data to the client (forward traffic or link).
  • a host enables receipt of communication data at the host from the client (reverse traffic or link) by sending a special command or packet type to the client that allows it take over the bus for a specified duration and send data to the host as reverse packets.
  • a type of packet referred to as an encapsulation packet (discussed below) is used to accommodate the transfer of reverse packets over the transfer link, creating the reverse link.
  • the time interval allocated for the host to poll the display for data is pre-determined by the host and is based on the requirements of each specified application. This type of half-duplex bi-directional data transfer is especially advantageous where a USB port is not available for transfer of information or data form the client.
  • the Type-U interface transfers signals which are well suited for use in laptop and desktop applications where a USB interface is widely supported by extensive amounts of motherboards or other hardware, and by operating system software.
  • the use of an added USB interface allows use with "plug-and-play" features and easy application configuration.
  • the inclusion of USB also allows general-purpose bi-directional flow of commands, status, audio data, and so forth while video and audio data intended for the client device can be transferred using the twisted pairs at low power and high speed. Power can be transferred using other wires, as discussed below.
  • Embodiments of the invention using a USB interface allow high speed transfers over one set of conductors while implementing mainly signaling and control on the USB connection, which can be shut down when not in use and consumes little power.
  • USB interface is a very extensively used standard for modern personal computer equipment, and the details of a USB interface and its operation are very well known in the art, so not explained here.
  • communication between the host and display are compliant with the Universal Serial Bus Specification, Revision 2.0.
  • USB is the primary signaling channel and possibly a voice return channel, it is optional for the host to poll the client through the MDDI serial data signals.
  • High-performance displays capable of HDTV type or similar high resolutions require around 1.5 Gbps rate data streams in order to support full-motion video.
  • the Type-U interface supports high data rates by transmitting 2 bits in parallel, the Type-Ill by transmitting 4 bits in parallel, and the Type-IN interface transfers 8 bits in parallel.
  • the protocol used by the MDDI allows each Type-I,- U, -UI, or -IN host to communicate with any Type-I, -U, -UI, or -IN client or display by negotiating what is the highest data rate possible that can be used.
  • the capabilities or available features of what can be referred to as the least capable device is used to set the performance of the link.
  • Type-I interface As a rule, even for systems where the host and client are both capable using Type- ⁇ , Type-UI, or Type-IN interfaces, both begin operation as a Type-I interface.
  • the host determines the capability of the target client or display, and negotiates a hand-off or reconfiguration operation to either Type-II, Type-UI, or Type-IN mode, as appropriate for the particular application.
  • the host may use the proper link-layer protocol (discussed further below) and at any time to step down or again reconfigure operation to a slower mode to save power or to step up to a faster mode to support higher speed transfers, such as for higher resolution display content.
  • a host may change display modes when the display system switches from a power source such as a battery to AC power, or when the source ofthe display media switches to a lower or higher resolution format, or a combination of these or other conditions or events may be considered as a basis for changing a display or data transfer mode.
  • a system can communicate data using one mode in one direction and another mode in another direction.
  • a Type JN interface mode could be used to transfer data to a display at a high rate
  • a Type I or Type U mode is used when transferring data to a host device from peripheral devices such as a keyboard or a pointing device.
  • FIGS. 4 and 5 The general disposition of a device or link controller for establishing communications between host and client devices is shown in FIGS. 4 and 5.
  • a MDDI link controller 402 is shown installed in a host device 202 and a MDDI link controller 404 is shown installed in a client device 204.
  • host 202 is connected to a client 204 using a bi-directional communication channel 406 comprising a series of conductors.
  • both the host and client link controllers can be manufactured as an integrated circuit using a single circuit design that can be set, adjusted or programmed to respond as either a host controller (driver) or a client controller (receiver). This provides for lower costs due to larger scale manufacturing of a single circuit device.
  • USB host device 401 and a USB client device 410 are also shown for use in implementing Type U interface versions of the MDDI. Circuits and devices for implementing such functions are well known in the art, and are not described in further detail herein.
  • a MDDI link controller 502 is shown installed in a host device 202' and a MDDI link controller 504 is shown installed in a client device 204'.
  • host 202' is connected to a client 204' using a bi-directional communication channel 506 comprising a series of conductors.
  • both the host and client link controllers can be manufactured using a using a single circuit design.
  • MDDI link or the physical conductors used, are also illustrated in FIGS. 4 and 5.
  • the primary path or mechanism for transferring data through the MDDI uses data signals labeled as MDDI_Data0+/- and MDDI_Stb+/-.
  • MDDI_Data0+/- and MDDI_Stb+/- are low voltage data signals that are transferred over a differential pair of wires in a cable.
  • MDDI_Data0 pair or the MDDI_Stb pair for each bit sent over the interface.
  • This is a voltage based transfer mechanism not current based, so static current consumption is near zero.
  • the host drives the MDDI_Stb signals to the client display.
  • MDDIJData pairs that is it is a bi-directional transfer path
  • the host is the master or controller of the data link.
  • the MDDI_Data0 and MDDI-Stb signal paths are operated in a differential mode to maximize noise immunity.
  • the data rate for signals on these lines is determined by the rate of the clock sent by the host, and is variable over a range of about 1 kbps up to 400 Mbps or more.
  • the Type- ⁇ interface contains one additional data pair or conductors or paths beyond that of the Type-I, referred to as MDDI_Datal+/-.
  • the Type-UI interface contains two additional data pairs or signal paths beyond that of the Type-U interface referred to as MDDI_Data2+/-, and MDDI_Data3+/-.
  • the Type-IN interface contains four more data pairs or signal paths beyond that of the Type-UI interface referred to as: MDDI_data4+/-, MDDI_Data5+/-, MDDI_Data6+/-, and MDDI_Data7+/-, respectively.
  • a host sends power to the client or display using the wire-pair or signals designated as MDDIJPwr and MDDI_Gnd.
  • a type of transfer generally only made available for the Type-U configuration is the MDDI USB connection or signal path.
  • the MDDI USB connection comprises a secondary path for communication between a host and a client display. In certain applications it may be more advantageous to send certain information at a relatively low data rate between a host and client.
  • Using the USB transfer link allows devices without an MDDI Link Controller that have a USB host or limited host capability to communicate with an MDDI-compatible client or display equipped with the Type-U interface. Examples of information that can be usefully transferred over a USB interface to a display are: static bitmaps, digital audio streams, pointing device data, keyboard data, and control and status information. All functionality supported through the USB interface can also be implemented using the primary MDDI high-speed serial data path.
  • MDDI link are illustrated in Table I, below, in accordance with the interface type.
  • Cabling generally used to implement the above structure and operation is nominally on the order of 1.5 meters in length and contains three twisted pairs of conductors, each in turn being multi-strand 30 AWG wire.
  • a foil shield covering is wrapped or otherwise formed above the three twisted pairs, as an additional drain wire.
  • the twisted pairs and shield drain conductor terminate in the display connector with the shield connected to the shield for the display (client), and there is an insulating layer, covering the entire cable, as would be well known in the art.
  • the wires are paired as: MDDI_Gnd with MDDI_Pwr; MDDI_Stb+ with MDDI_Stb-; MDDI_Data0+ with MDDI_Data0-; MDDI_Datal+ with MDDI_Datal-; and so forth.
  • the nominal cable diameter is on the order of 3.0 mm with a nominal impedance of 85 ohms ⁇ 10%, and DC resistance nominally of 110 ohms per 1000 feet.
  • the signal propagation velocity should be nominally 0.66c, with a maximum delay through the cable less than around 8.0 nsec.
  • the Mobile Digital Data Interface provides support for a variety of displays and display information, audio transducers, keyboards, pointing devices, and many other input devices that might be integrated into or working in concert with a mobile display device, along with control information, and combinations thereof.
  • the MDD interface is designed to be able to accommodate a variety of potential types of streams of data traversing between the host and client in either the forward or reverse link directions using a minimum number of cables or conductors. Both isochronous streams and asynchronous stream (updates) are supported. Many combinations of data types are possible as long as the aggregate data rate is less than or equal to the maximum desired MDDI link rate. These could include, but are not limited to those items listed in Tables ⁇ and i ⁇ below.
  • the interface is not fixed but extensible so that it can support the transfer of a variety of information "types" which includes user-defined data, for future system flexibility.
  • data to be accommodated are: full-motion video, either in the form of full or partial screen bitmap fields or compressed video; static bitmaps at low rates to conserve power and reduce implementation costs; PCM or compressed audio data at a variety of resolutions or rates; pointing device position and selection, and user- definable data for capabilities yet to be defined.
  • Such data may also be transferred along with control or status information to detect device capability or set operating parameters.
  • the present invention advances the art for use in data transfers that include, but are not limited to, watching a movie (video display and audio), using a personal computer with limited personal viewing (graphics display, sometimes combined with video and audio), playing a video game on a PC, console, or personal device (motion graphics display, or synthetic video and audio), "surfing" the Internet, using devices in the form of a video phone (bi-directional low-rate video and audio), a camera for still digital pictures, or a camcorder for capturing digital video images, and for productivity enhancement or entertainment use with cell phones, smart phones, or PDAs.
  • the mobile data interface as discussed below is presented in terms of providing large amounts of A-V type data over a communication or transfer link which is generally configured as a wire-line or cable type link.
  • a communication or transfer link which is generally configured as a wire-line or cable type link.
  • the signal structure, protocols, timing, or transfer mechanism could be adjusted to provide a link in the form of an optical or wireless media, if it can sustain the desired level of transfer.
  • the MDD interface signals use a concept known as the Common Frame (CF) for the basic signal protocol or structure.
  • CF Common Frame
  • the idea behind using of a Common Frame is to provide a synchronization pulse for simultaneous isochronous data streams.
  • a display device can use this common frame rate as a time reference.
  • a low CF rate increases channel efficiency by decreasing overhead to transmit the sub-frame header.
  • a high CF rate decreases the latency, and allows a smaller elastic data buffer for audio samples.
  • the CF rate of the present inventive interface is dynamically programmable and may be set at one of many values that are appropriate for the isochronous streams used in a particular application. That is, the CF value is selected to best suit the given display device and host configuration, as desired.
  • Fractional counts of bytes per common frame are easily obtained using a simple programmable M N counter structure. For example, a count of 26-2/3 bytes per CF is implemented by transferring 2 frames of 27 bytes each followed by one frame of 26 bytes. A smaller CF rate may be selected to produce an integer number of bytes per CF.
  • a simple M/N counter in hardware should require less area within an integrated circuit chip used to implement part or all of the invention than the area needed for a larger audio sample FIFO buffer.
  • An exemplary application that illustrates the impact of different data transfer rates and data types is a Karaoke system.
  • a system user sings along with a music video program. Lyrics of the song are displayed at the bottom of a screen so the user knows the words to be sung, and roughly the timing of the song.
  • This application requires a video display with infrequent graphics updates, and mixing of the user's voice with a stereo audio stream.
  • each CF will consist of:
  • 92,160 bytes of video content and 588 bytes of audio content (based on 147 16-bit samples, in stereo) over the forward link to the display device, and an average of 29.67 (26-2/3) bytes of voice are sent back from a microphone to the mobile Karaoke machine.
  • Asynchronous packets are sent between the host and the display. This includes at most 768 bytes of graphics data (quarter-screen height), and less than about 200 bytes (several) bytes for miscellaneous control and status commands.
  • Table V shows how data is allocated within a Common Frame for the Karaoke example.
  • the total rate being used is selected to be about 225 Mbps.
  • a slightly higher rate of 226 Mbps allows about another 400 bytes of data per sub-frame to be transferred which allows the use of occasional control and status messages.
  • Data transferred using the MDD interface high-speed serial data signals consists of a stream of time-multiplexed packets that are linked one after the other. Even when a transmitting device has no data to send, a MDDI link controller automatically sends filler packets, thus, maintaining a stream of packets.
  • the use of a simple packet structure ensures reliable isochronous timing for video and audio signals or data streams.
  • Groups of packets are contained within signal elements or structures referred to as sub-frames, and groups of sub-frames are contained within signal elements or structures referred to as a media-frame.
  • a sub-frame contains one or more packets, depending on their respective size and data transfer uses, and a media-frame must contain one more sub-frames.
  • the largest sub-frame provided by the protocol employed by the present invention is on the order of 2 32 -l or 4,294,967,295 bytes, and the largest media-frame size then becomes on the order of 2 16 -1 or 65,535 sub-frames.
  • a special header packet that contains a unique identifier that appears at the beginning of each sub-frame, as is discussed below. That identifier is also used for acquiring the frame timing at the client device when communication between the host and display is initiated. Link timing acquisition is discussed in more detail below.
  • a display screen is updated once per media-frame when full-motion video is being displayed.
  • the display frame rate is the same as the media-frame rate.
  • the link protocol supports full-motion video over an entire display, or just a small region of full-motion video content surrounded by a static image, depending on the desired application. In some low-power mobile applications, such as viewing web pages or email, the display screen may only need to be updated occasionally. In those situations, it is advantageous to transmit a single sub-frame and then shut down the link to minimize power consumption.
  • the interface also supports effects such as stereo vision, and handles graphics primitives.
  • Sub-frames exist to enable the transmission of high-priority packets on a periodic basis.
  • the MDDI link controller shown in FIGS. 4 and 5 is manufactured or assembled to be a completely digital implementation with the exception of the differential line receivers which are used to receive MDDI data and strobe signals. No analog functions or phase lock loops (PLLs) are required to implement the hardware for the link controller.
  • PLLs phase lock loops
  • the host and display link controllers contain very similar functions, with the exception of the display interface which contains a state machine for link synchronization. Therefore, the present invention allows the practical advantage of being able to create a single controller design or circuit that can be configured as either a host or client, which can reduce manufacturing costs for the link controllers, as a whole.
  • FIG. 6 The signal protocol or frame structure used to implement the forward link communication for packet transfer is illustrated in FIG. 6.
  • information or digital data is grouped into elements known as packets. Multiple packets are in turn grouped together to form what are referred to as a "sub-frame,” and multiple sub-frames are in turn grouped together to form a "media" frame.
  • each sub-frame begins with a specially predefined packet referred to as a Sub-frame Header Packet (SHP).
  • SHP Sub-frame Header Packet
  • the host device selects the data rate to be used for a given transfer. This rate can be changed dynamically by the host device based on both the maximum transfer capability of the host, or the data being retrieved from a source by the host, and the maximum capability of the display, or other device the data is being transferred to.
  • a recipient client device designed for, or capable of, working with the MDDI or inventive signal protocol is able to be queried by the host to determine the maximum, or current maximum, data transfer rate it can use, or a default slower minimum rate may be used, as well as useable data types and features supported. This information could be transferred using a Display Capability Packet (DCP), as discussed further below.
  • DCP Display Capability Packet
  • the client display device is capable of transferring data or communicating with other devices using the interface at a pre-selected minimum data rate or within a minimum data rate range, and the host will perform a query using a data rate within this range to determine the full capabilities of the client devices.
  • the host sends filler packets when there are no (more) data packets to be transferred in the present sub-frame, or when the host cannot transfer at a rate sufficient to keep pace with the data transmission rate chosen for the forward link. Since each sub- frame begins with a sub-frame header packet, the end of the previous sub-frame contains a packet (most likely a filler packet) the exactly fills the previous sub-frame. In the case of a lack of room for data bearing packets per se, a filler packet will most likely be the last packet in a sub-frame, or at the end of a next previous sub-frame and before a sub- frame header packet.
  • sub-frame transmission has two modes.
  • One mode is a periodic sub-frame mode used to transmit live video and audio streams.
  • the Sub-frame length is defined as being non-zero.
  • the second mode is an asynchronous or non-periodic mode in which frames are used to provide bitmap data to a display device only when new information is available. This mode is defined by setting the sub-frame length to zero in the Sub-frame Header Packet .
  • sub-frame packet reception may commence when the display has synchronized to the forward link frame structure. This corresponds to the "in sync" states defined according to the state diagram discussed below with respect to FIG. 49.
  • reception commences after the first Sub- frame Header packet is received.
  • each packet type denotes a pre-defined packet structure for a given packet which is used in manipulating the packets and data being transferred.
  • the packets may have pre-selected lengths or have variable or dynamically changeable lengths depending on their respective functions.
  • the bytes or byte values used in the various packets are configured as multi-bit (8- or 16-bit) unsigned integers.
  • Packets have a common basic structure or overall set of minimum fields comprising a Packet Length field, a Packet Type field, Data Bytes field(s), and a CRC field, which is illustrated in FIG. 7.
  • the Packet Length field contains information, in the form of a multi-bit or -byte value, that specifies the total number of bits in the packet, or its length between the packet length field and the CRC field.
  • the packet length field contains a 16-bit or 2-byte wide, unsigned integer, that specifies the packet length.
  • the Packet Type field is another multi-bit field which designates the type of information that is contained within the packet. In the exemplary embodiment of the present example, this is an 8-bit or 1-byte wide value, in the form of an 8-bit unsigned integer, and specifies such data types as display capabilities, handoff, video or audio streams, status, and so forth.
  • a third field is the Data Bytes which contains the bits or data being transferred or sent between the host and client devices as part of that packet.
  • the format of the data is defined specifically for each packet type according to the specific type of data being transferred, and may be separated into a series of additional fields, each with its own format requirements. That is, each packet type will have a defined format for this portion or field.
  • the last field is the CRC field which contains the results of a 16-bit cyclic redundancy check calculated over the Data Bytes, Packet Type, and Packet Length fields, which is used to confirm the integrity of the information in the packet. In other words, calculated over the entire packet except for the CRC field itself.
  • the client generally keeps a total count of the CRC errors detected, and reports this count back to the host in the Display Request and Status Packet (see further below).
  • LSB Significant Bit
  • MSB Most Significant Bit
  • Parameters that are more than one byte in length are transmitted using the least significant byte first, which results in the same bit transmission pattern being used for a parameter greater than 8 bits in length, as is used for a shorter parameter where the LSB is transmitted first.
  • the data on the MDDI_DataO signal path is aligned with bit 0 of bytes transmitted on the interface in any of the modes, Type-I, Type- ⁇ , Type-ILT, or Type-IN.
  • the data for arrays of pixels are transmitted by rows first, then columns, as is traditionally done in the electronics arts.
  • all pixels that appear in the same row in a bit map are transmitted in order with the left-most pixel transmitted first and the right-most pixel transmitted last.
  • the next pixel in the sequence is the leftmost pixel of the following row.
  • Rows of pixels are generally transmitted in order from top to bottom for most displays, although other configurations can be accommodated as needed.
  • the sub-frame header packet is the first packet of every sub-frame, and has a basic structure as illustrated in FIG. 8. As can be seen in FIG. 8, this type of packet is structured to have Packet Length, Packet Type, Unique Word, Sub-Frame Length, Protocol Nersion, Sub-Frame Count, and Media-frame Count fields, generally in that order. This type of packet is generally identified as a Type 255 (Oxff hexadecimal) packet and uses a pre-selected fixed length of 17 bytes.
  • the Packet Type field uses a 1 byte value
  • the Unique Word field uses a 3 byte value.
  • the 4-byte combination of these two fields together forms a 32-bit unique word with good autocorrelation.
  • the actual unique word is 0x005a3bff where the lower 8 bits are transmitted first as the Packet Type, and the most significant 24 bits are transmitted afterward.
  • the Sub-frame Length field contains 4 bytes of information that specifies the number of bytes per sub-frame.
  • the length of this field may be set equal to zero to indicate that only one sub-frame will be transmitted by the host before the link is shut down into an idle state.
  • the value in this filed can be dynamically changed "on-the-fly" when transitioning from one sub-frame to the next. This capability is useful in order to make minor timing adjustments in the sync pulses for accommodating isochronous data streams. If the CRC of the Sub-frame Header packet is not valid then the link controller should use the Sub-frame Length of the previous known-good Sub-frame Header packet to estimate the length of the current sub-frame.
  • the Protocol Version field contains 2 bytes that specify the protocol version used by the host.
  • the Protocol Version field is set to '0' to specify the first or current version of the protocol as being used. This value will change over time as new versions are created.
  • the Sub-frame Count field contains 2 bytes that specify a sequence number that indicates the number of sub-frames that have been transmitted since the beginning of the media-frame.
  • the first sub-frame of the media-frame has a Sub-frame Count of zero.
  • the last sub-frame of the media-frame has a value of n-1, where n is the number of sub- frames per media-frame.
  • the Media-frame Count field contains 3 bytes that specify a sequence number that indicates the number of media-frames that have been transmitted since the beginning of the present media item or data being transferred.
  • the first media-frame of a media item has a Media-frame Count of zero.
  • the Media-frame Count value may be reset generally at any time by the Host to suit the needs of an end application.
  • a filler packet is a packet that is transferred to, or from, a client device when no other information is available to be sent on either the forward or reverse link. It is recommended that filler packets have a minimum length in order to allow maximum flexibility in sending other packets when required.
  • a link controller sets the size of the filler packet to fill the remaining space to maintain packet integrity.
  • FIG. 9 The format and contents of a Filler Packet are shown in FIG. 9. As shown in
  • this type of packet is structured to have Packet Length, Packet Type, Filler Bytes, and CRC fields.
  • This type of packet is generally identified as a Type 0, which is indicated in the 1 byte type field.
  • the bits or bytes in the Filler Bytes field comprise a variable number of all zero bit values to allow the filler packet to be the desired length.
  • the smallest filler packet contains no bytes in this field. That is, the packet consists of only the packet length, packet type, and CRC, and uses a pre-selected fixed length of 3 bytes.
  • Video Stream Packets carry video data to update atypically rectangular region of a display device.
  • the size of this region may be as small as a single pixel or as large as the entire display.
  • the format of the video stream packet (Nideo Data Format Descriptor) is shown in FIG. 10. As seen in FIG.
  • this type of packet is structured to have Packet Length, Packet Type, Nideo Data Descriptor, Display Attributes, X Left Edge, Y Top Edge, X Right Edge, Y Bottom Edge, X and Y Start, Pixel Count, Parameter CRC, Pixel Data, and CRC fields.
  • This type of packet is generally identified as a Type 1, which is indicated in the 1 byte type field.
  • Nideo Stream Packet must contain an integer number of pixels, even though it might not contain an integer number of rows of pixels. This is important if pixels are more than one byte each, or if they are in a packed format as shown in FIG. 12.
  • the Nideo Data Format Descriptor field contains 2 bytes in the form of a 16-bit unsigned integer that specifies the format of each pixel in the Pixel Data in the present stream in the present packet. It is possible that different streams (designated by the Stream ID field) may use different pixel data formats, that is, use a different value in the Nideo Data Format Descriptor, and similarly, any stream may change its data format on-the-fly.
  • the Nideo Data Format Descriptor defines the pixel format for the present packet only which does not imply that a constant format will continue to be used for the lifetime of a particular video stream.
  • FIGS. 11a through 1 Id illustrate how the Nideo Data Format Descriptor is coded.
  • the video data when bits [15:13] are equal to '000', as shown in FIG. 11a, then the video data consists of an array of monochrome pixels where the number of bits per pixel is defined by bits 3 through 0 of the Video Data Format Descriptor word. Bits 11 through 4 are set to zero in this situation.
  • bits [15:13] are instead equal to '001', as shown in FIG. 1 lb, then the video data consists of an array of color pixels that each specify a color through a color map. In this situation, bits 5 through 0 of the Video Data Format Descriptor word define the number of bits per pixel, and bits 11 through 6 are be set equal to zero.
  • the video data consists of an array of color pixels where the number of bits per pixel of red is defined by bits 11 through 8, the number of bits per pixel of green is defined by bits 7 through 4, and the number of bits per pixel of blue is defined by bits 3 through 0.
  • the total number of bits in each pixel is the sum of the number of bits used for red, green, and blue.
  • the video data consists of an array of video data in 4:2:2 format with luminance and chrominance information, where the number of bits per pixel of luminance (Y) is defined by bits 11 through 8, the number of bits of the Cr component is defined by bits 7 through 4, and the number of bits of the Cb component is defined by bits 3 through 0.
  • the total number of bits in each pixel is the sum of the number of bits used for red, green, and blue.
  • the Cr and Cb components are sent at half the rate as Y.
  • the video samples in the Pixel Data portion of this packet are organized as follows: Y n , Cr n , Cb n , Y n+ i, Yn + 2, Cr n+2 , Cb n+2 , Y n+3 , ... where Cr n and Cb n are associated with Y n and Y n+ ⁇ , and Cr n4 . 2 and Cb n+2 are associated with Y n+ and Y n+3 , and so on. If there are an odd number of pixels in a row (X Right Edge - X Left Edge + 1) in the present stream then the Cb value corresponding to the last pixel in each row will be followed by the Y value of the first pixel of the next row.
  • bit 12 which is designated as "P" specifies whether or not the Pixel Data samples are packed, or byte-aligned pixel data.
  • a value of '0' in this field indicates that each pixel and each color within each pixel in the Pixel Data field is byte-aligned with an MDDI interface byte boundary.
  • a value of '1' indicates that each pixel and each color within each pixel in the Pixel Data is packed up against the previous pixel or color within a pixel leaving no unused bits.
  • the first pixel in the first video stream packet for a particular display window will go into the upper left corner of the stream window defined by an X Offset and Y Offset, and the next pixel received is placed in the next pixel location in the same row, and so on.
  • the display keeps a "next pixel row and column" counter associated with each active video stream ID.
  • the audio stream packets carry audio data to be played through the audio system of the display, or for a stand alone audio presentation device.
  • Different audio data streams may be allocated for separate audio channels in a sound system, for example: left-front, right-front, center, left-rear, and right-rear, depending on the type of audio system being used.
  • a full complement of audio channels is provided for headsets that contain enhanced spatial-acoustic signal processing.
  • the format of Audio Stream Packets are illustrated in FIG. 13. As shown in FIG. 13, this type of packet is structured to have Packet Length, Packet Type, Audio Channel ID, Audio Sample Count, Bits Per Sample and Packing, Audio Sample Rate, Parameter CRC, Digital Audio Data, and Audio Data CRC fields. This type of packet is generally identified as a Type 2 packet.
  • the Bits Per Sample and Packing field contains 1 byte in the form of an 8-bit unsigned integer that specifies the packing format of audio data.
  • the format generally employed is for Bits 4 through 0 to define the number of bits per PCM audio sample.
  • Bit 5 then specifies whether or not the Digital Audio Data samples are packed.
  • the difference between packed and byte-aligned audio samples is illustrated in FIG. 14.
  • a value of '0' indicates that each PCM audio sample in the Digital Audio Data field is byte- aligned with an MDDI interface byte boundary, and a value of T indicates that each successive PCM audio sample is packed up against the previous audio sample. This bit is effective only when the value defined in bits 4 through 0 (the number of bits per PCM audio sample) is not a multiple of eight.
  • Bits 7 through 6 are reserved for future use and are generally set at a value of zero. 5.
  • Packet types 3 through 55 are reserved for stream packets to be defined for use in future versions or variations of the packet protocols, as desired for various applications encountered. Again, this is part of making the MDD interface more flexible and useful in the face of ever changing technology and system designs as compared to other techniques.
  • Eight data stream types are reserved for use in proprietary applications that may be defined by equipment manufacturers for use with a MDDI link. These are known as User-defined Stream Packets.
  • the video stream packets carry video data to update (or not) a rectangular region of the display.
  • the definition of the stream parameters and data for these packet types is left to the specific equipment manufacturers seeking their use.
  • the format of the user-defined stream packets is illustrated in FIG. 15. As shown in FIG. 15, this type of packet is structured to have Packet Length, Packet Type, Stream ID number, Stream Parameters, Parameter CRC, Stream Data, and Stream Data CRC fields.
  • the color map packets specify the contents of a color map look-up table used to present colors for a display. Some applications may require a color map that is larger than the amount of data that can be transmitted in a single packet. In these cases, multiple Color Map packets may be transferred, each with a different subset of the color map by using the offset and length fields described below.
  • the format of the Color Map packet is illustrated in FIG. 16. As shown in FIG. 16, this type of packet is structured to have Packet Length, Packet Type, Color Map Data Size, Color Map Offset, Parameter CRC, Color Map Data, and Data CRC fields. This type of packet is generally identified as a Type 64 packet. 8. Reverse Link Enc apsulation Packets
  • Packet A forward link packet is sent and the MDDI link operation (transfer direction) is changed or turned around in the middle of this packet so that packets can be sent in the reverse direction.
  • the format of the Reverse Link Encapsulation packet is illustrated in FIG. 17. As shown in FIG. 17, this type of packet is structured to have Packet Length, Packet Type, Reverse Link Flags, Turn- Around Length, Parameter CRC, Turn-Around 1, Reverse Data packets, and Turn-Around 2. This type of packet is generally identified as a Type 65 packet.
  • the MDDI link controller behaves in a special manner while sending a Reverse
  • the MDD interface has a strobe signal that is always driven by the host.
  • the host behaves as if it were transmitting a zero for each bit of the Turn- Around and Reverse Data Packets portions of the Reverse Link Encapsulation packet.
  • the host toggles MDDI_Strobe signal at each bit boundary during the two turn-around times and during the time allocated for reverse data packets. (This is the same behavior as if it were transmitting all-zero data.)
  • the host disables its MDDI data signal line drivers during the time period specified by Turn- Around 1, and the client re-enables its line drivers during the Driver Re-enable field following the time period specified by Turn-Around 2 field.
  • the display reads the Turn-Around Length parameter and drives the data signals toward the host immediately after the last bit in the Turn-Around 1 field.
  • the display uses the Packet Length and Turn-Around Length parameters to know the length of time it has available to send packets to the host.
  • the client may send filler packets or drive the data lines to a zero state when it has no data to send to the host. If the data lines are driven to zero, the host interprets this as a packet with a zero length (not a valid length) and the host does not accept any more packets from the client for the duration of the current Reverse Link Encapsulation Packet.
  • the display drives the MDDI data lines to the zero level for at least one reverse link clock period before the start of the Turn Around 2 field. This keeps the data lines in a deterministic state during the Turn Around 2 time period. If the client has no more packets to send, it may even disable the data lines after driving them to a zero level because the hibernation bias resistors (discussed elsewhere) keep the data lines at a zero level for the remainder of the Reverse Data Packets field.
  • the Reverse Link Request field of the Display Request and Status Packet may be used to inform the host of the number of bytes the display needs in the Reverse Link Encapsulation Packet to send data back to the host.
  • the host attempts to grant the request by allocating at least that number of bytes in the Reverse Link Encapsulation Packet.
  • the host may send more than one Reverse Link Encapsulation Packet in a sub- frame.
  • the display may send a Display Request and Status Packet at almost any time, and the host will interpret the Reverse Link Request parameter as the total number of bytes requested in one sub-frame.
  • a host needs to know the capability of the display (client) it is communicating with in order to configure the host-to-display link in an generally optimum or desired manner. It is recommended that a display send a Display Capability Packet to the host after forward link synchronization is acquired. The transmission of such a packet is considered required when requested by the host using the Reverse Link Flags in the Reverse Link Encapsulation Packet.
  • the format of the Display Capability packet is illustrated in FIG. 18. As shown in FIG.
  • this type of packet is structured to have Packet Length, Packet Type, Protocol Version, Min Protocol Version, Bitmap Width, Bitmap Height, Monochrome Capability, Color Map Capability, RGB Capability, Y Cr Cb Capability, Display Feature Capability, Data Rate Capability, Frame Rate Capability, Audio Buffer Depth, Audio Stream Capability, Audio Rate Capability, Min Sub-frame rate, and CRC fields.
  • This type of packet is generally identified as a Type 66 packet.
  • a keyboard data packet is used to send keyboard data from the client device to the host.
  • a wireless (or wired) keyboard may be used in conjunction with various displays or audio deices, including, but not limited to, a head mounted video display/audio presentation device.
  • the Keyboard Data Packet relays keyboard data received from one of several known keyboard-like devices to the host. This packet can also be used on the forward link to send data to the keyboard.
  • the format of a Keyboard Data Packet is shown in FIG. 19, and contains a variable number of bytes of information from or for a keyboard. As shown in FIG. 19, this type of packet is structured to have Packet Length, Packet Type, Keyboard Data, and CRC fields. This type of packet is generally identified as a Type 67 packet.
  • a pointing device data packet is used to send position information from a wireless mouse or other pointing device from the display to the host. Data can also be sent to the pointing device on the forward link using this packet.
  • the format of a Pointing Device Data Packet is shown in FIG. 20, and contains a variable number of bytes of information from or for a pointing device. As shown in FIG. 20, this type of packet is structured to have Packet Length, Packet Type, Pointing Device Data, and CRC fields. This type of packet is generally identified as a Type 68 packet in the 1-byte type field.
  • a Link Shutdown Packet is sent from the host to the client display to indicate that the MDDI data and strobe will be shut down and go into a low-power consumption "hibernation" state.
  • This packet is useful to shut down the link and conserve power after static bitmaps are sent from a mobile communication device to the display, or when there is no further information to transfer from a host to a client for the time being. Normal operation is resumed when the host sends packets again.
  • the first packet sent after hibernation is a sub-frame header packet.
  • the format of a Display Status Packet is shown in FIG. 21. As shown in FIG. 21, this type of packet is structured to have Packet Length, Packet Type, and CRC fields. This type of packet is generally identified as a Type 69 packet in the 1-byte type field, and uses a pre-selected fixed length of 3 bytes.
  • the MDDIJData driver In the low-power hibernation state the MDDIJData driver is disabled into a high- impedance state, and the MDDI_Data signals are pulled to a logic zero state using a high- impedance bias network that can be overdriven by the display.
  • the strobe signal used by the interface is set to a logic zero level in the hibernation state to minimize power consumption. Either the host or display may cause the MDDI link to "wake up" from the hibernation state as described elsewhere, which is a key advance for and advantage of the present invention. 13. Display Request and Status Packets
  • the host needs a small amount of information from the display so it can configure the host-to-display link in an optimum manner. It is recommended that the display send one Display Status Packet to the host each sub-frame. The display should send this packet as the first packet in the Reverse Link Encapsulation Packet to ensure that it is delivered reliably to the host.
  • the format of a Display Status Packet is shown in FIG. 22. As shown in FIG. 22, this type of packet is structured to have Packet Length, Packet Type, Reverse Link Request, CRC Error Count, and CRC fields. This type of packet is generally identified as a Type 70 packet in the l-byte type field, and uses a pre-selected fixed length of 7 bytes.
  • the Reverse Link Request field may be used to inform the host of the number of bytes the display needs in the Reverse Link Encapsulation Packet to send data back to the host.
  • the host should attempt to grant the request by allocating at least that number of bytes in the Reverse Link Encapsulation Packet.
  • the host may send more than one Reverse Link Encapsulation Packet in a sub-frame in order to accommodate data.
  • the display may send a Display Request and Status Packet at any time and the host will interpret the Reverse Link Request parameter as the total number of bytes requested in one sub-frame. Additional details and specific examples of how reverse link data is sent back to the host are shown below.
  • the Bit Block Transfer Packet provides a means to scroll regions of the display in any direction. Displays that have this capability will report the capability in bit 0 of the Display Feature Capability Indicators field of the Display Capability Packet.
  • the format of a Bit Block Transfer Packet is shown in FIG. 23. As shown in FIG. 23, this type of packet is structured to have Packet Length, Packet Type, Upper Left X Value, Upper Left Y Value, Window Width, Window Height, Window X Movement, Window Y Movement, and CRC fields. This type of packet is generally identified as a Type 71 packet, and uses a pre-selected fixed length of 15 bytes.
  • the fields are used to specify the X and Y values of the coordinate of the upper left corner of the window to be moved, the width and height of the window to be moved, and the number of pixels that the window is to be moved horizontally, and vertically, respectively. Positive values for the latter two fields cause the window to be moved to the right, and down, and negative values cause movement to the left and up, respectively.
  • the Bitmap Area Fill Packet provides a means to easily initialize a region of the display to a single color. Displays that have this capability will report the capability in bit 1 of the Display Feature Capability Indicators field of the Display Capability Packet.
  • the format of a Bitmap Area Fill Packet is shown in FIG. 24. As shown in FIG. 24, this type of packet is structured to have Packet Length, Packet Type, Upper Left X Value, Upper Left Y Value, Window Width, Window Height, Data Format Descriptor, Pixel Area Fill Value, and CRC fields. This type of packet is generally identified as a Type 72 packet in the 1-byte type field, and uses a pre-selected fixed length of 17 bytes.
  • the Bitmap Pattern Fill Packet provides a means to easily initialize a region of the display to a pre-selected pattern. Displays that have this capability will report the capability in bit 2 of the Display Feature Capability Indicators field of the Display Capability Packet.
  • the upper left corner of the fill pattern is aligned with the upper left corner of the window to be filled. If the window to be filled is wider or taller than the fill pattern, then the pattern may repeated horizontally or vertically a number of times to fill the window. The right or bottom of the last repeated pattern is truncated as necessary. If the window is smaller than the fill pattern, then the right side or bottom of the fill pattern may be truncated to fit the window.
  • FIG. 25 The format of a Bitmap Pattern Fill Packet is shown in FIG. 25. As shown in
  • this type of packet is structured to have Packet Length, Packet Type, Upper Left X Value, Upper Left Y Value, Window Width, Window Height, Pattern Width, Pattern Height, Data Format Descriptor, Parameter CRC, Pattern Pixel Data, and Pixel Data CRC fields.
  • This type of packet is generally identified as a Type 73 packet in the 1-byte type field.
  • the Communication Link Data Channel Packet provides a means for a display with high-level computing capability, such as a PDA, to communicate with a wireless transceiver such as a cell phone or wireless data port device.
  • a wireless transceiver such as a cell phone or wireless data port device.
  • the MDDI link is acting as a convenient high-speed interface between the communication device and the computing device with the mobile display, where this packet transports data at a Data Link Layer of an operating system for the device.
  • this packet could be used if a web browser, email client, or an entire PDA were built into a mobile display. Displays that have this capability will report the capability in bit 3 of the Display Feature Capability Indicators field of the Display Capability Packet.
  • this type of packet is structured to have Packet Length, Packet Type, Parameter CRC, Communication Link Data, and Communication Data CRC fields.
  • This type of packet is generally identified as a Type 74 packet in the type field.
  • the Interface Type Handoff Request Packet enables the host to request that the client or display shift from an existing or current mode to the Type-I (serial), Type-U (2- bit parallel), Type-UI (4-bit parallel), or Type-IN (8-bit parallel) modes. Before the host requests a particular mode it should confirm that the display is capable of operating in the desired mode by examining bits 6 and 7 of the Display Feature Capability Indicators field of the Display Capability Packet.
  • the format of a Interface Type Handoff Request Packet is shown in FIG. 27. As shown in FIG. 27, this type of packet is structured to have Packet Length, Packet Type, Interface Type, and CRC fields. This type of packet is generally identified as a Type 75 packet, and uses a pre-selected fixed length of 4 bytes. 19. Interface Type Acknowledge Packets
  • the Interface Type Acknowledge Packet is sent by the display to confirm receipt of the Interface Type Handoff Packet.
  • the requested mode Type-I (serial), Type-II (2- bit parallel), Type- ⁇ i (4-bit parallel), or Type-IV (8-bit parallel) mode, is echoed back to the host as a parameter in this packet.
  • the format of a Interface Type Acknowledge Packet is shown in FIG. 28. As shown in FIG. 28, this type of packet is structured to have Packet Length, Packet Type, Interface Type, and CRC fields. This type of packet is generally identified as a Type 76 packet, and uses a pre-selected fixed length of 4 bytes.
  • the Perform Type Handoff Packet is a means for the host to command the display to handoff to the mode specified in this packet. This is to be the same mode that was previously requested and acknowledged by the Interface Type Handoff Request Packet and Interface Type Acknowledge Packet. The host and display should switch to the agreed upon mode after this packet is sent. The display may lose and re-gain link synchronization during the mode change.
  • the format of a Perform Type Handoff Packet is shown in FIG. 29. As shown in FIG. 29, this type of packet is structured to have Packet Length, Packet Type, Packet Type, and CRC fields. This type of packet is generally identified as a Type 77 packet in the 1-byte type field, and uses a pre-selected fixed length of 4 bytes.
  • This packet allows the host to enable or disable audio channels in the display.
  • FIG. 30 The format of a Forward Audio Channel Enable Packet is shown in FIG. 30. As shown in FIG 30, this type of packet is structured to have Packet Length, Packet Type, Audio Channel Enable Mask, and CRC fields. This type of packet is generally identified as a Type 78 packet in the l-byte type field, and uses a pre-selected fixed length of 4 bytes.
  • This packet allows the host to enable or disable the reverse-link audio channel, and to set the audio data sample rate of this stream.
  • the host selects a sample rate that is defined to be valid in the Display Capability Packet. If the host selects an invalid sample rate then the display will not send an audio stream to the host.
  • the host may disable the reverse-link audio stream by setting the sample rate to 255.
  • the default state assumed when the display system is initially powered-up or connected is with the reverse-link audio stream disabled.
  • the format of a Reverse Audio Sample Rate Packet is shown in FIG. 31. As shown in FIG. 31, this type of packet is structured to have Packet Length, Packet Type, Audio Sample Rate, and CRC fields. This type of packet is generally identified as a Type 79 packet, and uses a pre-selected fixed length of 4 bytes.
  • This packet allows the host and a display to exchange messages related to the digital content protection method being used.
  • Presently two types of content protection are contemplated, Digital Transmission Content Protection (DTCP), or High-bandwidth Digital Content Protection System (HDCP), with room reserved for future alternative protection scheme designations.
  • the method being used is specified by a Content Protection Type parameter in this packet.
  • the format of a Digital Content Protection Overhead Packet is shown in FIG. 32. As shown in FIG. 32, this type of packet is structured to have Packet Length, Packet Type, Content Protection Type, Content Protection Overhead Messages, and CRC fields. This type of packet is generally identified as a Type 80 packet.
  • the Transparent Color Enable Packet is used to specify which color is transparent in a display and to enable or disable the use of a transparent color for displaying images. Displays that have this capability will report that capability in bit 4 of the Display Feature Capability Indicators field of the Display Capability Packet. When a pixel with the value for transparent color is written to the bitmap, the color does not change from the previous value.
  • the format of a Transparent Color Enable Packet is shown in FIG. 33. As shown in FIG. 33, this type of packet is structured to have Packet Length, Packet Type, Transparent Color Enable, Data Format Descriptor, Transparent Pixel Value, and CRC fields. This type of packet is generally identified as a Type 81 packet in the 1-byte type field, and uses a pre-selected fixed length of 10 bytes.
  • the Round Trip Delay Measurement Packet is used to measure the propagation delay from the host to a client (display) plus the Delay from the client (display) back to the host. This measurement inherently includes the delays that exist in the line drivers and receivers and an interconnect sub-system. This measurement is used to set the turn around delay and reverse link rate divisor parameters in the Reverse Link Encapsulation Packet, described generally above. This packet is most useful when the MDDI link is running at the maximum speed intended for a particular application.
  • the MDDI_Stb signal behaves as though all zero data is being sent during the following fields: All Zero, both Guard Times, and the Measurement Period. This causes MDDI_Stb to toggle at half the data rate so it can be used as periodic clock in the display during the Measurement Period.
  • this type of packet is structured to have Packet Length, Packet Type, Parameter CRC, Strobe Alignment, All Zero, Guard Time 1, Measurement Period, Guard Time 2, and Driver Re-enable fields.
  • This type of packet is generally identified as a Type 82 packet, and uses a pre-selected fixed length of 535 bits.
  • FIG. 35 the host transmits the Round Trip Delay Measurement Packet, shown by the presence of the Parameter CRC and Strobe Alignment fields followed by the All Zero and Guard Time 1 fields.
  • a delay 3502 occurs before the packet reaches the client display device or processing circuitry.
  • the display receives the packet, it transmits the Oxff, Oxff, 0x0 pattern as precisely as practical at the beginning of the Measurement Period as determined by the display.
  • the actual time the display begins to transmit this sequence is delayed from the beginning of the Measurement Period from the point of view of the host.
  • the amount of this delay is precisely the time it takes for the packet to propagate through the line drivers and receivers and the interconnect subsystem.
  • a similar amount of delay 3504 is incurred for the pattern to propagate from the display back to the host.
  • the host In order to accurately determine the round trip delay time for signals traversing to and from the client, the host counts the number of bit time periods occurring after the start of the Measurement Period until the beginning of the Oxff, Oxff, 0x0 sequence is detected upon arrival. This information is used to determine the amount of time for a round trip signal to pass from the host to the client and back again. Then, about one half of this amount is attributed to a the delay created for the one way passage of a signal to the client.
  • the display disables its line drivers substantially immediately after sending the last bit of the Oxff, Oxff, 0x0 pattern.
  • Guard Time 2 allows time for the display's line drivers to go completely to the high-impedance state before the host transmits the Packet Length of the next packet.
  • the hibernation pull-up and pull-down resistors (see FIG. 42) ensure that the MDDIJData signals are held at a valid low level in the intervals where the line drivers are disabled in both the host and display.
  • the CRC fields appear at the end of the packets and sometimes after certain more critical parameters in a packet that may have a significantly large data field, and thus, an increased likelihood of errors during transfer.
  • the CRC generator when only one is used, is re-initialized after the first CRC so the CRC computations following a long data field are not affected by the parameters at the beginning of the packet.
  • the polynomial used for the CRC calculation is known as the CRC-16, or X 16 + X 15 + X 2 + X°.
  • FIG. 36 A sample implementation of a CRC generator and checker 3600 useful for implementing the invention is shown in FIG. 36.
  • a CRC register 3602 is initialized to a value of 0x0001 just prior to transfer of the first bit of a packet which is input on the Tx_MDDI_Data_Before__CRC line, then the bytes of the packet are shifted into the register starting with the LSB first. Note that the register bit numbers in this figure correspond to the order of the polynomial being used, and not the bit positions used by the MDDI.
  • the packet contents for the Display Request and Status Packets are: 0x07, 0x46, 0x000400, 0x00 (or represented as a sequence of bytes as: 0x07, 0x00, 0x46, 0x00, 0x04, 0x00, 0x00), and are submitted using the inputs of the multiplexors 3604 and 3606, and NAND gate 3608, the resulting CRC output on the Tx_MDDI_Data_With_CRC line is OxOeal (or represented as a sequence as Oxal, OxOe).
  • CRC generator and checker 3600 When CRC generator and checker 3600 is configured as a CRC checker, the CRC that is received on the Rx_MDDI_Data line is input to multiplexor 3604 and NAND gate 3608, and is compared bit by bit with the value found in the CRC register using NOR gate 3610, exclusive-OR (XOR) gate 3612, and AND gate 3614. If there are any errors, as output by AND gate 3614, the CRC is incremented once for every packet that contains a CRC error by connecting the output of gate 3614 to the input of register 3602. Note that the example circuit shown in the diagram of FIG. 36 can output more than one CRC error signal within a given CHECK_CRC_NOW window (see FIG. 37b).
  • the CRC error counter will only count the first CRC error instance within each interval where CHECK_CRC_NOW is active. If configured as a CRC generator the CRC is clocked out of the CRC register at the time coinciding with the end of the packet.
  • FIGS. 37a and 37b The timing for the input and output signals, and the enabling signals, is illustrated graphically in FIGS. 37a and 37b.
  • the generation of a CRC and transmission of a packet of data are shown in FIG. 37a with the state (0 or 1) of the GenJ eset, Check_CRC_Now, Generate_CRC_Now, and Sending_MDDI_Data signals, along with the Tx_MDDI_Data_Before_CRC and Tx_MDDI_Data_With_CRC signals.
  • the reception of a packet of data and checking of the CRC value are shown in FIG. 37b with the state of the Gen_Reset, Check_CRC_Now, Generate_CRC_Now, and Sending_MDDI_Data signals, along with the Rx_MDDI_Data and CRC error signals.
  • MDDI_Data to a logic one state for about 150 ⁇ sec and then activates MDDI_Stb and simultaneously drives MDDI_Data to a logic zero state for 50 ⁇ sec, and then starts forward link traffic by sending a sub-frame header packet. This generally allows bus contentions to be resolved before the sub-frame header packet is sent by providing enough settling time between signals.
  • the client here a display
  • This action causes the host to start or restart data traffic on the forward link (208) and to poll the client for its status.
  • the host must detect the presence of the request pulse within 50 ⁇ sec and then begin the startup sequence of driving MDDI_Data0 to logic one for 150 ⁇ sec and to logic zero for 50 ⁇ sec.
  • the display must not send a service request pulse if it detects MDDIJDataO in the logic one state for more than 50 ⁇ sec. The nature of selection of the times and tolerances of time intervals related to the hibernation processing and start up sequence are discussed further below.
  • FIG. 38 An example of the processing steps for a typical service request event 3800 with no contention is illustrated in FIG. 38, where the events are labeled for convenience in illustration using the letters A, B, C, D, E, F, and G.
  • the process commences at point A when the host sends a Link Shutdown Packet to the client device to inform it that the link will transition to a low-power hibernation state.
  • the host enters the low- power hibernation state by disabling the MDDIJDataO driver and setting the MDDI_Stb driver to a logic zero, as shown at point B.
  • MDDIJDataO is driven to a zero level by a high-impedance bias network.
  • the client sends a service request pulse to the host by driving MDDI_Data0 to a logic one level as seen at point C.
  • the host still asserts the zero level using the high-impedance bias network, but the driver in the client forces the line to a logic one level.
  • the host recognizes the service request pulse, and asserts a logic one level on MDDIJDataO by enabling its driver, as seen at point D.
  • the client then ceases from attempting to assert the service request pulse, and the client places its driver into a high-impedance state, as seen at point E.
  • the host drives MDDIJDataO to a logic zero level for 50 ⁇ sec, as shown at point F, and also begins to generate MDDI_Stb in a manner consistent with the logic zero level on MDDIJDataO.
  • the host After asserting MDDIJDataO to a zero level and driving MDDI_Stb for 50 ⁇ sec, the host begins to transmit data on the forward link by sending a Sub-frame Header Packet, as shown at point G.
  • a service request is asserted after the link restart sequence has begun, and the events are again labeled using the letters A, B, C, D, E, F, and G.
  • the process commences at point A when the host again sends a Link Shutdown Packet to the client device to inform it that the link will transition to a low-power hibernation state.
  • the host enters the low-power hibernation state by disabling the MDDIJDataO driver and setting the MDDI_Stb driver to a logic zero, as shown at point B.
  • MDDIJDataO is driven to a zero level by a high-impedance bias network.
  • the host begins the link restart sequence by driving MDDIJDataO to a logic one level for 150 ⁇ sec as seen at point C.
  • the display Prior to 50 ⁇ sec passing after the link restart sequence begins the display also asserts MDDI_Data0 for a duration of 70 ⁇ sec, as seen at point D. This happens because the display has a need to request service from the host and does not recognize that the host has already begun the link restart sequence.
  • the client then ceases attempting to assert the service request pulse, and the client places its driver into a high-impedance state, as seen at point E.
  • the host continues to drive MDDIJDataO to a logic one level.
  • the host drives MDDI_Data0 to a logic zero level for 50 ⁇ sec, as shown at point F, and also begins to generate MDDI_Stb in a manner consistent with the logic zero level on MDDIJDataO. After asserting MDDIJDataO to a zero level, and driving MDDI_Stb for 50 ⁇ sec, the host begins to transmit data on the forward link by sending a Sub-frame Header Packet, as shown at point G.
  • Zero (NRZ) format is encoded using a data-strobe signal or DATA-STB format, which allows clock information to be embedded in the data and strobe signals.
  • the clock can be recovered without complex phase lock loop circuitry.
  • Data is carried over a bidirectional differential link, generally implemented using a wire-line cable, although other conductors, printed wires, or transfer elements can be used, as stated earlier.
  • the strobe signal (STB) is carried over a uni-directional link which is driven only by the host. The strobe signal toggles value (0 or 1) whenever there is a back-to-back state, 0 or 1, that remains the same on the Data line or signal.
  • FIG. 40 An example of how a data sequence such as bits "1110001011" can be transmitted using DATA-STB encoding is shown in graphical form in FIG. 40.
  • a DATA signal 4002 is shown on the top line of a signal timing chart and a STB signal 4004 is shown on a second line, each time aligned as appropriate (common starting point).
  • the STB line 4004 maintains a previous state, thus, the first T state of the DATA signal correlates with the first '0' state for the STB signal, its starting value.
  • the STB signal toggles to the opposite state or T in the present example, as is the case in FIG. 40 where the DATA is providing another T value. That is, there is always one and only one transition per bit cycle between DATA and STB. Therefore, the STB signal transitions again, this time to '0' as the DATA signal stays at T and holds this level or value as the DATA signal changes level to '0'.
  • the STB signal toggles to the opposite state or T in the present example, and so forth, as the DATA signal changes or holds levels or values.
  • an exclusive-OR (XOR) operation is performed on the DATA and STB signals to produce a clock signal 4006, which is shown on the bottom of the timing chart for relative comparison with the desired data and strobe signals.
  • XOR exclusive-OR
  • a transmission portion 4100 is used to generate and transmit the original DATA and STB signals over an intermediary signal path 4102, while a reception portion 4120 is used to receive the signals and recover the data.
  • the DATA signal is input to two D-type flip- flop circuit elements 4104 and 4106 along with a clock signal for triggering the circuits.
  • the two flip-flop circuit outputs (Q) are then split into a differential pair of signals MDDI_Data0+, MDDIJDataO- and MDDI_Stb+, MDDI Stb-, respectively, using two differential line drivers 4108 and 4110 (voltage mode).
  • a three-input exclusive-NOR (XNOR) gate, circuit, or logic element 4112 is connected to receive the DATA and outputs of both flip-flops, and generates an output that provides the data input for the second flip-flop, which in turn generates the MDDI_Stb+, MDDI_Sfb- signals.
  • the XNOR gate has the inversion bubble placed to indicate that it is effectively inverting the Q output of the flip-flop that generates the Strobe.
  • MDDI_Stb+, MDDI_Sfb- signals are received by each of two differential line receivers 4122 and 4124, which generate single outputs from the differential signals.
  • the outputs of the amplifiers are then input to each of the inputs of a two-input exclusive-OR (XOR) gate, circuit, or logic element 4126 which produces the clock signal.
  • the clock signal is used to trigger each of two D-type flip-flop circuits 4128 and 4130 which receive a delayed version of the DATA signal, through delay element 4132, one of which (4128) generates data '0' values and the other (4130) data T values.
  • the clock has an independent output from the XOR logic as well.
  • the MDDI_Data+, MDDI_Data-, MDDI_Stb+, and MDDI_Stb- signals are operated in a differential mode to maximize immunity from the negative affects of noise. Each portion of the differential signal path is source terminated with one-half of the characteristic impedance of the cable or conductor being used to transfer signals. MDDIJData+ and MDDI_Data- are source terminated at both the host and client ends. Since only one of these two drivers is active at a given time, there is always a termination at the source for the transfer link. The MDDI_Stb+ and MDDI_Stb- signals are only driven by the host.
  • FIG. 42 An exemplary configuration of elements useful for achieving the drivers, receivers, and terminations for transferring signals as part of the inventive MDD interface are shown in FIG. 42, while corresponding DC electrical specifications of MDDIJData and MDDI_Stb are shown in Table VU.
  • This exemplary interface uses low voltage sensing, here 200 V, with less than 1 volt power swings and low power drain.
  • the driver transfers the logic level on the input directly to a positive output, and the inverse of the input to a negative output.
  • the delay from input to outputs is well-matched to the differential line which is driven differentially.
  • the voltage swing on the outputs is less than the swing on the input to minimize power consumption and electromagnetic emissions.
  • Table VUI presents a minimum voltage swing to be around 0.8V. However, other values can be used, as would be known by those skilled in the art, and the inventors contemplate a smaller value on the order of 0.5 or 0.6V in some embodiments, depending on design constraints.
  • the differential line receivers have the same characteristic as a high-speed voltage comparator.
  • the input without the bubble is the positive input and the input with the bubble is the negative input.
  • the output is a logic one if: (Vj nput+ ) - (N m pu t -) is greater than zero.
  • Another way to describe this is a differential amplifier with very large (virtually infinite) gain with the output clipped at logic 0 and 1 voltage levels.
  • a host controller 4202 and a client or display controller 4204 are shown transferring packets over the communication link 4206.
  • the host controller employs a series of three drivers 4210, 4212, and 4214 to receive the host DATA and STB signals to be transferred, as well as to receive the client Data signals to be transferred.
  • the driver responsible for passage of the host DATA employs an enable signal input to allow activation of the communication link only when transfer from the host to the client is desired. Since the STB signal is formed as part of the transfer of data, no additional enable signal is employed for that driver (4212).
  • the outputs of each of the DATA and STB drivers are connected to termination impedances or resistors 4216a, 4216b, 4216c, and 4216d, respectively.
  • Termination resistors 4216a and 4216b will also act as impedances on the input of the client side receiver 4220 for the STB signal processing while additional termination resistors 4216e and 4216f are placed in series with resistors 4216c and 4216d, respectively on the input of the client data processing receiver 4222.
  • a sixth driver 4226 in the client controller is used to prepare the data signals being transferred from the client to the host, where driver 4214, through termination resistors 4216c and 4216d, on the input side, processes the data for transfer to the host for processing.
  • Two additional resistors 4218a and 4218b are placed between the termination resistors and ground and a voltage source 4220, respectively, as part of the hibernation control discussed elsewhere.
  • the voltage source is used to drive the transfer lines to the high or low levels previously discussed to manage the flow of data.
  • the above drivers and impedances can be formed as discrete components or as part of an application specific integrated circuit (ASIC) which acts as a more cost effective encoder or decoder solution.
  • ASIC application specific integrated circuit
  • the MDDI_Gnd portion of the signal acts as the reference ground and the power supply return path or signal for the display device.
  • the MDDI_Pwr signal acts as the display device power supply which is driven by the host device In an exemplary configuration, for low power applications, the display device is allowed to draw up to 500 mA.
  • the MDDI_Pwr signal can be provided from portable power sources, such as but not limited to, a lithium-ion type battery or battery pack residing at the host device, and may range from 3.2 to 4.3 volts with respect to MDDI_Gnd. VII. Timing Characteristics
  • FIG. 43 The steps and signal levels employed by a client to secure service from the host and by the host to provide such service, are illustrated in FIG. 43.
  • the first part of signals being illustrated shows a Link Shutdown Packet being transferred from the host and the data line is then driven to a logic zero state using the high-impedance bias circuit. No data is being transmitted by the client display, or host, which has its driver disabled. A series of strobe pulses for the MDDI_Stb signal line can be seen at the bottom, since MDDI_Stb is active during the Link Shutdown Packet.
  • the MDDI_Stb signal line changes to a zero level as well. This represents the termination of the last signal transfer or service from the host, and could have occurred at any time in the past, and is included to show the prior cessation of service, and the state of the signals prior to service commencement. If desired, such as signal can be sent just to reset the communication link to the proper state without a 'known' prior communication having been undertaken by this host device.
  • the signal output from the client is initially set at a logic level of zero.
  • the client output is at a high impedance, and the driver is disabled.
  • the client enables its driver and sends a service request to the host, which is a period of time, designated t serv i ce , during which the line is driven to a logic one level.
  • t serv i ce a period of time
  • a certain amount of time then passes or may be needed before the host detects the request, termed t hos t-detect, after which the host responds with a link startup sequence by driving the signal to a logic one level.
  • the client de-asserts the request, and disables the service request driver so that the output line from the client goes to zero logic level again.
  • the MDDI_Stb signal is at a logic zero level.
  • the host drives the host data output at the '1' level for a period termed t rest art-high, after which the host drives the logic level to zero and activates MDDI_Stb for a period termed t resta rt-iow, after which the first forward traffic begins with a Frame Header Packet, and the forward traffic packets are then transferred.
  • the MDDI_Stb signal is active during the t restart -i ow period and the subsequent Frame Header Packet.
  • Table VHI shows representative times for the length of the various periods discussed above, and the relationship to exemplary minimum and maximum data rates, where:
  • FIGS. 41 and 42 are well known, and the function of the elements in FIG. 42 is confirmed by the timing diagram in FIG. 43. Details about the series terminations and hibernation resistors that are shown in FIG. 42 were omitted from FIG. 41 because that information is unnecessary for a description of how to perform the Data-Strobe encoding and recover the clock from it.
  • Table DC presents a tabular form of the minimum and maximum desired, versus typical times for certain signal transitions to occur.
  • a DataO to DataO transition termed t tdd -( host - out p ut , is tt i t while the minimum time is about t tb i t -0.5 nsec, and the maximum is about t tb i t +0,5 nsec.
  • FIG. 44 The relative spacing between transitions on the DataO, other data lines (DataX), and the strobe lines (Stb), is illustrated in FIG. 44 where the DataO to Strobe, Strobe to Strobe, Strobe to DataO, DataO to non-DataO, non-DataO to non-DataO, non- DataO to Strobe, and Strobe to non-DataO transitions are shown, which are referred to as ttds-(host-output)) ttss-(host-output)5 ttsd-(host-output>5 ttddx-(host-output)> ttdxdx-Chost-output), ttd ⁇ s-(host-output) 5 n ttsdx-(h ⁇ st-output), respectively.
  • ttds-(host-output) ttss-(host-output)5 ttsd-(host-output>5 ttddx-(host-
  • Table X The typical MDDI timing requirements for the client receiver input for the same signals transferring data on the forward link is shown in Table X. Since the same signals are being discussed but time delayed, no new figure is needed to illustrate the signal characteristics or meaning of the respective labels, as would be understood by those skilled in the art. Table X
  • FIGS. 45 and 46 illustrate the presence of a delay in response that can occur when the host disables or enables the host driver, respectively.
  • the host disables the line driver after the desired packets are forwarded, such as the Parameter CRC, Strobe Alignment, and All Zero packets illustrated in FIG. 45 as having been transferred.
  • the state of the line does not necessarily switch from O' to a desired higher value instantaneously, although this is potentially achievable with certain control or circuit elements present, but takes a period of time termed the host Driver Disable Delay period to respond. While it could occur virtually instantly such that this time period is 0 nanoseconds (nsec.) in length, it could more readily extend over some longer period with 10 nsec. being a desired maximum period length, which occurs during the Guard Time 1 or Turn Around 1 packet periods.
  • the Driver is enabled for transferring a packet such as Reverse Link Encapsulation Packet or the Round Trip Delay Measurement Packet.
  • a packet such as Reverse Link Encapsulation Packet or the Round Trip Delay Measurement Packet.
  • the host driver is enabled and begins to drive a level, here '0', which value is approached or reached over a period of time termed the Host Driver Enable Delay period, which occurs during the Driver Re-enable period, prior to the first packet being sent.
  • '0' a period of time termed the Host Driver Enable Delay period, which occurs during the Driver Re-enable period, prior to the first packet being sent.
  • a similar process occurs for the drivers and signal transfers for the client device, here a display.
  • Table XI The general guidelines for the length of these periods, and their respective relationships are shown in Table XI, below.
  • FIGS. 47, and 48 The switching characteristics and timing relationships for the data and strobe signals used to transfer data on the reverse link from the client driver output are shown in FIGS. 47, and 48. The typical times for certain signal transitions are discussed below.
  • FIG. 47 illustrates the relationship at the host receiver input between the timing of the data being transferred and the leading and trailing edges of the strobe pulses. That is, what is referred to as the set-up time for the rising or leading edge of the strobe signals, t su - sr and the set-up time for the trailing or falling edge of the strobe signals, t su .
  • S f A typical length of time for these set-up periods in on the order of 8 nanoseconds.
  • FIG. 48 illustrates the switching characteristics and corresponding client output delay developed by the reverse data timing.
  • FIG. 48 one can see the relationship between the timing of the data being transferred and the leading and trailing edges of the strobe pulses accounting for induced delay. That is, what is referred to as the propagation delay between the rising or leading edge of the strobe signals and the data, tp -sr, and the propagation delay between the data and the trailing or falling edge of the strobe signals, t Pd - Sf - A typical length of time for these propagation delay periods in on the order of 8 nanoseconds. VIII. Implementation of Link Control (Link Controller Operation)
  • Packets being transferred over a MDDI link are dispatched very rapidly, typically at a rate on the order of 300 Mbps or more, although lower rates are certainly accommodated, as desired.
  • This type of bus or transfer link speed is too great for currently commercially available (economical) general-purpose microprocessors or the like to control. Therefore, a practical implementation to accomplish this type of signal transfer is to utilize a programmable state machine to parse the input packet stream to produce packets that are transferred or redirected to the appropriate audio-visual subsystem for which they are intended.
  • General purpose controllers, processors, or processing elements can be used to more appropriately act upon or manipulate some information such as control or status packets, which have lower speed demands.
  • packets control, status, or other pre-defined packets
  • the state machine should pass them through a data buffer or similar processing element to the general-purpose processor so the packets can be acted upon to provide a desired result (effect) while the audio and visual packets are transferred to their appropriate destination for action.
  • the general purpose processor function can be realized in some embodiments by taking advantage of the processing power, or excess cycles available for, microprocessors (CPUs) in computer applications, or processors, digital signal processors (DSPs), or ASICs found in wireless devices, in much the same manner as some modems or graphics processors utilize the processing power of CPUs in computers to perform some functions and reduce hardware complexity and costs.
  • CPUs microprocessors
  • DSPs digital signal processors
  • ASICs digital signal processors
  • FIG. 49 A high level diagram of states achieved by signal processing steps or a method by which such a synchronization can be implemented is presented in the illustration of FIG. 49.
  • the possible forward link synchronization "states" for a state machine 4900 are shown being categorized as one Async Frames State 4904, two Acquiring Sync States 4902 and 4906, and three In-Sync States 4908, 4910, and 4912.
  • the display starts in a pre-selected "no sync" state, and searches for a unique word in the first sub-frame header packet that is detected. It is to be noted that this no sync state represents the minimum communication setting or "fall-back" setting in which a Type I interface is selected.
  • this no sync state represents the minimum communication setting or "fall-back" setting in which a Type I interface is selected.
  • the display saves the sub-frame length field. There is no checking of the CRC bits for processing on this first frame, or until synchronization is obtained. If this sub-frame length is zero, then sync state processing proceeds according to the method to state 4904 labeled here as the "async frames" state, which indicates that synchronization has not yet been achieved.
  • This step in the processing is labeled as having encountered cond 3, or condition 3, in FIG. 49. Otherwise, if the frame length is greater than zero, then the sync state processing proceeds to a state 4906 where the interface state is set as "found one sync frame.” This step in the processing is labeled as encountering cond 5, or condition 5, in FIG. 49. In addition, if the state machine sees a frame header packet and good CRC determination for a frame length greater than zero, processing proceeds to the "found one sync frame" state. This is labeled as meeting cond 6, or condition 6, in FIG. 49.
  • the interface can be configured to accommodate a certain number of "sync errors” prior to deciding that synchronization is lost and returning to the "no sync frame” state.
  • FIG. 49 once the state machine has reached the "in-sync state” and no errors are found, it is continuously encountering a cond 1 result, and remains in the "in-sync” state. However once one cond 2 result is detected, processing changes the state to a "one-sync- error" state 4910. At this point, if processing results in detecting another cond 1 result, then the state machine returns to the "in-sync” state, otherwise it encounters another cond 2 result, and moves to a "two-sync-errors" state 4912.
  • the sub-frame length in the sub-frame Header Packet may be set to zero to indicate that the host will transmit only one sub-frame before the link is shut down, and the MDD interface is placed in or configured into an idle hibernation state. In this case, the display must immediately receive packets over the forward link after detecting the sub-frame Header Packet because only a single sub-frame is sent before the link transitions to the idle state. In normal or typical operations, the sub-frame length is nonzero and the display only processes forward link packets while the interface is in those states collectively shown as "INJSYNC" states in FIG. 49.
  • the time required for a display to synchronize to the forward link signal is variable depending on the sub-frame size and the forward link data rate.
  • the likelihood of detecting a "false copy" of the unique word as part of the random, or more random, data in the forward link is greater when the sub-frame size is larger.
  • the ability to recover from a false detection is lower, and the time taken to do so is longer, when a forward link data rate is slower.
  • the host configures the forward link to operate at or below a minimum required, or desired, data rate of 1 Mbps, and configures the sub-frame length and media-frame rate appropriately for a given application. That is, both the forward and reverse links begin operation using the Type-I interface. These parameters are generally only going to be used temporarily while the host determines the capability or desired configuration for the client display (or other device).
  • the host sends or transfers a sub-frame Header Packet over the forward link followed by a Reverse Link Encapsulation Packet which has bit '0' of the Request Flags set to a value of one (1), in order to request that the display responds with a Display Capability Packet.
  • the display acquires synchronization on (or with) the forward link, it sends a Display Capability Packet and a Display Request and Status Packet over the reverse link or channel.
  • the host examines the contents of the Display Capability Packet in order to determine how to reconfigure the link for optimal or a desired level of performance.
  • the host examines the Protocol Version and Minimum Protocol Version fields to confirm that the host and display use versions of the protocol that are compatible with each other.
  • the protocol versions remain as the first two parameters of the display capability Packet so that compatibility can be determined even when other elements of the protocol might not be compatible or completely understood as being compatible.
  • the packet processor state machine ensures that the CRC checker is controlled appropriately or properly. It also increments a CRC error counter when a CRC comparison results in one or more errors being detected, and it resets the CRC counter at the beginning of each sub-frame being processed.
  • Forward link packets are generally processed according to the exemplary processing listed in Table X ⁇ below.
  • certain parameters used for the host link controller can be adjusted or configured in a certain manner in order to achieve a maximum or more optimized (scale) reverse link data rate, which is very desirable. For example, during the time used to transfer the Reverse Data Packets field of the Reverse Link Encapsulation Packet, the MDDI_Stb signal pair toggles to create a periodic data clock at half the forward link data rate. This occurs because the host link controller generates the MDDI_Stb signal that corresponds to the MDDIJDataO signal as if it were sending all zeroes.
  • the MDDI_Stb signal is transferred from the host to a display where it is used to generate a clock signal for transferring reverse link data from the display, with which reverse data is sent back to the host.
  • a series of delay values 1.5 nsec, 8.0 nsec, 2.5 nsec, 2.0 nsec, 1.0 nsec, 1.5 nsec, 8.0 nsec, and 2.5 nsec, are shown near processing portions for the Stb+/- generation, cable transfer-to- display, display receiver, clock generation, signal clocking, Data0+/- generation, cable transfer-to-host, and host receiver stages, respectively.
  • the Reverse Rate Divisor makes it possible for one bit time on the reverse link to span multiple cycles of the MDDI_Stb signal. This means that the reverse link data rate is less than the forward link rate.
  • the actual length of signal delays through the interface may differ depending on each specific host-client system or hardware being used.
  • Each system can generally be made to perform better by using the Round Trip Delay Measurement Packet to measure the actual delay in a system so that the Reverse Rate Divisor can be set to an optimum value.
  • a round-trip delay is measured by having the host send a Round Trip Delay
  • Measurement Packet to the display.
  • the display responds to this packet by sending a sequence of ones back to the host inside of, or during, a pre-selected measurement window in that packet called the Measurement Period field. The detailed timing of this measurement was described previously. The round-trip delay is used to determine the rate at which the reverse link data can be safely sampled.
  • the round-trip delay measurement consists of determining, detecting, or counting the number of forward link data clock intervals occurring between the beginning of the Measurement Period field and the beginning of the time period when the Oxff, Oxff, 0x00 response sequence is received back at the host from the display. Note that it is possible that the response from the display could be received a small fraction of a forward link clock period before the measurement count was about to increment. If this unmodified value is used to calculate the Reverse Rate Divisor it could cause bit errors on the reverse link due to unreliable data sampling. An example of this situation is illustrated in FIG.
  • the Reverse Rate Divisor is the number of MDDI_Stb cycles the host should wait before sampling the reverse link data. Since MDDI_Stb is cycled at a rate that is one half of the forward link rate, the corrected round-trip delay measurement needs to be divided by 2 and then rounded up to the next integer. Expressed as a formula, this relationship is:
  • Link Clock There is a counter or similar known circuit or device present in both the host and client (display) to generate the Reverse Link Clock.
  • the counters are initialized so that the first rising edge of the Reverse Link Clock occurs at the beginning of the first bit in the Reverse Link Packets field of the Reverse Link Encapsulation packet. This is illustrated, for the example given below, in FIG. 52.
  • the counters increment at each rising edge of the MDDI_Stb signal, and the number of counts occurring until they wrap around is set by the Reverse Rate Divisor parameter in the Reverse Link Encapsulation Packet. Since the MDDI_Stb signal toggles at one half of the forward link rate, then the reverse link rate is one half of the forward link rate divided by the Reverse Rate Divisor. For example, if the forward link rate is 200 Mbps and the Reverse Rate Divisor is 4 then the reverse link data rate is expressed as:
  • FIG. 52 An example showing the timing of the MDDIJDataO and MDDI_Stb signal lines in a Reverse Link Encapsulation Packet is shown in FIG. 52, where the packet parameters used for illustration have the values:
  • Strobe Alignment is 0x00, 0x00, 0x60
  • the first reverse link packet returned from the display is the Display Request and
  • This packet having a Packet Length of 7 and a packet type of 70.
  • This packet begins with the byte values 0x07, 0x00, 0x46, ... and so forth. However, only the first byte (0x07) is visible in FIG. 52.
  • This first reverse link packet is time-shifted by nearly one reverse link clock period in the figure to illustrate an actual reverse link delay. An ideal waveform with zero host to display round-trip delay is shown as a dotted-line trace.
  • the strobe from the host is switching from one to zero and back to one as the data from the host changes level forming wider pulses. As the data goes to zero, the strobe switches at the higher rate, only the change in data on the data line causes a change near the end of the alignment field. The strobe switches at the higher rate for the remainder of the figure due to the fixed 0 or 1 levels of the data signal for extended periods of time, and the transitions falling on the pulse pattern (edge).
  • the reverse link clock for the host is at zero until the end of the Turn Around 1 period, when the clock is started to accommodate the reverse link packets
  • the arrows in the lower portion of the figure indicate when the data is sampled, as would be apparent from the remainder of the disclosure.
  • the first byte of the packet field being transferred (here 11000000) is shown commencing after Turn Around 1 and the line level has stabilized from the host driver being disabled.
  • the delay in the passage of the first bit, and as seen for bit three, can bee seen in the dotted lines for the Data signal.
  • a first region 5302 corresponds to an area of safe operation
  • a second region 5304 corresponds to an area of marginal performance
  • a third region 5306 indicates settings that are unlikely to function properly.
  • Packet and the Guard Time 1 field in the Round Trip Delay Measurement Packet designate values for lengths of time that allow for the host interface drivers to be disabled before the display interface drivers are enabled. Turn Around 2 and Guard Time 2 fields provide time values which allow the display drivers to be disabled before the host drivers are enabled.
  • the Guard Time 1 and Guard Time 2 fields are generally filled with pre-set or pre-selected values for lengths that are not meant to be adjusted. Depending on the interface hardware being used, these values may be developed using empirical data and adjusted in some instances to improve operation.
  • the maximum host driver disable time is specified in Table XI, where it shows that the drivers take about 10 nsec. maximum to disable and about 2 nsec. to enable.
  • the minimum number of forward link clocks required for the host driver to be disabled is expressed according to the relationship: ⁇ 7 7 ,. , , ForwardLinkDataRate ⁇ _ . _,. , , _. ,
  • Interface Type Factor is 1 for Type-I, 2 for Type-U, 4 for Type-UI, and 8 for Type-IV. [0257] Combining the two equations from above, one can see that the Interface Type
  • Turn Around 1 is defined as:
  • the timing margin improves from the point in time when the host is disabled to the time the display is enabled.
  • the factors that determine the length of time generally used for Turn Around 2 are the forward link data rate, the maximum disable time of the MDDIJData drivers in the display, and the round-trip delay of the communication link.
  • the calculation of the time required to disable the display driver is essentially the same as that for the host driver discussed above, and is defined according to the relationship:
  • a 1500 Mbps Type-UI forward link with a round-trip delay of 10 forward link clocks typically uses a Turn Around 2 delay on the order of:
  • Physical connections useful for implementing an interface according to the present invention can be realized using commercially available parts such as part number 3260-8S2(01) as manufactured by Hirose Electric Company Ltd on the host side, and part number 3240-8P-C as manufactured by Hirose Electric Company Ltd on the display device side.
  • An exemplary Type-I Interface pin assignment or "pinout" for such connectors used with a Type-I interface is listed in Table XUJ.
  • Interconnection elements or devices are chosen or designed in order to be small enough for use with mobile communication and computing devices, such as PDAs and wireless telephones, or portable game devices, without being obtrusive or unaesthetic in comparison to relative device size.
  • Any connectors and cabling should be durable enough for use in the typical consumer environment and allow for small size, especially for the cabling, and relatively low cost.
  • the transfer elements should accommodate data and strobe signals that are differential NRZ data having a transfer rate up to around 450 Mbps for Type I and Type U and up to 3.6 Gbps for the 8-bit parallel Type TV version.
  • FIGS. 54a and 54b A summary of the general steps undertaken in processing data and packets during operation of an interface using embodiments of the invention is shown in FIGS. 54a and 54b, along with an overview of the interface apparatus processing the packets in FIG. 55.
  • the process starts in a step 5402 with a determination as to whether or not the client and host are connected using a communication path, here a cable. This can occur through the use of periodic polling by the host, software or hardware that detects the presence of connectors or cables or signals at the inputs to the host (such as is seen for USB interfaces), or other known techniques.
  • a client Once a client is connected to the host, or visa versa, , or detected as present, either the client or the host sends appropriate packets requesting service in steps 5404 and 5406.
  • the client could send either Display Service Request or Status packets in step 5404. It is noted that the link, as discussed above, could have been previously shut down or be in hibernation mode so this may not be a complete initialization of the communication link that follows.
  • the client Once the communication link is synchronized and the host is trying to communicate with the client, the client also needs to provide Display Capabilities packet to the host, as in step 5408. The host can now begin to determine the type of support, including transfer rates, the client can accommodate.
  • the host and client also negotiate the type (rate/speed) of service mode to be used, for example Type I, Type U, Type ⁇ , and so forth, in a step 5410.
  • the host can begin to transfer information.
  • the host may use Round Trip Delay Measurement Packets to optimize the timing of the communication links in parallel with other signal processing, as shown in step 5411.
  • Sub-Frame Header Packet shown being transferred in step 5412, followed by the type of data, here video and audio stream packets, and filler packets, shown being transferred in step 5414.
  • the audio and video data will have been previously prepared or mapped into packets, and the filler packets are inserted as needed to fill out the required number of bits for the media frames.
  • the host can send packets such as the Forward Audio Channel Enable Packets to activate sound device, or
  • the host can transfer commands and information using other packet types discussed above, here shown as the transfer of Color Map, Bit Block Transfer or other packets in step 5416.
  • the host and client can exchange data relating to a keyboard or pointing devices using the appropriate packets.
  • a computer or other device communicating data could encounter loading conditions in processing data that causes a slow down in the preparation or presentation of packets.
  • a display receiving the data could change from a dedicated AC power source to a more limited battery power source, and either not be able to transfer in data as quickly, process commands as readily, or not be able to use the same degree of resolution or color depth under the more limited power settings.
  • a restrictive condition could be abated or disappear allowing either device to transfer data at higher rates. This being more desirable, a request can be made to change to a higher transfer rate mode.
  • step 5420 the host sends Interface Type Handoff Request Packets to the client requesting a handoff to another mode, the client sends Interface Type Acknowledge Packets confirming a change is sought, and the host sends_Perform Type Handoff Packets to make the change to the specified mode.
  • the client and host can also exchange packets relating to data intended for or received from pointing devices, keyboards, or other user type input devices associated primarily with the client, although such elements may also be present on the host side. These packets are typically processed using a general process or type element and not the state machine (5502). In addition, some of the commands discussed above will also be processed by the general processor. (5504, 5508)
  • step 5422 After data and commands have been exchanged between the host and client, at some point decision is made as to whether or not additional data is to be transferred or the host or client is going to cease servicing the transfer. This is shown in step 5422. If the link is to enter either a hibernation state or be shut down completely, the host sends a Link Shutdown packet to the client, and both sides terminate the transfer of data.
  • the packets being transferred in the above operations processing will be transferred using the drivers and receivers previously discussed in relation to the host and client controllers.
  • These line drivers and other logic elements are connected to the state machine and general processors discussed above, as illustrated in the overview of FIG. 55.
  • a state machine 5502 and general processors 5504 and 5508 may further be connected to other elements not shown such as a dedicated USB interface, memory elements, or other components residing outside of the link controller with which they interact, including, but not limited to, the data source, and video control chips for view display devices.
  • the processors, and state machine provide control over the enabling and disabling of the drivers as discussed above in relation to guard times, and so forth, to assure efficient establishment or termination of communication link, and transfer of packets.
  • the Display attributes field (1 byte) has a series of bit values that are interpreted as follows. Bits 1 and 0 select how the display pixel data is routed. For bit values of '00' or '11' data is displayed for both eyes, for bit values '10', data is routed only to the left eye, and for bit values '01', data is routed only to the right eye. Bit 2 indicates whether or not the Pixel Data is presented in an interlace format, with a value of '0' meaning the pixel data is in the standard progressive format, and that the row number (pixel Y coordinate) is incremented by 1 when advancing from one row to the next.
  • Bit 3 indicates that the Pixel Data is in alternate pixel format. This is similar to the standard interlace mode enabled by bit 2, but the interlacing is vertical instead of horizontal.
  • Bit 3 is 0 the Pixel Data is in the standard progressive format, and the column number (pixel X coordinate) is incremented by 1 as each successive pixel is received.
  • Bit 3 is 1 the Pixel Data is in alternate pixel format, and the column number is incremented by 2 as each pixel is received.
  • Bits 7 through 4 are reserved for future use and are generally set as zero.
  • the 2-byte X Start and Y Start fields specify the absolute X and Y coordinates of the point (X Start, Y Start) for the first pixel in the Pixel Data field.
  • the 2-byte X Left Edge and Y Top Edge fields specify the X coordinate of the left edge and Y coordinate of the top edge of the screen window filled by the Pixel Data field, while the X Right Edge and Y Bottom Edge fields specify the X coordinate of the right edge, and the Y coordinate of the bottom edge of the window being updated.
  • the Pixel Count field (2 bytes) specifies the number of pixels in the Pixel Data field below.
  • the Parameter CRC field (2 bytes) contains a CRC of all bytes from the Packet
  • the Pixel Data field contains the raw video information that is to be displayed, and which is formatted in the manner described by the Nideo Data Format Descriptor field. The data is transmitted one "row” at a time as discussed elsewhere.
  • the Pixel Data CRC field (2 bytes) contains a 16-bit CRC of only the Pixel Data.
  • the Audio Channel ID field (1 byte) identifies a particular audio channel to which audio data is sent by the client device.
  • the physical audio channels are specified in or mapped by this field as values of 0, 1, 2, 3, 4, 5, 6, or 7 indicate the left front, right front, left rear, right rear, front center, sub-woofer, surround left, and surround right channels, respectively.
  • An audio channel ID value of 254 indicates that the single stream of digital audio samples is sent to both the left front and right front channels. This simplifies applications where a stereo headset is used for voice communication, productivity enhancement apps in a PDA, or any application where a simple User Interface generates warning tones. Nalues for the ID field ranging from 8 through 253, and 255 are currently reserved for use where new designs desire additional designations.
  • the Audio Sample Count field (2 bytes) specifies the number of audio samples in this packet.
  • the Bits Per Sample and Packing field contains 1 byte that specifies the pacing format of audio data.
  • the format generally employed is for Bits 4 through 0 to define the number of bits per PCM audio sample.
  • Bit 5 then specifies whether or not the Digital Audio Data samples are packed.
  • FIG. 12 illustrates the difference between packed and byte-aligned audio samples.
  • a value of '0' for Bit 5 indicates that each PCM audio sample in the Digital Audio Data field is byte-aligned with the interface byte boundary, and a value of T indicates that each successive PCM audio sample is packed up against the previous audio sample.
  • This bit is effective only when the value defined in bits 4 through 0 (the number of bits per PCM audio sample) is not a multiple of eight.
  • Bits 7 through 6 are reserved for use where system designs desire additional designations and are generally set at a value of zero.
  • the Audio Sample Rate field (1 byte) specifies the audio PCM sample rate.
  • the format employed is for a value of 0 to indicate a rate of 8,000 samples per second (sps), a value of 1 indicates 16,000 sps., value of 2 for 24,000 sps, value of 3 for 32,000 sps, value of 4 for 40,000 sps, value of 5 for 48,000 sps, value of 6 for 11,025 sps, value of 7 for 22,050 sps, and value of 8 for 44,100 sps, respectively, with values of 9 through 15 being reserved for future use, so they are currently set to zero.
  • the Parameter CRC field (2 bytes) contains a 16-bit CRC of all bytes from the
  • the Digital Audio Data field contains the raw audio samples to be played, and is usually in the form of a linear format as unsigned integers.
  • the Audio Data CRC field (2 bytes) contain a 16-bit CRC of only the Audio Data. If this CRC fails to check then the Audio Data can still be used, but the CRC error count is incremented.
  • the 2-byte Stream ID Number field is used to identify a particular video stream.
  • the contents of the Stream Parameters and Stream Data fields are defined by the MDDI equipment manufacturer.
  • the 2-byte Stream Parameter CRC field contains a 16-bit CRC of all bytes of the stream parameters starting from the Packet Length to the Audio Coding byte. If this CRC fails to check then the entire packet is discarded.
  • the 2-byte Stream Data CRC field contains a CRC of only the Stream Data. If this CRC fails to check appropriately then use of the Stream Data is optional, depending on the requirements of the application. Use of the stream data contingent on the CRC being good generally requires that the stream data be buffered until the CRC is confirmed good. The CRC error count is incremented if the CRC does not check.
  • the Color Map Data Size field (2 bytes) specifies the total number of color map table entries that exist in the Color Map Data in this packet. The number of bytes in the Color Map Data is 3 times the Color Map Size. The Color Map Size is et to zero to send no color map data. If the Color Map Size is zero then a Color Map Offset value is still sent but it is ignored by the display. The Color Map Offset field (2 bytes) specifies the offset of the Color Map Data in this packet from the beginning of the color map table in the display device. [0287] A 2-byte Parameter CRC field contains a CRC of all bytes from the Packet
  • each color map location is a 3-byte value, where the first byte specifies the magnitude of blue, the second byte specifies the magnitude of green, and the third byte specifies the magnitude of red.
  • the Color Map Size field specifies the number of 3-byte color map table items that exist in the Color Map Data field. If a single color map cannot fit into one Nideo Data Format and Color Map Packet, then the entire color map may be specified by sending multiple packets with different Color Map Data and Color Map Offsets in each packet.
  • a 2-byte Color Map Data CRC field contains a CRC of only the Color Map Data.
  • the Reverse Link Flags field (1 byte) contains a set of flags to request information from the display. If a bit(here Bit 0) is set to one then the host requests the specified information from the display using the Display Capability Packet. If the bit is zero then the host does not need the information from the display. The remaining bits (here Bits 1 through 7) are reserved for future use and are set to zero.
  • the Reverse Rate Divisor field (1 byte) specifies the number of MDDI_Stb cycles that occur in relation to the reverse link data clock.
  • the reverse link data clock is equal to the forward link data clock divided by two times the Reverse Rate Divisor.
  • the reverse link data rate is related to the reverse link data clock and the Interface Type on the reverse link. For a Type I interface the reverse data rate equals the reverse link data clock, for Type H, Type UI, sand Type IN interfaces the reverse data rates equal two times, four times, and eight times the reverse link data clock, respectively.
  • the Turn-Around 1 Length field (1 byte) specifies the total number of bytes that are allocated for Turn- Around 1.
  • the recommended length of Turn- Around 1 is the number of bytes required for the MDDIJData drivers in a host to have the outputs disabled. This is based on the output disable time discussed above, the forward link data rate, and the forward link Interface Type selection being used. A more complete description of the setting of Turn-Around 1 is given in above.
  • the Turn-Around 2 Length field (1 byte) specifies the total number of bytes that are allocated for Turn-Around.
  • the recommended length of Turn-Around 2 is the number of bytes required for the MDDIJData drivers in the Display to disable their outputs plus the round-trip delay. A description of the setting of Turn- Around 2 is given above.
  • the Parameter CRC field (2 bytes) contain a 16-bit CRC of all bytes from the
  • the Strobe Alignment field (3 bytes) contains a value so that the MDDIjStb signal makes a low to high transition at the bit boundary between the last bit of the All
  • MDDI Stb behaves in a consistent manner with respect to the byte boundaries in the Reverse Data Packets field.
  • All Zero field (1 byte) is set equal to zero, and is used to ensure that all
  • MDDIJData signals are in the zero state prior to disabling the line drivers during the first
  • the Turn-Around 1 field is used for establishing the first turn-around period.
  • the number of bytes specified by the Turn-Around Length parameter are allocated by this field to allow the MDDIJData line drivers in the host to disable before the line drivers in the client (display) are enabled.
  • the host disables its MDDIJData line drivers during bit
  • the Reverse Data Packets field contains a series of data packets being transferred from the client to a host. As stated earlier, Filler packets are sent to fill the remaining space that is not used by other packet types.
  • Turn-Around 2 field is used for establishing the second turn-around period. The number of bytes specified by the Turn-Around Length parameter are allocated by this field.
  • the Driver Re-enable field uses 1 byte that is equal to zero to ensure that all
  • MDDIJData signals are re-enabled prior to the Packet Length Field of the next packet.
  • the Protocol Version field uses 2 bytes to specify a protocol version used by the client.
  • the initial version is set equal to zero
  • the Minimum Protocol Version field uses 2 bytes to specify the minimum protocol version that the client can employ or interpret.
  • the Display Data Rate Capability field (2 bytes) specifies the maximum data rate the display can receive on the forward link of the interface, and is specified in the form of megabits per second (Mbps).
  • the Interface Type Capability field (1 byte) specifies the interface types that are supported on the forward and reverse links.
  • Bit 1 This is currently indicated by selecting Bit 0, Bit 1, or Bit 2 to select either a Type-H, Type-IH or Type-IN mode on the forward link, respectively, and Bit 3, Bit 4, or Bit 5 to select either a Type-II, Type-UI, or Type-JN mode on the reverse link, respectively; with Bits 6 and 7 being reserved and set to zero.
  • the Bitmap Width and Height fields (2 bytes) specify the width and height of the bitmap in pixels.
  • the Monochrome Capability field (1 byte) is used to specify the number of bits of resolution that can be displayed in a monochrome format. If a display cannot use a monochrome format then this value is set at zero. Bits 7 through 4 are reserved for future use and are, thus, set as zero. Bits 3 through 0 define the maximum number of bits of grayscale that can exist for each pixel. These four bits make it possible to specify values of 1 to 15 for each pixel. If the value is zero then monochrome format is not supported by the display.
  • the Colormap Capability field (3 bytes) specifies the maximum number of table items that exist in the colormap table in the display. If the display cannot use the colormap format then this value is zero.
  • the RGB Capability field (2 bytes) specifies the number of bits of resolution that can be displayed in RGB format. If the display cannot use the RGB format then this value is zero.
  • the RGB Capability word is composed of three separate unsigned values where: Bits 3 through 0 define the maximum number of bits of blue, Bits 7 through 4 define the maximum number of bits of green, and Bits 11 through 8 define the maximum number of bits of red in each pixel. Currently, Bits 15 through 12 are reserved for future use and are generally set to zero.
  • the Y Cr Cb Capability field (2 bytes) specifies the number of bits of resolution that can be displayed in Y Cr Cb format. If the display cannot use the Y Cr Cb format then this value is zero.
  • the Y Cr Cb Capability word is composed of three separate unsigned values where: Bits 3 through 0 define the maximum number of bits in the Cb sample, Bits 7 through 4 define the maximum number of bits in the Cr sample, Bits 11 through 8 define the maximum number of bits in the Y sample, and Bits 15 through 12 are currently reserved for future use and are set to zero.
  • the Display Feature Capability Indicators field uses 4 bytes that contain a set of flags that indicate specific features in the display that are supported. A bit set to one indicates the capability is supported, and a bit set to zero indicates the capability is not supported. The value for Bit 0 indicates whether or not Bitmap Block Transfer Packet (packet type 71) is supported. The value for Bits 1, 2, and 3 indicate whether or not Bitmap Area Fill Packet (packet type 72), Bitmap Pattern Fill Packet (packet type 73), or Communication Link Data Channel Packet (packet type 74), respectively, are supported.
  • the value for Bit 4 indicates whether or not the display has the capability to make one color transparent, while values for bits Bit 5 and 6 indicate if the display can accept video data or audio data in packed format, respectively, and the value for Bit 7 indicates if the display can send a reverse-link video stream from a camera.
  • the value for Bits 11 and 12 indicate when the client is communicating either with a pointing device and can send and receive Pointing Device Data Packets, or with a keyboard and can send and receive Keyboard Data Packets, respectively. Bits 13 through 31 are currently reserved for future use or alternative designations useful for system designers and are generally set equal to zero.
  • the Display Video Frame Rate Capability field (1 byte) specifies the maximum video frame update capability of the display in frames per second. A host may choose to update the image at a slower rate than the value specified in this field.
  • the Audio Buffer Depth field (2 bytes) specifies the depth of the elastic buffer in a
  • the Audio Channel Capability field (2 bytes) contains a group of flags that indicate which audio channels are supported by the display (client). A bit set to one indicates the channel is supported, and a bit set to zero indicates that channel is not supported.
  • the Bit positions are assigned to the different channels such that Bit positions 0, 1, 2, 3, 4, 5, 6, and 7 indicate the left front, right front, left rear, right rear, front center, sub-woofer, surround left, and surround right channels, respectively. Bits 8 through 15 are currently reserved for future use, and are generally set to zero.
  • a 2-byte Audio Sample Rate Capability field for the forward link, contains a set of flags to indicate the audio sample rate capability of the client device. Bit positions are assigned to the different rates accordingly as Bits 0, 1, 2, 3, 4, 5, 6, 7, and 8 are assigned to 8,000, 16,000, 24,000, 32,000, 40,000, 48,000, 11,025, 22,050, and 44,100 samples per second (SPS), respectively, with Bits 9 through 15 being reserved for future or alternative rate uses, as desired, so they are currently set to '0'. Setting a bit value for one of these bits to T indicates that that particular sample rate is supported, and setting the bit to '0' indicates that that sample rate is not supported.
  • SPS samples per second
  • the Minimum Sub-frame Rate field (2 bytes) specifies the minimum sub-frame rate in frames per second.
  • the minimum sub-frame rate keeps the display status update rate sufficient to read certain sensors or pointing devices in the display.
  • a 2-byte Mic Sample Rate Capability field for the reverse link, that contains a set of flags that indicate the audio sample rate capability of a microphone in the client device.
  • a client device microphone is configured to minimally support at least an 8,000 sample per second rate. Bit positions for this field are assigned to the different rates with bit positions 0, 1, 2, 3, 4, 5, 6, 7, and 8 are used to represent 8,000, 16,000, 24,000, 32,000, 40,000, 48,000, 11,025, 22,050, and 44,100 samples per second (SPS), respectively, with Bits 9 through 15 being reserved for future or alternative rate uses, as desired, so they are currently set to '0'. Setting a bit value for one of these bits to T indicates that that particular sample rate is supported, and setting the bit to '0' indicates that that sample rate is not supported. If no microphone is connected then each of the Mic Sample Rate Capability bits are set equal to zero.
  • the Content Protection Type field (2 bytes) contains a set of flags that indicate the type of digital content protection that is supported by the Display. Currently, bit position 0 is used to indicate when DTCP is supported and bit position 1 is used to indicate when HDCP is supported, with bit positions 2 through 15 being reserved for use with other protection schemes as desired or available, so they are currently set to zero. G. For Display Request and Status Packets
  • the Reverse Link Request field (3 byte) specifies the number of bytes the display needs in the reverse link in the next sub-frame to send information to the host.
  • the CRC Error Count field (1 byte) indicates how many CRC errors have occurred since the beginning of the media-frame.
  • the CRC count is reset when a sub- frame header packet with a Sub-frame Count of zero is sent. If the actual number of CRC errors exceeds 255 then this value saturates at 255.
  • the Capability Change field uses 1 byte to indicate a change in the capability of the display. This could occur if a user connects a peripheral device such as a microphone, keyboard, or display, or for some other reason.
  • Bits[7:0] are equal to 0 then the capability has not changed since the last Display Capability Packet was sent. However, when Bits [7:0] are equal to 1 to 255, the capability has changed.
  • the Display Capability Packet is examined to determine the new display characteristics.
  • the Window Upper Left Coordinate X Value and Y Value fields use 2 bytes each to specify the X and Y value of the coordinates of the upper left corner of the window to be moved.
  • the Window Width and Height fields use 2 bytes each to specify the width and height of the window to be moved.
  • the Window X Movement and Y Movement fields use 2 bytes each to specify the number of pixels that the window shall be moved horizontally and vertically, respectively. Positive values for X cause the window to be moved to the right, and negative values cause movement to the left, while positive values for Y cause the window to be moved down, and negative values cause upward movement.
  • Window Upper Left Coordinate X Value and Y Value fields use 2 bytes each to specify the X and Y value of the coordinates of the upper left corner of the window to be filled.
  • the Window Width and Height fields (2 bytes each) specify the width and height of the window to be filled.
  • the Video Data Format Descriptor field (2 bytes) specifies the format of the Pixel Area Fill Value. The format is the same as the same field in the Video Stream Packet.
  • the Pixel Area Fill Value field (4 bytes) contains the pixel value to be filled into the window specified by the fields discussed above. The format of this pixel is specified in the Video Data Format Descriptor field.
  • Window Upper Left Coordinate X Value and Y Value fields use 2 bytes each to specify the X and Y value of the coordinates of the upper left corner of the window to be filled.
  • the Window Width and Height fields (2 bytes each) specify the width and height of the window to be filled.
  • the Pattern Width and Pattern Height fields (2 bytes each) specify the width and height, respectively, of the fill pattern.
  • the 2-byte Video Data Format Descriptor field specifies the format of the Pixel Area Fill Value.
  • FIG. 11 illustrates how the Video Data Format Descriptor is coded. The format is the same as the same field in the Video Stream Packet.
  • the Parameter CRC field (2 bytes) contains a CRC of all bytes from the Packet
  • the Pattern Pixel Data field contains raw video information that specifies the fill pattern in the format specified by the Video Data Format Descriptor. Data is packed into bytes, and the first pixel of each row must be byte-aligned. The fill pattern data is transmitted a row at a time.
  • the Pattern Pixel Data CRC field (2 bytes) contains a CRC of only the Pattern Pixel Data. If this CRC fails to check then the Pattern Pixel Data shall still be used but the CRC error count shall be incremented.
  • the Parameter CRC field (2 bytes) contain a 16-bit CRC of all bytes from the
  • the Communication Link Data field contains the raw data from the communication channel. This data is simply passed on to the computing device in the display.
  • the Communication Link Data CRC field (2 bytes) contains a 16-bit CRC of only the Communication Link Data. If this CRC fails to check then the Communication Link Data is still used or useful, but the CRC error count is incremented.
  • the Interface Type field (1 byte) specifies the new interface type to use. The value in this field specifies the interface type in the following manner. If the value in Bit 7 is equal to 0 the Type handoff request is for the forward link, if it is equal to 1, then the Type handoff request is for the reverse link. Bits 6 through 3 are reserved for future use, and are generally set to zero. Bits 2 through 0 are used to define the interface Type to be used, with a value of 1 meaning a handoff to Type-I mode, value of 2 a handoff to Type- U mode, a value of 3 a handoff to Type-IU mode, and a value of 4 a handoff to Type-IV mode. The values of 0 and 5 through 7 are reserved for future designation of alternative modes or combinations of modes. .
  • the Interface Type field (1 byte) has a values that confirms the new interface type to use. The value in this field specifies the interface type in the following manner. If Bit 7 is equal to 0 the Type handoff request is for the forward link, alternatively, if it is equal to 1 the Type handoff request is for the reverse link. Bit positions 6 through 3 are currently reserved for use in designating other handoff types, as desired, and are generally set to zero. However, bit positions 2 through 0 are used define the interface Type to be used with a value of 0 indicating a negative acknowledge, or that the requested handoff cannot be performed, values of 1, 2, 3, and 4 indicating handoff to Type-I, Type- ⁇ , Type- ⁇ i, and Type-IV modes, respectively. Values of 5 through 7 are reserved for use with alternative designations of modes, as desired.
  • the 1-byte Interface Type field indicates the new interface type to use.
  • the value present in this field specifies the interface type by first using the value of Bit 7 to determine whether or not the Type handoff is for the forward or reverse links.
  • a value of '0' indicates the Type handoff request is for the forward link, and a value of T the reverse link.
  • Bits 6 through 3 are reserved for future use, and as such are generally set to a value of zero.
  • Bits 2 through 0 are used to define the interface Type to be used, with the values 1, 2, 3, and 4 specifying the use of handoff to Type-I, Type-II, Type-IU, and Type-IV modes, respectively.
  • the use of values 0 and 5 through 7 for these bits is reserved for future use.
  • the Audio Channel Enable Mask field (1 byte) contains a group of flags that indicate which audio channels are to be enabled in a client. A bit set to one enables the corresponding channel, and a bit set to zero disables the corresponding channel Bits 0 through 5 designate channels 0 through 5 which address left front, right front, left rear, right rear, front center, and sub-woofer channels, respectively. Bits 6 and 7 are reserved for future use, and in the mean time are be set to zero.
  • the Audio Sample Ratefield(l byte) specifies the digital audio sample rate.
  • the values for this field are assigned to the different rates with values of 0, 1, 2, 3, 4, 5, 6, 7, and 8 being used to designate 8,000, 16,000, 24,000, 32,000, 40,000, 48,000, 11,025, 22,050, and 44,100 samples per second (SPS), respectively, with values of 9 through 254 being reserved for use with alternative rates, as desired, so they are currently set to O ⁇ A value of 255 is used to disable the reverse-link audio stream.
  • the Sample Format field (1 byte) specifies the format of the digital audio samples. When Bits[l:0] are equal to 0, the digital audio samples are in linear format, when they are equal to 1, the digital audio samples are in ⁇ -Law format, and when they are equal to 2, the digital audio samples are in A-Law format. Bits[7:2] are reserved for alternate use in designating audio formats, as desired, and are generally set equal to zero. Q. For The Digital Content Protection Overhead Packets
  • the Content Protection Type field (1 byte) specifies the digital content protection method that is used. A value of 0 indicates Digital Transmission Content Protection (DTCP) while a value of 1 indicates High-bandwidth Digital Content Protection System (HDCP). The value range of 2 through 255 is not currently specified but is reserved for use with alternative protection schemes as desired.
  • the Content Protection Overhead Messages field is a variable length field containing content protection messages sent between the host and client.
  • the Transparent Color Enable field (1 byte) specifies when transparent color mode is enabled or disabled. If Bit 0 is equal to 0 then transparent color mode is disabled, if it is equal to 1 then transparent color mode is enabled and the transparent color is specified by the following two parameters. Bits 1 through 7 of this byte are reserved for future use and are set to zero.
  • the Video Data Format Descriptor field (2 bytes) specifies the format of the Pixel Area Fill Value.
  • FIG. 11 illustrates how the Video Data Format Descriptor is coded.
  • the format is generally the same as the same field in the Video Stream Packet.
  • the Pixel Area Fill Value field uses 4 bytes allocated for the pixel value to be filled into the window specified above.
  • the format of this pixel is specified in the Video Data Format Descriptor field.
  • the Parameter CRC field (2 bytes) contains a 16-bit CRC of all bytes from the
  • the Strobe Alignment field (2 bytes) contains a value so that the MDDI_Stb signal makes a low to high transition at the bit boundary immediately prior to the first bit of the All Zero field of this packet. This ensures that the MDDI_Stb signal behaves in a consistent manner with respect to the byte boundaries in the Measurement Period any time this packet is sent.
  • the All Zero field (1 byte) contains zeroes to ensure that all MDDIJData signals are in the zero state prior to disabling the line drivers during the first Guard Time period.
  • the Guard Time 1 field (8 bytes) is used to allow the MDDIJData line drivers in the host to disable before the line drivers in the client (display) are enabled.
  • the host disables its MDDIJData line drivers during bit 0 of Guard Time 1 and the Display enables its line drivers immediately after the last bit of Guard Time 1.
  • the Measurement Period field is a 512 byte window used to allow the Display to respond with a Oxff, Oxff, 0x0 at half the data rate used on the forward link. This rate corresponds to a Reverse Link Rate Divisor of 1.
  • the Display returns this response immediately at the beginning of the Measurement Period. This response will be received at a host at precisely the round trip delay of the link after the beginning of the first bit of the Measurement Period at the host.
  • the MDDI JData line drivers in the Display are disabled immediately before and immediately after the Oxff, Oxff, 0x00 response from the Display.
  • Guard Time 2 8 bytes
  • Client MDDIJData line drivers to disable before line drivers in the Host are enabled.
  • Guard Time 2 is always present but is only required when the round trip delay is at the maximum amount that can be measured in the Measurement Period.
  • the Client disables its line drivers during bit 0 of Guard Time 2 and the Host enables its line drivers immediately after the last bit of Guard Time 2.
  • the Driver Re-enable field (1 byte) is set equal to zero, to ensure that all
  • MDDIJData signals are re-enabled prior to the Packet Length Field of the next packet.

Abstract

L'invention concerne une interface de données pour le transfert de données numériques entre un hôte et un client, sur un trajet de communication à structures en paquet reliées entre elles pour l'établissement d'un protocole de communication capable d'assurer le transfert d'une série prédéterminée de données numériques de contrôle et de présentation. Des unités de contrôle de liaison utilisent le protocole. Ce unités sont capables de produire, de transmettre et de recevoir des paquets formant le protocole, et aussi de présenter des données numériques en un ou plusieurs types de paquets de données, sachant qu'au moins un de ces paquets réside dans le dispositif hôte et est mis en relation avec le client via le trajet de communication. L'interface assure un mécanisme de transmission rentable, à faible consommation d'énergie, bidirectionnel, à grande vitesse, sur une liaison de données du type 'série' à courte portée, qui se prête à la mise en oeuvre de connecteurs miniature et de câbles flexibles fins particulièrement utiles pour le raccordement d'éléments d'affichage, du type micro-afficheurs prêt-à-porter, à des ordinateurs portatifs et des dispositifs de communication hertziens.
PCT/US2001/047807 2000-12-15 2001-12-14 Etablissement et mise en oeuvre d'un protocole de communication pour le transfert de signaux a debit binaire eleve WO2002049314A2 (fr)

Priority Applications (11)

Application Number Priority Date Filing Date Title
KR1020037008002A KR100944843B1 (ko) 2000-12-15 2001-12-14 높은 데이터 레이트의 신호 전송을 위한 통신 프로토콜 및 인터페이스의 형성과 구현
IL15638501A IL156385A0 (en) 2000-12-15 2001-12-14 Generating and implementing a communication protocol and interface for high data rate signal transfer
AU2002227359A AU2002227359B2 (en) 2000-12-15 2001-12-14 Generating and implementing a communication protocol and interface for high data rate signal transfer
JP2002550691A JP2004531916A (ja) 2000-12-15 2001-12-14 通信プロトコルの発生と実施および高いデータレート信号転送のためのインターフェース
BRPI0116157A BRPI0116157B1 (pt) 2000-12-15 2001-12-14 geração e implementação de um protocolo e uma interface de comunicação para transferência de sinal com alta taxa de dados
AU2735902A AU2735902A (en) 2000-12-15 2001-12-14 Generating and implementing a communication protocol and interface for high datarate signal transfer
MXPA03005310A MXPA03005310A (es) 2000-12-15 2001-12-14 Generar e implementar un protocolo de comunicaciones e interfase para transferencia de senal de alta velocidad de datos.
EP01996216A EP1342352A2 (fr) 2000-12-15 2001-12-14 Etablissement et mise en oeuvre d'un protocole de communication pour le transfert de signaux a debit binaire eleve
CA2431492A CA2431492C (fr) 2000-12-15 2001-12-14 Etablissement et mise en oeuvre d'un protocole de communication pour le transfert de signaux a debit binaire eleve
HK04110331.3A HK1067477A1 (en) 2000-12-15 2004-12-30 Generating and implementing a communication protocol and interface for high data rate signal transfer
IL196247A IL196247A (en) 2000-12-15 2008-12-28 Production and implementation of a protocol and communication interface for high-speed signal transmission

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US25583300P 2000-12-15 2000-12-15
US60/255,833 2000-12-15

Publications (2)

Publication Number Publication Date
WO2002049314A2 true WO2002049314A2 (fr) 2002-06-20
WO2002049314A3 WO2002049314A3 (fr) 2003-05-01

Family

ID=22970054

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2001/047807 WO2002049314A2 (fr) 2000-12-15 2001-12-14 Etablissement et mise en oeuvre d'un protocole de communication pour le transfert de signaux a debit binaire eleve

Country Status (13)

Country Link
EP (1) EP1342352A2 (fr)
JP (1) JP2004531916A (fr)
KR (2) KR100944843B1 (fr)
CN (2) CN100473058C (fr)
AU (2) AU2735902A (fr)
BR (1) BRPI0116157B1 (fr)
CA (4) CA2431492C (fr)
HK (1) HK1067477A1 (fr)
IL (2) IL156385A0 (fr)
MX (1) MXPA03005310A (fr)
RU (1) RU2003121400A (fr)
TW (1) TW577208B (fr)
WO (1) WO2002049314A2 (fr)

Cited By (55)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2005018191A2 (fr) * 2003-08-13 2005-02-24 Qualcomm, Incorporated Interface de signal pour debits binaires superieurs
WO2005122509A1 (fr) * 2004-06-04 2005-12-22 Qualcomm Incorporated Appareil et procede a interface a debit binaire eleve
JP2007509533A (ja) * 2003-10-15 2007-04-12 クゥアルコム・インコーポレイテッド 高速データレートインタフェース
JP2007513591A (ja) * 2003-12-08 2007-05-24 クゥアルコム・インコーポレイテッド 改良されたリンク同期を備えた高速データレートインタフェース
JP2007528681A (ja) * 2004-03-10 2007-10-11 クゥアルコム・インコーポレイテッド 高データレートインタフェース装置及び方法
JP2007531120A (ja) * 2004-03-24 2007-11-01 クゥアルコム・インコーポレイテッド 高データレートインターフェース装置および方法
KR100882166B1 (ko) * 2004-06-04 2009-02-06 퀄컴 인코포레이티드 고 데이터 레이트 인터페이스 장치 및 방법
US7751853B2 (en) 2003-04-25 2010-07-06 Apple Inc. Female receptacle data pin connector
US7757026B2 (en) 2004-04-27 2010-07-13 Apple Inc. Techniques for transferring status information between an accessory and a multi-communication device
US7779185B2 (en) 2004-04-27 2010-08-17 Apple Inc. Communication between a media player and an accessory using a protocol with multiple lingoes
US7823214B2 (en) 2005-01-07 2010-10-26 Apple Inc. Accessory authentication for electronic devices
CN101938493A (zh) * 2003-06-02 2011-01-05 高通股份有限公司 生成并实施一用于更高数据率的讯号协议和接口
US7877532B2 (en) 2004-04-27 2011-01-25 Apple Inc. Communication between an accessory and a media player with multiple lingoes and lingo version information
JP2011041290A (ja) * 2004-11-24 2011-02-24 Qualcomm Inc バッファを更新するための方法及びシステム
JP2011066935A (ja) * 2003-09-10 2011-03-31 Qualcomm Inc 高速データレートインタフェース
WO2011097303A1 (fr) * 2010-02-08 2011-08-11 Apple Inc. Système de télécommunications numériques comportant des canaux de trafic à bande passante adaptable
US8047966B2 (en) 2008-02-29 2011-11-01 Apple Inc. Interfacing portable media devices and sports equipment
US8086332B2 (en) 2006-02-27 2011-12-27 Apple Inc. Media delivery system with improved interaction
US8099536B2 (en) 2004-04-27 2012-01-17 Apple Inc. Communication between an accessory and a media player with general and accessory lingoes
US8102849B2 (en) 2009-02-12 2012-01-24 Qualcomm, Incorporated Association procedure to enable multiple multicast streams
US8112567B2 (en) 2006-09-11 2012-02-07 Apple, Inc. Method and system for controlling power provided to an accessory
US8208853B2 (en) 2008-09-08 2012-06-26 Apple Inc. Accessory device authentication
US8238811B2 (en) 2008-09-08 2012-08-07 Apple Inc. Cross-transport authentication
US8253683B2 (en) 2005-05-30 2012-08-28 Renesas Electronics Corporation Liquid crystal display drive and control device, mobile terminal system, and data processing system
US8275924B2 (en) 2007-09-04 2012-09-25 Apple Inc. Smart dock for chaining accessories
US8370555B2 (en) 2006-06-27 2013-02-05 Apple Inc. Method and system for allowing a media player to determine if it supports the capabilities of an accessory
JP2013034221A (ja) * 2003-11-12 2013-02-14 Qualcomm Inc 改善されたリンク制御を有する高速データレートインタフェース
JP2013539636A (ja) * 2010-08-26 2013-10-24 サムスン エレクトロニクス カンパニー リミテッド 非圧縮動画データパケットを生成する方法及びその装置
US8590036B2 (en) 2006-06-27 2013-11-19 Apple Inc. Method and system for authenticating an accessory
US8667144B2 (en) 2007-07-25 2014-03-04 Qualcomm Incorporated Wireless architecture for traditional wire based protocol
US8674957B2 (en) 2011-02-04 2014-03-18 Qualcomm Incorporated User input device for wireless back channel
US8694663B2 (en) 2001-09-06 2014-04-08 Qualcomm Incorporated System for transferring digital data at a high rate between a host and a client over a communication path for presentation to a user
US8692838B2 (en) 2004-11-24 2014-04-08 Qualcomm Incorporated Methods and systems for updating a buffer
US8692839B2 (en) 2005-11-23 2014-04-08 Qualcomm Incorporated Methods and systems for updating a buffer
US8811294B2 (en) 2008-04-04 2014-08-19 Qualcomm Incorporated Apparatus and methods for establishing client-host associations within a wireless network
US8964783B2 (en) 2011-01-21 2015-02-24 Qualcomm Incorporated User input back channel for wireless displays
US9065876B2 (en) 2011-01-21 2015-06-23 Qualcomm Incorporated User input back channel from a wireless sink device to a wireless source device for multi-touch gesture wireless displays
US9198084B2 (en) 2006-05-26 2015-11-24 Qualcomm Incorporated Wireless architecture for a traditional wire-based protocol
US9264248B2 (en) 2009-07-02 2016-02-16 Qualcomm Incorporated System and method for avoiding and resolving conflicts in a wireless mobile display digital interface multicast environment
JP2016511965A (ja) * 2013-01-25 2016-04-21 クゥアルコム・インコーポレイテッドＱｕａｌｃｏｍｍ Ｉｎｃｏｒｐｏｒａｔｅｄ ワイヤレスディスプレイデバイスのためのユーザ入力制御のためのコネクションレストランスポート
US9398089B2 (en) 2008-12-11 2016-07-19 Qualcomm Incorporated Dynamic resource sharing among multiple wireless devices
US9413803B2 (en) 2011-01-21 2016-08-09 Qualcomm Incorporated User input back channel for wireless displays
US9467735B2 (en) 2007-09-04 2016-10-11 Apple Inc. Synchronizing digital audio and analog video from a portable media device
US9503771B2 (en) 2011-02-04 2016-11-22 Qualcomm Incorporated Low latency wireless display for graphics
US9525998B2 (en) 2012-01-06 2016-12-20 Qualcomm Incorporated Wireless display with multiscreen service
US9582238B2 (en) 2009-12-14 2017-02-28 Qualcomm Incorporated Decomposed multi-stream (DMS) techniques for video display systems
US9582239B2 (en) 2011-01-21 2017-02-28 Qualcomm Incorporated User input back channel for wireless displays
US9787725B2 (en) 2011-01-21 2017-10-10 Qualcomm Incorporated User input back channel for wireless displays
US9813070B2 (en) 2015-02-16 2017-11-07 Postech Academy—Industry Foundation Display apparatus and driving method for the same
US10108386B2 (en) 2011-02-04 2018-10-23 Qualcomm Incorporated Content provisioning for wireless back channel
US10135900B2 (en) 2011-01-21 2018-11-20 Qualcomm Incorporated User input back channel for wireless displays
CN111371542A (zh) * 2015-04-13 2020-07-03 高通股份有限公司 用于基于脉冲的多线链路的时钟和数据恢复
WO2020150187A1 (fr) * 2019-01-14 2020-07-23 Texas Instruments Incorporated Identification de point d'échantillonnage à des fins de capture de données asynchrone basse fréquence
TWI748447B (zh) 2020-05-12 2021-12-01 瑞昱半導體股份有限公司 影音介面之控制訊號傳輸電路及控制訊號接收電路
US11800054B2 (en) 2020-06-19 2023-10-24 Realtek Semiconductor Corporation Multimedia audio/video system

Families Citing this family (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6760772B2 (en) 2000-12-15 2004-07-06 Qualcomm, Inc. Generating and implementing a communication protocol and interface for high data rate signal transfer
EP1692842A1 (fr) 2003-10-29 2006-08-23 Qualcomm Incorporated Interface a haut debit
BRPI0416895A (pt) 2003-11-25 2007-03-06 Qualcomm Inc interface de alta taxa de dados com sincronização de link melhorada
WO2005091593A1 (fr) * 2004-03-17 2005-09-29 Qualcomm Incorporated Appareil et procede d'interface de donnees grande vitesse
US8650304B2 (en) 2004-06-04 2014-02-11 Qualcomm Incorporated Determining a pre skew and post skew calibration data rate in a mobile display digital interface (MDDI) communication system
US8699330B2 (en) 2004-11-24 2014-04-15 Qualcomm Incorporated Systems and methods for digital data transmission rate control
US8539119B2 (en) 2004-11-24 2013-09-17 Qualcomm Incorporated Methods and apparatus for exchanging messages having a digital data interface device message format
US8667363B2 (en) 2004-11-24 2014-03-04 Qualcomm Incorporated Systems and methods for implementing cyclic redundancy checks
US8873584B2 (en) 2004-11-24 2014-10-28 Qualcomm Incorporated Digital data interface device
EP2317688A3 (fr) * 2004-11-24 2012-03-21 QUALCOMM Incorporated Systèmes et procédés permettant la mise en oeuvre de controles de redondance cycliqués
US8723705B2 (en) 2004-11-24 2014-05-13 Qualcomm Incorporated Low output skew double data rate serial encoder
US7979561B2 (en) 2005-03-10 2011-07-12 Qualcomm Incorporated Method of multiplexing over an error-prone wireless broadcast channel
US7599439B2 (en) * 2005-06-24 2009-10-06 Silicon Image, Inc. Method and system for transmitting N-bit video data over a serial link
KR100685664B1 (ko) * 2005-08-12 2007-02-26 삼성전자주식회사 호스트 및 클라이언트로 구성된 데이터 통신 시스템 및데이터 통신 시스템의 작동 방법
WO2007037147A1 (fr) * 2005-09-29 2007-04-05 Nikon Corporation Systeme de reproduction de donnees de contenu et programme de realisation du systeme de reproduction de donnees
US8730069B2 (en) 2005-11-23 2014-05-20 Qualcomm Incorporated Double data rate serial encoder
CN101432683B (zh) * 2006-05-26 2013-08-28 高通股份有限公司 用于传统的基于线路的协议的无线结构
US8356331B2 (en) * 2007-05-08 2013-01-15 Qualcomm Incorporated Packet structure for a mobile display digital interface
JP5231533B2 (ja) * 2008-05-06 2013-07-10 クゥアルコム・インコーポレイテッド モバイル・ディスプレイ・ディジタル・インターフェース用パケット構造
JP5367539B2 (ja) * 2009-11-09 2013-12-11 シャープ株式会社 インターフェース装置
TWI497307B (zh) * 2010-04-21 2015-08-21 Via Tech Inc 通用串列匯流排事務轉譯器及通用串列匯流排傳輸轉譯方法
KR101141421B1 (ko) 2010-07-12 2012-05-04 고려대학교 산학협력단 모바일 디지털 디스플레이 인터페이스 장치
JP6790435B2 (ja) * 2016-04-20 2020-11-25 ソニー株式会社 受信装置、送信装置、および通信システム、ならびに、信号受信方法、信号送信方法、および通信方法
CN108847920B (zh) * 2018-06-25 2021-06-29 北京零态空间数码科技有限公司 一种通信方法以及系统

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5490247A (en) * 1993-11-24 1996-02-06 Intel Corporation Video subsystem for computer-based conferencing system
WO1996042158A1 (fr) * 1995-06-13 1996-12-27 Telefonaktiebolaget Lm Ericsson Synchronisation de la transmission de donnees via une liaison bidirectionnelle
WO1998002988A2 (fr) * 1996-07-12 1998-01-22 Philips Electronics N.V. Procede et appareil de cadrage de paquets
US5751951A (en) * 1995-10-30 1998-05-12 Mitsubishi Electric Information Technology Center America, Inc. Network interface

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6101601A (en) * 1998-04-20 2000-08-08 International Business Machines Corporation Method and apparatus for hibernation within a distributed data processing system
KR20000039224A (ko) * 1998-12-11 2000-07-05 윤종용 고속 데이터전송을 위한 통신 상호접속 네트워크

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5490247A (en) * 1993-11-24 1996-02-06 Intel Corporation Video subsystem for computer-based conferencing system
WO1996042158A1 (fr) * 1995-06-13 1996-12-27 Telefonaktiebolaget Lm Ericsson Synchronisation de la transmission de donnees via une liaison bidirectionnelle
US5751951A (en) * 1995-10-30 1998-05-12 Mitsubishi Electric Information Technology Center America, Inc. Network interface
WO1998002988A2 (fr) * 1996-07-12 1998-01-22 Philips Electronics N.V. Procede et appareil de cadrage de paquets

Cited By (112)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8694663B2 (en) 2001-09-06 2014-04-08 Qualcomm Incorporated System for transferring digital data at a high rate between a host and a client over a communication path for presentation to a user
US7783070B2 (en) 2003-04-25 2010-08-24 Apple Inc. Cable adapter for a media player system
US7751853B2 (en) 2003-04-25 2010-07-06 Apple Inc. Female receptacle data pin connector
US8165634B2 (en) 2003-04-25 2012-04-24 Apple Inc. Female receptacle connector
US8190205B2 (en) 2003-04-25 2012-05-29 Apple Inc. Male plug connector
US8271038B2 (en) 2003-04-25 2012-09-18 Apple Inc. Wireless adapter for media player system
US8078224B2 (en) 2003-04-25 2011-12-13 Apple Inc. Male plug connector
US8467829B2 (en) 2003-04-25 2013-06-18 Apple Inc. Wireless adapter for media player system
US8050714B2 (en) 2003-04-25 2011-11-01 Apple Inc. Docking station for media player system
CN101938493A (zh) * 2003-06-02 2011-01-05 高通股份有限公司 生成并实施一用于更高数据率的讯号协议和接口
JP2011176810A (ja) * 2003-06-02 2011-09-08 Qualcomm Inc より高いデータレートのための信号プロトコルおよびインターフェイスの生成および実行
EP2363989A1 (fr) * 2003-08-13 2011-09-07 Qualcomm Incorporated Interface pour signaux haut débit
JP2015216659A (ja) * 2003-08-13 2015-12-03 クゥアルコム・インコーポレイテッドＱｕａｌｃｏｍｍ Ｉｎｃｏｒｐｏｒａｔｅｄ より高速なデータレート用の信号インタフェース
JP2011066904A (ja) * 2003-08-13 2011-03-31 Qualcomm Inc さらに高速なデータレート用の信号インタフェース
TWI455539B (zh) * 2003-08-13 2014-10-01 Qualcomm Inc 透過在一ｍｄｄｉ通訊系統中之一訊框同步訊包為同時間等時的資料流提供多媒體同步化之方法、裝置、與系統及其非過渡電腦可執行媒體
JP2013158026A (ja) * 2003-08-13 2013-08-15 Qualcomm Inc さらに高速なデータレート用の信号インタフェース
JP2014195288A (ja) * 2003-08-13 2014-10-09 Qualcomm Incorporated さらに高速なデータレート用の信号インタフェース
JP2012217189A (ja) * 2003-08-13 2012-11-08 Qualcomm Inc さらに高速なデータレート用の信号インタフェース
WO2005018191A3 (fr) * 2003-08-13 2008-01-10 Qualcomm Inc Interface de signal pour debits binaires superieurs
WO2005018191A2 (fr) * 2003-08-13 2005-02-24 Qualcomm, Incorporated Interface de signal pour debits binaires superieurs
US8635358B2 (en) 2003-09-10 2014-01-21 Qualcomm Incorporated High data rate interface
JP2011066935A (ja) * 2003-09-10 2011-03-31 Qualcomm Inc 高速データレートインタフェース
JP2012227933A (ja) * 2003-10-15 2012-11-15 Qualcomm Inc 高速データレートインタフェース
JP2010200332A (ja) * 2003-10-15 2010-09-09 Qualcomm Inc 高速データレートインタフェース
JP2012191650A (ja) * 2003-10-15 2012-10-04 Qualcomm Inc 高速データレートインタフェース
JP2010011480A (ja) * 2003-10-15 2010-01-14 Qualcomm Inc 高速データレートインタフェース
JP2007509533A (ja) * 2003-10-15 2007-04-12 クゥアルコム・インコーポレイテッド 高速データレートインタフェース
JP2013034221A (ja) * 2003-11-12 2013-02-14 Qualcomm Inc 改善されたリンク制御を有する高速データレートインタフェース
JP2007513591A (ja) * 2003-12-08 2007-05-24 クゥアルコム・インコーポレイテッド 改良されたリンク同期を備えた高速データレートインタフェース
US8730913B2 (en) 2004-03-10 2014-05-20 Qualcomm Incorporated High data rate interface apparatus and method
JP2011023009A (ja) * 2004-03-10 2011-02-03 Qualcomm Inc 高データレートインタフェース装置及び方法
JP2013258691A (ja) * 2004-03-10 2013-12-26 Qualcomm Inc 高データレートインタフェース装置及び方法
US8625625B2 (en) 2004-03-10 2014-01-07 Qualcomm Incorporated High data rate interface apparatus and method
JP2007528681A (ja) * 2004-03-10 2007-10-11 クゥアルコム・インコーポレイテッド 高データレートインタフェース装置及び方法
JP2011019255A (ja) * 2004-03-24 2011-01-27 Qualcomm Inc 高データレートインターフェース装置および方法
JP2014053920A (ja) * 2004-03-24 2014-03-20 Qualcomm Incorporated 高データレートインターフェース装置および方法
JP2007531120A (ja) * 2004-03-24 2007-11-01 クゥアルコム・インコーポレイテッド 高データレートインターフェース装置および方法
US8386680B2 (en) 2004-04-27 2013-02-26 Apple Inc. Communication between an accessory and a media player with multiple protocol versions and extended interface lingo
US8271705B2 (en) 2004-04-27 2012-09-18 Apple Inc. Dual key electronic connector
US8402187B2 (en) 2004-04-27 2013-03-19 Apple Inc. Method and system for transferring button status information between a media player and an accessory
US7757026B2 (en) 2004-04-27 2010-07-13 Apple Inc. Techniques for transferring status information between an accessory and a multi-communication device
US7877532B2 (en) 2004-04-27 2011-01-25 Apple Inc. Communication between an accessory and a media player with multiple lingoes and lingo version information
US8078776B2 (en) 2004-04-27 2011-12-13 Apple Inc. Electronic device having a dual key connector
US8082376B2 (en) 2004-04-27 2011-12-20 Apple Inc. Communication between an accessory and a media player with multiple protocol versions
US7779185B2 (en) 2004-04-27 2010-08-17 Apple Inc. Communication between a media player and an accessory using a protocol with multiple lingoes
US8099536B2 (en) 2004-04-27 2012-01-17 Apple Inc. Communication between an accessory and a media player with general and accessory lingoes
JP2010226725A (ja) * 2004-06-04 2010-10-07 Qualcomm Inc 高速データレートインタフェース装置及び方法
JP2008502221A (ja) * 2004-06-04 2008-01-24 クゥアルコム・インコーポレイテッド 高速データレートインタフェース装置及び方法
WO2005122509A1 (fr) * 2004-06-04 2005-12-22 Qualcomm Incorporated Appareil et procede a interface a debit binaire eleve
KR100882166B1 (ko) * 2004-06-04 2009-02-06 퀄컴 인코포레이티드 고 데이터 레이트 인터페이스 장치 및 방법
EP1978693A3 (fr) * 2004-06-04 2010-05-26 QUALCOMM Incorporated Appareil d'interface à débit de données élevé et procédé correspondant
US8630305B2 (en) 2004-06-04 2014-01-14 Qualcomm Incorporated High data rate interface apparatus and method
AU2005253592B2 (en) * 2004-06-04 2009-02-05 Qualcomm Incorporated High data rate interface apparatus and method
US8692838B2 (en) 2004-11-24 2014-04-08 Qualcomm Incorporated Methods and systems for updating a buffer
JP2011041290A (ja) * 2004-11-24 2011-02-24 Qualcomm Inc バッファを更新するための方法及びシステム
US9223958B2 (en) 2005-01-07 2015-12-29 Apple Inc. Accessory authentication for electronic devices
US8161567B2 (en) 2005-01-07 2012-04-17 Apple Inc. Accessory authentication for electronic devices
US10049206B2 (en) 2005-01-07 2018-08-14 Apple Inc. Accessory authentication for electronic devices
US7823214B2 (en) 2005-01-07 2010-10-26 Apple Inc. Accessory authentication for electronic devices
US9754099B2 (en) 2005-01-07 2017-09-05 Apple Inc. Accessory authentication for electronic devices
US8253683B2 (en) 2005-05-30 2012-08-28 Renesas Electronics Corporation Liquid crystal display drive and control device, mobile terminal system, and data processing system
US8692839B2 (en) 2005-11-23 2014-04-08 Qualcomm Incorporated Methods and systems for updating a buffer
US8086332B2 (en) 2006-02-27 2011-12-27 Apple Inc. Media delivery system with improved interaction
US9198084B2 (en) 2006-05-26 2015-11-24 Qualcomm Incorporated Wireless architecture for a traditional wire-based protocol
US8590036B2 (en) 2006-06-27 2013-11-19 Apple Inc. Method and system for authenticating an accessory
US8370555B2 (en) 2006-06-27 2013-02-05 Apple Inc. Method and system for allowing a media player to determine if it supports the capabilities of an accessory
US9160541B2 (en) 2006-06-27 2015-10-13 Apple Inc. Method and system for authenticating an accessory
US8112567B2 (en) 2006-09-11 2012-02-07 Apple, Inc. Method and system for controlling power provided to an accessory
US8667144B2 (en) 2007-07-25 2014-03-04 Qualcomm Incorporated Wireless architecture for traditional wire based protocol
US8275924B2 (en) 2007-09-04 2012-09-25 Apple Inc. Smart dock for chaining accessories
US9467735B2 (en) 2007-09-04 2016-10-11 Apple Inc. Synchronizing digital audio and analog video from a portable media device
US8047966B2 (en) 2008-02-29 2011-11-01 Apple Inc. Interfacing portable media devices and sports equipment
US20120028761A1 (en) * 2008-02-29 2012-02-02 Apple Inc. Interfacing portable media devices and sports equipment
US8317658B2 (en) * 2008-02-29 2012-11-27 Apple Inc. Interfacing portable media devices and sports equipment
US8811294B2 (en) 2008-04-04 2014-08-19 Qualcomm Incorporated Apparatus and methods for establishing client-host associations within a wireless network
US8238811B2 (en) 2008-09-08 2012-08-07 Apple Inc. Cross-transport authentication
US8509691B2 (en) 2008-09-08 2013-08-13 Apple Inc. Accessory device authentication
US8208853B2 (en) 2008-09-08 2012-06-26 Apple Inc. Accessory device authentication
US8634761B2 (en) 2008-09-08 2014-01-21 Apple Inc. Cross-transport authentication
US9398089B2 (en) 2008-12-11 2016-07-19 Qualcomm Incorporated Dynamic resource sharing among multiple wireless devices
US8102849B2 (en) 2009-02-12 2012-01-24 Qualcomm, Incorporated Association procedure to enable multiple multicast streams
US9264248B2 (en) 2009-07-02 2016-02-16 Qualcomm Incorporated System and method for avoiding and resolving conflicts in a wireless mobile display digital interface multicast environment
US9582238B2 (en) 2009-12-14 2017-02-28 Qualcomm Incorporated Decomposed multi-stream (DMS) techniques for video display systems
WO2011097303A1 (fr) * 2010-02-08 2011-08-11 Apple Inc. Système de télécommunications numériques comportant des canaux de trafic à bande passante adaptable
CN102812653A (zh) * 2010-02-08 2012-12-05 苹果公司 具有可变带宽业务信道的数字通信系统
US8130790B2 (en) 2010-02-08 2012-03-06 Apple Inc. Digital communications system with variable-bandwidth traffic channels
US8457157B2 (en) 2010-02-08 2013-06-04 Apple Inc. Digital communications system with variable-bandwidth traffic channels
JP2013539636A (ja) * 2010-08-26 2013-10-24 サムスン エレクトロニクス カンパニー リミテッド 非圧縮動画データパケットを生成する方法及びその装置
US9332321B2 (en) 2010-08-26 2016-05-03 Samsung Electronics Co., Ltd. Method and apparatus for generating uncompressed video data packet
US10382494B2 (en) 2011-01-21 2019-08-13 Qualcomm Incorporated User input back channel for wireless displays
US9787725B2 (en) 2011-01-21 2017-10-10 Qualcomm Incorporated User input back channel for wireless displays
US10911498B2 (en) 2011-01-21 2021-02-02 Qualcomm Incorporated User input back channel for wireless displays
US10135900B2 (en) 2011-01-21 2018-11-20 Qualcomm Incorporated User input back channel for wireless displays
US9413803B2 (en) 2011-01-21 2016-08-09 Qualcomm Incorporated User input back channel for wireless displays
US9582239B2 (en) 2011-01-21 2017-02-28 Qualcomm Incorporated User input back channel for wireless displays
US8964783B2 (en) 2011-01-21 2015-02-24 Qualcomm Incorporated User input back channel for wireless displays
US9065876B2 (en) 2011-01-21 2015-06-23 Qualcomm Incorporated User input back channel from a wireless sink device to a wireless source device for multi-touch gesture wireless displays
US10108386B2 (en) 2011-02-04 2018-10-23 Qualcomm Incorporated Content provisioning for wireless back channel
US9503771B2 (en) 2011-02-04 2016-11-22 Qualcomm Incorporated Low latency wireless display for graphics
US9723359B2 (en) 2011-02-04 2017-08-01 Qualcomm Incorporated Low latency wireless display for graphics
US8674957B2 (en) 2011-02-04 2014-03-18 Qualcomm Incorporated User input device for wireless back channel
US9525998B2 (en) 2012-01-06 2016-12-20 Qualcomm Incorporated Wireless display with multiscreen service
JP2016511965A (ja) * 2013-01-25 2016-04-21 クゥアルコム・インコーポレイテッドＱｕａｌｃｏｍｍ Ｉｎｃｏｒｐｏｒａｔｅｄ ワイヤレスディスプレイデバイスのためのユーザ入力制御のためのコネクションレストランスポート
US9813070B2 (en) 2015-02-16 2017-11-07 Postech Academy—Industry Foundation Display apparatus and driving method for the same
CN111371542A (zh) * 2015-04-13 2020-07-03 高通股份有限公司 用于基于脉冲的多线链路的时钟和数据恢复
CN111371542B (zh) * 2015-04-13 2022-11-18 高通股份有限公司 用于基于脉冲的多线链路的时钟和数据恢复的方法和装置
WO2020150187A1 (fr) * 2019-01-14 2020-07-23 Texas Instruments Incorporated Identification de point d'échantillonnage à des fins de capture de données asynchrone basse fréquence
US11343067B2 (en) 2019-01-14 2022-05-24 Texas Instruments Incorporated Sampling point identification for low frequency asynchronous data capture
US10862666B2 (en) 2019-01-14 2020-12-08 Texas Instruments Incorporated Sampling point identification for low frequency asynchronous data capture
TWI748447B (zh) 2020-05-12 2021-12-01 瑞昱半導體股份有限公司 影音介面之控制訊號傳輸電路及控制訊號接收電路
US11490141B2 (en) 2020-05-12 2022-11-01 Realtek Semiconductor Corporation Control signal transmission circuit and control signal receiving circuit for audio/video interface
US11800054B2 (en) 2020-06-19 2023-10-24 Realtek Semiconductor Corporation Multimedia audio/video system

Also Published As

Publication number Publication date
IL156385A0 (en) 2004-01-04
RU2003121400A (ru) 2005-02-10
CA2725878A1 (fr) 2002-06-20
CN101030952B (zh) 2016-03-09
EP1342352A2 (fr) 2003-09-10
AU2735902A (en) 2002-06-24
AU2002227359B2 (en) 2006-12-07
IL196247A (en) 2012-07-31
KR100978497B1 (ko) 2010-08-30
CA2725844C (fr) 2015-03-31
JP2004531916A (ja) 2004-10-14
MXPA03005310A (es) 2004-03-26
TW577208B (en) 2004-02-21
CN1543734A (zh) 2004-11-03
CA2725878C (fr) 2012-05-29
CA2431492C (fr) 2011-09-27
CA2726149A1 (fr) 2002-06-20
CA2431492A1 (fr) 2002-06-20
KR100944843B1 (ko) 2010-03-04
WO2002049314A3 (fr) 2003-05-01
BR0116157A (pt) 2004-07-06
CN100473058C (zh) 2009-03-25
KR20030061001A (ko) 2003-07-16
KR20090087513A (ko) 2009-08-17
CN101030952A (zh) 2007-09-05
CA2726149C (fr) 2013-06-25
CA2725844A1 (fr) 2002-06-20
HK1067477A1 (en) 2005-04-08
BRPI0116157B1 (pt) 2016-07-19

Similar Documents

Publication Publication Date Title
CA2431492C (fr) Etablissement et mise en oeuvre d'un protocole de communication pour le transfert de signaux a debit binaire eleve
US8745251B2 (en) Power reduction system for an apparatus for high data rate signal transfer using a communication protocol
US8694663B2 (en) System for transferring digital data at a high rate between a host and a client over a communication path for presentation to a user
CA2459941C (fr) Creation et mise en oeuvre d'un protocole de communication et d'une interface de transfert de signaux a haut debit
US8700744B2 (en) Generating and implementing a signal protocol and interface for higher data rates
US8635358B2 (en) High data rate interface
US8687658B2 (en) High data rate interface with improved link synchronization
US8756294B2 (en) High data rate interface
AU2002227359A1 (en) Generating and implementing a communication protocol and interface for high data rate signal transfer
WO2005018191A2 (fr) Interface de signal pour debits binaires superieurs
CA2542649A1 (fr) Interface a haut debit binaire
KR20040036945A (ko) 하이 데이터 레이트 신호 전송을 위한 통신 프로토콜 및인터페이스의 생성 및 구현
AU2009200172A1 (en) Generating and implementing a communication protocol and interface for high data rate signal transfer
AU2002324904A1 (en) Generating and implementing a communication protocol and interface for high data rate signal transfer
CA2818773A1 (fr) Systeme de transfert de donnees numeriques a un debit eleve entre un hote et un client par une voie de communication afin de les presenter a un utilisateur

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PH PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
WWE Wipo information: entry into national phase

Ref document number: 156385

Country of ref document: IL

WWE Wipo information: entry into national phase

Ref document number: 2431492

Country of ref document: CA

WWE Wipo information: entry into national phase

Ref document number: 200304611

Country of ref document: ZA

WWE Wipo information: entry into national phase

Ref document number: 938/CHENP/2003

Country of ref document: IN

Ref document number: PA/a/2003/005310

Country of ref document: MX

WWE Wipo information: entry into national phase

Ref document number: 1020037008002

Country of ref document: KR

WWE Wipo information: entry into national phase

Ref document number: 2002550691

Country of ref document: JP

WWE Wipo information: entry into national phase

Ref document number: 2002227359

Country of ref document: AU

WWE Wipo information: entry into national phase

Ref document number: 2001996216

Country of ref document: EP

ENP Entry into the national phase

Ref country code: RU

Ref document number: RU A

WWP Wipo information: published in national office

Ref document number: 1020037008002

Country of ref document: KR

WWE Wipo information: entry into national phase

Ref document number: 018225837

Country of ref document: CN

WWP Wipo information: published in national office

Ref document number: 2001996216

Country of ref document: EP

REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

WWW Wipo information: withdrawn in national office

Ref document number: 2001996216

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 196246

Country of ref document: IL

Ref document number: 196245

Country of ref document: IL

Ref document number: 196247

Country of ref document: IL

Ref document number: 196244

Country of ref document: IL