Generating and implementing a communication protocol and interface for high data rate signal transfer

Generate and implement communication protocol and interface for high data rate signal transmission

Background of the invention

I. Field of Inventions

The present invention relates to a digital signal protocol and a process for high-speed signal transmission between a host communication device and a user-side video/audio presentation device. More specifically, the present invention relates to a technology that utilizes a low-power, high-data-rate transmission mechanism to transmit multimedia and other types of digital signals to a micro display unit or other presentation devices.

II. Related skills

Computers, electronic game-related products, and various imaging technologies (such as DVDs and high-definition VCRs) have made significant progress in the past few years, providing users with such devices with increasing resolution. Still life, images, on-demand images, and graphic images of, which also include several types of text. This advancement can handle higher-resolution electronic viewing devices, such as high-definition video displays, HDTV monitors, or professional video projection devices. Combining this type of visual image with high-definition or high-quality audio data can be used to create more realistic and more content for users when, for example, CD-style audio reproduction, DVD, and other devices with related audio signal output are used. Richer, or more realistic multimedia. In addition, highly mobile, high-quality sound systems and music delivery mechanisms, such as MP3 players, have developed sound effects that are only presented to users.

In a general image presentation mechanism, image data is usually transmitted at a rate of one to ten thousand bits per second at a rate that can be called a slow or medium rate according to the current technology. The data is then stored temporarily or in a memory device with a longer retention period, in order to delay (later) playback in the desired viewing device. E.g, The image can be transmitted via the Internet, using a program resident in a computer with a modem or an Internet-connected device, to receive or transmit digital data representing the image. A similar transmission process can be generated by a wireless device, such as a portable computer equipped with a wireless modem, or a wireless personal data assistant (PDA), or a wireless phone.

Once received, the data is stored in memory components, circuits or devices, such as RAM or flash memory, including external storage devices, for playback. Depending on the amount of data and image resolution, playback may start soon or after a long delay. That is to say, in some examples, when a very small or low-resolution image does not require a large amount of data, the presentation of the image allows a certain degree of real-time playback, or through a certain type of buffering method, so that after a slight delay, Some data can be presented at the same time and other data can be sent at the same time. Assuming that there is no interruption during the transmission of the link, once the presentation starts, the transmission is reasonably transparent to the user of the viewing device.

The data used to create still images and moving videos are usually compressed using some well-known technology, such as "Joint Photographic Experts Group" (JPEG) and "Motion Picture Experts Group" (Motion Picture Experts Group). ;MPEG), or the technology prescribed by other well-known standard organizations or companies in the media, computers, and communications industries to accelerate the transmission of data on communications links. Using a small amount of bits to transmit a given amount of information will speed up the transmission of images or data.

Once the data is sent to a "local" device, such as a computer or other device, the generated information is decompressed (or played with a specific decoder), and based on the The display resolution and control components should be available, and appropriate display methods should be prepared. For example, a typical computer image resolution is based on the screen resolution X by Y pixels, and usually has specifications ranging from 480×640, 600×800 to 1024×1024, and other different resolutions are provided as needed .

Image display is also affected by the content of the image and the ability of known image controllers to manipulate the image, including certain predefined color levels or color densities (bits per pixel used to produce colors) and saturation, as well as other overhead used Overhead bit. For example, a typical computer monitor expects that the number of bits for each pixel to present different colors (shades and hue) is between 8 and 32 or more, and there are other values.

From the above values, we can understand that the typical resolution and density of the known screen image, from the lowest to the highest, require a data transfer rate from 2.45 megabits (Mb) to about 33.55Mb, respectively. To view images or animations at a rate of 30 frames per second, the amount of data required is approximately 73.7 to 1,006 megabits of data per second (Mbps), or approximately 9.21 to 125.75 megabytes per second (MBps). In addition, sometimes it is necessary to present sound effects with images, such as multimedia presentations, or individual high-resolution sound effects, such as CD-quality music. Other signals such as interactive commands, controls, or signals can also be used. These options will add more data to be sent. In any case, when anyone wants to send high-quality or high-resolution image data and high-quality audio information or data signals to users to create a rich experience, the presentation component and the source or host device that provide such data Between, there must be a high-speed data transmission link.

About 115 kilobytes (KBps) or 920 kilobytes (Kbps) of data per second The speed can be processed by the serial interface of the modem. Other interfaces, like the USB serial interface, can reach a data transfer rate of 12MBps, and like the exclusive high-speed transmission using the electrical and electronic engineering (IEEE) 1394 standard configuration, the rate can reach 50 to 100MBps. Unfortunately, these rates are not as high as the desired high data rates discussed above. The rates discussed above are hoped to be used in future wireless data devices and services to provide high-resolution, rich content, and provide output signals to drive data rates. Portable video display or audio device. In addition, these interfaces require the use of a large number of hosts or systems and client software to operate. Their software protocol stack also creates an unnecessary large number of overhead bits, especially when considering wireless mobile devices or phone applications. Even some interfaces use bulky cables, but they are too bulky and unpopular for aesthetically oriented mobile applications, and complicated connectors will increase costs or consume too much power.

Other well-known interfaces include analog video graphics array (VGA), digital video interactive (DVI), or gigabit video interface (GVIF). The first two are parallel interfaces, processing data at a higher transmission rate, and also use bulky cables and consume a lot of power, about a few watts. These features are not suitable for portable consumer electronic products. The third interface consumes too much power and requires expensive or bulky connectors.

Although some of the above-mentioned interfaces have very high-speed data systems/protocols or transmission mechanisms when used for data transmission in fixed computer equipment, they still have other shortcomings. In order to achieve the desired data transmission rate, an extremely large amount of power and/or high current operation is also required. This reduces the usefulness of this type of technology as a highly mobile consumer product.

Generally speaking, in order to achieve this data transmission rate, you can use optical fiber connections and transmission devices, but such alternative devices require a number of additional converters and components, which increase the complexity and cost of use, and are not commercialized. The desired result of consumer products. In addition to the expensive characteristics of the optical system, its power requirements and complexity are not suitable for lightweight, low-power portable applications.

Currently, there is no technology available in the market for portable or mobile application devices that can provide a high-quality presentation experience based on audio, video, or multimedia, and can be used by users with high mobility. In other words, when using portable computers, wireless phones, PDAs, or other high-mobile communication devices or devices, none of the current audio-visual presentation systems or devices can provide output with the desired high-quality level. Usually, the quality seen is the result of not being able to deliver high-quality presentation data at the required high data rate. Therefore, a new transmission mechanism is needed to increase the data flow between the host device that provides data and the client display or component that provides output for the user.

Summary of the invention

The above-mentioned and other shortcomings exist in the techniques proposed by the specific embodiments of the present invention, in which new protocols and data transmission mechanisms have been developed for high-speed data transmission between the host device and the receiving client.

The advantages of the specific embodiments of the present invention are that the technology provided for data transmission has low complexity, low cost, high reliability, is suitable for the environment in which it is used, and is very durable and flexible at the same time.

The specific embodiment of the present invention is a mobile digital data interface (MDDI) for high-speed transmission between a host device and a server device on a communication path. Send digital data, and use multiple or a group of interconnected packet structures to form a communication protocol to transfer a set of pre-selected digital control and presentation data between the host and the client device. The signal communication protocol connection or connection layer is used by the host or client to connect to the physical layer of the controller. At least one link controller in the host device is coupled to the client device through a communication path or link, and is configured to generate, transmit, and receive packets forming a communication protocol, and make the digital presentation data form one or more types of data packets . This interface provides two-way transmission of information between the host and the client.

In another aspect of the specific embodiments of the present invention, at least one client connection controller or client receiver is located in the client and is coupled to the host device through a communication path or connection. The client connection controller is also configured to generate, transmit, and receive packets forming a communication protocol, and make the digital presentation data form one or more types of data packets. Generally, the host or link controller uses a state machine to process data packets used in command or certain signal preparation or query processing, but a slow general-purpose processor can be used to manipulate the data used in the communication protocol and some Less complicated packet. The host controller includes one or more differential line drivers; the client receiver also includes one or more differential line receivers coupled to the communication path.

The packets are gathered in a media frame transmitted between the host and the client. The media frame has a predetermined fixed length and a predetermined number of packets, and the packets have different variable lengths. Each packet contains a packet length field, one or more packet data fields, and a cyclic redundancy check field. A sub-frame header packet is transmitted from the host link controller, or is located at the beginning of the transmission of other packets. One or more video stream type packets and audio effects stream The type packet is used by the communication protocol to transmit the image type data and the audio type data from the host to the client through the forward link, so as to be presented to the user of the client device. One or more reverse link encapsulation packets are used by the communication protocol to transmit data from the client device to the host link controller.

The padding packet is generated by the host link controller to occupy the forward link transmission period when there is no data. A plurality of other packets are used by the communication protocol to transmit image information. Such packets include color correspondence, bit block transmission, dot pattern area filling, dot pattern filling, and transparent color-enabled packets. The user-defined stream packet is used by the communication protocol to transmit interface-user-defined data. The keyboard data and pointing device data type packets are used by the communication protocol to send data to and from the user input device related to the client device. The connection closed packet is used by the communication protocol to terminate the data transmission in any direction on the communication path.

The communication path generally includes or uses a cable with a string of four or more conductors and a shield. In some embodiments, the link controller includes a USB data interface, and the cable uses a USB type interface and other conductors. In addition, printed circuits or elastic conductors can be used as needed.

The host link controller requests the display function information of the client device in order to determine what type of data and data rate the client can use through the interface. The client connection controller uses at least one display function type packet to transmit the display or presentation function to the host connection controller. Multiple transmission modes are used for communication protocols. Each mode allows a different maximum amount of data bits to be transmitted in parallel within a known time period, and each mode can be selected by negotiation between the host and the client connection controller. These transfer modes can be used in the data It is dynamically adjusted during transmission, and on the reverse connection, there is no need to use the same mode as the forward connection.

In another aspect of some specific embodiments of the present invention, the host device includes a wireless communication device, such as a wireless phone, a wireless PDA, or a portable computer equipped with a wireless modem. A typical client device includes a portable image display, such as a micro display device, and/or a portable audio presentation system. Furthermore, the host can use a storage device or component to store presentation or multimedia data sent out to display to the user of the client device.

Other features and advantages of the present invention, as well as the structure and operation of different specific embodiments of the present invention, will be described in detail below with reference to the accompanying drawings. In the drawings, the same reference numbers generally indicate the same, similar function, and/or similar components and processing steps, and the first appearance of the element in the drawings is added by the leftmost number in the reference number. instruct.

Figure 1a illustrates the basic environment in which the present invention can operate, including the use of a microdisplay device that can be used in conjunction with a portable computer.

Fig. 1b illustrates the basic environment in which the present invention can operate, including the use of a micro-display device and a sound effect rendering element used in conjunction with a wireless transceiver.

Figure 2 illustrates the overall concept of the mobile digital data interface based on the interactive connection between the host and the client.

FIG. 3 illustrates the packet structure used to realize the transmission of data from the client device to the host device.

Figure 4 illustrates the use of the MDDI link controller, as well as for Type I and Type U interfaces, which are transmitted between the host and the client through the physical data link conductor The signal type.

Figure 5 illustrates the use of the MDDI link controller and the types of signals that are transmitted between the host and the client through the physical data link conductors for Type II, III, and IV interfaces.

Figure 6 illustrates the structure of the frame and sub-frames used to implement the interface protocol.

Figure 7 illustrates the general structure of the packet used to implement the interface protocol.

Figure 8 illustrates the format of the subframe header packet.

Figure 9 illustrates the format and content of the padding packet.

Figure 10 illustrates the format of the video stream packet.

Figure 11 illustrates the format and content of the image data format descriptor of Figure 10;

Figure 12 illustrates the use of data encapsulation and de-encapsulation formats.

Figure 13 illustrates the format of the audio stream packet.

Figure 14 illustrates the byte-arrangement of data and the use of the encapsulated PCM format.

Figure 15 illustrates the format of a user-defined stream packet.

Figure 16 illustrates the format of the color corresponding packet.

Figure 17 illustrates the format of a reverse link encapsulation packet.

Figure 18 illustrates the format of the display function packet.

Figure 19 illustrates the format of the keyboard data packet.

Figure 20 illustrates the format of the pointer device data packet.

Figure 21 illustrates the format of a link close packet.

Figure 22 illustrates the format of the display request and status packet.

Figure 23 illustrates the format of a bit block transmission packet.

Figure 24 illustrates the format of the bitmap area filled packet.

Figure 25 illustrates the format of a dot matrix pattern filled packet.

Figure 26 illustrates the format of a communication link data channel packet.

Figure 27 illustrates the format of an interface-type handover request packet.

Figure 28 illustrates the format of the interface type confirmation packet.

Figure 29 illustrates the format of an execution-type handover packet.

Figure 30 illustrates the format of the forward audio channel enable packet.

Figure 31 illustrates the format of the reverse audio sample rate packet.

Figure 32 illustrates the format of a digital content protection overhead packet.

Figure 33 illustrates the format of a transparent color enable packet.

Figure 34 illustrates the format of a round trip delay measurement packet.

Figure 35 illustrates the timing of events during the round-trip delay measurement packet.

Figure 36 illustrates a sample implementation of the CRC generator and checker that can be used in the present invention.

Figure 37a illustrates the timing of the CRC signal of the device of Figure 36 when transmitting data packets.

Figure 37b illustrates the timing of the CRC signal of the device of Figure 36 when receiving a data packet.

Figure 38 illustrates the processing steps for a typical service request when there is no contention.

FIG. 39 illustrates the processing steps of asserting a typical service request after the start of the link restart sequence to process the link start.

Figure 40 illustrates how to use DATA-STB encryption to transmit data sequences.

Figure 41 illustrates the circuit that generates the DATA and STB signals of the input data on the host and then restores the data on the user side.

Figure 42 illustrates the driver and termination circuit used to implement a specific embodiment of the present invention. Hinder.

Figure 43 illustrates the client's use to protect services from the host, as well as the steps and signal levels used by the host to provide such services.

Fig. 44 illustrates the relative interval when switching between Data0, other data lines (DataX), and strobe lines (Stb).

Figure 45 illustrates the delay in response when the host disables the host driver after transmitting the packet.

Figure 46 illustrates the response delay that occurs when the host activates the host driver to transmit packets.

Figure 47 illustrates the relationship between the timing of the transmitted data and the leading and trailing edges of the strobe pulse in the host receiver input.

Figure 48 illustrates the transfer characteristics developed by the reverse data timing and the corresponding user-side output delay.

FIG. 49 illustrates a high-level signal processing step diagram. Through this step, the present invention can use a state machine to achieve synchronization.

Figure 50 illustrates the number of delays that a system implementing MDDI typically encounters when processing signals on the forward and reverse paths.

Figure 51 illustrates the round-trip delay measurement of the edge.

Figure 52 illustrates the change in the backlink data rate.

Figure 53 graphically presents the values of the reverse rate divisor and the forward link data rate.

Figures 54a and 54b illustrate the steps taken when operating the interface.

<b>Detailed description of specific embodiments</b>

<b>I. Summary</b>

The general purpose of the present invention is to provide a mobile display digital interface (MDDI), As discussed below, create or provide a cost-effective, low-power-consumption transmission mechanism that uses "serial" data links or channels to allow high-speed or very high-speed data to be transmitted on the short-distance communication link between the host device and the display device . This mechanism provides its own realization of miniature connectors and thin flexible cables, both of which are particularly suitable for connecting display elements or devices, such as wearable microdisplays (goggles or projectors), as well as portable computers, wireless telecommunication devices, Or entertainment device.

The present invention can be used in various situations to communicate or transmit large amounts of data. It is generally used in audio, video, or multimedia applications, from the host or source device that generates or stores such data, to the high-speed client display or presentation device. . Typical applications, discussed below, are data transmission, from portable computers or cordless phones or modems to image display devices, such as small video screens or wearable microdisplay devices, such as protective devices that include small projection lenses and screens. Eyepiece or helmet.

The characteristics or attributes of MDDI have nothing to do with a particular display technology. This is a highly flexible mechanism for high-speed transmission of data. It has nothing to do with the internal structure of the data, the functional view of the data or the commands it implements. This allows the timing of the transmitted data packet to be adjusted to the characteristics of a specific display device or the unique display of certain devices, or to meet the conditions of the combination of audio and video in certain AV systems. As long as the selected protocol is met, the interface is only a display element or an unknown client device. In addition, the aggregated serial link data or data rate will vary according to the level of magnitude, allowing the communication system or host device designer to optimize cost, power requirements, client equipment complexity, and Display device update rate.

The data interface is mainly used to transmit large amounts of high-speed data over "wired" signal links or small cables. However, some applications can also use wireless links, including link-based optical devices, provided it is configured to use the same packet and data structure developed for the interface protocol, and can maintain the desired transmission with low power consumption Or complexity to maintain practicality.

<b>II. Environment</b>

A typical application can be seen in Figures 1a and 1b, where a portable or laptop computer 100 and a wireless phone or personal digital assistant (PDA) device 102 are shown, and the display devices 104 and 106, and the sound reproduction system 108 and 110 to deliver information. The wireless device can receive data or pre-store a certain amount of multimedia data in a memory element or device for later presentation or viewing and/or for users of the wireless device to listen. Since most of the time the wireless device is used for voice and simple text communication, it has a relatively small display screen and a simple sound system (speaker) for transmitting information to the user of the device 102.

The computer 100 has a large screen, but the external audio system is not enough, and it still lacks other multimedia presentation devices, such as a high-definition TV or an animation screen. The computer 100 can be used for illustrations and other types of processing procedures, and interactive video games and consumer electronic devices can also be used in the present invention. The computer 100 can be used, but not limited to, wireless modems and other built-in wireless communication devices, or connected to such devices using cables and wireless connections as needed.

This makes the presentation of more complex or "rich" information less useful or less interesting. Therefore, the industry is developing other mechanisms and devices to It will present information to users and provide the most basic fun or real experience.

As previously discussed, certain types of display devices have been developed or are currently developed to present information to the user of the device 100. For example, more than one company has developed several sets of wearable goggles, which can project images in front of the eyes of the device user to present a visual display. When worn correctly, such devices can effectively "project" visual images so that the user's eyes can see. Such devices are much larger than the components that provide visual output. In other words, a very small projection device allows the user's eyes to "see" an image on a device much larger than a normal LCD screen or similar device. The use of a larger visual screen image has a higher resolution image than a limited LCD screen. Other display devices also include, but are not limited to, small LCD screens, or different flat display elements, transmissive lenses, and display drivers for projecting images on the surface.

There are other components connected to or related to the use of the wireless device 102 and the computer 100 to present the output to other users or other devices, transmit the signal to other places or store it. For example, data can be stored in flash memory in optical form, for example, using writable CD media or magnetic media, such as tape recorders and similar devices, for future use.

In addition, many wireless devices and computers now have built-in MP3 music decoding functions, as well as other advanced sound decoders and systems. Portable computers generally have CD and DVD playback capabilities, and have a small and exclusive flash memory reader to receive pre-recorded audio files. have The problem with this type of function is that digital music files promise many new features and rich experience, but they can only be used when the decoding and playback processing flow can keep up with the pace. Digital image files also have the same problem. To assist in sound reproduction, an external speaker 108, as shown in Figure 1a, can also be accompanied by other components, such as an auxiliary woofer for front and rear sound projection or a surround sound speaker. At the same time, the speaker or earphone 110 is built in the supporting structure and mechanism of the micro display device 106 as shown in FIG. 1b. As we all know, other sound effects and sound reproduction components that can be used include power amplifiers and sound shaping devices.

In any case, as discussed above, when we want to send high-quality or high-resolution image data and high-quality audio information or data signals through more than one communication link 112 from the data source to the user, we must There is a very high data rate. In other words, since the current transmission mechanism cannot achieve the generally required high data rate, the transmission link 112 is obviously a potential bottleneck in data transmission, as discussed before, and limits system performance. As discussed before, for example, when a higher image resolution, such as 1024 by 1024 pixels, a color density of 24-32 bits per pixel, and a data rate of 30fps, the data rate can reach more than 336Mbps. In addition, such images can be presented as part of multimedia. The so-called multimedia presentation includes audio data and potentially other signals, which are responsible for processing interactive games or communications, or different commands, controls, or signals. Further increase the quantity or data and data rate.

Its also clear that the fewer cables or interconnecting devices to establish data connections, it means that display-related mobile devices are easier to use and easier to use. Accepted by more users. This is especially important when multiple devices are usually used to create a full sound-image experience, and especially when the quality of display and sound output devices continues to increase.

Unfortunately, this higher data rate exceeds the data transmission rate of current technology. There is a need for a technology that can transmit data on the data transmission link or communication path between the presentation component and the data source at a higher rate, and has a consistent low power, a small size, and a cable structure that is as simple and as possible as possible Economical. The applicant for this patent has developed new technologies, or methods, and decorations to achieve these and other purposes to allow many mobile, portable, or even fixed-location devices to transmit data at extremely high data rates. To the desired display, micro-display, or audio transmission component, while maintaining the desired power consumption and complexity.

<b>III. High-speed digital data interface system architecture</b>

In order to create new device interfaces and effectively utilize them, signal protocols and system architectures have been designed to provide high data transfer rates using low-power signals. The protocol is built on the structure of the packet and the general frame, or on the interconnected structure, so as to form a protocol for transmitting the pre-selected data set or data type set and the command or operating structure using the interface.

<b>A. Summary</b>

The device connected by the MDDI link or the device passed on the MDDI link is called the host and the client. The client is usually a certain type of display device. The data from the host to the display device is transmitted in the forward direction (referring to forward traffic or connection), and the data from the display device to the host is transmitted in the reverse direction Transmission (reverse traffic and link), as enabled by the host. The basic configuration shown in Figure 2 is shown. In FIG. 2, the host 202 uses a two-way communication channel 206 to connect to the client 204, where the channel includes a forward connection 208 and a reverse connection 210. However, these channels are formed by ordinary conductors whose data transmission effectively switches between forward and reverse connection operations.

As discussed elsewhere, the host includes one of several types of devices that use the present invention. For example, the host 202 can be a portable computer holding a laptop, or a similar mobile computing device, and can be a PDA, a calling device, or one of many wireless phones or modems. At the same time, the client 204 may include various devices for presenting information to the user. For example, a micro display integrated in goggles or glass, a projection device built in a hat or helmet, a small screen built in a car, or even a holographic camera element, such as in a window or windshield, Or various speakers, headphones, or sound systems to present high-quality sound or music. However, experts in the industry will find that the present invention is not limited to these devices. There are many other devices on the market that have been proposed for use in an attempt to provide users with high-quality images and sounds, whether in storage or transmission or in Presented during playback. The present invention can be used to increase the data flow between different devices, so as to provide the high data rate required when realizing user experience.

<b>B. Interface type</b>

The MDD interface is believed to provide more than five unique physical interfaces in the telecommunications and computer industries. Here, they are simply referred to as Type-I, Type-II, Type-III, Type-IV, and Type-U.

The Type-I interface is configured as a 6-wire (conductor) interface, suitable for mobile or wireless phones, PDAs, e-books, electronic games, and portable media players, optical disc players, or MP3 players, and similar electronic consumer Technical device. The Type-U interface is configured as an 8-wire (conductor) interface, which is more suitable for laptops, notebooks, and desktop personal computers and similar devices and applications. It does not need to update the display quickly, and does not need to have internal Built MDDI link controller. This interface type is also different from the Universal Serial Bus (USB) interface that uses additional two lines, which is particularly suitable for working with existing operating systems or software support found on most personal computers. The Type-U interface can also be used in USB-only mode, for example, when the monitor has only a USB connector and is connected to a standard USB port on a computer or similar device.

Type-II, Type-III, and Type-IV interfaces are suitable for high-performance displays or devices, and the use of larger complex cable structures with additional twisted-pair conductors in order to provide adequate protection and low loss for data signals Transmission.

The Type-I interface can transmit signals including display, audio, control, and limited signal information, and is usually used for devices that do not require high-resolution, full-rate video data. This type of interface is mainly used for devices like mobile wireless devices, which usually do not have a USB host for connection and signal transmission. In this configuration, the mobile device is the MDDI host device and serves as the "main device" that controls the communication link from the host. The link generally transmits display data to the client (forward traffic and link).

In this interface, the host makes the host receive communication data from the server (Reverse traffic or connection), by sending a special command or packet type to the client to allow it to take over the bus for a certain period of time and send the data to the host as a reverse packet. As shown in Figure 3, the packet type called encapsulated packet (discussed below) is used to accommodate the transmission of reverse packets on the transmission link in order to establish a reverse link. The time interval allocated to the host to poll the data display is determined in advance by the host, and will also be determined according to the conditions of each specific application. This type of half-duplex two-way data transmission is especially suitable when there is no USB port to transmit client information and data.

The Type-U interface is very suitable for laptop and desktop computer applications. The USB interface is widely supported by most motherboards or other hardware, as well as operating system software. Using the newly added USB interface, you can use the "plug and play" function and easily configure the application device. The inclusion of USB also allows two-way flow of general commands, status, and audio data. At the same time, the image and audio data for the client device can be transmitted using low-power and high-speed twisted-pair cables. Electricity can be transmitted using other lines, as discussed below. The specific embodiment of the present invention using the USB interface allows high-speed transmission over a set of conductors. At the same time, the signal transmission and control are mainly realized on the USB connection, and it is turned off when it is not in use or consumes a small amount of power.

The USB interface is a standard widely used in modems and personal computer equipment. The details of the USB interface and its operation are well known in the industry, so I wont explain it here. In terms of the USB interface, the communication between the host and the display complies with the 2.0 version of the universal serial bus specification. In applications using Type-U interface, USB is the main signal transmission channel and possible voice return Channel, the host can choose whether to poll the client through the MDDI serial data signal.

A high-performance display with HDTV type or similar high-resolution requires a data stream of about 1.5Gbp to support full animation images. The Type-II interface supports high data rates by transmitting 2 bits in parallel, the Type-III interface is capable of transmitting 4 bits in parallel, and the Type-IV interface can transmit 8 bits in parallel. The protocol used by MDDI allows Type-I, -1I, -III, or -N hosts to negotiate the highest data rate that can be used to communicate with Type-I, -II, -III, or -IV clients or displays. The ability or available function of the device considered the least usable is used to set the performance of the link. Generally, even systems where both the host and the client can use the Type-II, Type-III, or Type-IV interface, both of which start to operate from the Type-I interface. Then, the host determines the functions of the target client and the display, and negotiates the handover or reconfiguration operation of any mode of Type-II, Type-III, or Type-IV, depending on the specific application device.

Usually the host may use the appropriate link layer protocol (discussed further below), and at any time slow down or reconfigure the operation to a slower mode to save power, or increase to a faster mode for support Higher rate transmission, for example when used for higher resolution display content. For example, when the display system is switched from a power source such as a battery to AC power, the host may change the display mode, or when the source of the display media is switched to a lower or higher resolution format, or these or other situations Or a combination of events may be regarded as the reason for changing the display or data transmission mode.

When the system transmits data, it can also use a certain mode in a certain direction, And use another mode in the other direction. For example, the Type IV interface mode can be used to transmit data to the display at a high speed, and when transmitting data from a peripheral device such as a keyboard or pointing device to the host device, the Type I or Type U mode is used.

<b>C. Physical interface structure</b>

The general location of the device for establishing communication between the host and the client device or the connection controller is shown in Figures 4 and 5. In FIGS. 4 and 5, the MDDI connection controller 402 shown is installed in the host device 202, and the MDDI connection controller 404 is installed in the client device 204. As before, the host 202 is connected to the client 204, using a two-way communication channel 406 containing a set of conductors. As discussed below, both the host and client connection controllers can use a single-circuit design integrated circuit, which can be set, adjusted or programmed to be used as a host controller (driver) or a client controller ( receiver). Since single circuit devices are mass-produced, the cost is low.

In FIG. 4, the USB host device 401 and the USB client device 410 are used to implement MDDI of the Type U interface version. Circuits and devices that realize this type of function are well known in the industry, so no further explanation is given here.

In FIG. 5, the MDDI connection controller 502 shown is installed in the host device 202', and the MDDI connection controller 504 is installed in the client device 204'. As before, the host 202' is connected to the client 204' via a two-way communication channel 506 containing a set of conductors. As discussed before, both the host and client connection controllers can be manufactured using a single circuit design method.

The signal transmitted between the host and the client, such as on the MDDI link The display device signal, or the actual conductor signal used, are shown in Figures 4 and 5. As shown in Figures 4 and 5, the main path or mechanism for transmitting data via MDDI uses data signals labeled MDDI Data0+/- and M DDI Stb+/-. These signals are low-voltage data signals and are transmitted through the differential line group on the cable. Each bit transmitted on the interface will only be transferred once on the MDDI Data0 group or MDDI Stb group. This is a voltage-based transfer mechanism rather than current-based, so the consumption of electrostatic current is close to zero. The host directs the MDDI Stb signal to the user terminal display.

When data can flow in both forward and reverse directions on the MDDI Data group, that is to say, when it is a two-way transmission path, the host is the master of the data link controller. Both MDDI Data0 and MDDI Stb signal paths operate in differential mode to improve noise immunity. The data rate of the signals on these lines is determined by the clock rate transmitted by the host, and the range is about 1 kbps to more than 400 Mbps.

In addition to Type-I data groups or conductors or paths, Type-II interfaces also include additional data groups or conductors or paths, called MDDI Data1+/-. In addition to the data group or signal path of the Type-II interface, the Type-III interface also contains two additional data groups or signal paths, called MDDI Data2+/- and MDDI Data3+/-. In addition to the data groups or signal paths of the Type-III interface, the Type-IV interface also contains four additional data groups or signal paths, called MDDI Data4+/+, MDDI Data5+/-, MDDI Data6+/-, and MDDI Data7+ /-. In the above interface configuration, the host uses the label MDDI Pwr and The line group or signal of MDDI Gnd transmits power to the user terminal or the display.

Generally, only the transmission type for Type-U configuration is MDDI USB connection or signal path. The MDDI USB connection contains a primary path for communication between the host and the user-side display. In some applications, it is better to transmit certain information between the host and the client at a very low data rate. Using the USB transfer link allows devices that do not have an MDDI link controller but have a USB host or a limited host function to communicate with MDDI-compatible clients or displays equipped with a Type-U interface. Examples of information that can be sent to the display via the USB interface are: static bitmaps, digital audio streams, pointing device data, keyboard data, and control and status information. All the functions supported through the USB interface can be implemented using the main MDDI high-speed serial data path. When the data defined above (see the packet below) can be transmitted through the USB interface, the requirement to link the data in the form of back-to-back packets does not apply to this type of USB interface, nor does it apply to the case of using support for MDDI delivery packets.

Table I below shows the outline of the signal transmitted between the host and the client on the MDDI connection based on the interface type.

<tables><img file="TW577208B_D0001.tif" /></tables><tables><img file="TW577208B_D0002.tif" /></tables>

The cables generally used to realize the above-mentioned structure and operation are actually about 1.5 meters in length and include three sets of twisted pairs of conductors, each of which is a 30AWG line with multiple wires. Wrap it with a foil shielding cover, or form the above-mentioned three sets of twisted pairs as additional drain lines. The twisted pair and the shielded drain conductor terminate at the display connector, a shield is connected to the display by the shield (user side), and there is an insulating layer that covers the entire cable, which is well known in the industry. The pairing methods of this line are: MDDI Gnd and MDDI Pwr; MDDI Stb+ and MDDI Stb-; MDDI Data0+ and MDDI Data0-; MDDI Data1+ and MDDI Data1-; etc. The actual diameter of the cable is 3.0 mm, the impedance is 85 ohms ± 10%, and the DC resistance is 110 ohms per 1000 feet. The signal propagation speed should be 0.66c, and the maximum delay after passing the cable is less than about 8.0 nsec.

<b>D. Data type and rate</b>

In order to achieve a complete user experience and application interface, the Mobile Digital Data Interface (MDDI) supports a variety of displays and display information, audio converters, keyboards, pointing devices, and many other input devices, which may be integrated into It can be used in a mobile display device or together with a mobile display device, plus control information and a combination of the above. The MDD interface is designed to be capable of cooperating with a variety of different types of cables or conductors using a basic number of cables or conductors, in either the forward or reverse connection direction, and the potential type of data stream transmitted between the host and the client. It also supports isochronous streaming and asynchronous streaming (update). Many combinations of data types are feasible, as long as the data rate after aggregation is low At or equal to the required maximum MDDI link rate. These can include, but are not limited to the items listed in Table II and Table III below.

<tables><img file="TW577208B_D0003.tif" /></tables>

<tables><img file="TW577208B_D0004.tif" /></tables>

The interface is not fixed, but can be extended to provide flexibility to adapt to future systems, so it can support the transmission of various "types" of information, including user-defined data. Examples of specific data that can be matched include: full animated images, which can be full or partial screen bitmaps or compressed images; low-speed static bitmaps, which can save power and reduce implementation costs; various resolutions or rates PCM or compressed audio data; the location and options of the pointing device, and user-defined data whose functions have yet to be defined. Such data can also be sent with control or status information to detect device functions or set operating parameters.

Techniques that can be improved when the present invention is used in data transmission include but are not limited to The following items: watching movies (video display and sound effects), using a personal computer with limited viewing (graphics display, sometimes combined with video and sound effects), including: powering on a personal computer, console, or personal device ( Animated graphic display, or synthesizing audio and video), "singing" on the Internet, using videophone-like devices (two-way low-speed audio and video), including: cameras for still digital pictures, cameras for capturing digital images , Used to enhance productivity or entertainment purposes, including: mobile phones, smart phones or PDAs.

The following will discuss the mobile data interface, which can provide a large amount of AV-type data through communication or transmission links, and is usually configured as a line or cable-type link. However, it is obvious that the signal structure, protocol, timing, or transmission mechanism can be adjusted to optical or wireless media type connection, as long as it can provide the required transmission.

The concept used by MDD interface signals is called Common Frame (CF), which can be used for basic signal protocols or structures. The concept behind the use of a common communication frame is to provide synchronization pulses for simultaneous isochronous data streams. The display device can use this common communication frame rate as a time reference. Low-speed CF increases channel efficiency by reducing overhead to transmit sub-frame headers. On the other hand, high-speed CF reduces the waiting time and allows a smaller flexible data buffer to be used for audio samples. The CF rate of the interface of the present invention is dynamically programmable and can be set to many values for isochronous streaming in specific applications. In other words, the CF value that is most suitable for the known display device and host configuration will be selected as needed.

The number of bytes generally required for each common communication frame can be adjusted or programmed for the isochronous data stream most likely to be used in a certain application, as shown in Table IV Head-mounted microdisplay.

<tables><img file="TW577208B_D0005.tif" /></tables>Using a simple programmable M/N counting structure, you can easily obtain the bit component number calculation formula for each common communication frame. For example, to realize that each CF has 26-2/3 bytes, that is, when transmitting 2 frames of 27 bytes, each frame must be followed by a frame of 26 bytes. A smaller CF rate can be selected, and an integer number of bytes can be generated per CF. However, generally speaking, in terms of the area of the integrated circuit chip used to partially or fully implement the present invention, the area required to implement simple M/N calculations on the hardware requires a relatively large audio sample FIFO buffer. The required area is small.

The following example application used to illustrate the influence of different data transfer rates and data types is a karaoke system. In the case of karaoke, system users sing along with music and video programs. The lyrics appear at the bottom of the screen, so the user knows the lyrics to sing and the approximate time of the song. This application needs to occasionally update the image display of the screen and mix the user's voice with the stereo audio stream.

Assuming the common communication frame rate is 300Hz, each CF will include: 92,160 bytes of video content and 588 bytes of audio content (based on 147 16-bit stereo samples) are sent to the display device through a forward link, and an average of 29.67 (26-2/3) bytes of sound , From the microphone back to the mobile karaoke machine. Asynchronous packets are sent between the host and the display. This contains up to 768 bytes of graphics data (a quarter of the screen height), and less than about 200 bytes (some) for various control and status commands.

Table V shows the data configuration in the CCP communication frame of the karaoke example. The total rate used was chosen to be approximately 225 Mbps. The slightly higher rate of 226 Mbps allows an additional transmission of approximately 400 bytes of data per sub-frame, so that control or status messages can be used occasionally.

<tables><img file="TW577208B_D0006.tif" /></tables>

<b>E. Connection layer</b>

The data transmitted using the MDD interface high-speed serial data signal includes time-multiplexed packet streams connected to each other. Even when the transmitting device has no data to transmit, the MDDI link controller will automatically transmit the padding packet, so The packet flow is also maintained. Using a simple packet structure can ensure reliable isochronous timing of video and audio signals or data streams.

The packet group included in the signal component or structure is called the sub-frame, and the sub-frame group included in the signal component or structure is called the media frame. The sub-frame contains one or more packets, depending on its individual size and data transmission purpose, and the media frame must include more than one sub-frame. The largest sub-frame that can be provided by the protocol used in the present invention is 2³²-1 or 4,294,967,295 bytes, the largest media frame size becomes 2¹⁶-1 or 65,535 sub-frames.

The following will discuss the special header packet that appears at the beginning of each subframe and contains a unique identification item. When the communication between the host and the display starts, the identification item is also used to obtain the frame timing of the client device. The link timing acquisition will be discussed further below. Generally, when displaying a full animation image, the display is updated once for each media frame. The display frame and the media frame have the same rate.

Depending on the application, the linking protocol will determine whether to support the full animation image on the entire display, or a small part of the full animation image content surrounded by static images. In some low-power mobile applications, such as viewing web pages or emails, the display only needs to be updated occasionally. In this case, it is best to send a single subframe first and then close the link to reduce power consumption. The interface also supports stereoscopic video effects and can handle basic graphic units.

The sub-frame can transmit packets with high priority at regular intervals. This allows simultaneous isochronous streaming to coexist with a minimum amount of data buffering. This is one of the benefits provided by the present invention for the display process, allowing multiple data streams (high-speed transmission of images, sounds, control, status, pointing devices, etc.) to be actually shared Public passage. It uses relatively few signals to transmit information. And to achieve the effects of certain display technologies, such as the horizontal sync pulse and blanking interval of the CRT screen.

<b>F. Link control tool</b>

The MDDI link controller shown in Figures 4 and 5 is produced or assembled as a complete digital implementation, except for the differential line receiver used to receive MDDI data and strobe signals. To realize the hardware of the link controller, no analog function or phase-locked loop (PLL) is required. The host computer and the display link controller contain very similar functions, except for the display interface, which includes a state machine for link synchronization. Therefore, the present invention can be designed as a single controller that can be configured as a host or a user side, which can reduce the production cost of the connected controller as a whole.

<b>IV. Interface Link Agreement</b>

<b>A. Frame structure</b>

Figure 6 shows the signal protocol or frame structure used to implement forward link communication for packet transmission. As shown in Figure 6, information or digital data combined into components is called a packet. Multiple packets can be combined into a "sub-frame", and multiple sub-frames can be combined into a "media" frame. In order to control the formation of the frame and the transmission of the sub-frames, each sub-frame starts with a specially defined packet, which is called a sub-frame header packet (SHP).

The host device selects the data rate to be used for the known transmission. This rate can be dynamically changed by the host device according to the maximum transmission capacity of the host or the data retrieved from the source by the host, and the maximum capacity of the display or other devices to which the data is transmitted.

Receiving client devices designed or capable of working with MDDI or innovative signal protocols can accept host queries to determine the maximum value, the current maximum value, the available data transfer rate, or the slower preset minimum rate that can be used, and Available data types and supported functions. This information can be transmitted using Display Capability Packet (DCP), which will be discussed further below. The client display device can use the interface to transmit data or communicate with other devices at a pre-selected minimum data rate or within the minimum data rate range, and the host can use the data rate within this range to perform queries. In order to determine all the functions of the client device.

Other status information that defines the bitmap characteristics and the display image frame rate function can be sent to the host in the status packet, so the host can use the most efficient or optimized method as far as possible within the system limits according to actual needs. To configure the interface.

When there are no (more) data packets to send in the current subframe, or when the host's transfer rate cannot keep up with the data transfer rate selected for the forward link, the host will send a padding packet. Since each sub-frame starts with a sub-frame header packet, the end of the previous sub-frame includes a packet that completely fills the previous sub-frame (most likely a padding packet). If there is no space to carry the data of the packet itself, the padding packet is most likely to be filled in the last packet of the sub-frame, or the end of the first two sub-frames and before the header packet of a certain sub-frame. Ensuring that there is enough space left in the sub-frame so that every packet in the sub-frame can be transmitted is a control operation of the host device. At the same time, once the host device starts the transmission of the data packet, the host must be able to successfully complete the packet of this size in the frame without data being sent Circumstances of private execution.

In a certain viewpoint of the specific embodiment of the present invention, there are two modes of sub-frame transmission. One is the cyclic sub-frame mode, which is used to transmit real-time video and audio streams. In this mode, the length of the sub-frame is defined as non-zero. The second mode is asynchronous or acyclic mode. In this mode, the frame only provides bitmap data to the display device when new information appears. The definition of this mode is to define the sub-frame length in the sub-frame header packet as zero. When using the cyclic mode, if the display is synchronized with the forward link frame structure, the sub-frame packet reception will start. This corresponds to the "synchronizing" state defined according to the state diagram discussed in Figure 49. In the asynchronous acyclic sub-frame mode, the reception starts after the first sub-frame header packet is received.

<b>B. The overall packet structure</b>

The packet format or structure that constitutes the signal protocol implemented by the present invention will be described below. It should be remembered that the interface is expandable, and additional packet structures can be added as needed. According to the function of the packet in the interface, that is, the command or the transmitted data, the packet is marked as or divided into different "packet types". Therefore, each packet type represents a pre-defined packet structure of a known packet, which can be used to manipulate the packet and the transmitted data. Obviously, the packet has a pre-selected length, or a variable or dynamically changing length according to its individual function. The bytes or byte values used in different packets are all configured as multi-bit (8- or 16-bit) unsigned integers. Table VI shows a summary of the used packets and their representative "types", sorted by type. The table also indicates the effective packet transmission direction and whether it can be used in the Type-U interface.

<tables><img file="TW577208B_D0007.tif" /></tables>

The packet has a common basic structure or a basic set of fields, including a packet length field, a packet type field, a data byte field, and a CRC field, as shown in Figure 7. As shown in Figure 7, the packet length field contains information in a multi-byte or byte value format. You can specify the total number of bits in the packet or the packet The length between the length field and the CRC field. In a preferred embodiment of the present invention, the packet length field contains a 16-bit or 2-byte wide, unsigned integer, and the packet length can be specified. The packet type field is another multi-bit field that represents the type of message contained in the packet. In the exemplary embodiment of the present invention, it is an 8-bit or 1-byte wide value, and the format is an 8-bit unsigned integer. This type of data is designated as display function, handover, image or audio stream , Status, etc.

The third field is the data byte, which contains the bits or data being sent or sent between the host and the client device. According to the specific type of transmitted data, the data format is defined for each packet type and divided into a series of additional fields, each format has its own format conditions. In other words, every package type has the definition format of this part or this field. The last field is the CRC field, which contains the results of the 16-bit cyclic redundancy check calculated on the data byte, packet type, and packet length fields. This field is used to confirm the integrity of the information in the packet sex. In other words, all packets except the CRC field itself are calculated. Usually the client will keep the total number of CRC errors detected and report this number back to the host in the display request and status packet (see the following description).

During the transmission of the packet, the field will be transmitted first from the "Least Significant Bit" (LSB), and finally the "Most Significant Bit" (MSB) ends. Parameters longer than one byte are transmitted first using the least significant byte, which results in parameters longer than 8 bits using the same transmission mode as the shorter parameters used to transmit the LSB first. The data on the MDDI Data0 signal path is in any of the following modes Type- I, Type-II, Type-III, or Type-IV are all aligned with the bit 0 byte transmitted on the interface.

When controlling the data of the display, first transmit the pixel data from the column, and then the column, just like the traditional electronic technology. In other words, all the pixels appearing in the same column in the bitmap are transmitted in a way that starts with the leftmost pixel first, and finally transmits the rightmost pixel. After the rightmost pixel in a column is transmitted, the next pixel in the transmission sequence will be the leftmost pixel in the next column. For most displays, the pixel rows are generally transmitted in a top-to-bottom order, but other configurations can also be used as needed. In addition, when processing bitmaps, the traditional method, that is, the method mentioned below, is to define a reference point, that is, to mark the upper left corner of the bitmap as the position or offset "0,0". The X and Y axes are used to define or determine the position in the bitmap. As they get closer to the right and lower sides of the bitmap, the values increase. The first column and the first column start with a value of zero.

<b>C. Packet definition</b>

<u style="single">1. Sub-frame header packet</u>

The sub-frame header packet is the first packet of each sub-frame, and has a basic structure as shown in FIG. 8. As shown in FIG. 8, this type of packet structure has packet length, packet type, unique word, sub-frame length, protocol version, sub-frame calculation, and media-frame calculation fields, which are usually arranged in this order. This type of packet is usually called a Type 255 (Oxff hexadecimal) packet and uses a pre-selected fixed length of 17 bytes.

When 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 can form a good 32-bit unique word with good auto-correlation. In fact, the unique word is 0x005a3bff, in which the lowest 8 bits are first transmitted in packet type, and then the highest 24 bits are transmitted.

The sub-frame length field contains 4 bytes of information, which specifies the number of bytes per sub-frame. The length of this field can be set equal to zero, which means that the host can only send one sub-frame before the link is closed to an idle state. The value in this field can be dynamically and quickly changed when moving from a sub-frame to the next sub-frame. This function is very useful and can adjust the secondary timing in the sync pulse to match the isochronous data stream. If the CRC of the sub-frame header packet is invalid, the link controller should use the sub-frame length of the previous known good sub-frame header packet to evaluate the length of the current sub-frame.

The protocol version field contains 2 bytes, which can specify the protocol version used by the host. Set the protocol version field to "0" to specify the first or current protocol version used. When a new version is created, this value will change over time. The sub-frame count field contains 2 bytes, which can specify the sequence number, which indicates the number of sub-frames that have been transmitted since the start of the media frame. The first sub-frame of the media frame has a sub-frame count of zero. The value of the last sub-frame of the media frame is n-1, where n is the number of sub-frames in each media frame. It should be noted that if the length of the sub-frame is set to zero (indicating a non-cyclic sub-frame), the sub-frame count must also be set to zero.

The media frame count field contains 3 bytes, which can specify the sequence number, which indicates the number of media frames that have been sent since the start of the current media item or data. The media frame count of the first media frame of the media item is zero. Before the first subframe of each media frame, the media frame count will gradually increase, and After using the largest media frame count, it will return to zero (media one frame number 2²⁴-1=16,777,215). The media-frame count value is generally reset by the host at any time to meet the needs of the end application device.

<u style="single">2. Fill the packet</u>

A stuffing packet is a packet sent to or from the client device when no other information is sent on the forward or reverse link. We recommend that the filling packet has a minimum length to have the greatest flexibility when transmitting other packets. At the end of the sub-frame or reverse link encapsulated packet (see below), the link controller sets the size of the padding packet to fill the remaining space to maintain the integrity of the packet.

The format and content of the padding packet are shown in Figure 9. As shown in Figure 9, the structure of this type of packet includes packet length, packet type, padding bytes, and CRC fields. This type of packet is generally called Type 0 and is indicated in the 1-byte type field. The bits or bytes in the padding byte field include all zero-bit values whose number can be changed, so that the padding packet has the required length. There is no byte field in the smallest padding packet. In other words, the packet only contains the packet length, packet type, and CRC, and uses a pre-selected fixed-length 3-byte group.

<u style="single">3. Image stream packet</u>

The image stream packet carries image data to update the irregular rectangular area of the display device. The size of this area can be as small as the size of a pixel, as large as the size of the entire display. There is almost no limit to the number of streams that can be displayed at the same time, only limited by system resources, because all the content needed to display the streams is contained in the video stream packet. Video stream packet format (video data format descriptor) As shown in Figure 10. Please refer to Figure 10. This type of packet structure includes packet length, packet type, image data descriptor, display attributes, X left edge, Y top edge, X right edge, Y bottom edge, and X and Y starting points, pixel count , Parameter CRC, pixel data, and CRC field. This type of packet is generally called Type 1, and is indicated in the 1-byte type field.

The concept of the shared communication frame discussed above is an effective way to reduce the size of the sound buffer and reduce the waiting time. However, for image data, it may be necessary to expand the pixels of the image frame to multiple image stream packets in the media frame. It is also possible that the pixels in a single video stream packet cannot completely correspond to the rectangular window on the display. Taking the image frame rate of 30 frames per second as an example, there are 300 sub-frames per second, which can result in 10 sub-frames for each media frame. If each frame has 480 rows of pixels, each video stream packet in each subframe will contain 48 rows of pixels. In other cases, the video stream packet may not contain an integer number of pixels. This also applies to other video frame sizes. The number of sub-frames for each media frame is not necessarily divided into the number of rows per video frame (called video lines). Each video stream packet must contain an integer number of pixels, even if it does not necessarily contain an integer number of pixels. This is especially important if the pixels of each packet are more than one tuple, or if the pixels have a packet-type format, as shown in Figure 12.

Use the format and content to implement the above-mentioned image data descriptor field operations, as shown in Figures 11a-11d. In FIGS. 11a-11d, the image data format description subfield contains a 2-byte group with a 16-bit unsigned integer format, which specifies the format of each pixel in the pixel data of the current stream of the current packet. Different streams (specified by the stream ID field) may use different pixel data Format, that is, using different image data format descriptors, and similarly, any stream can quickly change its data format. The image data format descriptor only defines the pixel format of the current packet, which does not mean that a particular image stream will always use the same format.

Figures 11a to 11d illustrate the encoding method of the image data format descriptor. As shown in these figures, when the bit [15:13] is equal to "000", as shown in Figure 11a, the image data will contain a set of monochrome pixels, and the number of bits of each pixel is determined by the image data The format description sub-text is defined by bits 3 to 0. In this case, bits 11 to 4 are set to zero. When the bit [15:13] is equal to "001", as shown in Figure 11b, the image data will include a set of color pixels, and each pixel corresponds to a specified color through color. In this case, bits 5 to 0 of the image data format description sub-word define the number of bits per pixel, and bits 11 to 6 are set equal to zero. When bit [15:13] is equal to "010", as shown in Figure 11c, the image data contains a set of color pixels, where the number of red pixels is defined by bits 11 to 8, and the number of green pixels The number of bits is defined by bits 7 to 4, and the number of bits of the blue pixel is defined by bits 3 to 0. In this case, the total number of bits for each pixel is equal to the sum of the number of bits used by red, green, and blue.

However, when the bit [15:13] is equal to "011", as shown in Figure 11d, the image data includes a set of image data with luminance and chrominance information and a format of 4:2:2, in which the pixel luminance ( The number of bits of Y) is defined by bits 11 to 8, the number of bits of Cr elements is defined by bits 7 to 4, and the number of bits of Cb elements is defined by bits 3 to 0. The total number of bits for each pixel is equal to the sum of the number of bits used by red, green and blue. The transfer rate of Cr and Cb elements is half of Y. Otherwise In addition, the image samples in the pixel data part of this packet are arranged as follows: Y_n, Cr_n, Cb_n, Y_n+1, Y_n+2, Cr_n+2, Cb_n+2, Y_n+3,...Of which Cr_nAnd Cb_nWith Y_nAnd Y_n+1Related, and Cr_n+2And Cb_n+2With Y_n+2And Y_n+3Relevant, and so on. If a column in the current stream has an odd number of pixels (X right edge-X left edge + 1), the Cb value corresponding to the last pixel in each column will be immediately after the Y value of the first pixel in the next column.

For the four formats shown in the figure, bit 12 is represented by "P", indicating whether the pixel data sample is encapsulated or whether it is pixel data that is byte-aligned. The "0" in this field means that each pixel and each color in each pixel in the pixel data field are aligned with the boundary bytes of the MDDI interface byte. "1" means that each pixel and each color in each pixel in the pixel data corresponds to the previous pixel or color in the unused bit pixel to be encapsulated.

The first pixel in the first video stream of a specific display window will enter the upper left corner of the streaming window defined by the X offset and Y offset, and the received bottom pixel will be placed next to the same column Pixel position, and so on. To speed up this operation, the display must associate the "Next Pixel Row and Column" count with each active video stream ID.

<u style="single">4. Audio stream packet</u>

The audio stream packet carries the audio data played through the display system or independent display device. Different sound effect data streams can be assigned to individual sound effect channels in the sound system. For example, according to the type of sound effect system used, they can be assigned to left front, right front, center, left rear, and right rear. The complete supplementary interval of the sound effect channel can also be provided to the ears that include enhanced surround sound signal processing. machine. The format of the audio stream packet is shown in Figure 13. As shown in Figure 13, the structure of this type of packet includes packet length, packet type, sound effect channel ID, sound effect sample count, bits and encapsulation of each sample, sound effect sampling rate, parameter CRC, digital sound effect data, and sound effect data CRC Field. This type of packet is generally called a Type 2 packet.

Each sample bit and package field contains a 1-byte group of 8-bit unsigned integers, which can specify the encapsulation format of the audio data. The generally adopted format is bits 4 to 0 to define the number of bits for each PCM audio sample. Bit 5 specifies whether the digital audio data sample is encapsulated. The difference between packed and byte-aligned audio samples is shown in Figure 14. "0" means that each PCM sound effect sample in the digital sound effect data field is aligned with the boundary byte of the MDDI interface byte, and "1" means that each successive PCM sound effect sample is encapsulated corresponding to the previous sound effect sample. This bit is valid only when the value defined in bits 4 to 0 (the number of bits per PCM sound effect sample) is not a multiple of eight. Bits 7 to 6 are reserved for future use and are generally set to zero.

<u style="single">5. Keep stream packets</u>

Packet types 3 to 55 are reserved for streaming packets that define future versions or modified packet protocols, which can be used by different application devices encountered in the future. From here, it is again confirmed that compared with other technologies, this technology can make the MDD interface more flexible and more useful in the face of ever-changing technologies and system designs.

<u style="single">6. User-defined stream packets</u>

Eight data stream types, called Types 56 to 63, are reserved for exclusive applications. When equipment manufacturers want to use MDDI links, they can add them definition. These packets are called user-defined flow packets. The image stream packet carries image data to update the rectangular (or non-rectangular) area of the display device. The streaming parameters and data definitions of these packet types are reserved for specific equipment manufacturers to use when seeking their exclusive use. The format of the user-defined stream packet is shown in Figure 15. As shown in Figure 15, the structure of this type of packet includes the packet length, packet type, stream ID number, stream parameter, parameter CRC, stream data, and stream data CRC fields.

<u style="single">7. Color corresponding packet</u>

The color mapping packet can specify the content of the color mapping lookup table used to present the color of the display. When the amount of data applied is greater than the amount of data that can be transmitted in a single packet, color correspondence is required. In these cases, multiple color-corresponding packets can be sent. By using the following offset and length fields, each packet has a different color-corresponding subset. The format of the color corresponding packet is shown in Figure 16. As shown in Figure 16, the structure of this type of packet includes packet length, packet type, color corresponding data size, color corresponding offset, parameter CRC, color corresponding data, and data CRC fields. This type of packet is generally called Type 64 packet.

<u style="single">8. Reverse link encapsulation packet</u>

Data is sent in the reverse direction using reverse link encapsulation packets. After the forward connection packet is transmitted, the MDDI connection operation (transmission direction) is changed or turned in the packet, and the packet will be transmitted in the reverse direction. The format of the reverse link encapsulation packet is shown in Figure 17. As shown in Figure 17, the structure of this type of packet includes packet length, packet type, reverse link flag, turn length, parameter CRC, turn 1, reverse data packet, and turn 2. This type of cover Packets are generally called Type 65 packets.

The MDDI link controller acts in a special way in transmitting reverse link encapsulation packets. The MDD interface has a certain strobe signal driven by the host. The host acts like it transmits zeros to every bit of the reverse link encapsulated packet's turn and reverse data packet portion. The host switches the MDDI strobe signal at each bit boundary during the two turnarounds and the period allocated to the reverse data packet. (This action is the same as sending all zero data). The host disables its MDDI data signal line driver during the period specified by the turn 1, and the client re-enables its line driver during the driver re-enable field after the period specified by the turn 2 field. The display reads the turning length parameter, and after turning to the last bit of the 1 field, it immediately drives the data signal to the host. The display uses the packet length and turn-around length parameters to understand the length of time it can transmit the packet to the host. When no data is sent to the host, the client can send padding packets or make the data line zero. If the data line is driven to zero, the host will interpret this as the length of the packet is zero (invalid length), and the host will not accept any other packets from the client during the current reverse connection encapsulation packet.

At least one reverse link clock cycle before the start of the turn 2 field of the display drives the MDDI data line to zero order. This keeps the data line in a decisive state during Turn 2. If the client does not have any packets to send, it may disable the data line after driving the packet to zero, because the sleep bias resistor (discussed elsewhere) will keep the data line during the remaining reverse data packet fields In the zero order.

Display request and status packet reverse link request field can be used to notify the host The number of bytes required in the reverse link encapsulation packet when the display sends data back to the host. The host attempts to allow the request by allocating at least this number of bytes on the reverse link encapsulation packet. The host can send more than one reverse link encapsulation packet in the subframe. The display can transmit display request and status packets almost at any time, and the host will interpret the reverse link request parameter as the total number of bytes required in the subframe.

<u style="single">9. Display function package</u>

The host needs to know the function of the display (client) with which it communicates in order to configure the connection of the host to the display in the best or generally required way. The present invention proposes that after obtaining the forward link synchronization, the display transmits a display function packet to the host. When the host uses the reverse connection flag in the reverse connection encapsulation packet to make a request, the transmission of this type of packet is deemed necessary. The format of the display function packet is shown in Figure 18. As shown in Figure 18, this type of packet structure includes packet length, packet type, protocol version, minimum protocol version, bitmap width, bitmap screen height, monochrome function, color correspondence function, RGB function, Y Cr Cb function , Display feature function, data rate function, frame rate function, sound effect buffer depth, sound effect streaming function, sound effect rate function, minimum sub frame rate, and CRC field. This type of packet is generally called a Type 66 packet.

<u style="single">10. Keyboard data packet</u>

The keyboard data packet is used to transmit data from the client device to the host. The wireless (or wired) keyboard can be used in combination with different displays or sound effects devices, including but not limited to head-mounted video displays/sound effects presentation devices. The keyboard data packet will be forwarded to the keyboard data received from a number of known similar keyboard devices Host. This packet can also send data to the keyboard on the forward link. The format of the keyboard data packet is shown in Figure 19 and contains a variable number of information bytes from or for the keyboard. As shown in Figure 19, the structure of this type of packet includes packet length, packet type, keyboard data, and CRC fields. This type of packet is generally called Type 67 packet.

<u style="single">11. Pointer device data packet</u>

The pointing device data packet is used to transmit location information from the wireless mouse or other pointing device of the display to the host. Data can also be sent to the pointing device on the forward link using this packet. The format of the pointing device data packet is shown in Figure 20, and contains a variable number of information bytes from or for the pointing device. As shown in Figure 20, the structure of this type of packet includes packet length, packet type, indicator device data, and CRC fields. This type of packet is generally called a Type 68 packet in the 1-byte type field.

<u style="single">12. Link closed packet</u>

The link close packet is sent from the host to the client display, indicating that the MDDI data and strobe are about to be closed, and it enters a low-power consumption "sleep" state. This packet can be used to close the connection and save power after the static bitmap is transmitted from the mobile communication device to the display, or when there is no further information transmitted from the host to the client for the time being. When the host transmits the packet again, normal operation resumes. The first packet transmitted after sleep is the sub-frame header packet. The format of the display status packet is shown in Figure 21. As shown in Figure 21, the structure of this type of packet includes packet length, packet type, and CRC fields. This type of packet is usually called a Type 69 packet in the 1-byte field, and uses a pre-selected fixed-length 3-byte packet.

In the low-power sleep state, the MDDI data driver will be disabled and enter a high-impedance state. The system uses a high-impedance offset network that can be overdriven by the display to pull the MDDI Data signal to a logic zero state. The strobe signal used by the interface is set to logic zero in the sleep state to reduce power consumption. The host or the display will cause the MDDI link to "wake up" from the sleep state mentioned elsewhere, which is an important improvement and advantage of the present invention.

<u style="single">13. Display requirements and status packets</u>

The host needs a small amount of information about the display in order to configure the connection of the host to the display in the best way. The present invention suggests that each sub-frame transmits a display status packet to the host. The display will send this packet as the first packet in the reverse link encapsulation packet to ensure that the packet will be reliably transmitted to the host. The format of the display status packet is shown in Figure 22. As shown in Figure 22, the structure of this type of packet includes packet length, packet type, reverse connection requirements, CRC error count, and CRC fields. This type of packet is usually called a Type 70 packet in the 1-byte field, and uses a pre-selected fixed-length 7-byte packet.

The reverse link request field can be used to inform the host that the number of bytes required in the reverse link encapsulation packet when the display sends data back to the host. The host should attempt to allow the request by allocating at least this number of bytes in the reverse link encapsulation packet. The host can send more than one reverse link encapsulation packet in the subframe to contain data. The display can send display request and status packets at any time, and the host will interpret the reverse link request parameter as the total number of bytes required in the subframe. Other details and specific examples of how backlink data is returned to the host will be explained later.

<u style="single">14. Bit block transmission packet</u>

The bit block transfer packet provides a way to scroll the display area in any direction. Displays with this function will notify this function in the display feature function indication field of the display function package at bit 0. The format of the bit block transmission packet is shown in Figure 23. As shown in Figure 23, the structure of this type of packet includes 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 usually called a Type 71 packet and uses a pre-selected fixed length of 15 bytes.

Some fields are used to indicate the X and Y values of the coordinate axis in 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 when the window is moved horizontally and vertically. When the value of the last two fields is positive, it will make the window move to the right and down, if it is negative, it will make the window move to the left and up.

<u style="single">15. Fill the bitmap area with the packet</u>

Filling the bitmap area into a packet provides a way to simply start the display area as a single color. Displays with this function will notify this function in the display feature function indication field of the display function package. The format of the bitmap area filled in the packet is shown in Figure 24. As shown in Figure 24, the structure of this type of packet includes packet length, packet type, upper left X value, upper left Y value, window width, window height, data formatting descriptor, pixel area filling value, and CRC field. This type of packet is usually called a Type 72 packet in the 1-byte field, and uses a pre-selected fixed length of 17 bytes.

<u style="single">16. Fill the packet with a dot matrix pattern</u>

The dot matrix pattern filling packet provides a way to simply start the display area as a pre-selected pattern. Displays with this function will notify this function in the display feature function indication field of the display function package. The upper left corner of the filled pattern is aligned with the upper left corner of the window to be filled. If the window to be filled is wider or higher than the filled pattern, the pattern will be repeated horizontally or vertically several times to fill the window. The right or bottom of the final repeated pattern will be truncated as necessary. If the window is smaller than the filled pattern, the right or bottom of the filled pattern will be cut off to fit the window.

The format of the dot matrix pattern filling packet is shown in Figure 25. As shown in Figure 25, the structure of this type of packet includes 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 the CRC field of the pixel data. This type of packet is generally called a Type 73 packet in the 1-byte type field.

<u style="single">17. Communication link data channel packet</u>

The communication link data channel packet provides a method that allows displays with high-level computing functions, such as PDAs, to communicate with wireless transceivers such as mobile phones or wireless data port devices. In this case, the MDDI link is like a convenient high-speed interface between a communication device and a computing device with a mobile display, where this packet transmits data to the device through the data link layer of the operating system. For example, this packet can be used in a web browser, email client, or an entire PDA built into the mobile display. Displays with this function will be displayed in the display feature function indicator field of the function package Among 3, this function is notified.

The format of the communication link data channel packet is shown in Figure 26. As shown in Figure 26, the structure of this type of packet includes packet length, packet type, parameter CRC, communication link data, and communication data CRC fields. This type of packet is generally called Type 74 packet in the type field.

<u style="single">18. Interface-based delivery request packet</u>

The interface type handover request packet allows the host to request the client or display to switch from the existing or current mode to Type-I (serial), Type-II (2-bit parallel), Type-III (4-bit parallel), Or Type-IV (8-bit parallel) mode. When the host requests a specific mode, it will first check the display feature function indicator field of the display function package of bits 6 and 7 to confirm that the display can work in the desired mode. The format of the interface-type handover request packet is shown in Figure 27. As shown in Figure 27, the structure of this type of packet includes packet length, packet type, interface type, and CRC fields. This type of packet is usually called Type 75 packet and uses a pre-selected fixed-length 4-byte group.

<u style="single">19. Interface type confirmation packet</u>

The interface type confirmation packet is sent by the display to confirm the receipt of the interface type handover packet. The required mode, Type-I (serial), Type-II (2-bit parallel), Type-III (4-bit parallel), or Type-IV (8-bit parallel) mode, will be returned The host is used as a parameter in this packet. The format of the interface type confirmation packet is shown in Figure 28. 28, this type of packet structure comprises a packet length, packet type type, interface type, and CRC fields. This type of packet is usually called a Type 76 packet and uses a pre-selected fixed-length 4-byte group.

<u style="single">20. Execution type handover packet</u>

The execution type handover packet is the method by which the host instructs the display to hand over to the specified mode of the packet. This packet mode will be the same as the previous request and confirmation mode of the interface-type handover request packet and the interface-type confirmation packet. After sending this packet, the host and display will switch to a mutually agreed mode. During the mode change, the monitor may lose or regain the connection synchronization. The format of the execution type handover packet is shown in Figure 29. As shown in Figure 29, the structure of this type of packet includes packet length, packet type, interface type, and CRC fields. This type of packet is usually called a Type 77 packet in the 1-byte field, and uses a pre-selected fixed-length 4-byte packet.

<u style="single">21. Enabling packet for forward audio channel</u>

This packet allows the host to enable or disable the audio channel in the display. The function of this function is: when the host is not outputting sound effects, the display (user terminal) can turn off the power of the sound effect amplifier or similar circuit components to save power. It will be difficult to achieve just by streaming with or without sound effects. The default state when the system is turned on is to enable all audio channels. The format of the forward audio channel enable packet is shown in Figure 30. As shown in Figure 30, the structure of this type of packet includes packet length, packet type, audio channel enablement mask, and CRC fields. This type of packet is usually called a Type 78 packet in the 1-byte field, and uses a pre-selected fixed-length 4-byte packet.

<u style="single">22. Reverse audio sampling rate packet</u>

This packet allows the host to enable or disable the reverse link audio channel and set the audio data sampling rate of this stream. The host will choose to display the effective sampling rate defined in the function package. If the host selects an invalid sampling rate Rate, the display will not send audio stream to the host. By setting the sampling rate to 255, the host can disable reverse link audio streaming. The default state when the display system is turned on or connected to the display system is to disable reverse link audio streaming. The format of the reverse audio sampling rate packet is shown in Figure 31. As shown in Figure 31, the structure of this type of packet includes packet length, packet type, audio sampling rate, and CRC fields. This type of packet is usually called Type 79 packet and uses a pre-selected fixed-length 4-byte group.

<u style="single">23. Overhead packet for digital content protection</u>

This packet allows the host and display to exchange messages related to the digital content protection method used. Currently, only two types of content protection are considered, digital transmission content protection (DTCP), or high-bandwidth digital content protection system (HDCP), and space is reserved for other protection methods to be specified in the future. The method used is specified by the content protection type parameter in this packet. The format of the digital content protection overhead packet is shown in Figure 32. As shown in Figure 32, the structure of this type of packet includes packet length, packet type, content protection type, content protection overhead message, and CRC fields. This type of packet is generally called a Type 80 packet.

<u style="single">24. Transparent color enable packet</u>

The transparent color enable packet is used to specify which color in the display is transparent, and to determine whether to enable the transparent color function of the displayed image. Displays with this function will notify this function in bit 4 of the display feature function indication field of the display function package. When a pixel with a transparent color value is written into the bitmap, the color will not change the original value. The format of the transparent color enable packet is shown in Figure 33. As shown in Figure 33, the structure of this type of packet includes the packet length Degree, packet type, transparent color enable, data format descriptor, transparent pixel value, and CRC field. This type of packet is usually called a Type 81 packet in the 1-byte field, and uses a pre-selected fixed-length 10-byte packet.

<u style="single">25. Round-trip delay measurement packet</u>

The round-trip delay measurement packet is used to measure the propagation delay from the host to the user (display) and the delay from the user (display) back to the host. This measurement basically includes the delays that exist in the line driver and receiver and interconnect subsystems. This measurement can be used to set the steering delay and reverse connection rate divisor parameters in the reverse connection encapsulation packet, as described above. This packet is most useful when the MDDI link is trying to perform at the maximum speed of a particular application. The operation of MDDI Stb signal is to send all zero data during the following fields: all zeros, including guard time and measurement period. This causes the MDDI Stb to switch at half the data rate so that it can be used as the cyclic clock in the display during the measurement.

The format of the round-trip delay measurement packet is shown in Figure 34. As shown in Figure 34, the structure of this type of packet includes packet length, packet type, parameter CRC, strobe arrangement, all zeros, guard time 1, measurement period, guard time 2, and drive re-enable fields. This type of packet is usually called a Type 82 packet and uses a pre-selected fixed length of 535 bits.

The sequence of events during the round-trip delay measurement packet is shown in Figure 35. In Figure 35, the host transmits a round-trip delay measurement packet. As shown in the figure, the parameter CRC and strobe array fields are followed by all zeros and guard time 1 fields. There is a delay 3502 before the packet reaches the client display device or processing circuit. When the display receives the packet, the way it transmits the 0xff, 0xff, and 0x0 models is exactly the same as the display actually determines at the beginning of the measurement period. The actual time when the display starts to transmit this sequence is delayed from the point of view of the host from the start of the measurement period. The delay time is exactly equal to the time the packet travels through the line driver and receiver and the interconnection subsystem. A similar amount of delay 3504 is required to propagate from the display back to the host in this model.

In order to correctly determine the round-trip delay time of the signal to and from the user end, the host calculates the number of bit times from the beginning of the measurement period to the beginning of the sequence of 0xff, 0xff, and 0x0 detected when it arrives. This message is used to determine the time it takes for the round-trip signal to travel from the host to the client and back again. Half of the time is spent on the delay caused by the one-way signal to the user end.

As soon as the display transmits the last bit of the 0xff, 0xff, and 0x0 model, its line driver will be disabled. Guard time 2 allows the line driver time of the display to fully enter the high impedance state before the host transmits the packet length of the next packet. The sleep pull-up and pull-down resistors (see Figure 42) ensure that the MDDI Data signal remains at a valid low level during the period when the host and the display are both disabled.

<b>D. Packet CRC</b>

In the exemplary embodiment of the present invention, the polynomial used for CRC calculation is CRC-16, or X¹⁶+X¹⁵+X²+X⁰. The sample implementation of the CRC generator and checker 3600 used to implement the present invention is shown in FIG. 36. In Figure 36, the CRC register 3602 starts with a value of 0x0001, just before the transmission of the first bit of the packet input to the Tx MDDI Data Before CRC line, and then the packet bytes are transferred to the register starting with LSB . Please note that the number of register bits in this figure corresponds to the power of the polynomial used, and does not correspond to the bit positions used by MDDI. It is more efficient to transfer the CRC register in one direction, and this causes the CRC bit 15 to appear in the bit position 0 of the MDDI CRC field, and the CRC register bit 14 appears in the MDDI CRC field bit position 1. And so on, until MDDI bit position 14.

For example, if the content of the display request and status packet is: 0x07, 0x46, 0x000400, 0x00 (or the following byte sequence: 0x07, 0x00, 0x46, 0x00, 0x04, 0x00, 0x00), and use multiplexing The input of the device 3604 and 3606 and the NAND gate 3608 submitted, the CRC output generated on the Tx MDDI Data With CRC line is 0x0ea1 (or expressed as 0xal, 0x0e).

When the CRC generator and checker 3600 is configured as a CRC checker, the CRC received on the Rx MDDI Data line is input to the multiplexer 3604 and NAND gate 3608, and the NOR gate 3610 and the exclusive OR (XOR) gate 3612 are used , And AND gate 3614, compare with the value found in the CRC register bit by bit. If there is any error, such as the output of the AND gate 3614, by connecting the output of the gate 3614 and the input of the register 3602, CRC It will be accumulated once for each packet containing CRC errors. It should be noted that the example circuit shown in Figure 36 can input more than one CRC error signal in the known CHECK CRC NOW window (see Figure 37b). Therefore, the CRC error counter will only count the first CRC error instance in each interval where CHECK CRC NOW is active. If configured as a CRC generator, CRC will record the time of the CRC register at the end of the packet.

The input and output signals, and the timing of the enable signal are shown in Figures 37a and 37b. The generation of CRC and the transmission of data packets are shown in Figure 37a, including the Gen Reset, Check CRC Now, Generate CRC Now and Sending MDDI Data signals, as well as the status of the Tx MDDI Data Before CRC and Tx MDDI Data With CRC signals (0 or 1 ). The reception of the data packet and the check of the CRC value are shown in Figure 37b, including the status of the Gen Reset, Check CRC Now, Generate CRC Now, and Sending MDDI Data signals, as well as the Rx MDDI Data and CRC error signals.

<b>V. Restart the link from hibernation</b>

When the host restarts the forward link from the dormant state, it drives MDDI Data to a logic one state for about 150 μsec, then starts MDDI Stb and drives MDDI Data to a logic zero state 50 usec, and then sends a sub-frame header packet Activate forward link traffic. Usually, this can provide sufficient setting time between signals to resolve the bus contention problem before transmitting the sub-frame header packet.

When the user side, here is the display, needs data or communication from the host, the user side will drive the MDDI Data0 line to be in a logic state about 70 usec, but can still use other time lengths as needed, and then put the line in a high impedance state to disable the driver. This action causes the host to start or restart data traffic on the forward link (208) and poll the client's status. The host must detect the existence of the request pulse within 50 μsec, and then start driving the MDDI Data0 at logic one 150 usec and at logic zero for 50 μsec. If the monitor detects that MDDI Data0 is in a logic one state more than 50 usec, the monitor will never send a service request pulse. The selection characteristics of the time length and tolerance of the time interval related to the sleep processing and the start sequence will be discussed in detail as follows.

An example of the processing steps of a typical service request event 3800 without contention is shown in FIG. 38. For convenience of explanation, each event is marked with letters A, B, C, D, E, F, and G. When the host sends a connection close packet to the client device, informing it that the connection will transition to a low-power sleep state, the process starts from point A. In the next step, the host enters the low-power sleep state by disabling the MDDI Data0 driver and setting the MDDI Stb driver to logic zero, as shown in point B. With the high impedance bias network, MDDI Data0 is driven to zero. After a period of time, by driving MDDI Data0 to logic one, the client sends a service request pulse to the host, as shown in point C. The host still uses a high-impedance bias network to declare zero, but the driver in the client forces the line to be a logic one. Within 50 μsec, the host discovers that the service requires a pulse, and declares MDDI Data0 as a logical one by enabling its driver, as shown in point D. Then the client no longer attempts to declare the service request pulse, and the client puts its driver in a high impedance state State, as shown in point E. The host drives MDDI Data0 at logic zero 50usec, as shown by point F, and starts to generate MDDI Stb in a logic zero manner consistent with MDDI Data0. After declaring MDDI Data0 as zero and driving MDDI Stb 50 usec, the host starts to send data on the forward link by sending a subframe header packet, as shown by point G.

A similar example is shown in Figure 39, where the service request is announced after the link restart sequence starts, and each event is also marked with the letters A, B, C, D, E, F, and G. This example represents the worst case, where the request pulse from the client is about to destroy the sub-frame header packet. When the host sends a connection close packet to the client device again, notifying it that the connection will transition to a low-power sleep state, the process starts from point A. In the next step, the host enters the low-power sleep state by disabling the MDDI Data0 driver and setting the MDDI Stb driver to logic zero, as shown in point B. As before, MDDI Data0 is driven to zero by the high impedance bias network. After a period of time, by driving MDDI Data0 to a logic 150 μsec, the host starts the connection restart sequence, as shown in point C. Before 50 μsec after the connection restart sequence starts the display, MDDI Data0 is also declared for a duration of 70 μsec, as shown in point D. The reason for the situation is that the display needs the service requested by the host, and the host has not been found to have started the connection restart sequence. Then the client no longer attempts to declare the service request pulse, and the client puts its driver in a high impedance state, as shown by point E. The host continues to drive MDDI Data0 as a logic one. The host drives MDDI Data0 at logic zero for 50 μsec, as shown by point F, and is in line with MDDI The consistent logic zero mode on Data0 starts to generate MDDI Stb. In the declaration of MDDI Data0 as After zero parallel drive MDDI Stb 50 usec, the host starts to send data on the forward link by sending a subframe header packet, as shown by point G.

<b>VI. Interface electronic specifications</b>

In an exemplary embodiment of the present invention, data with a "Non-Return-to-Zero" (NRZ) format is encoded using a data strobe signal or DATA-STB format to allow clock information to be embedded in the data And strobe signal. The clock can be restored without a complicated phase-locked loop circuit. The data is carried by a two-way differential link, which is generally realized by a cable, but other conductors, printed circuits, or transmission components can also be used, as described earlier. The strobe signal (STB) is carried by a unidirectional link, which is driven only by the host. Whenever there is a back-to-back state, 0 or 1, maintained on the same data line or signal, the strobe signal will switch value (0 or 1).

For example, an example of how a data sequence like bit "1110001011" is transmitted using DATA-STB encoding is shown in Figure 40. In FIG. 40, the DATA signal 4002 is the line at the top of the signal timing diagram, and the STB signal 4004 is the second line, and each timing sequence is aligned as necessary (the starting point is the same). After a period of time, when the state of the DATA line 4002 (signal) changes, the STB line 4004 (signal) will maintain the previous state. Therefore, the "1" state of the first DATA signal is the same as the "1" state of the first STB signal. 0" state (its starting value) is related. However, if or when the state or level of the DATA signal has not changed, in this example, the STB signal will switch to a relative state or "1", as in the case of Figure 40, DATA will provide another "1" value. In other words, there is always one and only one conversion per bit cycle between DATA and STB. Therefore, the STB signal switches again, this time when the DATA signal When maintained at "1", STB becomes "0", and when the DATA signal level becomes "0", STB remains at this level or value. When the DATA signal remains at "1", the STB signal switches to a relative state or in this example, "1", and so on. When the DATA signal changes or maintains the level or value, the principle is the same.

When these signals are received, an exclusive OR (XOR) operation is performed on the DATA and STB signals to generate a clock signal 4006, as shown at the bottom of the timing diagram, to compare data and strobe signals. An example of the circuit used to generate the DATA and STB output or signals of the input data on the host, and then recover or retrieve the DATA and STB signal data on the user side, is shown in Figure 41.

In FIG. 41, the transmission part 4100 is used to generate and transmit original DATA and STB signals through the intermediate signal path 4102, while the receiving part 4120 is used to receive signals and restore data. As shown in Figure 41, in order to transmit data from the host to the user, the DATA signal and the clock signal are input to two D-type positive and negative circuit elements 4104 and 4106 to drive the circuit. Then the two positive and negative circuit outputs (Q), using two differential line drivers 4108 and 4110 (voltage mode), are divided into differential signal groups MDDI Data0+, MDDI Data0- and MDDI Stb+, MDDI Stb-. The three-input mutually exclusive-NOR (XNOR) gate, circuit, or logic element 4112 is connected to receive the DATA and input of the flip-flop and generate an output, which provides the data input to the second flip-flop to generate MDDI Stb+ , MDDI Stb-signal. For convenience, a reversal bubble is placed in the XNOR gate to indicate that the Q output of the forwarder that is effectively reversed to produce a strobe.

In the receiving part 4120 of Figure 41, the MDDI Data0+, MDDI Data0- and MDDI Stb+, MDDI Stb- signals consist of two Differential line receivers 4122 and 4124 receive, which can produce a single output of the differential signal. Then, the output of the amplifier is input to the input of the mutually exclusive-OR (XOR) gate, circuit, or logic element 4126 of the two input terminals that generate the clock signal. The clock signal is used to drive the two D-type positive and negative circuits 4128 and 4130 that receive the delayed DATA signal. Through the delay element 4132, one of them (4128) generates the data "0" value, and the other (4130) generates the data" 1" value. This clock also has a different output from the XOR logic. Since the clock information is distributed between the DATA and STB lines, no signal conversion speed between states exceeds half of the clock rate. Since the clock is regenerated by the mutual exclusion-OR processing of DATA and STB signals, the amount of skew that the system can effectively tolerate between the input data and the clock is twice that of the clock signal directly transmitted through a single dedicated data line.

MDDI Data+, MDDI Data-, MDDI Stb+, and MDDI Stb- signals all operate in differential mode to improve the ability to avoid the negative effects of noise. The source end of any part of the differential signal path uses only half the impedance of the transmission signal cable or conductor. The source of MDDI Data+ and MDDI Data- is located at the host and client at the same time. Since only one of the two drives is active in a known time, there must be a source on the transmission link. The MDDI Stb+ and MDDI Stb- signals can only be driven by the host.

Drivers, receivers, and terminals used to transmit signals are shown in Figure 42 as part of the MDD interface of the present invention. The corresponding DC electronic specifications of MDDI Data and MDDI Stb are shown in Table VII. This example interface uses low voltage sensing, here is 200mV, with Power changes below 1 volt and lower power consumption.

<tables><img file="TW577208B_D0008.tif" /></tables>

The electrical parameters and characteristics of the differential line driver and line receiver are shown in Table VIII. In terms of function, the driver transfers the input logic level directly to the positive output, and transfers the opposite of the input to the negative output. The delay from input to output is very compatible with the differential circuit of different driving methods. In most implementations, the output voltage change is smaller than the input change to reduce power consumption and electromagnetic emission. Table VIII represents a minimum voltage change of approximately 0.8V. However, other values can be used, which are well known by experts in the industry, and the inventor considers a smaller value of 0.5 or 0.6V in some specific embodiments according to design constraints.

The differential line receiver has the same characteristics as the high-rate voltage comparator. In Figure 41, the input without bubbles is a positive input, and the input with bubbles is a negative input. If (V_input+)-(V_input-) Is greater than zero, and the output is a logic output. Another illustrated method is a differential amplifier, which has a very large (in fact infinite) magnification and limits the output level at logic 0 and 1 volt.

The delay deviation between different pairs should be reduced in order to operate the differential transmission system at the highest possible speed.

In FIG. 42, the host controller 4202 and the client or display controller 4204 transmit packets over a communication link 4206. The host controller uses three consecutive drivers 4210, 4212, and 4214 to receive the host DATA and STB signals to be transmitted, and provide the user-side data signals to be transmitted. The driver responsible for the DATA channel of the host uses the enable signal input to allow the start of the communication link only when it is transmitted from the host to the client. Since the STB signal is part of the data transmission, the driver (4212) does not need to use an additional enable signal. The output of each DATA and STB driver is connected to terminal impedance or resistors 4216a, 4216b, 4216c, and 4216d, respectively.

The terminating resistors 4216a and 4216b will also be used as resistors on the input of the client receiver 4220 to process the STB signal, while additional terminating resistors 4216e and 4216f will be on the input of the client data processing receiver 4222, and the resistors 4216c and 4216d, respectively In series. The sixth driver 4226 on the client controller is used to prepare data signals sent from the client to the host. The driver 4214 processes the data sent to the host through the terminating resistors 4216c and 4216d on the input end.

There are two additional resistors 4218a and 4218b located between the terminating resistor and the ground and voltage source 4220 to perform the sleep control discussed elsewhere. The voltage source is used to drive the transmission line to the high or low position discussed earlier Standards to manage the flow of information.

The above-mentioned drivers and resistors can be composed of separate components, or part of a specific function integrated circuit (ASIC), as a more cost-effective encoder or decoder solution.

It can be easily understood that the power is transmitted from the host device to the user end device, or the display, using MDDI Pwr and MDDL Gnd signals on a set of conductors. The MDDI Gnd part of the signal serves as the reference ground and power return path or signal for the display device. The MDDI Pwr signal is used as the power supply of the display device driven by the host device. In the example configuration, for low-power applications, the display device can be pulled up to 500 mA. The MDDI Pwr signal can be provided by a portable power source, including but not limited to a lithium battery or battery pack in the host device, and the voltage is 3.2 to 4.3 volts relative to the MDDI Gnd.

<b>VIII. Timing characteristics</b>

<b>A. Summary</b>

The client is used to protect services from the host, and the steps and signal levels for the host to provide such services are shown in Figure 43. In Figure 43, the first part of the signal shows that the connection closed packet sent from the host and the data line is driven to a logic zero state by a high-impedance bias circuit. The client display, or host, did not send any data, which made its drive disabled. During the connection closing packet, starting from the MDDI Stb becoming active, you can see the continuous strobe pulses of the MDDI Stb signal at the bottom of the figure. Once the packet is over, and the logic level is changed to zero when the host drive bias circuit and logic are zero, the MDDI Stb signal line also changes to the zero level. This represents the termination of the last signal transmission or service from the host, which can be used in the past. When it occurs, and it is included to show the stop of the previous service and the signal state before the service started. If necessary, an image signal can be sent to reset the communication link to an appropriate state, and there is no need to know the previous communication performed by the host device.

As shown in Figure 43, the signal output from the user terminal is initially set to a logic zero level. In other words, the user terminal output is at high impedance and the driver is disabled. When a service is requested, the client activates its driver and sends the service request to the host. This will take a period of time. Use t_serviceIndicates that the line is driven to a logic level during this period. Before the host detects the request, a period of time or may take some time, called t_host-detectAfter this period of time, the host responds with the link initiation sequence by driving the signal to a logic level. At this time, the client cancels the announcement request and disables the service request driver, so that the output line of the client returns to the zero logic level again. During this period, the MDDI Stb signal is at the logic zero level.

Host at t_restart-highDuring the period, the host data output is driven to the "1" level. After that, the host drive logic level is zero, and at t_restart-lowDuring this period, MDDI Stb is activated, after which the first forward traffic starts with a frame header packet, and then forward traffic packets are sent. At t_restart-lowDuring and subsequent frame header packets, the MDDI Stb signal is active.

Table VIII shows the representative time length of the different periods discussed above, and the relationship between the minimum and maximum data rates of the example, where:

<img file="TW577208B_D0009.tif" />

<tables><img file="TW577208B_D0010.tif" /></tables>

Experts in the industry will understand that the functions of the individual components shown in Figures 41 and 42 are well known, and that the functions of the components in Figure 42 are confirmed by the timing diagram of Figure 43. The details of the series terminal and the sleep resistor shown in FIG. 42 are omitted from FIG. 41, because this information is not needed when describing how to perform the data-strobe encoding and recover the clock from the encoded state.

<b>B. Data-strobe timing forward link</b>

The transfer characteristics of the output and transmission data from the host drive on the forward link are shown in Table IX. Table IX presents the desired minimum and maximum values in tabular form and the typical times when certain signal transitions occur. For example, the typical length of time that the data value (the output of "0" or "1") transitions from the beginning to the end, Take t_{tdd-(h.st-output)}The conversion period from Data0 to Data0 is t_tbit, And the minimum time is about t_tbit-0.5 nsec, the maximum time is about t_tbit+0.5 nsec. The relative distance between the transition on Data0, other data lines (DataX), and the strobe line (Stb), as shown in Figure 44, which shows the Data0 pair strobe, strobe pair, strobe The conversion of data0, Data0 to non-Data0, non-Data0 to non-Data0, non-Data0 to strobe, and strobe to non-Data0 conversion are expressed in the following ways: t_{tds-(host-output)}, T_{tss-(host-output)}, T_{tsd-(host-output)}, T_{tddx-(host-output)}, T_{tdxdx-(host-output)}, T_{tdxs-(host-output)}, And t_{tsdx-(host-output)}。

<tables><img file="TW577208B_D0011.tif" /></tables>The typical MDDI timing requirements of the client receiver input when the same signal transmits data on the forward link are shown in Table X. Since the same signal has been discussed (but time delayed), there is no need for a new chart to illustrate the signal characteristics or the meaning of individual titles, which can still be understood by experts in the industry.

<tables><img file="TW577208B_D0012.tif" /></tables>

Figures 45 and 46 illustrate the possible response delay when the host disables or enables the host driver. If the host forwards some packets, such as reverse link encapsulation packets or round-trip delay measurement packets, the host will deactivate after forwarding the required packets (such as the parameter CRC, strobe arrangement, and all zero packets shown in Figure 45) Line driver. However, as shown in Figure 45, the line state does not need to change from "0" to the desired higher value immediately. Although the above result can be achieved by some control or circuit components, in fact, it only needs a section of "host driver". Disable delay" time to respond. In fact, this can happen immediately. It only takes 0 billionths of a second (nsec.). The more likely time is to extend by 10 nsec. If the maximum time length is desired, it should be during the guard time 1 or turn to 1 packet period. happen.

Please refer to Figure 46, you can see that when the host driver is enabled to transmit packets such as reverse link encapsulation packets or round-trip delay measurement packets, the signal level will change. Here, after the guard time 2 or turn to 2 packet period, the host driver is enabled and starts to drive the level, here is "0", after a period of host driver enable delay period can approach or reach this value, this result is transmitted NS Occurs during the reactivation of the drive before a packet.

The driver will have a similar process, and the client device (here, the display) will have a similar signal transmission. The typical length of this period and the relationship between them are shown in Table XI.

<tables><img file="TW577208B_D0013.tif" /></tables>

<b>C. Data-strobe timing reverse link</b>

The data and strobe signals are used to output the transfer characteristics and timing relationships of the transmitted data from the client driver in the reverse connection, as shown in Figs. 47 and 48. The typical time for some signal transitions will be discussed below. Figure 47 illustrates the relationship between the timing of the transmitted data and the leading and trailing edges of the strobe pulse in the host receiver input. That is, the set time of the rising or leading edge of the strobe signal is marked as t_su-sr, And the trailing or falling edge of the strobe signal is marked as t_su-sf. The standard length of time for these setting periods is 8 billionths of a second.

Figure 48 illustrates the transfer characteristics developed by the reverse data timing and the corresponding user-side output delay. In Figure 48, you can see the relationship between the timing of the transmitted data and the leading and trailing edges of the strobe pulse caused by the induced delay. That is, the propagation delay between the rising or leading edge of the strobe signal and the data is marked as t_pd-sr, And the propagation delay between the subsequent or falling edge of the data and strobe signal is denoted as t_pd-sf. The standard length of time for these propagation delay periods is 8 billionths One second.

<b>VIII. Realization of connection control (operation of connection controller)</b>

<b></b>

The packet distribution speed transmitted on the MDDI link is quite fast, usually at a speed of over 300 Mbps, but a lower speed can still be used if necessary. The speed of this type of bus or transmission link is too large to be controlled by general microprocessors or similar products for current commercial use (in terms of economic efficiency). Therefore, the actual method to accomplish this type of signal transmission is to use a programmable state machine to analyze the input packet stream to generate transmittable packets or redirect the packets to the desired appropriate audio-visual subsystem.

General-purpose controllers, processors, or processing elements can be used in more appropriate places, or used to manipulate slower information, such as control or status packets. When receiving these packets (control, status, or other predefined packets), the state machine will send them to the general-purpose processor through buffers or similar processing elements, so that the packets can provide the desired results (effects) , And the audio and video packets are sent to the appropriate destination at the same time.

The function of a general-purpose processor can be realized by processing power in some specific embodiments, or by a microprocessor (CPU), or a processor, a digital signal processor (DSP), or a wireless Excessive loops of ASICs that can be found in equipment, some modems or graphics processors use the processing power of the computer's CPU in a fairly similar way to perform functions and reduce hardware complexity and cost. However, this has a negative impact on the processing speed, timing, or overall operations of such components. Therefore, in many applications, dedicated circuits or components, it is more desirable to use general processing methods.

In order to be able to view the image data on the display (microdisplay), or to reliably receive all the packets sent by the host, the display signal processing must be synchronized with the timing of the forward link channel. In other words, the signals arriving at the display and the display circuit must be synchronized in time for correct signal processing. The high-level state diagrams that can be achieved by the signal processing steps or methods to achieve this type of synchronization are shown in the diagram in Figure 49. In Figure 49, the possible forward link synchronization "states" of the state machine 4900 shown are divided into an asynchronous frame state 4904, two synchronized states 4902 and 4906, and three synchronized states 4908, 4910, and 4912.

As shown in the start step or state 4902, the display starts in the pre-selected "no synchronization" state and searches for the unique word in the first sub-frame header packet detected. It should be noted that this "no synchronization" state means that the most basic communication settings or the "return" settings of the Type I interface have been selected. If a unique word is found during the search, the display will store the sub-frame length field. The CRC bit will not be checked when processing this first frame, or it will not be checked until synchronization is obtained. If the length of this sub-frame is zero, the synchronization state processing will continue according to this method to the "non-synchronization frame" state marked here as state 4904, which indicates that synchronization has not yet been reached. In Figure 49, this processing step is labeled as cond3 or condition 3 is encountered. Otherwise, if the frame length is greater than zero, the synchronization state processing will continue to state 4906, where the interface state is set to "find a synchronization frame". In Figure 49, this processing step is marked as cond5 or condition 5 encountered. In addition, if the state machine sees the frame header packet and determines that there is a good CRC because the frame length is greater than zero, the processing continues to the "find a synchronization frame" state. In Figure 49, this is marked as cond6 or condition 6.

In one case, if the system is in a state other than "no synchronization", when a unique word is detected and the sub-frame header packet is determined to be a good CRC result, and the sub-frame length is greater than zero, the interface state is changed to " Synchronizing" status 4908. In Figure 49, this processing step is labeled as cond 1 or condition 1 is encountered. On the other hand, if the unique word or the CRC in the subframe header packet is not correct, the synchronization state processing will continue or return to the interface state 4902 of the "no synchronization frame" state. In the state diagram of Figure 49, this processing part is marked as cond2 or condition 2 encountered.

<b>B. Get synchronized time</b>

The interface can be configured to accept a certain number of "synchronization errors" before deciding that the synchronization is lost and returning to the "no synchronization frame" state. In Figure 49, once the state machine reaches the "synchronizing state" and cannot find any errors, it will continue to encounter the cond 1 result and remain in the "synchronizing" state. However, once a cond 2 result is detected, the process will change the status to "a synchronization error" status 4910. At this point, if the processing results in another cond 1 result being detected, the state machine will return to the "synchronizing" state, otherwise, it will encounter another cond 2 result and move to the "two synchronization errors" state 4912 . Once again, if cond 1 occurs, processing will bring the state machine back to the "synchronizing" state. Otherwise, another cond2 will be encountered, and the processing will bring the state machine back to the "unsynchronized" state. It is also obvious that if a "connection closed packet" is encountered, the connection will terminate the data transmission and return to the "unsynchronized frame" state, just like there is no syncable object. This refers to the encounter of cond4, or status 4. , As shown in the state diagram in Figure 49.

It can be understood that the unique word may have repeated "fake copies", which may appear in certain fixed positions in the sub-frame. In this case, the state machine will be extremely unlikely to synchronize with the sub-frame, because the CRC processing on the header packet of the sub-frame must also be valid before the MDD interface processing can continue to the "synchronizing" state.

The length of the sub-frame in the sub-frame header packet can be set to zero to indicate that the host can only send one sub-frame before closing the link, and the MDD interface is in or configured in an idle sleep state. In this example, after the display detects the sub-frame header packet, it must immediately receive the packet on the forward link, because only one sub-frame was sent before the link turned into an idle state. In normal or typical operations, the sub-frame length is non-zero and the display only processes forward link packets. The interfaces in these states are shown as the "synchronizing" state in Figure 49 as a whole.

The time required for the display to synchronize with the forward link signal will vary with the size of the sub-frame and the forward link data rate. When the sub-frame is large, it is more likely to detect the "fake copy" of the unique word as random or more random data in the forward link. At the same time, the ability to recover from false detections is low, and because the rate of forward connection is slower, it takes longer to do so.

<b>C. Initialization</b>

As mentioned earlier, at the "initial" time, the host configures the forward link to operate at a data rate of 1 Mbps that is basically required or lower than the basic required data rate, and configures the sub-frame according to known applications Length and media frame rate. In other words, both forward and reverse connections use the Type-I interface to start operations. Decide users on the host Before the end display function or the required configuration, usually these parameters are only for temporary use. The host sends or transmits the sub-frame header packet through the forward link, and then the reverse link encapsulates the packet. The packet causes the bit "0" of the request flag to be set to the value one (1) to request the display to respond with "display Function package". Once the display is synchronized on the forward link (or with the forward link), it will send display function packets and display request and status packets via the reverse link or channel.

The host checks the contents of the display function packet to determine how to reconfigure the best or required performance. The host checks the protocol version and minimum protocol version fields to confirm that the host and display use their mutually compatible protocol versions. The protocol version remains the first two parameters of the display function package. Therefore, even if the other items of the protocol may be incompatible or deemed not completely compatible, the compatibility can still be determined.

<b>D. CRC processing</b>

For all packet types, the packet processor state machine ensures that the CRC checker is properly and correctly controlled. When more than one error is detected due to CRC comparison, it will also accumulate the CRC error counter, and reset the CRC counter at the beginning of each sub-frame processing.

<b>IX. Packet processing</b>

For the aforementioned various packets received by the state machine, the packets will take a specific processing step or a series of steps to implement interface operations. Forward connection packets are usually processed according to the example process listed in XII below.

<tables><img file="TW577208B_D0014.tif" /></tables><tables><img file="TW577208B_D0015.tif" /></tables>

<b>X. Reduce backlink data rate</b>

The inventors of the present invention have observed that certain parameters used for the host link controller can be adjusted or configured in a certain way in order to achieve the maximum or more optimal This is a very necessary function for the conversion (degree) of the reverse link data rate. For example, during the reverse data packet field used to transmit the reverse link encapsulation packet, the MDDI Stb signal pair is switched to create a cyclic data clock with only half the forward link data rate. The reason for this result is that the MDDI Stb signal generated by the host connected to the controller is equivalent to the MDDI Data0 signal, as if it transmits all zeros. The MDDI Stb signal is transferred from the host to the display to generate a clock signal for transmitting reverse link data from the display, and thereby transmit the reverse data back to the host. The number of delays that a system that implements MDDI usually encounters when transmitting and processing signals on the forward and reverse paths is shown in Figure 50. In the left figure 50, 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 displayed near the processing area, respectively for Stb+ /-Generation, cable transmission-to-display, display receiver, clock generation, signal clock, Data0+/- generation, cable transmission-to-host, and host receiver stages.

Depending on the forward link data rate and signal processing delay encountered, the MDDI Stb signal may take more than one cycle to achieve this "round trip" effect or complete the event set, which will waste unnecessary time or cycles. To avoid this problem, the reverse rate divisor can extend the MDDI Stb signal of multiple cycles on the reverse link with one bit time. This means that the reverse link data rate will be lower than the forward link rate.

It should be noted that the actual signal delay length using this interface will vary depending on the specific host-client system or hardware used. By using the round-trip delay to measure packets, the actual delay in the system is measured, and each system communicates It can often perform better, so that the reverse rate divisor can be set to an optimal value.

The round-trip delay measurement method is to enable the host to send a round-trip delay measurement packet to the display. The display responds to this packet by sending the packet sequence back to the host within or during the pre-selected measurement window in the measurement period field. The detailed timing of this measurement has been explained before. The round-trip delay is used to determine the rate at which reverse link data can be safely sampled.

The round-trip delay measurement includes determination, detection, or calculation. When a response sequence of 0xff, 0xff, 0x00 from the display back to the host is received, it occurs when the forward link data between the start of the measurement period field and the start of the time period is received Number of pulse intervals. It should be noted that before the measurement count is accumulated, the response received from the display may be a small part of the clock cycle of the forward link. If this unmodified value is used to calculate the reverse rate divisor, it will cause bit errors in the reverse link due to unreliable data sampling. An example of this situation is shown in Figure 51, where the signals representing the host MDDI Data, the host MDDI Stb, the forward link data clock in the host, and the delay count are all drawn as graphics. In Figure 51, before the delay count is increased from 6 to 7, the response sequence received from the display is part of the forward link clock cycle. If the delay is assumed to be 6, the host must sample the reverse data after or possibly during the bit conversion. This may cause incorrect sampling of the host. For this reason, the measured delay must be used to divide by the reverse rate divisor before adding one.

The reverse rate divisor is the number of MDDI Stb cycles that the host should wait before sampling reverse link data. Since the MDDI Stb cycle rate is half of the forward link rate, the corrected round-trip delay measurement needs to be divided by 2 and then four. Round to the next whole number. The relationship is expressed by the formula as follows: reverse_rate_divisor=RoundUpToNextlnteger<img file="TW577208B_D0016.tif" />

For this example, the result: reverse_rate_divisor=RoundUpToNextlnteger<img file="TW577208B_D0017.tif" />

If the round-trip delay measurement used in this example is 7 instead of 6, the reverse rate divisor is also equal to 4.

The host samples the reverse link data on the rising edge of the reverse link clock. Both the host and the client (display) have counters or similar known circuits or devices to generate the reverse link clock. The counter is initialized so that the first rising edge of the reverse link clock appears at the very first bit in the reverse link packet field of the reverse link encapsulated packet. Examples are provided below, as shown in Figure 52. The counter is accumulated at each rising edge of the MDDI Stb signal, and the reverse rate divisor parameter in the reverse connection encapsulated packet is set to count until all bits are covered. Since the MDDI Stb signal is switched at half of the forward link rate, the reverse link rate is 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 The divisor is 4, and the reverse link data rate is as follows:

<img file="TW577208B_D0018.tif" />

An example showing the timing of the MDDI Data0 and MDDI Stb signal lines in the reverse connection encapsulation packet is shown in Figure 52. The packet parameters used for explanation have the following values:

<img file="TW577208B_D0019.tif" />

The strobe arrangement is 0x00, 0x00, 0x60

The packet data between the packet length and the parameter CRC field is:

0x00, 0x04, 0x41, 0x00, 0x02, 0x01, 0x01, 0x43, 0xdb, 0x00, 0x00, 0x60, 0x00,...

The first reverse link packet returned from the display is the display request and status packet, the packet length is 7 and the packet type is 70. This packet starts with byte values 0x07, 0x00, 0x46, etc. However, only the first byte (0x07) is shown in Figure 52. In this figure, the time variation of the first reverse link packet is about one reverse link clock cycle, which is used to illustrate the actual reverse link delay. Ideally, the waveform whose round-trip delay between the host and the display is zero is shown in dotted lines.

The MS byte of the parameter CRC field is transmitted immediately after the strobe array byte, and then all zero fields are transmitted. When the data from the host changes to form a wider pulse level, the strobe from the host will switch from one to zero and back to one. When the data is zero, the strobe is converted at a higher speed, and only the data on the data line changes, which will result in a change near the end of the array field. Since the data signal during the extended period has a fixed 0 or 1 level, and the transition falls on the pulse pattern (edge), in the other parts of the figure, the strobe is converted at a higher speed.

When the clock starts to carry reverse link packets, the host's reverse link clock remains at zero until the end of the turnaround 1 period. The arrow in the lower half of the figure indicates when the data will be sampled, which is obvious from the rest of the description of this patent specification see. The first byte of the transmitted packet field (here, 11000000) is displayed after turning to 1, and since the host driver is disabled, the line level remains stable. The first bit, here is the channel delay of bit three, is shown in the dashed line of the data signal.

In Figure 53, you can see the representative value of the reverse rate divisor based on the forward link data rate. The actual reverse rate divisor is determined as the result of the round-trip connection measurement to ensure proper reverse connection operation. The first area 5302 is equivalent to the safe operation range, the second area 5304 is equivalent to the marginal efficiency range, and the third area 5306 indicates settings that cannot operate correctly.

When operating with any interface type setting on the forward or reverse link, the round-trip delay measurement is the same as the reverse rate divisor setting, because the forward or reverse link is expressed or operated in units of actual clock cycles , Instead of representing or operating in terms of the number of bits transmitted or received.

<b>XI. Turn and guard time</b>

As discussed before, the turn 1 field in the reverse link encapsulation packet and the guard time 1 field in the round-trip delay measurement packet both specify the length of time that the host interface driver is allowed to be disabled before the display interface driver is enabled. . The Steering 2 and Guard Time 2 fields provide time values that allow the display driver to be disabled before the host driver is enabled. The protection time 1 and protection time 2 fields are usually filled with preset or pre-selected length values that will not be deliberately adjusted. Depending on the interface hardware used, these values will be developed based on empirical data and adjusted with some examples to improve the operation.

Some of the factors that help determine the length of the turn 1 are the forward link data rate and the maximum MDDI Data drive deactivation time in the host. Maximum host drive The deactivation time is shown in Table XI, which shows that it takes about 10 nsec maximum time to deactivate the driver, and it takes about 2 nsec to activate. The maximum number of clocks required to disable the forward link of the host drive is shown in the following relationship:

<img file="TW577208B_D0020.tif" />

According to the relationship, the allowable value range of Turn 1 is:

<img file="TW577208B_D0021.tif" />

The interface type factor is 1 for Type-I, 2 for Type-II, 4 for Type-III, and 8 for Type-IV.

Combining the above two equations, it can be seen that the interface type factor term is eliminated, and turn 1 is defined as:

<img file="TW577208B_D0022.tif" />

For example, a 1500 Mbps Type-III forward link can use the following turnaround 1 delay:

<img file="TW577208B_D0023.tif" />Byte. When the round-trip delay increases, the timing margin improves from the point in time when the host is disabled to the point in time when the display is enabled.

The factors used to determine the length of time for turn 2 are generally the forward link data rate, the maximum deactivation time of the MDDI Data driver in the display, and the round-trip delay of the communication link. The time required to deactivate the display driver is essentially the same as the above The host drives discussed are the same and defined according to the following relationship:

<img file="TW577208B_D0024.tif" />The allowable values for Turn 2 are as follows:

<img file="TW577208B_D0025.tif" />

For example, a 1500 Mbps Type-III forward link that uses a 10 forward link clock round trip delay usually uses a turnaround 2 delay:

<img file="TW577208B_D0026.tif" />

<b>XII. Physical layer interconnection description</b>

According to the present invention, the physical connection layer used to realize the interface can be realized by using commercial components. For example, the host side can use the part number 3260-8S2 (01) produced by Hirose Electric Company Ltd. The display device side You can use the part number 3240-8P-C. Type-I interface pin arrangement produced by Hirose Electronics Company or use the "pin characteristics" of this Type-I interface connector as shown in Table XIII.

<tables><img file="TW577208B_D0027.tif" /></tables>

The selection of internal components or devices or their design must be small enough to be used in mobile communication and computing devices, such as PDAs and wireless phones, or portable gaming devices, and should not be obtrusive or lacking in aesthetics when compared with the size of related devices. Any connector and wiring should be durable enough to be used in a typical user environment, and should have a small size, especially the wiring part, and the price should be low. The transmission component should allow data and strobe signals of different NRZ data. The transmission rate for Type I and Type II can reach approximately 450 Mbps, and the transmission rate of the 8-bit parallel Type IV version can reach 3.6 Gbps.

<b>XIII. Homework</b>

A summary of the general steps taken to process data and packets using the interface of the present invention is shown in Figures 54a and 54b. In these figures, the process starts with deciding whether the client and the host are connected using a communication path (here, a cable). This can be achieved by regular polling, software or hardware, to detect the presence of a connector or cable on the input of the host, or by other known techniques. If the host is not connected to any client, it will enter a waiting state of a predetermined length, or enter a sleep mode, or cancel the startup to wait for future use.

Once the client is connected to the host, and vice versa, the client or host will send appropriate packets to request services. Then the host sends a packet of the request message, which depends on the function of the client, and the client sends a display function containing the information. Can package to the host. The host and the client also negotiate the type of service mode (rate/speed) used, such as Type I, Type U, Type II, etc. Once the service type is established, the host can start sending information.

As mentioned earlier, all transmissions that start with a subframe header packet are followed by data types, which include video and audio stream packets, and padding packets; or commands and information, here are color correspondence and bit Lock transmission or other packets. In addition, the host and the client can use appropriate packets to exchange data related to the keyboard or pointing device.

During the operation, it may be desirable to exchange the mode, which can be accomplished by exchanging the appropriate interface type delivery request, type confirmation, and execution type delivery packet.

After the data and commands are exchanged between the host and the client, at a certain point, it will be decided whether to send additional data, or whether the link is going to sleep or shut down completely. If you want to terminate the connection, the host will send a connection close packet to the client, and both ends will terminate the data transmission at the same time.

<b>IX. Appendix</b>

In addition to the above discussion on the format, structure, and content of different packets that implement the structure and protocol of the specific embodiment of the present invention, more detailed field content or operations of some packet types are presented here. Here we need to further clarify its individual uses or operations, so that experts in the industry can understand more easily, and will use the present invention for various applications. There are only some undiscussed fields, which will be discussed further here.

<b>A. Used for image stream packet</b>

The display attribute field (1 byte) has a series of bit values, as follows bright. Bits 1 and 0 select how to deliver display pixel data. When the bit value is "00" or "11", the data is displayed to both eyes, when the bit value is "10", the data is only delivered to the left eye, when the bit value is "01", the data is only delivered to the right eye . Bit 2 indicates whether the pixel data is presented in an interlaced format. The value "0" indicates that the pixel data is in a standard progressive format, and when advancing from one row to the next, the number of rows (pixel Y-axis) accumulates by 1. When the bit value is "1", the pixel data is in an interlaced format, and when advancing from one row to the next, the number of rows accumulates by 2. Bit 3 indicates that the pixel data is in an interactive pixel format. This is similar to the standard interlace mode enabled by bit 2, but the interlace method is vertical rather than horizontal. When bit 3 is 0, the pixel data is in a standard progressive format, and when each sequence of pixels is received, the number of columns (pixel X axis) accumulates by 1. When bit 3 is 1, the pixel data is in an interactive pixel format, and when each pixel is received, the number of columns is accumulated by 2. Bits 7 to 4 are reserved for future use and are generally set to zero.

The 2-byte X starting point and Y starting point fields specify the absolute X and Y coordinates of the first pixel point (X starting point, Y starting point) in the pixel data field. 2-byte X right edge and Y top edge fields specify the pixel data field to fill in the X coordinate of the left edge and the Y coordinate of the top edge of the screen window. At the same time, the X right edge and Y bottom edge fields are specified and updated The X coordinate of the right edge and the Y coordinate of the bottom edge of the window.

The pixel count field (2 bytes) specifies the number of pixels in the following pixel data field.

The parameter CRC field (2 bytes) contains the CRC of all the bytes from the packet length to the pixel count. If the CRC cannot be checked, the entire packet will be discarded.

The pixel data field contains the original image information to be displayed, and uses the image Format the data in the method described in the data format description sub-field. As discussed elsewhere, send a "line" of data at the same time.

The pixel data CRC field (2 bytes) contains a 16-bit CRC with only pixel data. If the CRC confirmation of this value fails, the pixel data can still be used, but the CRC error count will be accumulated.

<b>B. Used for audio streaming packets</b>

The sound effect channel ID field (1 byte) can identify a specific sound effect channel, and the client device will send the sound effect data to this channel. The physical sound effect channel value specified or corresponding to this field is 0, 1, 2, 3, 4, 5, 6, or 7, indicating the left front, right front, left rear, right rear, front center, subwoofer, surround, respectively Left and surround right channels. The sound effect channel ID value 254 indicates that the signal stream of the digital sound effect samples is sent to the front left and front right channels at the same time. This makes it easier to use stereo headsets for voice communications and PDA production, or for simple user interfaces to generate warning sounds and other applications. The ID field values from 8 to 253 and 255 are currently reserved for additional designation in new designs.

The sound effect sample count field (2 bytes) specifies the number of sound effect samples in this packet.

Each sample bit and package field contains 1 byte that can specify the audio data package format. The generally adopted format is bits 4 to 0 to define the number of bits for each PCM audio sample. Bit 5 specifies whether the digital audio data sample is encapsulated. As mentioned above, Figure 12 illustrates the difference between packing and byte arrangement sound effect samples. Bit 5 of "0" means that each PCM sound effect sample in the digital sound data field is aligned with the interface byte boundary byte, and "1" means that each successive PCM sound effect sample corresponds to the previous sound effect sample. Package. Only in position This bit is valid only when the value defined in element 4 to 0 (the number of bits per PCM sound effect sample) is not a multiple of eight. Bits 7 to 6 are reserved for systems that require additional designation, and are generally set to zero.

The audio effect sampling rate field (1 byte) specifies the audio PCM sample rate. When the format value used is 0, it indicates that the rate is 8,000 samples per second (sps), when the value is 1, it indicates 16,000 sps, when the value is 2 it indicates 24,000 sps, when the value is 3 it indicates 32,000 sps, and when it is 4 it indicates 40,000 sps. , A value of 5 indicates 48,000 sps, a value of 6 indicates 11,025 sps, a value of 7 indicates 22,050 sps, and a value of 8 indicates 44,100 sps, values 9 to 15 are reserved for future use, so it is currently set to zero.

The parameter CRC field (2 bytes) contains the 16-bit CRC of all bytes from the packet length to the audio sampling rate. If this CRC cannot be checked correctly, the entire packet will be discarded. The digital sound effect data field contains the original sound effect samples to be played, usually in a linear format like an unsigned integer. The audio data CRC field (2 bytes) contains 16-bit CRC of audio data only. If the CRC cannot be checked, the audio data can still be used, but the CRC error count will be accumulated.

<b>C. Used for user-defined stream packets</b>

The 2-byte stream ID number field is used to identify a specific video stream. The content of the streaming parameters and streaming data fields are defined by the MDDI device manufacturer. The 2-byte stream parameter CRC field contains the 16-bit CRC of all the bytes of the stream parameter from the packet length to the audio effect encoding byte. If the CRC cannot be checked, the entire packet will be discarded. The 2-byte stream data CRC field contains only the CRC of the stream material. If this CRC cannot be Check, according to the different needs of the application, the use of streaming data is optional. To use the streaming data under the condition that the CRC is good, it is generally necessary to put the streaming data in the buffer until it is confirmed that the CRC is good. If the CRC is not checked, the CRC error count is accumulated.

<b>D. For color matching packets</b>

The color corresponding data size field (2 bytes) specifies the total number of color corresponding table items of the color corresponding data in this packet. The number of bytes in the color corresponding data is 3 times the size of the color corresponding. If the color mapping size is set to zero, no color mapping data will be sent. If the color corresponding size is zero, the color corresponding offset value is still transmitted, and the display will ignore the value. The color corresponding offset field (2 bytes) specifies the offset of the color corresponding data in this packet starting from the color corresponding table in the display device.

The 2-byte parameter CRC field contains the CRC of all the bytes from the packet length to the audio code byte. If the CRC cannot be checked, the entire packet will be discarded.

For the color corresponding data field, each color corresponding position is a 3-byte group, where the first byte specifies the intensity of blue, the second byte specifies the intensity of green, and the third byte specifies the intensity of red . The color correspondence size field specifies the number of 3-byte color correspondence table items that exist in the color correspondence data field. If a single color mapping cannot be applied to an image data format and color mapping packet, the entire color mapping can be specified by transmitting multiple packets with different color mapping data and color mapping offsets in each packet.

2-byte color corresponding data CRC field contains only color corresponding data CRC. If the CRC cannot be checked, the color mapping can still be used, but the CRC error count will be accumulated.

<b>E. Used for reverse link encapsulation packets</b>

The reverse link flag field (1 byte) contains a set of flags requesting display information. If the bit (bit 0 here) is set to one, the host will use the display function packet to request the specified display information. If the bit is zero, the host does not need display information. The remaining bits (bits 1 to 7 here) are reserved for future use and set to zero.

The reverse rate divisor field (1 byte) specifies the number of MDDI Stb cycles that occur due to the reverse link data clock. The reverse link data clock is equal to the forward link data divided by twice the reverse rate divisor. The reverse link data rate is related to the reverse link data clock and interface type on the reverse link. For Type I interfaces, the reverse data rate is equal to the reverse link data clock. For Type II, Type III, and Type IV interfaces, the reverse data rate is equal to twice, four times, and eight times the reverse Link data clock.

The Turn 1 Length field (l byte) specifies the total number of bytes allocated to Turn 1. The recommended length of Turn 1 is the number of bytes required by the MDDI Data driver in the host to disable the output. This is based on the above-discussed output disable time, forward link data rate, and the choice of forward link interface type used. The above also provides a more detailed description of the steering 1 setting.

The Turn 2 Length field (1 byte) specifies the total number of bytes allocated to Turn 1. The recommended length of Turn 2 is the number of bytes required by the MDDI Data driver in the display to disable the output and the round-trip delay. The above also provides instructions for steering 2 setting.

The parameter CRC field (2 bytes) contains the 16-bit CRC of all bytes from the packet length to the turn length. If the CRC cannot be checked, the entire packet will be discarded.

The value contained in the strobe array field (3 bytes) will cause the MDDI Stb signal of the bit boundary between the last bit of all zero fields and the first bit of the reverse data packet field to go from low Change to high. This ensures that the MDDI Stb signal and the byte boundary in the reverse data packet field have a consistent operation mode.

The all zero field (1 byte) is set equal to zero, and is used to ensure that all MDDI Data signals are in the zero state before the line driver is disabled during the first guard time.

The steering column is used to establish the first steering cycle. The number of bytes specified by the steering length parameter is allocated by this field to allow the MDDI Data line driver in the host to be disabled before the line driver in the user terminal (display) is enabled. The host disables its MDD1 Data line driver during the turn to 1 bit 0, and the user end (display) immediately activates its line driver after turning to the last bit of 1 bit. The MDDI Stb signal works as if the steering cycle is all zero.

The reverse data packet field contains a series of data packets sent from the client to the host. As mentioned earlier, the filled packet sent will fill the remaining space not used by other packet types.

The Turn 2 field is used to establish the second turn cycle. The number of bytes specified by the steering length parameter is allocated by this field.

The drive re-enable field uses 1 byte equal to zero to ensure that all The MDDI Data signal will be re-enabled before the packet length field of the next packet.

<b>F. Used to display function packets</b>

The protocol version field uses 2 bytes to specify the protocol version used by the client. The initial version setting is equal to zero, and the minimum protocol version field uses 2 bytes to specify the minimum protocol version that can be used or interpreted by the client. The display data rate function field (2 bytes) specifies the maximum data rate that the monitor can receive on the forward link of the interface, and is specified in megabits per second (Mbps) format. The interface type function field (1 byte) specifies the interface types supported on forward and reverse links. Currently by selecting bit 0, bit 1, or bit 2 to select the Type-II, Type-III or Type-IV mode on the forward link, and bit 3, bit 4, or bit 5 to select the negative Type-II, Type-III, or Type-IV mode on the link; bits 6 and 7 are reserved and set to zero. The bitmap width and height fields (2 bytes) specify the width and height of the bitmap in the pixel.

The monochrome function field (1 byte) is used to specify the number of resolution bits displayed in monochrome format. If the monitor cannot use the monochrome format, this value is set to zero. Bits 7 to 4 are reserved for future use, so they are set to zero. Bits 3 to 0 define the maximum number of grayscale bits that exist in each pixel. These four bits can specify the value of 1 to 15 for each pixel. If the value is zero, the monitor does not support the monochrome format.

The color function field (3 bytes) specifies the maximum number of table items that exist in the display color correspondence table. If the display cannot use the color mapping format, this value is zero.

The RGB function field (2 bytes) specifies the number of resolution bits displayed in RGB format. If the monitor cannot use the RGB format, this value is zero. The RGB function word includes three unsigned values: bits 3 to 0 define the maximum number of blue bits, bits 7 to 4 define the maximum number of green bits, and bits 11 to 8 define the maximum number of red bits in each pixel. Yuan number. Currently, bits 15 to 12 are reserved for future use and are generally set to zero.

The Y Cr Cb function field (2 bytes) specifies the number of resolution bits displayed in Y Cr Cb format. If the display cannot use the Y Cr Cb format, this value is zero. The Y Cr Cb function word includes three unsigned values: Bits 3 to 0 define the maximum number of Cb samples, bits 7 to 4 define the maximum number of Cr samples, and bits 11 to 8 define the maximum number of Y samples. Number, bits 15 to 12 are currently reserved for future use and set to zero.

Display features The function indicator field uses 4 bytes to contain a set of flags, which can indicate the features supported by the display. The bit is set to one to indicate the supported function, and set to zero to indicate the unsupported function. The value of bit 0 indicates whether to support bitmap block transmission of packets (packet type 71). The values of bits 1, 2, and 3 respectively indicate whether to support the dot pattern area to fill the packet (packet type 72), the dot pattern to fill the packet (packet type 73), or the communication link data channel packet (packet type 74). The value of bit 4 indicates whether the display can make the color transparent, the values of bit 5 and 6 respectively indicate whether the display accepts image data or sound effect data in encapsulated format, and the bit 7 indicates whether the display can send the reverse link image stream of the camera. Bits 11 and 12 respectively indicate that when the client communicates with the pointing device, it can send and receive the pointing device data packet, or when it communicates with the keyboard, it can send and receive the keyboard data packet. Bits 13 to 31 are currently reserved for future use or for system The system designer makes a special designation, and it is generally set to zero.

The display video frame rate function field (1 byte) specifies the maximum video frame update function of the display in the frame per second. The host can choose to update the image at a slower rate than the value specified in this field.

The sound buffer depth field (2 bytes) specifies the depth of the flexible buffer for each sound effect stream in the display.

The audio channel function field (2 bytes) contains a set of flags to indicate the audio channel supported by the monitor. The bit is set to a supported channel, and the bit is set to zero to indicate an unsupported channel. The different channels specified by the bit positions are bit positions 0, 1, 2, 3, 4, 5, 6, and 7, which indicate front left, front right, rear left, rear right, center front, subwoofer, surround left, respectively , And surround the right channel. Bits 8 to 15 are currently reserved for future use, and are generally set to zero.

The 2-byte audio sampling rate function field, used for forward connection, contains a set of flags to indicate the audio sampling rate function of the client device. The different rates specified for bit positions are in order: bits 0, 1, 2, 3, 4, 5, 6, 7, and 8 are specified as 8,000, 16,000, 24,000, 32,000, 40,000, 48,000, 11,025 per second, respectively , 22,050, and 44,100 samples (SPS), and bits 9 to 15 are reserved for future replacement, so they are currently set to "0". Setting one of these bits to "1" indicates that a specific sample rate is supported, and setting a bit to "0" indicates an unsupported sample rate.

The minimum sub-frame rate field (2 bytes) indicates the minimum sub-frame rate per second. The minimum sub-frame rate enables the display status update rate to be sufficient to read the pointing device in some sensors or displays.

The 2-byte microphone sampling rate function field, used for reverse connection, contains a set of flags to indicate the audio sampling rate function of the microphone in the client device. For MDDI, the client device microphone is configured to basically support a rate of at least 8,000 samples per second. The different rates specified for the bit positions of this field are: 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 (SPS), and bits 9 to 15 are reserved for future replacement rates, so they are currently set to "0". Setting one of these bits to "1" indicates that a specific sample rate is supported, and setting a bit to "0" indicates an unsupported sample rate. If the microphone is not connected, the microphone sampling rate function bit is set to zero.

The content protection type field (2 bytes) contains a set of flags that indicate the type of digital content protection supported by the display. Currently, bit position 0 is used to indicate when to support DTCP, bit position 1 is used to indicate when to support HDCP, bit positions 2 to 15 are reserved for other protection mechanisms, and are currently set to zero.

<b>G. Packets used to display requirements and status</b>

The reverse link request field (3 bytes) specifies the number of bytes required for the display to send information back to the host in the next subframe of the reverse link.

The CRC error count field (1 byte) indicates the number of CRC errors that have occurred since the beginning of the media frame. When sending a sub-frame header packet with a sub-frame count of zero, the CRC count will be reset. If the actual number of CRC errors exceeds 255, this value is 255.

The function change field uses 1 byte to indicate the change of the display function. If the user connects peripheral devices, like microphones, keyboards, or monitors, or other Reason, this result will happen. When the bit [7:0] is equal to 0, the function after the last display function packet is not changed. However, when bits [7:0] are equal to 1 to 255, the function changes. Check the display function package to determine the new display function.

<b>H. Used for bit block transmission packet</b>

The X value and Y value fields of the upper left coordinate of the window use 2 bytes to indicate the X and Y values of the upper left coordinate of the moving window respectively. The window width and height fields use 2 bytes to indicate the width and height of the moving window. The window X movement and Y movement fields use 2 bytes to indicate the number of pixels to move the window vertically and horizontally, respectively. A positive value X moves the window to the right, a negative value X moves the window to the left, a positive value Y moves the window down, and a negative value Y moves it up.

<b>I. Used to fill in the packet in the bitmap area</b>

The X value and Y value fields of the upper-left coordinate of the window use 2 bytes, respectively indicating the X and Y values of the coordinate of the upper-left corner of the filled-in window. The window width and height fields (2 bytes) indicate the width and height of the filled window. The image data format description sub-field (2 bytes) indicates the format of the value filled in the pixel area. This format is the same as the field in the video stream packet, and its format is the same. The pixel area fill-in value field (4 bytes) contains the pixel value to be filled in the window specified by the discussion field above. The pixel format is specified in the image data format description subfield.

<b>J. Used to fill the packet with dot matrix pattern</b>

The X value and Y value fields of the upper left coordinate of the window use 2 bytes, respectively indicating the X and Y values to be filled in the upper left coordinate of the window. The window width and height fields (2 bytes each) indicate the width and height of the filled window. The pattern width and pattern height fields (each 2 bytes) indicate the width and height of the pattern to be filled in. The 2-byte image data format description sub-field indicates the format of the value filled in the pixel area. Figure 11 illustrates the encoding method of the video data format descriptor. This format is the same as the field in the video stream packet, and its format is the same.

The parameter CRC field (2 bytes) contains the CRC of all the bytes from the packet length to the image format descriptor. If the CRC cannot be checked, the entire packet will be discarded. The pattern pixel data field contains the original image information that fills the pattern with the specified format of the image data format descriptor. The data is encapsulated in bytes, and the first pixel in each row must be byte aligned. Simultaneously send a row of filled pattern data. The pattern pixel data CRC field (2 bytes) contains only the pattern pixel data CRC. If the CRC cannot be checked, the pattern pixel data can still be used, but the CRC error count will be accumulated.

<b>K. Communication link data channel packet</b>

The parameter CRC field (2 bytes) contains the 16-bit CRC of all the bytes from the packet length to the packet type. If the CRC cannot be checked, the entire packet will be discarded.

The communication link data field contains the original data of the communication channel. This data is only sent to the computing device of the display.

The communication link data CRC field (2 bytes) contains a 16-bit CRC of only the communication link data. If the CRC cannot be checked, the communication link data can still be used, but the CRC error count will be accumulated.

<b>L. Used for interface-based delivery request packets</b>

The interface type field (1 byte) specifies the new interface type to be used. The value in this field specifies the interface type in the following way. If the value in bit 7 is equal to 0, the type handover requirement is used for forward connection, if it is equal to 1, then the type handover Pass requests are used for reverse links. Bits 6 to 3 are reserved for future use and are generally set to zero. Bits 2 to 0 are used to define the type of interface used. When the value is 1, it means the handover in Type-I mode, when the value is 2, it means the handover in Type-II mode, and when the value is 3, it means the handover in Type-III mode. Handover, when the value is 4, it means handover in Type-IV mode. Values 0 and 5 to 7 are reserved for future alternative or hybrid modes.

<b>M. Used for interface type confirmation packet</b>

The interface type field (1 byte) has a value to confirm the new interface used. The value in this field specifies the interface type in the following way. If bit 7 is equal to 0, the type handover request is used for forward connection, on the other hand, if it is equal to 1, the type handover request is used for reverse connection. Bit positions 6 to 3 are currently reserved for specifying other handover types, and are generally set to zero. However, bit positions 2 to 0 are used to define the type of interface used. When the value is 0, it means negative confirmation, or the requested handover cannot be performed. When the value is 1, 2, 3, and 4, it means Type-I, Handover of Type-II, Type-III, and Type-IV modes. Values from 5 to 7 are reserved for use in designated alternative modes.

<b>N. Used for execution type handover packet</b>

The 1-byte interface type field indicates the new interface type used. The value of this field indicates the interface type, by first using bit 7 to determine whether the type handover is used for forward or reverse links. The value "0" indicates that the type handover request is used for the forward link, and the value "1" indicates the reverse link. Bits 6 to 3 are reserved for future use and are generally set to zero. However, bits 2 to 0 are used to define the type of interface used. When the values are 1, 2, 3, and 4, it specifies the handover using Type-I, Type-II, Type-III, and Type-IV modes, respectively. . These bit values are 0 and 5 Up to 7 are reserved for future use.

<b>O. Used to enable the packet for the forward sound channel</b>

The audio effect channel enablement mask field (1 byte) contains a set of flags, indicating the audio effect channel of the client to be activated. The bit is set to one to enable the corresponding channel, the bit is set to zero to disable the corresponding channel, bits 0 to 5 specify channels 0 to 5, respectively representing left front, right front, left rear, right rear, front center, sub Subwoofer channel. Bits 6 to 7 are reserved for future use and are set to zero at the same time.

<b>P. Used for reverse audio sampling rate packet</b>

The audio sample rate field (1 byte) specifies the digital audio sample rate. Different rates are assigned to the value of this field: the values 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 (SPS), and values 9 to 254 are reserved for future replacement rates, so they are currently set to "0". The value 255 is used to disable reverse link audio streaming.

The sample format field (1 byte) specifies the digital audio sample format. When bit [1:0] is equal to 0, the digital sound effect sample is in a linear format. When these bits are equal to 1, the digital sound effect sample is in μ-law format. When the bit is equal to 2, the digital sound effect sample is in A-law format. Bits [7:2] are reserved for the alternative use of the specified audio format, and are generally set to zero.

<b>Q. Overhead packet for digital content protection</b>

The content protection type field (1 byte) specifies the digital content protection method used. A value of 0 indicates digital transmission content protection (DTCP), and a value of 1 indicates a high-bandwidth digital content protection system (HDCP). The value range 2 to 255 is currently unspecified. Reserved for use by alternative protection mechanisms. The content protection overhead message field is a variable-length field that contains the content protection message sent between the host and the client.

<b>R. Enable packet for transparent color</b>

The transparent color enable field (1 byte) specifies when to enable or disable the transparent color mode. If bit 0 is equal to 0, the transparent color mode is disabled, if it is equal to 1, the transparent color mode is enabled, and the transparent color is specified by the following two parameters. Bits 1 to 7 of this byte are reserved for future use and set to zero.

The image data format description sub-field (2 bytes) indicates the format of the value to be filled in the pixel area. Figure 11 illustrates the encoding method of the image data format descriptor. This format is roughly the same as the format of the same field in the video stream packet.

The pixel area fill-in value field uses 4 bytes to be assigned to the pixel value to be filled in the specified window above. The pixel format is specified in the image data format description subfield.

<b>S. Used for round-trip delay measurement packets</b>

The parameter CRC field (2 bytes) contains the 16-bit CRC of all the bytes from the packet length to the packet type. If the CRC cannot be checked, the entire packet will be discarded.

The value contained in the strobe array field (2 bytes) will cause the MDDI Stb signal to change from low to high at the bit boundary immediately before the first bit of all zero fields in this packet. This ensures that the MDDI Stb signal operates in a consistent manner with the byte boundary in the measurement period during which this packet is transmitted at any time.

All zeros field (1 byte) contains zeros to ensure all MDDI Data The signal is in the zero state before the line driver is deactivated in the first guard time period.

The guard time 1 field (8 bytes) is used to allow the MDDI Data line driver in the host to be disabled before the line driver in the client (display) is enabled. The host disables its MDD1 Data line driver during guard time 1 bit 0, and the display activates its line driver immediately after the last bit of guard time 1.

The measurement period field is a 512-byte window, which allows the display to respond to 0xff, 0xff0x0 at half the data rate of the forward link. This rate is equivalent to the reverse link rate divisor of 1. The display immediately returns this response at the beginning of the measurement period. The host will receive this response exactly at the link round-trip delay after the start of the first bit of the host measurement period. The MDDI Data line driver of the display is disabled immediately before and after the display 0xff, 0xff, and 0x00 respond.

The value of the guard time 2 field (8 bytes) allows the user side MDDI Data line driver to be disabled before the line driver in the host is enabled. Guard time 2 always appears, but it is only needed when the round-trip delay is measured at the maximum value during the measurement period. The user terminal disables its line driver during the guard time 2 bit 0, and the host activates its line driver immediately after the last bit of guard time 2.

The driver re-enable field (1 byte) is set to zero to ensure that all MDDI Data signals will be re-enabled before the packet length field of the next packet.

<b>X. Conclusion</b>

The different specific embodiments of the present invention are as described above, but it should be understood that these specific embodiments are only examples and are not used to limit the present invention. Therefore, the breadth and scope of the present invention should not be limited to the above-mentioned exemplary embodiments, but should be defined according to the scope of the following patent applications.