RU2353066C2 - Device and method for high-speed data transmission interface commitment - Google Patents

Abstract

FIELD: information systems.

SUBSTANCE: invention refers to method of multimedia signal transmission from the master device or the controller device to the client device to be displayed to the end user with using high-speed data transmission mechanism with low power consumption. There is disclosed data transmission interface. Pulsing is enabled in measuring window in direct and reverse signal delay measurement package from the client device for each data channel; direct and reverse signal delay is measured for mobile system digital interface (MSDI) of data transmission by detecting the pulsing in measurement window of measurement in direct and reverse signal delay measurement package for each data channel; pulsing phase is determined; measured direct and reverse signal delay is stored for each channel; reverse transmission data access time is evaluated from the measured direct and reverse signal delay for each data channel and client device pulsing phases relative to bit boundary in measurement window.

EFFECT: higher system throughput in data transmission between client devices and master device.

30 cl, 122 dwg, 17 tbl

Description

Priority claim pursuant to paragraph 119 of section 35 of the US Code

This application claims the priority of US patent applications No. 60/577500 "Switchable Threshold Differential Interface", filed June 4, 2004, and 60/577793 "Switchable Threshold Differential Interface", filed June 7, 2004, which are both transferred to the applicant of this application and are hereby expressly incorporated by reference.

Technical field

Embodiments of the invention in the present description relate to a digital signal protocol, process, method steps and apparatus, including integrated circuits and one or more electronic components, for exchanging or transmitting signals between a master (host) device and a client device with a high data rate. More specifically, the present disclosure relates to a method for transmitting multimedia and other types of digital signals from a host device or controller device to a client device for presentation or display to an end user using a low power, high speed data transmission mechanism having application programs of internal and external devices.

State of the art

Products related to computers, electronic games, and various video technologies (such as digital versatile discs (DVDs) and high-definition video recorders) have developed significantly over the past few years to provide significantly higher-resolution performance for still images, video, video requirements ”and graphic images, even when some types of text are included, to end users of such equipment. These improvements, in turn, allowed the use of higher-resolution electronic playback devices, such as high-definition video monitors, high-definition television (HDTV) monitors, or specialized image projection elements. The combination of such visual images with high-definition or “quality” audio data, for example, when using audio playback such as a compact disc (CD), DVD, surround sound and other devices also having associated audio output signals, is used to create a more realistic, rich in content or true perception of multimedia information for the end user.

In addition, high-quality, highly mobile sound systems and music transport mechanisms such as MP3 players have been designed to present audio only to end users. This has led to typical users increasing the expectations of commercial electronic devices, from computers to television and even telephones, now adapted to and expecting high quality or with improved output quality. In addition, various portable devices and wireless receivers have now been proposed for reproducing delayed or real-time images from content providers such as television or movie studios and sports privileged organizations or media.

In a typical video presentation scenario using electronic products, video data is usually transmitted using known methods at a speed that can best be called slow or medium, ranging in value from one to tens of kilobits per second. This data is then either buffered or stored in transition-based (dynamic) or long-term storage devices for delayed (later) playback on the desired playback device. For example, images may be transmitted “through” or using the Internet, using a program resident on a computer having a modem or other type of Internet connection device, to receive or transmit data useful in digitally representing the image. A similar transmission can take place using wireless devices, such as laptop computers equipped with wireless modems, or wireless personal digital assistants (PDAs, PDAs), or cordless telephones.

Once received, data is stored locally in memory elements, circuits, or devices, such as random access memory (RAM) or flash memory, including internal or external storage devices, such as small hard drives, for playback. Depending on the amount of data and image resolution, playback may start relatively quickly or be presented with a long delay. That is, in some cases, the image representation takes into account some degree of real-time playback for very small or low resolution images that do not require a large amount of data, or using some type of buffering, so that after a small delay some data is presented, while additional data is being transmitted. If there are no interruptions in the communication line or interference from other systems or users regarding the used transmission channel, as soon as the presentation starts, the transmission is quite transparent to the end user of the reproducing device. Naturally, when many users share a single communication path, such as a wired Internet connection, transmissions may be interrupted or slower than desired.

The data used to create either still images or movies is often compressed using one of several well-known methods, for example, the image compression method (JPEG) specified by the joint group of experts in the field of photography, the expert group on moving images (MPEG) and other well-known organizations standards or companies in multimedia, computers, and communications industries to speed up data communications. This allows you to transfer images or data faster, using fewer bits to transmit a given amount of information.

As soon as the data is transmitted to a "local" device, such as a computer having a storage mechanism, such as a storage device, or magnetic or optical storage elements, or other receiving devices, the received information is decompressed (or reproduced using special decoding playback devices) and decoded, if necessary, and is prepared for the appropriate view based on the appropriate available permission of the view and controls. For example, the resolution of a video image for a typical computer in terms of a screen resolution of X by Y pixels usually varies from as small as 480 × 640 pixels through 600 × 800 to 1024 × 1024, although a number of other resolution values are usually possible, desirable, or necessary.

The image presentation is also affected by the image content (content) and the ability of predetermined video controllers to control the image in terms of some predetermined color levels or color depths (bits per pixel used to form the color) and intensity and using any additional overhead bits. For example, a conventional computer representation is expected to be approximately 8 to 32 or more bits per pixel to represent different colors (shades and shades), although other values are found.

From the above values, it can be seen that a given display image may require transferring from about 2.45 megabytes (MB) to about 33.55 MB of data in a range from the lowest to the highest typical resolution and depth values, respectively. When viewing images such as videos or movies at a speed of 30 frames per second, the amount of data required is approximately 73.7 to 1006 megabytes of data per second (Mbps) or approximately 9.21 to 125.75 megabytes per second (MB / s ) In addition, you may want to present audio data along with images, for example, for multimedia presentation or as a separate high-resolution audio presentation, for example, music with CD quality. Additional signals associated with interactive commands, controls, or signals may also be used. Each of these parameters adds even more data to those that need to be transmitted. In addition, newer transmission methods, including HDTV and movie recordings, can add even more data and control information. In any case, when someone wants to transmit high-quality or high-resolution image data and high-quality audio information or data signals to the end user in order to create rich content, a high-speed data link between the presentation elements and the source or master device is required which is configured to provide such data types.

Data rates of approximately 115 kilobytes (KB / s) or 920 kilobits per second (Kbps) can usually be processed by some modern serial interfaces. Other interfaces, such as USB serial interfaces, can implement data transfers at speeds as high as 12 MB / s, and specialized high-speed transfers, such as those configured using the IEEE standard 1394 of the Institute of Electrical and Electronics Engineers (IEEE) , can occur at speeds of the order of 100 to 400 MB / s. Unfortunately, these speeds do not correspond to the desirable high data rates described above, which are considered as possible for use with future wireless data transmission devices and other services for providing high-resolution output signals and rich in content for controlling portable video displays or audio devices. This is true for business computers and other presentations, gaming devices, etc. In addition, these interfaces require the use of a substantial portion of the host or system software and client software for operation. Their software protocol stacks also create an undesirable large amount of overhead information, especially when considering mobile wireless devices or telephone application programs. Such devices have strict memory requirements and power consumption limits, as well as the already paid computing power. In addition, some of these interfaces use bulky cables that are too heavy and unsatisfactory for highly aesthetic mobile applications, complex connectors that add to the cost or simply consume too much power.

Other well-known interfaces are available, such as Analog Video Graphics Adapter (AVGA), Interactive Digital Video (DVI) Interfaces, or Gigabit Video Interface (GVIF). The first two of them are parallel-type interfaces that process data at higher transfer rates, but also use heavy cables and consume more power, on the order of several watts. None of these characteristics can be adjusted for use with consumer portable electronic devices. Even the third interface consumes too much power and uses expensive or large connectors.

For some of the aforementioned interfaces and other very high-speed systems / protocols for transmitting and processing data or transmission mechanisms related to data transfers for a fixed installation computer equipment, there is another major drawback. Adaptation to the desired data rates also requires significant power and / or operation at high current levels. This greatly reduces the usefulness of such methods for products that target a highly mobile consumer.

In general, to implement such data transfer rates using alternatives, such as, say, fiberglass connections and transmission elements, a number of additional converters and elements are also required, which introduce much greater complexity and cost than is desirable for a product oriented to a true commercial consumer. In addition to the current usually still expensive nature of optical systems, their power requirements and complexity interfere with the general use for lightweight, low-power portable applications.

What the industry lacks for portable, wireless, or mobile applications is a technique that delivers high-quality performance, whether audio, video, or multimedia-based, for highly mobile end users. That is, when using laptop computers, cordless telephones, PDAs, or other highly mobile communication devices or equipment, the current systems or video and audio presentation devices simply cannot produce an output signal at the desired level with high quality. The often perceived quality that is lacking is the result of inaccessible high data rates necessary for transmitting high quality presentation data. This may include a transfer for a more efficient, enhanced or feature rich external device for presentation to an end user, or a transfer between host computers and clients internal to portable devices such as computers, gaming machines, and wireless devices such as mobile phones.

In this latter case, there has been great success achieved by adding internal higher-resolution video screens and input and / or output devices of a different specialization and connections to wireless devices such as so-called third-generation telephones and to so-called laptop computers. However, internal data buses and connections can include connections through a rotating rod, or rod-like structures, or sliding contact structures that attach or connect video screens or other elements to the main body where the host device and / or various other control elements are located and output components. There are usually broadband or high-performance interfaces. It is very difficult to design high-performance data transfer interfaces using previous methods that may require up to 90 wires or more to achieve the required performance on, say, a cordless phone, for example. Modern solutions usually include the use of parallel interfaces, for example, with relatively high signal levels, which can make the connection more expensive, less reliable and potentially generate emitted radiation, which can interfere with the functions of the device. This presents a lot of manufacturing, cost and reliability problems that need to be overcome.

Such problems and requirements can also be seen on fixed devices where, for example, communication or computing devices are added to consumer devices and other devices to provide advanced data transfer capabilities, Internet connections and data lines, or integrated into entertainment. Another example would be airplanes and buses, where individual video and audio displays are installed in the seating area. However, in these situations, it is often more convenient, efficient, and simpler for maintenance to have elements of the main storage, processing, or exchange control located at a distance from visible screens or audio outputs with an interconnect line or channel for presenting information. This link must process a significant amount of data in order to achieve the required performance, as described above.

Therefore, a new transmission mechanism is needed in order to increase the data transmission capacity between the host devices providing the data and the client display devices or elements representing the output signal to the end users.

Applicants have proposed such new transfer mechanisms in US Patent Application No. 10 / 020,520, filed December 14, 2001, now US Patent No. 6,760,772, issued July 6, 2004 to Zou and others, and US Patent Application No. 10 / 236,657, filed September 6, 2002. " Generating And Implementing A Communication Protocol And Interface For High Data Rate Signal Transfer ", the rights to both of which are transferred to the applicant of the present invention and are incorporated herein by reference, as well as US Patent Application No. 10 / 860,116, filed June 2, 2004." Generating and Implementing a Signal Protocol and Interface for Higher Data Rates. " The methods described in these applications can significantly increase the transmission rate for large amounts of data in high speed data signals. However, the requirements for an ever-increasing data transfer rate, especially with regard to the presentation of video, continue to grow. Even with other developments that occur in data signal transmission technology, there is a constant need to fight for even faster transmission speeds, improved communication line efficiency and more powerful communication lines. Therefore, there is an urgent need to develop a new or improved transmission mechanism, which is necessary to increase the data throughput between client devices and the host device.

SUMMARY OF THE INVENTION

The aforementioned drawback, as well as others existing in the art, are overcome by embodiments of the invention in which a new protocol and data transmission means, a method and mechanism for transferring data between a host device and a client device of a receiver at high data rates are developed.

Embodiments of the invention relate to the digital interface of a mobile data transmission system (CIMS, MDDI) for transmitting digital data at a high data rate between a host device and a client device over a communication path that uses a plurality or sequence of packet structures to form an exchange protocol for communication in advance a selected set of digital management and presentation data between the master and client devices. The signal exchange protocol or link layer is used by the physical layer of the controllers, receivers, or drivers of the communication line of the host device or client device. At least one controller or driver of the communication line permanently located in the master device is connected to the client device via the communication path or communication line and configured to generate, transmit and receive packets forming the communication protocol (exchange), and generate digital data representations in data packets of one or more types. This interface provides bi-directional transmission of information between the master and client device, which can be carried out in a common common housing or supporting structure.

The entire implementation is usually digital in nature, with the exception of differential drivers (excitation devices) and receivers, which can be easily implemented on digital microcircuits of complementary metal oxide semiconductor technology (CMOS), it requires several, for example 6, signals and works at almost any speed data transfer, which is convenient for the system designer. The simple protocol of the physical layer and the link layer makes it easy to integrate, and this simplicity plus the standby state enable the portable system to have very low system power consumption.

To facilitate use and adoption, the interface will increase the cost of the device very slightly, take into account the very low power consumption, at the same time it will be able to supply power to the displays through the interface using standard battery voltages, and can provide the placement of devices with a pocket form factor. The interface is scalable to support resolutions other than HDTV, support simultaneous stereo video and 7.1 audio for a display device, performs regular updates for any screen area and supports many types of data in both directions.

In further aspects of embodiments of the invention, at least one client communication line controller, receiver, device, or driver is located in the client device and connected to the master device via a communication path or communication line. The client communication line controller is also configured to generate, transmit and receive packets forming an exchange protocol and generate digital presentation data into one or more types of data packets. Typically, the host controller or the communication line controller uses a state machine to process the packet data used in commands or some types of signal preparation and request processing procedures, but can use a slower universal (general purpose) processor to manage the data and some of the less complex packets used in the exchange protocol. The host controller includes one or more differential line drive devices; while the user receiver contains one or more differential line receivers connected to the communication path.

Packets are grouped together within frames of multimedia information exchanged between a host device and client devices having a predetermined fixed length with a predetermined number of packets having different variable lengths. Each of these packets contains a packet length field, one or more packet data fields, and a cyclic redundancy check field. The "Sub-frame header" packet is transmitted or positioned at the beginning of the transmission of other packets from the controller of the communication line of the master. One or more packets of the type "Video Stream" and packets of the type "Stream of Audio" are used in accordance with the exchange protocol to transmit data such as video and data such as audio, respectively, from the host device to the client via a direct communication line for presentation to the user of the client device. One or more packets, such as a Reverse Link Encapsulation packet, are used in accordance with an exchange protocol to transmit data from a client device to a communication controller of a host device. This transmission, in some embodiments, includes transmitting data from internal controllers having at least one MDDI device to internal video screens. Other embodiments include transmitting to internal audio systems and transmitting from various data input devices, including joysticks and complex keyboards, to internal masters.

Packets of type "Filler" are formed by the controller of the communication line of the master device to fill the transmission periods of the forward communication lines that do not have data. Many other packages are used in accordance with the exchange protocol to transmit video information. Such packages include Color Map, Bitmap Block Transfer, Bitmap Area Fill, Bitmap Template Fill, and Transparent Color Resolution packages. User Defined Stream packets are used in accordance with the communication protocol to transmit user-defined interface data. Packets such as “Keyboard Data” and “Pointing Device Data” are used in accordance with a communication protocol to transmit data to or from user input devices associated with said client device. A “Link Shutdown” type packet is used in accordance with an exchange protocol to terminate data transmission in any direction over said communication path.

The “Display Power Management Status” packets are formed to provide a structure, means, or method for translating specific display controller hardware into a low power state when a client, such as a display, is not in use or is not in current active use to minimize system power consumption or overhead of system resources. In one embodiment, the client indicates the ability to respond to Display Power Management Status packets using bit 9 of the Client Feature Capability Indicators field in the User Capabilities packet.

According to a format, in one embodiment, with respect to the “Display Power Management Status” packet, this packet type is structured to have “Packet Length”, “Packet Type”, “Client Identifier” (hClient ID) fields , “Power State” and “CRC” (cyclic redundancy check - CEC). This type of packet is usually identified as a Type 75 packet in a 2-byte type field. The 2-byte hClient ID field contains information or values that are reserved for the user ID. The Power State field defines the information used to translate a particular display into the indicated power consumption state according to the value of some pre-selected bits. The 2-byte CRC field defines or contains the CRC code of all bytes in the packet, including “Packet Length”.

The communication path typically contains or uses a cable having a set of four or more conductors and a shield wire. In addition, if necessary, printed wires or conductors may be used, some of which may be on flexible substrates.

The controller of the communication line of the master device requests information about the functionality of the display from the client device in order to determine what data and data transfer rates, the said client is able to provide through the said interface. The client communication line controller reports on the functionality of the display or presentation to the controller of the communication line of the master device using at least one “Client Features” packet. Many transmission modes are used in accordance with the exchange protocol (communication protocol), each of which allows the transmission of a different maximum number of data bits in parallel for a given period of time, each mode can be selected by negotiation (“negotiation”) between the controllers of the master communication line device and client. These transmission modes are dynamically adjusted during data transmission, and the same mode should not be used on the reverse link when it is used on the forward link.

In other aspects of some embodiments of the invention, the host device comprises a wireless communication device, such as a cordless telephone, a wireless PDA, or a laptop computer having a wireless modem located therein. A typical client device comprises a portable video display, such as a microimaging device (microdisplay), and / or a portable audio presentation system. In addition, the host device may use storage means or elements to store the presentation or multimedia data that must be transmitted in order to be presented to the user of the client device.

In other aspects of some embodiments, the host device comprises a controller or communication link control device with drivers, as described below, resident in a portable electronic device, such as a wireless communication device, such as a cordless telephone, wireless PDA, or laptop computer. A typical client device in this configuration comprises a client circuit, or an integrated circuit, or a module connected to a host device and resident in the same device and to an internal video display, such as a high-resolution screen for a mobile phone and / or portable presentation system audio, or, alternatively, a system or input device of some type.

Brief Description of the Drawings

Additional features and advantages, as well as the structure and operation of various embodiments of the invention, are described in detail below with reference to the accompanying drawings. In the drawings, like reference numerals usually indicate identical, functionally similar and / or structurally similar processing elements or steps.

1A illustrates a basic environment in which embodiments of the invention may operate, including using a microimage device or projector, together with a laptop computer or other data processing device.

FIG. 1B illustrates a basic environment in which embodiments of the invention may operate, including using a microimaging device or projector and audio presentation elements used in conjunction with a wireless transceiver.

2A is a basic environment in which embodiments of the invention may operate, including the use of an internal display or audio presentation devices used in a laptop computer.

FIG. 2B illustrates a basic environment in which embodiments of the invention may operate, including the use of an internal display or audio presentation elements used in a wireless transceiver.

Figure 3 - the General concept of MDDI with the exchange or connection of the host device and the client.

Figure 4 - the structure of the package, useful for implementing data transfers from the client device to the master device.

FIG. 5 illustrates the use of an MDDI link controller and the types of signals transmitted between the host device and the client over the physical conductors of the data link for the Type 1 interface.

6 - the use of the controller of the MDDI communication line and the types of signals transmitted between the host device and the client on the physical conductors of the data line for the interfaces of Types 2, 3 and 4.

7 is a frame structure and sub-frames used to implement the interface protocol.

Fig - the General structure of packets used to implement the interface protocol.

FIG. 9 is a sub-frame header packet format.

Figure 10 - format and content of the package "placeholder".

11 is a packet format "Video Stream".

FIG. 12A-12E illustrate the format and content for the “Video Data Format Descriptor” used in FIG. 11.

13 illustrates the use of packed and unpacked formats for data.

Fig. 14 is an audio stream packet format.

Fig. 15 shows the use of border-aligned bytes and packed PCM formats for data.

Fig. 16 shows a user-defined stream packet format.

Fig - format package "Color Map".

FIG. 18 illustrates a reverse link encapsulation packet format.

Fig is a format of the package "User Features".

Fig - the format of the package "Keyboard Data".

Fig - format packet "Data of the pointing device."

Fig - format of the package "Shutdown of the communication line."

Fig. 23 shows a format of the “Client and Status Request” packet.

Figa - packet format "Block transfer of the bitmap."

24B is a flowchart of an exemplary raster operation useful for implementing embodiments of the invention.

Fig - format packet "Placeholder area of the bitmap."

FIG. 26 is a packet format “Bitmap Template Placeholder” packet format.

Fig. 27 is a packet read frame buffer format.

Fig - format of the package "State power management display".

Fig. 29 is a packet format of “Handoff to a certain type of mode”.

Fig - packet format "Resolution of the direct channel audio".

Fig - package format "Sampling frequency audio reverse link".

Fig - format package "Service data digital protection of content."

Fig - format package "Setting a transparent color and mask."

Fig - format packet "Measurement of the delay of the signal in the forward and reverse directions."

FIG. 35 is a timing chart of events for the packet “Measuring the delay of the signal passage in the forward and reverse directions”.

Fig. 36 is an exemplary embodiment of a CRC code generator and verification device useful for practicing the invention.

Figa is a timing diagram of the signals of the CRC code for the device according to Fig when sending data packets.

Figv is a timing diagram of the signals of the CRC code for the device according to Fig when receiving data packets.

FIG. 38A and 38B illustrate exemplary behavior of a special low-power differential receiver compared to a standard differential receiver.

39A illustrates processing steps for a typical contention-free service request.

Figv - processing steps for a typical service request issued after the start of the restart sequence of the communication line, competing with the start of the communication line.

An example of processing steps for a typical non-contention customer service request event 3800 is illustrated in FIG. 39A.

A similar example is illustrated in FIG. 39B, where a service request is issued after the communication link restart sequence has started and the events are re-marked.

40 illustrates how a data sequence can be transmitted using DATA-STB encoding.

Fig. 41 is a diagram useful for generating DATA and STB signals from input data in a master device and then restoring data to a client.

Figa - master devices and terminator devices for transmitting signals useful for the implementation of one variant of implementation.

Fig. 42B is a block diagram of a driver in a differential current mode.

FIG. 43A-43C illustrate the steps and signal levels used by the client to protect the service from the master and the master to provide such a service.

Fig. 44 illustrates the relative spacing between transitions on Data0 lines, other data lines (DataX), and Gating lines (Stb).

Fig - the presence of a delay in the response, which can occur when the master device disconnects the master device of the master device after transmitting the packet.

Fig. 46 illustrates the presence of a delay in a response that may occur when the master allows the master of the master to transmit a packet.

Fig. 47 is an analysis of leakage currents.

Fig. 48 shows switching characteristics and relative time dependences for the enable and disable time of the output signal of the host and client devices.

Fig. 49 is an enlarged diagram of the stages of signal processing and states by which synchronization can be carried out using a state machine.

Fig. 50 shows typical delay values that occur when processing signals on the forward and reverse paths in a system using MDDI.

Fig - measurement of the maximum delay of the signal in the forward and reverse directions.

Figa - changes in the data rate on the reverse link.

52B is an example of an advanced reverse link data sample.

Fig - graphical representation of the values of the divisor of the transmission rate on the reverse link, depending on the data rate on the forward link.

FIG. 54A and 54B illustrate steps taken in operating an interface.

55 illustrates an overview of a packet processing interface device.

Fig. 56 is a forward link packet format.

Fig. 57 shows typical values for propagation delay and time shift in a Type 1 communication line interface.

Fig - data signals (Data), gating (Stb) and a timing diagram of the restoration of synchronization on the Type 1 communication line for example signal processing in the interface.

Fig. 59 shows typical values for propagation delay and time shift at the Type 1, Type 2, Type 3, or Type 4 communication line interfaces.

FIG. 60A, 60B and 60C illustrate various possibilities for the timing diagram of two data signals and MDDI_Stb relative to each other, which are ideal, early and late, respectively.

Fig. 61 illustrates a typical Type 2 straight forward link with a delay time shift compensation circuit for exemplary signal processing at an interface.

FIG. 62A and 62B illustrate possible waveforms of MDDI_Data and MDDI_Stb for both Type 1 and Type 2 interfaces, respectively.

63 illustrates an enlarged diagram of alternative steps for processing signals and states by which synchronization can be performed using a state machine.

Fig. 64 is an exemplary relative timing diagram between a sequence of clock cycles and the time distribution of various bits of reverse link packets and divider values.

65 is an exemplary error code transmission processing.

Fig. 66 is a device useful for processing transmission of an error code.

67A is an error code transmission processing for overriding a code.

Fig. 67B is an error code transmission processing for receiving a code.

Figa - processing steps for initiated by the master device "awakening".

Figv - processing steps for client-initiated "wakeup".

FIG. 68C illustrates processing steps for a wake-up contest initiated by the master device and client.

Fig - format package "Request for characteristics of a virtual control panel (VCP)."

Fig - the format of the package "Response with the characteristics of the VCP".

Fig - format "List with the answer with the characteristics of the VCP".

Fig - format package "Setting the characteristics of the VCP."

Fig - package format "Request valid parameter".

Fig - format package "Response on the actual parameter."

Fig - package format "Features scalable video stream."

Fig - format package "Install a scalable video stream."

Fig - format packet "Confirmation scalable video stream."

Fig - format package "Scalable video stream."

Fig - package format "Request a specific state."

Fig. 80 is a packet format of a "List with a response about the actual state."

Fig - format package "Personal display capabilities."

Fig - elements in the "List of points of curvature of the field."

Fig - format package "Report client errors."

Fig - format element "List of error messages."

Fig - format package "Client Identity Information".

Fig - format package "Features alternative display".

Fig - format package "Access to the register."

FIG. 88A-88C illustrate the use of two display buffers to reduce visible artifacts.

Fig illustrates two buffers with display updates, faster than image transmission.

Fig. 90 shows two buffers with display updates slower than image transmission.

Fig - two buffers with updating the display, much faster than image transmission.

Fig. 92 shows three buffers with display updates faster than image transfer.

Fig - three buffers with updating the display, slower than image transmission.

Fig - one buffer with a display update faster than image transmission.

95 is a master-client connection using a serial connection and a hub.

Fig - client devices connected through a combination of hubs and serial connections.

Fig. 97 is a color map.

Fig. 98 shows the use of more than one client in a data transmission configuration.

99 is an application for using loads without termination on transmission lines with two clients.

Detailed description

I. Overview

The general purpose of the invention is to provide MDDI (digital interface for a mobile data transmission system), as described below, which provides or provides a cost-effective, low-power transmission mechanism that allows high or very high data transfer rates over a communication link at short distances between the host device and the client device, such as a display element, using the "serial" type of line or communication channel. This mechanism is applicable for implementation using miniature connectors and thin flexible cables, which are especially useful in connections inside (the internal area relative to the housing or supporting structure) of the display, or elements, or data output devices, or data input devices to a central controller, or communication item or device. In addition, this connection mechanism is very useful for connecting external display elements or devices, for example, micro-displays suitable for wearing (display glasses or projectors) or other types of visual, audible, tactile (tactile) information presentation devices, to laptop computers, wireless communication devices or entertainment devices.

Although the terms “mobile” and “display” are associated with the name of the protocol, it should be understood that this is used only for convenience in terms of having a standard name that is easily understood by those skilled in the art working with the interface and protocol. This applies to the Video Electronics Standards Association (VESA) standard and the various applications of this standard. However, it is apparent that after considering the review of the embodiments presented below that many non-mobility and display applications will benefit from the use of this protocol by implementing an interface structure or transfer mechanism, and the MDDI designation is not intended to imply or restrictions on the nature or completeness of the invention or its various embodiments.

An advantage of the embodiments of the invention is that it provides a technique for transmitting data that is low in complexity, low in cost, has high reliability, adapts well in the environment of use and is very stable (robust), while maintaining great flexibility.

Embodiments of the invention can be used in a number of situations to exchange or transmit large amounts of data, usually for audio, video or multimedia applications from a host device or source device, where such data is generated, manipulated, for example, for transmission to specific devices, or otherwise processed or stored, by a user or receiver, such as a video display or projection element, audio speakers, or other high-speed presentation device Information chi. A typical application, which is described below, is the transmission of data either from a laptop computer, or from a cordless telephone, or modem to a visual display device, such as a small video screen or a wearable device with a microdisplay, for example in the form of display glasses or helmets containing small projection lenses and screens, or from the host device to the client device in such components. That is, from the processor or controller to the internal screen or other presentation element, as well as from various internal or external data input devices used by the client, to the host device (or connected to it) located in the same device housing or supporting structure) cable or conductors.

MDDI features or attributes are such that they are independent of a particular display or presentation technology. This is a highly flexible mechanism for transmitting data at a high data rate, regardless of the internal structure of this data and the functional aspects of the data or commands that it implements. This allows you to adjust the synchronization of the transmitted data packets to adapt to the characteristics of specific client devices, for example, for unique display requirements for some devices, or to meet the requirements of combining audio and video for some audio-visual (AV) systems, or for some input devices data such as joysticks, touch pads, etc. The interface is very agnostic for the display element or client device, as long as the selected protocol is supported. In addition, the aggregated data of the serial communication line or data transfer rate can vary by more than several orders of magnitude, which allows the designer of the communication system or master device to optimize the requirements of cost, power, complexity of the client device and the refresh rate of the client device.

This data interface is primarily intended for use in the transmission of large volumes of high-speed data over a “wired” signal line or small cable. However, some applications may also take advantage of the wireless link, including those based on optical link transmission, if it is configured to use the same packet and data structures designed for this interface protocol and can maintain the required transmission level at a sufficiently low power consumption. or complexity, to remain practicable.

II. Wednesday

A typical application can be seen in FIG. 1A and 1B, where the portable or desktop computer 100 and the cordless telephone or PDA device 102 (personal digital assistant, PDA) are shown exchanging data with display devices 104 and 106, respectively, as well as with audio playback systems 108 and 112. 1A also illustrates possible connections to a larger display, or screen 114, or image projector 116, which for clarity are shown in only one drawing, but can also be connected to wireless device 102. The wireless device can currently receive data or pre- storing a certain amount of multimedia data in an element or memory device for later presentation for viewing and / or listening by the end user of the wireless device. Since a typical wireless device is used most of the time for voice and simple text exchange, it has a rather small display screen and a simple audio system (speakers) for transmitting information to a user device 102.

The computer 100 has a much larger screen, but still inadequate external audio system, and still does not match other multimedia presentation devices, such as high-definition television or a movie screen. Computer 100 is used for purposes of illustration, and other types of processors, interactive video games, or consumer electronics devices may also be used with the present invention. Computer 100 may use, but is not limited to, a wireless modem or other integrated device for wireless communication, or to be connected to such devices using a cable or wireless line, as required.

This makes the presentation of more complex or "rich" data less convenient or pleasant to read. Therefore, the industry is developing other mechanisms and devices to present information to end users and provide the minimum level of desired pleasure or positive perception.

As previously described above, several types of display devices are available or are being developed to present information to end users of the device 100. For example, one or more companies have developed sets of wearable display glasses that project an image in front of the eyes of a device user to present a visual display. When correctly installed, such devices effectively "project" a virtual image, as it is perceived by the user's eyes, which is much larger than the element that provides visual output. That is, a very small projection element allows the user's eye (s) to "see" the images on a much larger scale than is possible with a conventional liquid crystal display (LCD), etc. The use of large virtual displayed images also allows the use of images with a much higher resolution than is possible with more limited displays with an LCD screen. Other display devices may include, but are not limited to, small LCD screens or various flat panel display elements projecting lenses and display drivers for projecting images onto a surface, etc.

Additional elements may also be present associated with or associated with using the wireless device 102 or computer 100 to present the output signal to another user or to another device, which in turn transmits the signals to another location or stores them. For example, the data may be stored in flash memory, in optical form, for example using recordable CD media, or on magnetic media such as a VCR and similar devices, for later use.

In addition, many wireless devices and computers now have built-in MP3 music decoding functionality (elements), as well as other advanced sound decoders and systems. Laptop computers use CD and DVD playback functionality as a general rule, and some have small specialized flash readers for receiving pre-recorded audio files. The problem with these features is that digital music files promise a particularly rich experience, but only if the decoding and playback process can maintain speed. The same holds true for digital video files.

To facilitate sound reproduction, external speakers 114 are illustrated in FIG. 1A, which can also be supplemented with additional elements, such as subwoofer speakers, or surround speakers for front and rear projection of sound. At the same time, speakers or headphones 108 are shown as being integrated for the supporting structure or mechanism of the microimage device 106 in FIG. 1B. As may be known, other audio or sound reproduction elements may be used, including power amplifiers or sound generators.

In any case, as described above, when someone wants to transmit high-quality or high-resolution image data and high-quality audio information or data signals from a data source to an end user via one or more communication lines 110, a high data rate is required. That is, the transmission line 110 is a clear potentially bottleneck in data exchange, as described previously, and limits the efficiency of the system, since modern transmission mechanisms do not achieve the generally desired high data rates. As described above, for example, for images with higher resolution values, such as 1024 × 1024 pixels with a color depth of 24-32 bits per pixel, and at data rates of 30 frames / s, data rates can reach 755 Mbit / s or more. In addition, such images can be presented as part of a multimedia presentation, which includes audio data and possibly additional signals related to an interactive game or exchanges, or various commands, controls or signals, further increasing the amount or data and transmission rate data.

It is also clear that the fewer cables or interconnects required to establish a communication channel means that the mobile devices associated with the display are easier to use and more likely to be accepted by more users. This is especially true for cases where many devices are commonly used to establish full audiovisual perception and, moreover, the quality level of displays and audio output devices is enhanced.

Another typical application relating to many of the above and other enhancements to video screens and other data output or input devices can be seen from FIG. 1C and 1D, which illustrate a laptop or desktop computer 130 and a cordless telephone or device 140 communicating with “internal” display devices 134 and 144, respectively, along with audio playback systems 136 and 146.

In FIG. 2A and 2B use small business-sized parts of complete electronic devices or products to show the location of one or more internal master devices and controllers in one part of a device with a common communication line, here 138 and 148, respectively, connecting them to video elements or screens having appropriate customers regarding the rotary joint of some well-known type used today in the electronics industry. It can be seen that the amount of data included in these transmissions requires a large number of conductors to contain communication lines 138 and 148. Obviously, such communication lines contain approximately 90 or more conductors to meet today's growth needs using advanced color and graphical interfaces, display elements on such devices due to the presence of parallel or other known communication methods available for transmitting such data.

Unfortunately, higher data rates exceed today's technology available for data transfer. And in terms of the raw amount of data that must be transmitted per unit of time, and in terms of manufacturing reliable, cost-effective physical transmission mechanisms.

What is needed is a technique, structure, means or method for transmitting data at higher speeds for a data line or communication path between presentation elements and a data source that uniformly apply (lower) power consumption, lighter weight and such a simple and economical connection structure, as far as it's possible. Applicants have developed a new technique, or method and device, to achieve these and other goals, to allow the mass of mobile, portable or even stationary devices to transmit data to the desired displays, microdisplays or audio transmission elements at very high data rates, at the same time providing consumption of desirable low power and having low complexity.

III. High-Speed Digital Data Interface System Architecture

In order to create and efficiently use the new interface, the system architecture and signal transmission protocol were formulated, which provides a very high data rate using low-power signals. The protocol is based on a packet and a common frame structure, or structures connected together to form a protocol for exchanging a set of preselected data or data types, along with a command or operating structure superimposed on the interface.

A. Overview

Devices connected or exchanged over an MDDI communication line are called a master device and a client, the client typically being a display device of some type, although other output and input devices are contemplated. Data from the host device to the display is transmitted in the forward direction (referred to as forward traffic or a direct communication line), and data from the client to the host devices is transmitted in the opposite direction (reverse traffic or reverse link) when enabled by the master. This is illustrated in the basic configuration shown in FIG. 3. 3, a host device 202 is connected to a client 204 using a bi-directional communication channel 206, which is illustrated as comprising a forward link 208 and a return link 210. However, these channels are formed by the usual set of conductors, the data transmission through which is effectively switched between the operations of the forward or reverse communication lines. This allows you to use a significantly smaller number of conductors, immediately solving one of the many problems that are encountered in current approaches to high-speed data transmission in low-power environments, such as mobile electronic devices.

As described herein, the host device contains one of several types of devices that can benefit from the use of the present invention. For example, the host device 202 may be a laptop computer in the form of a handheld computer, laptop or similar mobile computer. It can also be a PDA, a paging device, or one of many cordless phones or modems. Alternatively, the host device 202 may be a portable device for entertainment or presentation, such as a portable DVD or CD player or game device.

In addition, the master device may reside as a master device or control element in a number of other widely used or planned commercial products for which high-speed communication via a client communication line is desired. For example, a master device can be used to transfer high-speed data from a video recorder to a client based on a storage device for an improved response, or to a larger high-resolution screen for presentations. A household appliance, such as a refrigerator that contains an embedded or computing system and / or Bluetooth connections to other home devices, may improve display capabilities when connected to the Internet or Bluetooth, or have reduced wire requirements for displays built into the door (client ) and auxiliary keyboards or scanners (client), while an electronic computer or control system (master) is permanently located elsewhere in the enclosure. In general, those skilled in the art will recognize a wide variety of modern electronic devices and household electrical appliances that can be advantageously applied using this interface, as well as the ability to modify older devices with a higher data transfer rate using a limited number of conductors available or in newly added or existing connectors or cables.

At the same time, the client 204 may contain a variety of devices necessary for presenting information to the end user or presenting information from the user to the host device. For example, a microdisplay integrated in display glasses or glasses, a projection device integrated in a hat or helmet, a small screen or even a holographic element integrated in a vehicle, for example, in a window or a windshield, or various speakers, headphones, or sound systems for high quality sound or music presentations. Other presentation devices include projectors or projection devices used to present information for meetings or for film and television images. Another example would be the use of touch pads or touch devices, voice recognition input devices, protection scanners, etc., which may be called upon to transmit a significant amount of information from the user of the device or system with a small actual “input” other than touch or sound from the user. In addition, docking stations for computers and car kits or desktop kits and holders for cordless phones can act as interface devices to end users or other devices and equipment, and use either clients (output or data input devices, such as a mouse) , or host devices to aid in data transfer, especially when using high-speed networks.

However, those skilled in the art will readily understand that the present invention is not limited to these devices, that there are many other devices on the market and are proposed for use that are designed to provide end users with high quality images and sound, either in terms of storage and transmission, or playback performance terms. The present invention is useful in increasing data throughput between different elements or devices in order to utilize the high data rates necessary to realize the desired user experience.

The proposed MDDI and communication signal protocol can be used to simplify the interconnection between the host processor, controller, or circuit component (for example) and the display within the device or enclosure of the device or structure (referred to as internal mode) in order to reduce the cost or complexity associated with it power and control requirements or restrictions for these connections and to improve reliability not only for connecting to or for external elements, devices or equipment (referred to as external mode).

The aggregate (aggregated) data transfer rate of a serial communication line in each signal pair used by this interface structure can vary within many orders of magnitude, which allows the system or device designer to easily optimize the cost, power, implementation complexity, and display update rate for a given application or goals. MDDI attributes are independent of display technology or other presentation device (target client). The synchronization (clocking) of data packets transmitted through the interface can be easily adjusted to adapt to the individual distinctive features of specific clients, such as display devices, sound systems, storage devices and controls, or combined requirements for synchronization of audio-video systems. Although this makes it possible to have a system with very low power consumption, it is not a requirement for different clients to have frame buffers in order to use the MDDI protocol at least at some level.

B. Interface Types

MDDI is considered to address at least four, and possibly more, slightly different physical types of interfaces used in the communications and computer industries. They are simply identified as Type 1, Type 2, Type 3 and Type 4, although other marks or designations may be used by those skilled in the art depending on the particular applications for which they are used or the industry with which they are associated. For example, simple audio systems use fewer connections than more complex multimedia systems, and can refer to features such as channels, in different ways, etc.

The Type 1 interface is configured as having 6 wires or conductors or conductive elements of another type, which makes it suitable for mobile or cordless phones, PDAs, electronic games and portable media players such as CD players or MP3 players, and similar devices or devices, used on similar types of consumer electronics technology. In one embodiment, the interface may be configured as an 8-wire (with conductors) interface, which is more suitable for a laptop, laptop or desktop personal computers and similar devices or applications that do not require fast data updates and which do not have a built-in communication line controller MDDI This type of interface is also distinguished by the use of an optional two-wire Universal Serial Bus (USB) interface, which is extremely useful in existing operating systems or software support tools found on most personal computers.

Type 2, Type 3, and Type 4 interfaces are suitable for high-performance clients or devices and use more complex cable connections with optional twisted-pair conductors to provide appropriate shielding and low-loss transmission for data signals.

The Type 1 interface transmits signals, which may contain display, audio, control information and limited signaling information, and is commonly used for mobile clients or client devices that do not require high-speed, high-resolution video data. The Type 1 interface can easily support resolution (SVGA standard) with 30 frames / s plus 5.1 channel audio and in a minimal configuration can use only three wired pairs, two pairs for data transfer and one pair for power supply. This type of interface is primarily intended for devices, such as mobile wireless devices, where the USB host device is usually not available within the device for connecting and transmitting signals. In this configuration, the mobile wireless device is the MDDI master and acts as a “master” that controls the communication link from the master, which typically sends data to the user (direct traffic or direct link) for presentation, display or playback.

In this interface, the master device allows receiving data exchange in the master device from the client (reverse traffic or reverse link) by sending a special command or packet type to the client, which allows it to occupy the bus (communication line) for a given duration and send data to the master as reverse link packets. This is illustrated in FIG. 4, where a packet type, referred to as an encapsulation packet (described below), is used to accommodate reverse link packets on a transmission line, creating a reverse link. The time interval allocated for the master device to query in a specific order clients about the availability of data is predetermined by the master device and is based on the requirements of each specific application. This type of half-duplex bidirectional data transfer is especially advantageous when the USB port is not available for transferring information or data from the client.

High-performance displays capable of providing HDTV type or similar high-resolution values require data streams with a transfer rate of approximately 1.5 Gbps to support full-blown video. The Type 2 interface supports high data rates by transmitting 2 bits in parallel, Type 3 - transmitting 4 bits in parallel, and the Type 4 interface transmits 8 bits in parallel. Type 2 and Type 3 interfaces use the same cable and connector as Type 1, but can operate at double and quadruple data rates to support high-performance video applications on portable devices. The Type 4 interface is suitable for very high-performance clients or displays and requires slightly more cable connections that contain additional twisted-pair data signals.

The protocol used by MDDI allows each Type 1, 2, 3, or 4 master device to typically communicate with any Type 1, 2, 3, or 4 client through negotiation - what is the highest possible data rate that can be used. These features, or the available features of what might be called the device with the least functionality, are used to establish link performance. Typically, even for systems where the master and client are both capable of using a Type 2, Type 3, or Type 4 interface, both start working as a Type 1 interface. The master then determines the performance of the target client and matches the handover or reconfiguration operation with or Type 2, Type 3, or Type 4 as appropriate for the specific application.

It is usually possible for the master to use the proper link level protocol (described further below) and lower or reconfigure the operation, usually at any time, to a slower mode to save power, or switch to a faster mode to maintain higher bit rates , for example, for higher resolution display content. For example, the master can change interface types when the system switches from a power source, such as a battery, to an AC power source, or when a display source of audiovisual information switches to a lower or higher resolution format, or combinations thereof, or other conditions or events can be considered as the basis for changing the type of interface or transmission mode.

It is also possible for the system to exchange data using one mode in one direction and another mode in the other direction. For example, a Type 4 interface mode can be used to transmit data to a display at a high data rate, while Type 1 mode is used when transmitting data to a host device from peripheral devices such as a keyboard or pointing device. One skilled in the art will recognize that host devices and clients can exchange outgoing data at various transmission rates.

Often, users of the MDDI protocol can distinguish between an "external" mode and an "internal" mode. External mode describes the use of a protocol and interface for connecting a master device in one device to a client outside this device, which is located up to about 2 meters or so from the master device. In this situation, the master device can also send energy to an external user so that both devices can easily work in a mobile environment. The internal mode describes when the master device is connected to a client contained within the same device, for example, within a common housing or supporting structure or structure of some kind. An example would be applications within a cordless telephone, or another wireless device, or a laptop computer, or a gaming device where the client is a display, or a display driver, or a data input device, such as a keypad, or touch pad, or sound system and the master is the central controller, graphics system, or central processing unit (CPU) element. Since the client is located much closer to the master in internal mode applications as opposed to external mode applications, there are usually no requirements described for transferring power to the user in such configurations.

C. Physical structure of the interface

The general arrangement of a device or line controller for establishing communication between the master and client devices is shown in FIG. 5 and 6. In FIG. 5 and 6, the MDDI link controller 402 and 502 is shown installed in the host device 202, and the MDDI link controller 404 and 504 is shown installed in the client device 204. As before, the host device 202 is connected to the client 204 using a bi-directional channel 406 a connection containing a set of conductors. As described below, the controllers of the communication line and the host device and the client can be fabricated as integrated circuits using a single circuit structure, which can be installed, configured or programmed to respond either as the controller of the host device (master), or the client controller (receiver ) This provides lower costs with a larger scale of production of a separate circuit device.

6, an MDDI link controller 502 is shown installed in the host device 202 ', and an MDDI link controller 504 is shown installed in the client device 204'. As before, the host device 202 'is connected to the client 204' using a bi-directional communication channel 506 containing a set of conductors. As described above, the controllers of the communication line and the host device and the client can be manufactured using a single circuit structure.

The signals passing between the host device and the client, such as a display device, on the used MDDI communication lines or physical conductors are also illustrated in FIG. 5 and 6. As seen in FIG. 5 and 6, the primary path or mechanism for transmitting data via MDDI uses data signals designated as MDDI_Data0 +/- and MDDI_Stb +/-. Each of them is a low voltage data signal that is transmitted over a differential pair of wires in the cable. There is only one transition on either the MDDI_Data0 pair or the MDDI_Stb pair for each bit sent via the interface. This is a voltage based transmission mechanism, not a current based one, so that the current consumption in static is almost zero. The master sends MDDI_Stb signals to the client display.

While data can be transmitted in both - forward and reverse - directions in MDDI_Data pairs, that is, it is a bi-directional transmission path, the master is the master or the controller of the communication channel. The signal paths MDDI_Data0 and MDDI-Stb are used in differential mode to maximize noise immunity. The data rate for the signals on these communication lines is determined by the frequency of the synchronization signal sent by the master, and is variable in the range from about 1 kbit / s to 400 Mbit / s or more.

The Type 2 interface contains one additional pair of data or conductors, or paths, other than those in the Type 1 interface, referred to as MDDI_Data1 +/-. The Type 3 interface contains two additional data pairs, or signal paths, other than those in the Type 2 interface, referred to as MDDI_Data2 +/- and MDDI_Data3 +/-. The Type 4 interface contains four more pairs of data or signal paths, other than those in the Type 3 interface, referred to as MDDI_Data4 +/-, MDDI_Data5 +/-, MDDI_Data6 +/- and MDDI_Data7 +/-, respectively. In each of the above interface configurations, the host device can send energy to the client or display using a wired pair, or signals designated as HOST_Pwr and HOST_Gnd. As described further below, power transmission can also be adapted, if required, in some wire configurations MDDI_Data4 +/-, MDDI_Data5 +/-, MDDI_Data6 +/- or MDDI_Data7 +/- when using an “Type” interface that uses fewer wires than available or exists for other modes. This power transfer is typically used for external modes, and is usually not necessary for internal modes, although some applications may vary.

The summarized information about the signals transmitted between the host device and the client (display) over the MDDI communication line for various modes is illustrated in Table I below, in accordance with the type of interface.

Table I Type 1
HOST_Pwr / Gnd
MDDI_Stb +/-
MDDI_Data0 +/-
Optional food
Optional food
Optional food
Optional food Type 2
HOST_Pwr / Gnd
MDDI_Stb +/-
MDDI_Data0 +/-
MDDI_Data1 +/-
Optional food
Optional food
Optional food
Optional food Type 3
HOST_Pwr / Gnd
MDDI_Stb +/-
MDDI_Data0 +/-
MDDI_Data1 +/-
MDDI_Data2 +/-
MDDI_Data3 +/-
Optional food
Optional food
Optional food
Optional food Type 4
HOST_Pwr / Gnd
MDDI_Stb +/-
MDDI_Data0 +/-
MDDI_Data1 +/-
MDDI_Data2 +/-
MDDI_Data3 +/-
MDDI_Data4 +/-
MDDI_Data5 +/-
MDDI_Data6 +/-
MDDI_Data7 +/-

It should also be noted that the HOST_Pwr / Gnd connections for transmission from the master are usually provided for external modes. Internal applications or modes of operation typically have clients that use energy directly from other internal resources and do not use MDDI to control power distribution, as may be apparent to those skilled in the art, such distribution is not described in more detail below. However, of course, it is possible to allow the distribution of energy through MDDI in order to take into account some types of power control, synchronization or the convenience of interconnects, for example, as one of ordinary skill in the art would understand.

The cable connection, commonly used to carry out the aforementioned structure and operation, is nominally of the order of 1.5 meters in length, usually 2 meters or less, and contains three twisted pairs of conductors of the stranded wire. Although the size of the wire is not limited to a specific size, electrical specifications or restrictions must be satisfied in terms of maximum total “through” resistance, maximum capacitance per foot, total resistance (impedance) of each pair and crosstalk.

The enveloping foil screen is wrapped or otherwise formed around the entire set or group, here of three, twisted pairs and leakage wires as an additional leakage wire. The twisted pairs and the leakage screening conductor (screen) terminate in the client connector, wherein the screen is connected to the screen for the client, and there is an insulating layer covering the entire cable, as is known in the art. Wires are paired: HOST_Gnd with HOST_Pwr; MDDI_Stb + with MDDI_Stb-; MDDI_Data0 + with MDDI_Data0-; MDDI_Data1 + with MDDI_Data1-, etc. However, a plurality of conductors and connections can be used, as one skilled in the art understands, to implement embodiments of the invention depending on specific applications. For example, heavier outer coatings or even metal layers can be used to protect the cable in some applications, while thinner single layer tape structures can be well suited for other applications.

When used in "internal mode" as an internal connection or interconnect, mode, device, protocol, device or method for transmitting data, as described further below, it is possible that more than one client can be connected to a single master device. To work in internal mode, it is permissible to have this type of configuration. However, in this situation, only one client can be configured or be able to set (drive) the signals for the MDDI interface, the MDDI_Data signals back to the master. In this case, the other client or clients can only act as a receiver for signals from the master device and not act as a source or master for MDDI data signals.

One application for using multiple clients with a single master device is in the area of video or visual display panels, such as LCD panels, on a wireless device similar to a portable telephone. Many such wireless devices are being developed with two LCD panels, one being used as the primary or primary larger display to display information or images, and the smaller used to indicate the status of the phone, caller ID, time of day, or other functions, usually at a time when the main or primary display is not in use, for example, when the phone is in sleep or inactive mode, waiting for a call to be directed to the phone, or an alternative It is useful for a phone user to activate an outgoing call.

Here, each LCD panel may comprise or be connected to an MDDI client that is connected to an MDDI master. The main LCD panel may be able to send packets back to the master, and the secondary LCD panel can only receive packets from the master. Since this is an internal mode application, it is not necessary for the secondary panel to be able to send information about its capabilities or status back to the master, because the host will already know the characteristics of the client devices in advance.

An example of using more than one client in a data transfer configuration, in this case two clients, is shown in FIG. In FIG. 98, a master device 9800 is connected via conductors, cables, or buses 9802 and 9804 to clients 9806 and 9808, respectively. Each pair of MDDI_Data and MDDI_Stb behaves as described elsewhere in the present description, and is able to use the described proposed signaling protocol having packets and transmission ratios and mechanisms described below for transmitting data at a high transmission rate, as well as transmit some commands or settings or request information from the client to establish the possibilities of its presentation, etc. In this embodiment, the client 9806 is connected to, formed as part of, or located on, or connected to an LCD display device or panel of some type that acts as a “primary” or main display panel for some type of household appliance, equipment, or device using a master device or illustrated host device and clients. Client 9808, on the other hand, is formed as part of or located on or connected to an LCD display device or panel of some type, which acts as a “primary” or main display panel for some device using a master device or illustrated master device and clients.

It should be understood that these two display elements or devices do not have to be identical or even of the same type or nature as just separate display devices for which use is desired. For example, they may be different types of LCD panels or may be LCD-based display elements, while others use a different type of display technology from a cathode ray tube to bioluminescent, as required. In Fig. 98, each client is shown exchanging on a different bus or set of conductors 9810 and 9812, respectively, to transmit information and / or commands or control information or signals to respective display elements or panels. As indicated above, the client may be formed as part of the circuitry used to implement the panel controller 9814 and 9816, or otherwise attached to or formed as part of the circuitry, conductors, or elements on or in the panel area.

There are several possible scenarios for placing such a client on the panel, or by forming the appropriate transistors for other elements when forming the circuit or panel elements, or by later attaching the circuit module, or one that may be obvious to a person skilled in the art. In addition, the client itself and the panel controller can be separate elements in some applications, or can be considered or formed as a separate module or component, device or integrated circuit element in other applications. The pixels or image display elements installed in the physical matrix in the panel then form what is called the LCD panel in the drawings, one of these two panels acts as the primary or primary LCD panel, and the other as the secondary, secondary or auxiliary panel (can be redundant if desired for redundancy). Therefore, there are primary (or primary) and secondary clients. At any given point in time or time period, only one client transmits information or transmits signals back to the host computer. Otherwise, the host device does not know for sure that the information comes from various clients or which client generates it. Additional versions of the protocol may use client identifiers or identifiers in some way to provide better client control or switching between clients as required. There are many reserved parts of the identifier in packages, as presented here. Typically, the use used in the secondary panels does not require or use the same type of feedback or exchange with the master at this time. However, the invention does not prevent such control or a change in the primary and secondary state, for example, for some periods of time, in response to a command, or in a failure mode, or in similar cases, as required. In addition, when it is used for internal operating modes, the characteristics of the display elements are usually known in advance and the exchange of information on the reverse link is simply not necessary from the secondary display, unless it is selected as a new primary, in which case the previous primary is no longer used in this mode.

D. Data Types and Baud Rates

To create a useful interface for a wide variety of user and application perceptions, MDDI provides support for a variety of clients and display information, audio transducers, keyboards, pointing devices, and many other input or output devices that can be integrated into or work with mobile communications, computing, or a display device, along with control information and combinations thereof. MDDI is designed so that it can include a number of potential types of data streams transmitted between the master and the client via any of the forward or reverse links using the minimum number of cables or conductors. Both isochronous streams and asynchronous streams (updates) are supported. Many combinations of data types are possible, as long as the aggregate data rate is less than or equal to the maximum required MDDI link rate, which is limited by the maximum serial data rate and the number of data pairs used. They may include, but are not limited to, those elements that are listed in Tables II and III below.

Table II Transfer from master to client Isochronous video data 720 × 480, 12 bit, 30 frames / s ~ 124.5 Mbps Isochronous stereo audio data 44.1 kHz, 16 bit, stereo ~ 1.4 Mbps Asynchronous Graphics 800 × 600, 12 bit, 10 frames / s, stereo ~ 115.2 Mbps Asynchronous control Minimum << 1.0 Mbps

Table III Transfer from client to master Isochronous voice data 8 kHz, 8 bit << 1.0 Mbps Isochronous video data 640 × 480, 12 bit, 24 frames / s ~ 88.5 Mbps Asynchronous state, user input, etc. Minimum << 1.0 Mbps

The interface is not fixed, but is extensible so that it can support the transfer of many "types" of information, which include user-defined data, to provide flexibility for the future system. Specific examples of the data to be posted (included) are full-blown video, either in the form of bitmap fields on a full or partial screen, or compressed video; low-frequency static bitmaps to save energy and reduce implementation costs; PCM (Pulse Code Modulated) or compressed audio data having multiple resolutions or frequencies; Position and choice of pointing device and customer-defined data for functionalities not yet defined. Such data may also be transmitted along with management or status information to determine device functionality or set operational parameters.

Embodiments of the invention contribute to the prior art for use in data transmissions, which include, but are not limited to, the following: watching a movie (displaying video and audio); use of a personal computer with limited personal viewing (graphic display, sometimes combined with video and audio); playing a video game on a personal computer, console, or personal device (graphic motion display or synthetic video and audio); "surfing" the Internet, the use of devices in the form of a videophone (bidirectional video with a low bit rate and audio), a camera for still digital images or a video camera for capturing digital video images; using a telephone, computer or PDA docked with the projector to provide a presentation, or docked with a desktop docking station connected to a video monitor, keyboard and mouse; and to enhance the performance or entertainment used with cell phones, smart phones (smartphones), or PDAs, including wireless pointing devices and keyboard data.

The high-speed data transmission interface, which is described below, is presented in terms of providing large volumes of A-V type data over a communication line or transmission line, which is usually configured as having a type of wired communication line or cable communication line. However, it is obvious that the signal structure, protocols, synchronization or transmission mechanism can be adjusted to provide a communication line in the form of optical or wireless media, if they can maintain the required level of data transfer.

MDDI signals use a concept known as Total Frame Rate (CFR) for the basic signals or protocol structure. The idea behind using the Common Frame Rate is to provide a synchronization pulse for simultaneous isochronous data streams by sending Sub-frame Header Packets at a frequency that can be used to get from her clock signals or frame timing signals for multiple streams. The frequency at which the Sub-Frame Header packets are transmitted is called the Common Frame Rate (CFR).

The client device can use this Common frame rate as a time reference (reference clock). Low CFR increases channel performance by reducing overhead (overhead) for transmitting a sub-frame subtitle. On the other hand, high CFR reduces latency and allows the use of a less flexible data buffer for audio samples. The CFR in this proposed interface is dynamically programmable and can be set to one of many values that are suitable for isochronous streams used in a particular application. That is, the CFR value is selected to best suit the client and master configuration as required.

The number of bytes typically required per sub-frame, which is customizable or programmable, for isochronous data streams that are most likely to be used with the application, for example, for video or microdisplay, are illustrated in Table IV.

Table IV Total frame rate (CFR) = 300 Hz X Y Bit Frame frequency Channel Bit rate (Mbps) Bytes /
sub-frame Computer game 720 480 24 thirty one 248,832 103680 Computer graphics 800 600 24 10 one 115,200 48000 Video 640 480 12 29.97 or 30 one 221,184 92160 Cd audio one one 16 44100 2 1.4112 588 Speech one one 8 8000 one 0,064 26-2 / 3

Fractional byte count values per sub-frame are easily obtained using the simple programmable M / N counter structure. For example, a value of 26-2 / 3 bytes per sub-frame is obtained by transmitting 2 sub-frames containing 27 bytes each, followed by one sub-frame containing 26 bytes. A smaller CFR may be selected to obtain an integer number of bytes per sub-frame. However, generally speaking, implementing a simple M / N counter by hardware should require a smaller area on the integrated circuit chip or electronic module used to implement part or all of the embodiments of the invention than the area needed for a larger FIFO buffer (first come - first go ) to fetch audio.

An exemplary application that illustrates the effect of various data transfer frequencies and data types is a karaoke system. In a karaoke system, the end user, or users, sings simultaneously with the music video program. Song words are displayed anywhere in the screen, usually at the bottom, so that the user knows the words to be sung, and a rough time reference for the song. This application requires a video display with infrequent graphic updates and mixing the user's voice, or voices, with a stereo audio stream.

If we take the total frame rate of 300 Hz, then each sub-frame will consist of 92,160 bytes of video content and 588 bytes of audio content (based on 147 16-bit samples in stereo) on a direct line to the client and an average of 26.67 bytes ( 26-2 / 3) speeches sent back from the microphone to the mobile karaoke machine. Asynchronous packets are transmitted between the host device and the client, possibly installed on the user's head display. This includes updating the bottom quarter of the screen with word text at a frequency of 1/30 second intervals or periods and other mixed control and status commands sent in sub-frames when the word text is not updated.

Table V shows how data is distributed within a sub-frame for karaoke examples. The total used transmission rate is selected to be approximately 279 Mbps. A slightly higher transfer rate of 280 Mbps allows the transfer of another approximately 400 bytes of data per sub-frame, which allows for the use of irregular control and status messages.

Table v Element Transfer Rate Service bytes per sub-frame Bytes of audio-visual information per sub-frame Music video at 640 × 480 pixels and 30 frames / s 2 * 28 = 56 92160 Word text at 640 × 120 pixels and 1 frame / s, updated in 10 sub-frames, 1/30 second 28 23040 CD Audio at 44,100 samples / s, stereo, 16-bit 2 * 16 = 32 588 Voice at 8000 samples / s, mono, 8-bit 28 + 8 + 8 + (4 * 16) + (3 * 27) = 125 26.67 (27 max) Subframe Title 22 Total Bytes / CF 263 115815 Total speed (Mbps) (263 + 115815) * 8 * 300 = 278.5872

III. (Continued) High-Speed Digital Data Interface System Architecture

E. Link Level

Data transmitted using the serial high-speed MDDI data signals consists of a stream of time-multiplexed packets that are connected one after another. Even when the transmitter does not have any data to transmit, the MDDI link controller usually automatically sends placeholder packets, thereby maintaining the flow of packets. Using a simple packet structure ensures reliable isochronous timing for video or audio signals or data streams.

Packet groups are contained in signal elements or structures called subframes, and groups of subframes are contained in signal elements or structures called media frames (frames of audio-visual information). A sub-frame contains one or more packets, depending on their respective size and use in data transmission, and the media frame contains one or more sub-frames. The largest sub-frame provided in accordance with this protocol used in the embodiments presented herein is of the order of 2 ³² -1 or 4294967295 bytes, and the largest media frame then becomes of the order of 2 ¹⁶ -1 or 65535 sub-frames.

The special sub-frame header package contains a unique identifier that appears at the beginning of each sub-frame, as described below. This identifier is also used to capture frame synchronization in the client device when the exchange between the master and the client is initiated. Link synchronization capture is described in more detail below.

Typically, the display screen is updated once per media frame when a full-size video is displayed. The display frame rate is the same as the media frame rate. The communication protocol supports full-blown video across the entire display or only a small area of the full-blown video content surrounded by a static image, depending on the application you require. In some low-power mobile applications, such as browsing the web or email, the display screen may need to be updated only occasionally. In these situations, it is advantageous to transmit a single sub-frame and then shut down or deactivate the communication line to minimize power consumption. The interface also supports effects, such as stereo vision, and processes graphic primitives.

Subframes allow the system to permit the transmission of high priority packets on a periodic basis. This allows simultaneous isochronous streams to coexist with a minimum degree of data buffering. This is one of the advantageous embodiments provided for the display process, allowing multiple data streams (high-speed transmission of video, voice, control, status, pointing device data, etc.) to essentially share a common channel. Information is transmitted using a relatively small number of signals. It also enables the existence of actions “specific to the imaging technology”, such as horizontal (horizontal) pulses and blanking intervals for a cathode ray tube or for other actions specific to client technology.

F. Link Controller

The MDDI link controller shown in FIGS. 5 and 6 is manufactured or assembled as a fully digital implementation, with the exception of the differential line receivers, which are used to receive MDDI data and gate signals. However, even differential drivers and line receivers can be implemented on the same digital integrated circuits with a communication line controller, for example, in the manufacture of CMOS type ICs (CMOS). No analog phase-locked loop (PLL) or analog phase-locked loop (PLL) functions are required to recover bits or to implement hardware for a communication line controller. The communication controllers of the host and client contain very similar functions, with the exception of the client interface, which contains a state machine for synchronizing the communication line. Therefore, embodiments of the present invention provide the practical advantage of creating a separate controller or circuit design that can be configured either as a master or as a client, which can reduce the manufacturing costs of the communication line controllers as a whole.

IV. Interface Line Protocol

A. Frame structure

The frame structure or signal protocol used to perform forward link exchange for packet transmission is illustrated in FIG. 7. As shown in FIG. 7, information or digital data is grouped into elements known as packets. Many packets, in turn, are grouped together to form what is called a "sub-frame", and many sub-frames, in turn, are grouped together to form a "media frame". To control the formation of frames and the transmission of sub-frames, each sub-frame begins with a special predefined package called the Sub-Frame Header Packet (SHP) (sub-frame header package).

The master selects the baud rate to be used for a given transmission. This transmission rate can be dynamically changed by the master based on either the host’s maximum transmission ability or data retrieved from the source by the host, and the maximum ability of the client or other device to which data is being transmitted.

The recipient client device, designed to or capable of working with MDDI or the proposed signaling protocol, can be requested by the master to determine the maximum or current maximum data rate that it can use, or the default slower minimum speed can be used transfers, as well as data types used and features supported. This information may be transmitted using the Client Capability Packet (CCP), as further described below. The client display device is capable of transmitting data or exchanges with other devices using an interface with a predetermined minimum data rate or within the minimum data rate range, and the master will query using the data rate within this range to determine all client device capabilities.

Other status information that determines the nature of the bitmap and the client’s ability regarding the frame rate of the video can be transmitted in the status packet to the master so that the master can configure the interface to be as efficient or optimal in practice or as required in the limits of any system restrictions.

The master sends filler packets when there are no (more) data packets to be transmitted in the current sub-frame, or when the master cannot transmit at a transmission rate sufficient to maintain the tempo at the data rate selected for direct communication lines. Since each sub-frame starts with a “Sub-frame header” packet, the end of the previous sub-frame contains a packet (most likely a placeholder packet) that exactly fills the previous sub-frame. If there is not enough memory for packets carrying data as such, the placeholder packet will most likely be the last packet in the sub-frame or at the end of the next previous sub-frame and before the sub-frame header packet. The task of the control operations in the master is to ensure that there is enough space left in the sub-frame for each packet to be transmitted within this sub-frame. At the same time, as soon as the master initiates the sending of a data packet, the master should be able to successfully fill out a packet of this size within the frame without subjecting the data to a condition determined by execution.

In one aspect of the embodiments, sub-frame transmission has two modes. One mode is the mode of periodic sub-frames, or periodic periods of synchronization, used to transmit video and audio streams in real time. In this mode, the length of the sub-frame is defined as non-zero. The second mode is an asynchronous, or non-periodic, mode in which frames are used to provide the client with bitmap data when new information is available. This mode is determined by setting the sub-frame length to zero in the Sub-Frame Header Packet. When using the periodic mode, receiving a sub-frame packet may begin when the client is synchronized with the forward link frame structure. This corresponds to the “in synchronism” state determined according to the state diagram described below with reference to FIG. 49 or FIG. 63. In asynchronous non-periodic mode of sub-frames, reception starts after the first Sub-Frame Header Packet has been received.

B. General package structure

The format or structure of the packets used to formulate the protocol for exchanging or transmitting signals, or the method or means for transmitting data implemented by the embodiments, is presented below, bearing in mind that the interface is extensible, and additional packet structures may be added if necessary. Packets are labeled as, or divided into, various "packet types" in the sense of their functions in the interface, that is, command, information, values or data that they transmit or with which they are associated. Therefore, each type of packet denotes a predetermined packet structure for a given packet, which is used when manipulating packets and transmitted data. As will be appreciated, packets may have pre-selected lengths or have variable or dynamically variable lengths depending on their respective functions. Packages may also have different names, although the same function is still implemented, which may occur when the protocols were changed during inclusion in the standard. Bytes or byte values used in various packets are configured as unsigned multi-bit (8- or 16-bit) integers. The summarized data on the packages used along with their type designations, listed in order of type, are illustrated in Tables VI-1 - VI-4.

Each table represents a common “type” of the package within the overall structure of the package to facilitate illustration and understanding. There is no restriction or other influence, implied or expressed for the present invention by these groups, and packages can be organized in many other ways if necessary. The direction in which packet transmission is considered valid is also noted.

Table VI-1
Link Control Packages Package name Package type Valid on a forward link Valid on reverse link Subframe Header Package 15359 x Placeholder package 0 x x Reverse Link Encapsulation Package 65 x Package “Shutdown of the communication line” 69 x Display Power Management Status Pack 75 x Package “Resolution channel audio straight line” 78 x Package “Performing a handover to a specific type of mode” 77 x Package “Measuring the delay of signal transmission in the forward and reverse directions” 82 x Package “Calibration of the shift in time of the forward link” 83 x

Table VI-2
Major Media Stream Packages Package name Package type Valid on a forward link Valid on reverse link Video Stream Package 16 x x Audio Stream Package 32 x x Reserved Stream Packages 1-15
18-31
33-55 x x User Defined Stream Packages 56-63 x x Color Map Package 64 x x Package “Frequency of samples of audio reverse link” 79 x Package “Setting transparent color and masks” 81 x

Table VI-3
Management Packs and Client Statuses Package name Package type Valid on a forward link Valid on reverse link Client Features Package 66 x Keyboard Data Package 67 x x Package “Pointing Device Data” 68 x x "Request and customer status" packages 70 x Service package “Digital Content Protection” 80 x x VCP Feature Request Package 128 x VCP Feature Response Package 129 x VCP Feature Installation Package 130 x Package "Request valid parameter" 131 x Package "Response about the actual parameter" 132 x Package "Request for a specific state" 138 x Actual Response List List 139 x Personal Display Features Package 141 x Client Error Reporting Package 142 x Scalable Video Stream Features Package 143 x Package "Customer Identity Information" 144 x Alternative Display Features Package 145 x Register Access Package 146 x x

Table VI-4
Advanced Graphics and Display Packages Package name Package type Valid on a forward link Valid on reverse link Package "Bit Block Transfer" 71 x Package "Bitmap Area Placeholder" 72 x Package “Bitmap Template Placeholder” 73 x Frame Read Buffer Package 74 x Scalable Video Stream Features Package 143 x Package “Installation of scalable video stream” 136 x Scalable Video Stream Confirmation Package 137 x Scalable Video Stream Package eighteen x

What is clear from other descriptions within this text is that each of the sub-frames of the header, fill, encapsulate the reverse link, terminate the link, client capabilities and client request and status packets are considered very important or even required for many embodiments of exchange interfaces for operating in an external mode (External Mode). However, the packages “Encapsulation of the reverse link”, “Shutdown of the communication line”, “Client capabilities" and "Request client and status" can be or, more likely, should be considered as optional for the operation in the internal mode (Internal Mode). This creates yet another type of MDDI protocol that allows data exchange at very high speeds with a reduced set of communication packets and the corresponding simplification of control and synchronization.

Packets have a common basic structure or a complete set of minimum fields containing a Packet Length field, a Packet Type field, a Data Bytes field (s), a CRC field (cyclic redundancy check), which is illustrated in FIG. As shown in FIG. 8, the Packet Length field contains information in the form of a multi-bit or “byte” value that specifies the total number of bits in a packet or its length between the “Packet Length” field and the “CRC” field. In one embodiment, the Packet Length field has a 16-bit or 2-byte unsigned integer that defines the length of the packet. The "Package Type" field is another multi-bit field that sets the type of information that is contained within the package. In an exemplary embodiment, it is a 16-bit or 2-byte value in the form of a 16-bit unsigned integer and defines data types such as display capabilities, handoff, video or audio streams, status, etc.

The third field is the “Data Bytes” field, which contains bits or data sent or sent between the master and client devices as part of this packet. The format of this data is specified specifically for each type of packet according to the specific type of transmitted data and can be divided into a sequence of additional fields, each with its own format requirements. That is, each type of package will have a specific format for this part or field. The last field is the CRC field, which contains the results of the control of cyclic redundant 16-bit code calculated from the Data Bytes, Packet Type and Packet Length fields, which is used to confirm the integrity of the information in the packet. In other words, computed over the complete packet, with the exception of the CRC field itself. The client usually saves the total number of detected CRC error codes and reports this amount back to the master in the Client Request and Status Packet (see “Client and Status Request”) (see further below).

Typically, the width and organization of these fields is intended to store 2-byte fields aligned on an even byte boundary, and 4-byte fields aligned on 4-byte boundaries. This allows you to easily embed package structures in the main memory area of the host device and the client or associated with it (and) without violating the rules of alignment of the data type that most commonly used processors or control circuits encounter.

During packet transmission, fields are transmitted, starting with the transmission of the first least significant bit (MSB, LSB) and ending with the most significant bit (MSB, MSB) transmitted last. Parameters that are more than one byte in length are passed using the first least significant byte, which leads to the same bit pattern used for a parameter larger than 8 bits in length, which is used for a shorter parameter when the MBZ is transmitted first. . The data fields of each packet are usually transmitted in the order in which they are defined in the following sections below, with the first field listed in the list being transmitted first and the last described field being transmitted last. Data on the signal transmission path MDDI_Data0 is aligned with the '0' bit of the bytes transmitted over the interface in any of the modes Type 1, Type 2, Type 3 or Type-4.

When manipulating data for displays, data from pixel arrays is transmitted in order — first rows, then columns, as is traditionally done in the field of electronics. In other words, all the pixels that appear on the same line in the bitmap are transmitted in order: the leftmost pixel is transmitted first and the rightmost pixel is transmitted last. After the rightmost pixel of the row is transmitted, then the next pixel in the sequence is the leftmost pixel of the next row. Pixel strings are usually transmitted in order from top to bottom for most displays, although other configurations can be adapted if necessary. In addition, when processing bitmaps, the usual approach, which is presented below, is to determine the reference point by marking the upper left corner of the bitmap as a location or offset of "0.0". The X and Y coordinates used to determine or set the position in the bitmap increase in value as they approach the right and lower corners of the bitmap, respectively. The first row and the first column (upper left corner of the image) begin with an index value of zero. The value of the X coordinate increases towards the right side of the image, and the value of the Y coordinate increases towards the bottom of the image when the client is viewing the display.

The display window is the visible part of the bitmap, part of the pixels in the bitmap, which may be visible by the client on the physical display medium. Often there is a case that the display window and the bitmap are the same size. The upper left corner of the display window always displays the position of the '0,0' pixel of the bitmap. The width of the display window corresponds to the X axis of the bitmap, and the width of the display window for this embodiment is less than or equal to the width of the corresponding bitmap. The window height corresponds to the Y axis of the bitmap, and the height of the display window for this embodiment is less than or equal to the height of the corresponding bitmap. The display window itself is not addressed in the protocol, since it is defined only as the visible part of the bitmap.

The relationship between bitmaps and display windows is known in computer, electronic technology, Internet communications, and other electronics related fields. Therefore, no further description or illustration of these principles is given here.

C. Package Definitions

1. Package "Sub-frame header"

The Sub-frame Header Packet is the first packet of each sub-frame and has a basic structure, as illustrated in FIG. 9. A “sub-frame header” is used to synchronize the master device — the client, each master device must be able to generate this packet, while each client must be able to receive and interpret this packet. As can be seen in one embodiment of FIG. 9, this type of packet is structured to have the fields Packet Length, Packet Type, Unique Word, Reserved 1, Sub -frame Length, Protocol Version, Sub-frame Count, and Media-frame Count are usually in this order. In one embodiment, this type of packet is typically identified as a Type 15359 packet (0x3bff in hexadecimal) and uses a pre-selected fixed length of 20 bytes, not including packet length fields.

The Package Type field and the Unique Word field each use a 2-byte value (16-bit unsigned integer). A 4-byte combination of these two fields together forms a 32-bit unique word with good autocorrelation. In one embodiment, the actual unique word is 0x005a3bff, where the lower 16 bits are transmitted first as “Packet Type” and the most significant 16 bits are transmitted later.

The Reserved 1 field contains 2 bytes, which are a reserved area for future use, and is usually configured at present with all the bits set to zero. One of the tasks of this field is to align subsequent 2-byte fields with the 16-bit address of the word and align 4-byte fields with the 32-bit address of the word. The least significant byte is reserved to indicate whether the host device is capable of addressing multiple client devices. A value of zero for this byte is reserved to indicate that the master can only operate with a single client device.

The “Sub-frame length” field contains 4 bytes of information, or values that determine the number of bytes per sub-frame. In one embodiment, the length of this field may be set to zero to indicate that only one sub-frame will be transmitted by the master before the link is completed (put) in an “inactive” state. The value in this field can be dynamically changed "on the fly" when moving from one sub-frame to the next. This feature is useful for making smaller synchronization adjustments in clock pulses to accommodate isochronous data streams. If the CRC code of the “Sub-frame header” packet is invalid, then the communication line controller should use the “Sub-frame length” of the previous known-good “Sub-frame header” packet to estimate the length of the current sub-frame.

The Protocol Version field contains 2 bytes that specify the protocol version used by the master. The Protocol Version field can be set to '0' to specify the first or current version of the protocol that was used. This value will change over time, as new versions are created, and is already being upgraded to a value of '1' for some version fields. Version values will likely or usually follow the current version number for an approved standards document that covers interfaces such as MDDI, as may be known.

The Sub-frame Count field contains 2 bytes that specify a sequence number that indicates the number of sub-frames that were transmitted starting from the beginning of the media frame. The first sub-frame of the media frame has a Sub-frame Count value of zero. The last sub-frame of the media frame has a value equal to n-1, where n is the number of sub-frames in the media frame. The Sub-frame Count field value is equal to the Sub-frame Count value sent in the previous sub-frame packet plus 1, with the exception of the first sub-frame of the media frame, which should have an index of zero. It should be noted that if the Sub-frame Length value is set to zero (indicating a non-periodic sub-frame), then the Sub-frame Count is also set to zero.

The Media-frame Count field contains 4 bytes (an unsigned 32-bit integer) that defines a sequence number that indicates the number of media frames that were transmitted, starting from the beginning of the current item or data of the transmitted audio-visual information (media item). The first media frame of the audio-visual information element has a Media-frame Count value of zero. The value of the Media-frame Count increases immediately before the first sub-frame of each media frame and returns back to a value of zero after the maximum value of the Media-frame Count (for example, media frame number 2 ³² -1 = 4294967295), which is used. The Media-frame Count can usually be reset at any time by the master to meet the needs of the end application.

2. Placeholder package

A Filler Packet is a packet that is sent to or from a client device when no other information is available for forwarding either on the forward or reverse link. It is recommended that placeholder packets be kept as short as possible to provide maximum flexibility when sending other packets when necessary. At the very end of the sub-frame or encapsulation packet of the reverse link packet (see below), the link controller sets the size of the placeholder packet to fill the remaining interval to maintain packet integrity. A placeholder packet is useful for maintaining synchronization on a communication link when no master device or client has information to send or exchange. Each master and client must be able to send and receive this packet to ensure efficient use of the interface.

An exemplary embodiment of the format and content of the placeholder package is illustrated in FIG. 10. As shown in FIG. 10, this type of packet is structured to have the Packet Length, Packet Type, Filter Bytes, and CRC fields. In one embodiment, this type of packet is typically identified as Type 0, which is indicated in the 2-byte Type field. Bits or bytes in the "Bytes of the placeholder" field contain a variable number of all zero bit values to provide the desired length of the placeholder packet. The smallest placeholder packet does not contain bytes in this field. That is, a packet consists only of packet length, packet type and CRC, and in one embodiment uses a pre-selected fixed length of 6 bytes or a Packet Length value of 4. A CRC value is defined for all bytes in the packet, including the Packet Length field, which may be excluded in some other types of package.

3. Package "Stream video"

Video Stream Packets carry video information for updating typically rectangular areas of a display device. The size of this area can be as small as one pixel or as large as the entire display screen. There may be an almost unlimited number of streams displayed simultaneously, limited by system resources, since the entire context required to display the stream is contained within the Video Stream package. The format of one embodiment of a “Video Stream” (Video Data Format Descriptor) is shown in FIG. 11. As shown in FIG. 11, in one embodiment, this type of packet is structured to have Packet Length (2 bytes), Packet Type, bClient ID, Video Data Descriptor (Descriptor) fields video data), Pixel Display Attributes, X Left Edge, X Top Edge, X Right Edge, X Bottom Edge, Y Bottom Edge, Y Bottom and Y Start (X and Y start), Pixel Count (Number of pixels), Parameter CRC (Parameter CRC), Pixel Data (Pixel data) and Pixel Data CRC (CRC pixel data). This type of packet is usually identified as Type 16, which is indicated in the 2-byte Type field. In one embodiment, the client indicates the ability to receive a video stream packet using the red-green-blue (RGB), monochrome, and Y Cr Cb Capability fields of the Client Capabilities packet.

In one embodiment, the Client Identifier field contains 2 bytes of information that are reserved for the client identifier. Since the communication protocol is newly developed, the identifiers of the actual customers are not yet known or not sufficiently open. Therefore, the bits in this field are usually set to zero until such identifier values are known, and at this point in time, the identifier values can be inserted or used, as is obvious to those skilled in the art. The same process will usually be true for the client identifier fields described below.

The format and content used to implement the operation of the exemplary "Video data descriptor" field, which is mentioned above, are illustrated in FIG. 12A-12E. In FIG. 12A-12E, the “Video data format descriptor” field contains 2 bytes in the form of a 16-bit unsigned integer that defines the format of each pixel in the pixel data in the current stream in the current packet. It is possible that different packets of the video stream can use different pixel data formats, that is, use a different value in the "Video data format descriptor", and likewise, the stream (display area) can change its data format on the fly. The pixel data format must obey at least one of the valid formats for the client, as defined in the Client Capabilities package. The video data format descriptor defines only such a pixel format for the current packet, which does not imply that the constant format will continue to be used during the life of a particular video stream.

FIG. 12A-12D illustrate how a “Video Data Format Descriptor” is encoded. As used in these drawings and in this embodiment, when the bits [15:13] are '000', as shown in Fig. 12A, then the video data consists of an array of monochrome (monochrome) pixels, where the number of bits per pixel is determined by bits 3- 0 words “Video data format descriptor”. Bits 11-4 are usually reserved for future use or applications and are set to zero in this situation. When the bits [15:13] are instead equal to the values '001', as shown in Fig. 12B, then the video data is composed of an array of color pixels, each defines a color by means of a color map (palette). In this situation, bits 5-0 of the word “Video data format descriptor” determine the number of bits per pixel and bits 11-6 are usually reserved for future use or applications and are set to zero. When bits [15:13] are instead equal to the values of '010', as shown in FIG. 12C, then the video data consists of an array of color pixels, where the number of bits per red pixel is determined by bits 11-8, the number of bits per a green pixel is defined by bits 7-4 and the number of bits per blue pixel is determined by bits 3-0. In this situation, the total number of bits in each pixel is the sum of the number of bits used for red, green, and blue.

However, when the bits [15:13] instead are equal to the values or the string '011', as shown in Fig. 12D, then the video data consists of an array of video data in a 4: 2: 2 Y Cb Cr format with luminance and color information, where the number of bits per pixel of the luminance signal (Y) is determined by bits 11–8, the number of bits of the Cb component is determined by bits 7–4, and the number of bits of the Cr component is determined by bits 3–0. The total number of bits in each pixel is the sum of the number of bits used for red, green, and blue. The Cb and Cr components are sent at half the bit rate as Y. In addition, the video samples in the Pixel Data section of this packet are organized as follows: Cbn, Yn, Crn, Yn + 1, Cbn + 2, Yn + 2, Crn + 2, Yn + 3, ..., where Cbn and Crn are associated with Yn and Yn + 1 and Cbn + 2 and Crn + 2 are associated with Yn + 2 and Yn + 3, etc.

Yn, Yn + 1, Yn + 2, and Yn + 3 are the brightness values of four consecutive pixels in a separate row from left to right. If there is an odd number of pixels in a row (X Right Edge - X Left Edge + 1) in the window indicated by the Video Stream package, then the Y value corresponding to the last pixel in each row will be followed by the Cb value of the first pixel of the next row, and Cr value is not sent for the last pixel in the row. It is recommended that windows using the Y Cb Cr format have a width that is an even number of pixels. The pixel data in the packet must contain an even number of pixels. They may contain an odd or even number of pixels in the case when the last pixel of the pixel data corresponds to the last pixel of the row in the window indicated in the header of the Video Stream package, i.e. when the location X of the last pixel in the pixel data is equal to X Right Edge (X right border).

When bits [15:13] are instead equal to '100', then the video data consists of an array of pixels in Bayer format, where the number of bits per pixel is determined by bits 3-0 of the word “Video data format descriptor”. A “Pixel Group Pattern” is defined by bits 5 and 4, as shown in FIG. 12E. The order of the pixel data can be horizontal or vertical, and the pixels in rows or columns can be represented in the forward or reverse order, and is determined by bits 8-6. Bits 11-9 must be set to zero. A group of four pixels in a group of pixels in Bayer format is like what is often referred to as a single pixel in some display technologies. However, a single pixel in Bayer format is only one of the four color pixels of the mosaic group of pixels.

For all five formats shown in the drawings, bit 12, which is designated as “P,” determines whether the pixel data samples are packed or are pixel data aligned byte boundary. A value of '0' in this field indicates that each pixel in the Pixel Data field is aligned on the MDDI byte boundary. A value of '1' indicates that each pixel and each color in each pixel in the Pixel Data field is packed with the previous pixel or color in the pixel without leaving unused bits. The difference between byte aligned and packed pixel data format is shown in more detail in FIG. 13, where it can be clearly seen that byte aligned data can leave unused portions of a data sub-frame as opposed to a packed pixel format that does not have this.

4. Audio Stream Package

Audio stream packets carry audio data that must be played back by the client’s audio system or for a standalone audio presentation device. Different streams of audio data can be assigned to individual audio channels in the sound system, for example: left - front, right - front, center, left - rear and right - rear, depending on the type of audio system used. A complete set of audio channels is provided for headphones that contain facilities for advanced spatial-acoustic signal processing. The client indicates the ability to receive the Audio Stream packet using the Audio Channel Capability and Audio Sample Rate fields of the Client Capability Packet. The audio stream packet format is illustrated in FIG.

As shown in FIG. 14, this type of packet is structured in one embodiment such that it has the fields Packet Length, Packet Type, bClient ID, Audio Channel ID, Reserved 1 (Reserved 1), Audio Sample Count, Bits Per Sample and Packing, Audio Sample Rate, Parameter CRC (CRC Parameter), Digital Audio Data audio), Audio Data CRC (audio data CRC code). In one embodiment, this type of packet is typically identified as a Type 32 packet.

The Client ID field contains 2 bytes of information that are reserved for the client ID, as described above. The Reserved 1 field contains 2 bytes that are reserved for future use and are usually configured at the current time with all bits set to zero.

The “Bits for Sampling and Packing” field contains 1 byte in the form of an 8-bit unsigned integer that defines the packed audio data format. This format is usually used for 4-0 bits to determine the number of bits per PCM sample (sample according to pulse-code keying) audio. Bit 5 then determines whether Digital Audio Data samples are packed. The difference between packed and byte-aligned audio samples, here using 10-bit samples, is illustrated in FIG. A value of '0' indicates that each PCM audio sample in the Digital Audio Data field is aligned byte with an MDDI byte boundary, and a value of '1' indicates that each subsequent PCM audio sample is packed together (side by side) with previous audio sample. This bit is usually effective only when the value specified in bits 4-0 (the number of bits in the PCM sample of audio) is not a multiple of eight. Bits 7-6 are reserved for future use and are usually set to zero.

5. Reserved stream packets

In one embodiment, packet types 1-15, 18-31, and 33-55 are reserved for stream packets that must be defined for use in future versions or variations of packet protocols, as required for the various applications encountered. Again, this is part of making MDDI more flexible and useful in the face of ever-changing technology and system designs than other methods.

6. User Defined Stream Packages

Eight types of data streams, known as Types 56-63, are reserved for use in private applications that can be defined by equipment manufacturers for use with MDDI communication links. They are known as User Defined Stream packets. Such packages can be used for any purpose, but the host device and the client should only use such packages in situations where the result of such use is very well understood or known. A specific definition of flow parameters and data for these types of packages is provided to manufacturers of specific equipment or interface designers who implement these types of packages or find their use. Some examples of the use of User Defined Stream packages should include test parameters and test results, factory calibration data, and private special use data. The user-defined stream packet format that is used in one embodiment is illustrated in FIG. 16. As shown in FIG. 16, this type of packet is structured to have the Packet Length (2 bytes), Packet Type, bClient ID number, Stream Parameters, CRC Parameter, Stream Parameter Data (Stream data) and Stream Data CRC (CRC stream data).

7. Color Map Packages

Color Map Packets define the contents of the color map lookup table used to represent the color to the client. Some applications may require a color map, which is greater than the amount of data that can be transferred in one packet. In these cases, a plurality of Color Map packets may be transmitted, each with a different subset of the color map, using the offset and length fields described below. The color map packet format in one embodiment is illustrated in FIG. As shown in FIG. 17, this type of packet is structured to have Packet Length, Packet Type, hClient ID, Color Map Item Count, Color Map Offset, Parameter CRC (CRC Parameter), Color Map Data, and Data CRC (CRC Data). In one embodiment, this type of packet is usually identified as a Type 64 packet (packet "Video data format and color map"), as specified in the "Packet type" field (2 bytes). The client indicates the ability to receive Color Map packets using the Color Map Size and Color Map Width fields in the Client Features packet.

8. Packets "Encapsulation reverse link"

In an exemplary embodiment, data is transmitted in the reverse direction using the Reverse Link Encapsulation Packet (Reverse Link Encapsulation Packet). A forward link packet is sent, and the MDDI (transmit direction) link operation is reversed or reversed in the middle of this packet so that packets can be sent in the opposite direction. The reverse link encapsulation packet format in one embodiment is illustrated in FIG. As shown in FIG. 18, this type of packet is structured to have Packet Length, Packet Type, hCLient ID, Reverse Link Flags, Reverse Link Divisor (Reverse Link Rate Divider) , Turn-Around 1 Length, Turn-Around 2 Length, CRC parameter, All Zero 1, Turn-Around 1 (Change to 1), Reverse Data Packets, Turn-Around 2 (Change 2), and All Zero 2. In one embodiment, this type of packet is typically identified as a Type 65 packet. For external mode, each master must be able to generate this packet and receive data, and each client must be able to receive and send data to the master in order to effectively use the required protocol and the resulting speed. The implementation of this packet is optional for internal mode, but the Reverse Link Encapsulation packet is used for the master to receive data from the client.

The MDDI Link Controller behaves in a special way when sending the Reverse Link Encapsulation Packet. MDDI has a gate signal, which is usually always set (energized, set) by the master as a communication line controller. The master behaves as if it transmitted zero for each bit of the Turn-Around and Reverse Data Packets of the Reverse Link Encapsulation packet. The master device switches the MDDI_Strobe signal at each bit boundary for two points of change to the opposite and for the time assigned to the data packets of the reverse link. That is, the master switches MDDI_Stb from the beginning of the All Zero 1 field to the end of the All Zero 2 field. (This is the same behavior as if all zero data had been transmitted.)

The master device disables (disables) its MDDI data signal line drivers and usually ensures that they are completely disabled until the last bit of the Turn-Around 1 field, then re-enables its line drivers during the Turn-Around 2 field and usually ensures that masters are fully re-enabled until the last bit of the Turn-Around 2 field. The client reads the Turn-Around Length parameter and sets the data signals to the master immediately after the last bit in the Turn- Around field Around 1. That is, the client synchronizes new data in the communication line along some rising edges of the MDDI strobe, as indicated in the description of the packet contents below and elsewhere in this description. The client uses the Packet Length and Turn-Around Length parameters to know the length of time that is available for sending packets to the master. The client can send placeholder packets or set the data lines to zero when it does not have any data to send to the master. If the data lines are set to zero, the master interprets this as a packet with zero length (invalid length) and the master no longer receives packets from the client for the duration of the current reverse link encapsulation packet.

In one embodiment, the Reverse Link Request field of the Client Request and Status Packet can be used to inform the host of the number of bytes that are required by the client in the Reverse Encapsulation Packet link "to send data back to the master. The master is trying to provide a request by allocating at least that number of bytes in the Reverse Link Encapsulation packet. The master can send more than one Reverse Link Encapsulation packet in a sub-frame. The client can send the Client Request and Status packet at almost any time, and the master interprets the Reverse Link Request parameter as the total number of bytes, requested in one sub-frame.

9. Client Features Packages

The master device must know the functionality of the client (display) with which it is exchanging in order to configure the master-client communication line, usually in the optimal or desired way. It is recommended that the display sends a Client Capability Packet to the master device after the forward link synchronization is captured. The transmission of such a packet is considered necessary when requested by the master using the “Reverse Link Flags” in the “Reverse Link Encapsulation” packet. The Client Capabilities packet is used to inform the master about client functionality. In mode, each master must be able to receive this packet, and each client must be able to send this packet in order to make full use of this interface and protocol. significant for the internal mode, since the capabilities of the client, such as a display, keyboard or other input / output device, in this situation should already be well defined and known on the master device during manufacture or assembly into a single component or module of some type.

The format of the package "Client Features" in one embodiment, is illustrated in Fig.19. As shown in FIG. 19, for this embodiment, this type of packet is structured to have the fields Packet Length, Packet Type, cClient ID, Protocol Version, Min Protocol Version (Minimum Protocol Version), Pre-Calibration Data Rate Capability, Interface Type Capability, Number of Alt Displays, Post-Calibration Data Rate Capability data transfer after calibration), Bitmap Width, Bitmap Height bitmap), Display Window Width, Display Window Height, Color Map Size, Color Map RGB Width, RGB Capability, Monochrome Capability, Reserved 1 (Reserved 1), Y Cr Cb Capability (Bay Cr Capability), Bayer Capability (Reserved 2), Client Reserved 2 (Client Feature Capability), Max Video Frame Rate, Min Video Frame Rate, Min Sub-frame rate sub-frame rate), Audio Buffer Depth, Audio Channel Capability, Audio Sample Rate Capability, Audio Sample Resolution, Mic Sample Resolution Microphone), Mic Sample Rate Capability, Keyboard Data Format, Pointing Device Data Format, Content Protection Type, Mfr. Name, Product Code, Reserved 3, Serial Number, Week of Mfr. (Production Week), Year of Mfr. (Year of manufacture) and CRC (Cyclic Redundancy Check). In an exemplary embodiment, this type of packet is typically identified as a Type 66 packet.

10. Keyboard Data Packages

The Keyboard Data Format packet is used to send keyboard data from the client device to the host device. A wireless (or wired) keyboard can be used in conjunction with various displays or audio devices, including but not limited to a head-mounted presentation device with a video display / audio. The Keyboard Data package transmits keyboard data received from one of several known devices similar to a keyboard to a host device. This packet can also be used on the forward link to send data to the keyboard. The client indicates the ability to send and receive Keyboard Data packets using the Keyboard Data field in the Client Features packet.

The format of the “Keyboard Data” packet is illustrated in FIG. 20 and contains a variable number of bytes of information from or for the keyboard. As shown in FIG. 20, this type of packet is structured to have the Packet Length, Packet Type, bClient ID, Keyboard Data Format, Keyboard Data, and CRC fields. Here, this type of packet is commonly identified as a Type 67 packet.

The "Client ID" is a reserved field, as before, and CRC is executed on all bytes of the packet. The Keyboard Data Format field contains a 2 byte value that describes the keyboard data format. Bits 6-0 must be identical to the "Keyboard data format" field in the "Client Features" packet. This value should not be 127. Bits 15-7 are reserved for future use and therefore are currently set to zero.

11. Packets "Data device pointing"

The Pointing Device Data packet is used as a method, structure, or means for sending position information from a wireless mouse or other pointing device from a client to a host device. Data can also be sent to the pointing device on the forward link using this packet. An exemplary format of the “Pointing Device Data” packet is illustrated in FIG. 21 and contains a variable number of bytes of information from or for the pointing device.

As shown in FIG. 21, this type of packet is structured to have the Packet Length, Packet Type, bClient ID, Pointing Device Format, Pointing Device Data, and CRC fields. In an exemplary embodiment, this type of packet is typically identified as a Type 68 packet in a 1-byte type field.

12. Packages "Completion of the communication line"

The Link Shutdown Packet sends from the master to the client as a way or means to indicate that the MDDI data and strobe will be cleared and that it needs to go into an idle state with low power consumption. This package is useful for disconnecting the communication line and conserving power after static bitmaps are sent from the mobile communication device to the display, or when there is currently no additional information for transmission from the host device to the client. Normal operation continues when the master sends packets again. The first packet sent after inactivity is the Sub-Frame Header packet. The format of the Client Status Packet for one embodiment is illustrated in FIG. As shown in FIG. 22, this type of packet is structured to have the Packet Length, Packet Type, CRC, and All Zeros (all zeros) fields. In one embodiment, this type of packet is typically identified as a Type 69 packet in a 1-byte type field.

The packet length field uses 2 bytes to determine the total number of bytes in the packet, not including the packet length field. In one embodiment, the “Packet Length” of this packet depends on the Interface Type or link mode operating at the point in time when the “Link Shutdown” packet is sent. Therefore, a typical packet length becomes 20 bytes for Type 1 mode (a total of 22 bytes in a packet), 36 bytes for Type 2 mode (a total of 38 bytes in a packet), 68 bytes for a Type 3 mode communication link (total 70 bytes in packet) and 132 bytes for Type 4 mode (with a total of 134 bytes in the packet).

The All Zeros field uses a variable number of bytes to ensure that the MDDI_Data signals are set to logic zero for sufficient time to allow the client to start synchronization recovery using only MDDI_Stb until the master devices on the line disconnect. The length of the All Zeros field depends on the Type of Interface or the operating mode of the communication line that is in effect at the time the “Shutdown of the Communication Line” packet is sent. The length of the All Zeros field is designed to generate 64 pulses on MDDI_Stb for any setting of the Interface Type. Therefore, the length of All Zeros for each type of interface becomes 16 bytes for Type 1, 32 bytes for Type 2, 64 bytes for Type 3 and 128 bytes for Type 4.

The CRC field uses 2 bytes that contain a 16-bit CRC for bytes from Packet Length to Packet Type.

In the idle state with low power consumption, the MDDI_Data0 driver is turned off to the high resistance state, starting after the 16th to 48th cycle or MDDI_Stb pulse after the last bit of the All Zeros field. For Type-2, Type-3, or Type-4 communication lines, the MDDI_Data1 - MDDI_DataPwr7 signals are also put into a high-resistance state, while the MDDI_Data0 driver is turned off. Or, the host device or client can force the MDDI link to “wake up” from an idle state, as described herein, which is a key improvement and advantage of the present invention.

As described in the definition of the All Zeros field, MDDI_Stb is switched within 64 cycles after the MSB (least significant bit) of the CRC field of the Link Shutdown packet to facilitate proper shutdown in the client controller. One measure is the transition from low to high, followed by a transition from high to low or the transition from high to low, followed by a transition from low to high. After the All Zeros field is sent, the master device of the MDDI_Stb signal in the master device is blocked (disabled).

13. Packages "Request and customer status"

The host device needs a small amount of information from the client, so that it can configure the host-client link in the usually optimal way. It is recommended that the client send one Client Request and Status Packet packet to the master device every sub-frame. It is generally recommended that the client send this packet as the first packet in the Reverse Link Encapsulation packet to ensure that it is reliably delivered to the master. This packet is also transmitted when requested by the master using the Reverse Link Flags in Reverse Link Encapsulation Packet. The Request and Client Status package is used to report errors and status to the master. For external operation, each master must be able to receive this packet and each client must be able to send this packet in order to properly or optimally use the MDDI protocol. Although it is recommended that for internal operations, i.e. internal host devices and internal clients, there was support for this package, this is not required.

The format of the packet "Request and client status" is illustrated in Fig.23. As shown in FIG. 23, this type of packet is structured to have Packet Length, Packet Type, cClient ID, Reverse Link Request, Capability Change, Client Busy client), CRC Error Count and CRC. This type of packet is usually identified as a Type 70 packet in a 1-byte type field and usually uses a pre-selected fixed length of 12 bytes.

The Reverse Link Request field can be used to inform the host about the number of bytes the client needs in the Reverse Link Encapsulation packet, to send data back to the master. The master should try to issue this request by assigning at least of this number of bytes in the Reverse Link Encapsulation packet. The master can send more than one Reverse Link Encapsulation packet in a sub-frame to place the data. The client can send the Request and Client Status packet at any time, and the master will interpret the Reverse Link Request parameter as total number of bytes requested in one sub-frame Additional details and specific examples of how reverse link data is sent back to the master are presented below.

14. Packages "Block transfer color cards"

The Color Block Block Transfer package provides a means, structure, or method for scrolling display areas in any direction, typically copying a block of pixels from one rectangular area to another. Customers who have this feature will report this feature in bit 0 of the Display Feature Capability Indicators field in the Client Features packet. The format for one embodiment of the Color Block Block Transfer package is illustrated in FIG. As shown in FIG. 24, this type of packet is structured to have Packet Length, Packet Type, hClient ID, Pixel Data Attributes, Raster Operation, Upper Left X Value ( X value of the upper left corner), Upper Left Y Value (Y value of the upper left corner), Window Width, Window Height, Window X Movement (Window X movement), Window Y Movement (Window movement Y) and CRC. This type of packet is usually identified as a Type 71 packet, and in one embodiment uses a preselected fixed length of 15 bytes. The 2-byte hClient ID field contains information or values that are reserved for the client identifier, as described herein. Since this field is usually reserved for future use, the current value is usually set to zero by setting the bits to a logic zero, although it can be set to other values or used by those skilled in the art to convey the required information.

In one embodiment, the 2-byte “Pixel Data Attributes” field has values that specify where the pixel data should be updated, with bits 1 and 0 selecting a display where the pixel data should be updated. If the primary display in the client does not support stereo images, then the client can affect the pixel data in the primary display for one of the bit combinations of 01, 10 or 11. It is recommended that a value of 11 be used to address the primary display in clients that do not support the stereo display functionality . When bits [1: 0] have values 11 (double logical unit), pixel data is updated in the frame buffer of both the left and right eyes, if bits [1: 0] have values 10 (logical unit, logical zero), pixel data updated in the frame buffer of only the left eye. When bits [1: 0] are set to 01 (logical zero, logical unit), the pixel data is updated in the frame buffer of the right eye only. When bits [1: 0] are set to 00 (double logical zero), the pixel data is updated in the frame buffer of the alternate display indicated by bits 8-11, described below.

In one embodiment, bit 2 of the Pixel Data Attributes field determines whether the buffer for the left eye or the right eye is indeed the image source for this operation. Bit 2 applies only when bits [1: 0] are not equal to 00, which is usually implemented to indicate that it does not support source data from the main image buffer when the destination (destination) of the image is one of the alternative displays. Bit 2 is used to distinguish or specify both between the left and right eye frame buffers and the data source. When bit 2 is 0, then the left eye frame buffer is the data source, but when bit 2 is 1, then the right eye frame buffer is the data source.

Bit 3 of the Pixel Data Attributes field determines whether the buffer used to update the display or the stand-alone image buffer should be the image source for this operation. Bit 3 can also be applied to an alternate display if the alternate display uses a standalone image buffer. However, it does not support source data from the main image buffer when the image destination is an alternate display, or vice versa. When bit 3 is 0 or a logic zero, the image buffer used to update the display is the data source. When bit 3 is 1 or a logical unit level, the offline image buffer is the data source.

Bits 7 and 6 of the Pixel Data Attributes field serve as Display Update bits that define the frame buffer where the pixel data should be updated or recorded. The effect of the "Frame Update Bits" is described in more detail below. When bits [7: 6] are '01' (logical zero, logical unit), the pixel data is written to the offline image buffer. When bits [7: 6] are equal to '00' (two logical zeros), the pixel data is written to the image buffer used to update (regenerate) the display. When bits [7: 6] are '11' (two logical units), pixel data is written to all image buffers. If bits [7: 6] are '10', this combination is treated as an invalid value. These bits are currently reserved for future use. In this situation, the entire command is ignored and no image buffers are updated.

Bits 11-8 of the Pixel Data Attributes field form a 4-bit unsigned integer that defines an alternative display or alternative client destination (destination) where the pixel data should be updated. Bits 0 and 1 are set to 00 (two logical zeros) so that the client interprets bits 11-8 as an alternative display number. If bits 1 and 0 are not equal to 00, then bits 8-11 are usually set equal to the value or level of logical zero. Bits 4-5 and 12-15 are reserved for future use and are usually set to a value or logical zero level.

In one embodiment, the 2-byte Raster Operation field defines how to combine the pixels in the source and destination to form new pixel values that must be written to the image destination. Raster operations determine how the source area and the destination area of equal size in the image buffer are combined in the destination area (destination). The processing flow for data in a raster operation or raster operations is illustrated in Fig.24B. If the client does not support the Raster Operation field, as defined in the Client Capabilities packet, then the master typically sends this packet with bits 3–0 equal to 3, and the client ignores bits 3–0.

In one embodiment, bits 3-0 are used to set the actual raster operation by using or setting them equal to one of the values shown in Table VII below to select the corresponding operation shown next to this value. That is, each set value of the bits [3: 0] listed in the first column leads to the operation indicated in the second column, and is further defined here for explanation in the third column.

Table VII The value of the bits [3: 0] Values stored at destination Definition 0 0 one source & destination logical operation AND 2 source & ~ destination source AND (not destination) 3 source four ~ source & destination (not source) And destination 5 destination no operation 6 source ^ destination logical operation EXCLUSIVE OR 7 source | destination logical operation OR 8 ~ (source | destination) not (source OR destination) 9 ~ (source ^ destination) not (source EXCLUSIVE OR destination) 10 ~ (destination) not (destination) eleven source | ~ destination source OR (not destination) 12 ~ source not source 13 ~ source | destination (not source) OR destination fourteen ~ (source & destination) not (source AND destination) fifteen All units

Bits 9-8 are used to determine whether or not pixels are recorded at the destination (destination) when they refer to a transparent color. Bit 4 of the Client Feature Capability Indicators field in the Client Features package indicates whether the client supports transparent color and a transparent mask. Likewise, bit 4 of the “Display Performance Capability Indicators” field in the Alternate Display Capability Packet indicates whether the transparent color and transparent mask capability is supported by the specified alternate display. When transparent color and transparent mask are not supported, then the raster operation behaves as if bits [9: 8] were set to '00'. The operation indicated by bits [9: 8] applies whether the raster operation is supported by the client device. If the client does not support raster operations, then the resulting pixel value of the destination (destination), which should be considered for the operation specified by bits [9: 8], is equal only to the pixel value of the source. This behavior is the same as if bits [3: 0] are set to 3.

When the value of bits [9: 8] is 00, then the transparent color is not used. The resulting destination pixel is recorded at the destination pixel location without considering the value of the transparent color or the transparent mask. Transparent color is determined by the Transparent Color and Mask Setup Packet. The value of bits [5: 4], equal to '01', is currently reserved for future use and is usually not used, although it is available for those skilled in the art to set it for appropriate use. When the value of bits [5: 4] is '10', the resulting pixel is not written to the location of the destination pixel, if the resulting destination pixel calculated by the raster operation, the result of the AND operation on the original pixel and transparent mask is equal to the transparent color. Otherwise, it is written to the location of the destination pixel. When the value of the bits [9: 8] is '11', the resulting pixel is written to the location of the destination pixel if the resulting destination pixel calculated by the raster operation is equal to the transparent color. Otherwise, the resulting pixel is not written to the destination pixel location.

Bits 15-10 and 7-4 are reserved for future use and therefore are usually set to a value or logical zero level.

The remaining fields are used to determine the X and Y coordinates of the upper left corner of the window to be moved, the width and height of the window to be moved, and the number of pixels by which the window should be moved horizontally and vertically, respectively. Positive values for the last two fields cause the window to move right and down, and negative values cause the window to move left and up, respectively. The CRC field (here 2 bytes) contains the 16-bit CRC code of all bytes in the packet, including the Packet Length.

15. Packets "Filling the area of the bitmap"

The Bitmap Area Fill Packet provides a tool, structure, or method for easily initializing a display area to a single color. Displays that have this feature report this feature in bit 1 of the Client Feature Capability Indicators field in the Client Features package. One embodiment for the “Bitmap Area Fill” packet format is illustrated in FIG. As shown in FIG. 25, in this case, this type of packet is structured so that it has the Packet Length, Packet Type, hClient ID, Video Data Format Descriptor, Pixel Data Attributes fields. ), Raster Operation, Upper Left X Value, Upper Left Y Value, Window Width, Window Height, Pixel Area Fill Value (pixel area fill) and CRC. This type of packet is usually identified as a Type 72 packet in a 2-byte type field.

The 2-byte hClient ID field contains information or values that are reserved for the client identifier, as described herein. Since this field is usually reserved for future use, the current value is usually set to zero, setting bits equal to the logic zero level, although they can be set equal to other values or used by specialists in the art to transmit the required information.

The Video Data Format Descriptor field, in this embodiment using 2 bytes, defines the format of the Pixel Area Fill Value. This format is similar to the same field in the Video Stream package, which is described and illustrated above. The Pixel Area Fill Value field (4 bytes) contains the pixel value by which the window specified by the parameters in this packet should be filled. The format of this pixel is defined in the "Video data format descriptor" field. An example of pixel formats for “Pixel Area Fill Values” is the same as shown previously. If the Y Cb Cr format is selected, then the transparent color and the transparent mask should include subfields for the 1 & 2 Cb pixel, 1 Y pixel, 1 & 2 Cr pixel, and 2 Y pixel exactly as shown. The number of bytes allocated for the Transparent Color Value is determined by the "Video data format descriptor" field.

The functions of the Pixel Data Attributes and Raster Operation fields are similar to the same fields in the Bitmap Block Transfer packet described above and are presented in more detail below.

The remaining fields are used to determine the X and Y coordinates of the upper left corner of the window to be moved. The X and Y value fields of the upper left corner of the window use 2 bytes each to determine the X and Y coordinates of the upper left corner of the window to be filled. The Width and Height of the window fields (2 bytes each) determine the width and height of the window to be filled.

The CRC field (here 2 bytes) contains the 16-bit CRC of all bytes in the packet, including the Packet Length.

16. Packets "Filling the bitmap template"

The Fill Bitmap Template package provides a tool or structure to easily initialize a display area to a pre-selected template. Customers who have this capability report this capability in bit 2 of the Client Feature Capability field in the Client Capabilities Packet. The top left corner of the fill pattern is aligned with the top left corner of the window that should be filled if the horizontal or vertical offset of the pattern is zero. If the window to be filled is wider or taller than the fill pattern, then the pattern can be repeated horizontally or vertically several times to fill the window. The right side or bottom of the last repeating pattern is truncated as needed. If the window is smaller than the fill pattern, then the right side or the bottom of the fill pattern can be truncated to fit into the window.

If the horizontal offset of the template is nonzero, then the pixels between the left side of the window and the left side plus the horizontal offset of the template are filled with the rightmost pixels of the template. The horizontal offset of the template should be less than the width of the template. Similarly, if the vertical offset of the template is nonzero, then the pixels between the upper side of the window and the upper side plus the vertical offset of the template are filled with the lowest pixels of the template. The vertical offset of the template should be less than the height of the template.

One embodiment for the Fill Bitmap Template Packet format is illustrated in FIG. As shown in FIG. 26, this type of packet is structured to have Packet Length, Packet Type, hClient ID, Video Data Format Descriptor, Pixel Data Attributes, Raster Operation, Top Value X left corner, Y value of the upper left corner, Window width, Window height, Pattern Width, Pattern Height, Horizontal Pattern Offset, Vertical Pattern Offset, CRC parameter, Pattern Pixel Data and Pixel Data CRC (CRC pixel data). In some embodiments, this packet type is typically identified as a Type 73 packet in a 1-byte type field.

The 2-byte hClient ID field contains information or values that are reserved for the client identifier, as described herein. Since this field is usually reserved for future use, the current value is usually set to zero, setting the bits to a logical zero level.

The 2-byte “Video Data Format Descriptor” field defines the format of the “Pixel Area Fill Value”. 11 illustrates how a Video Data Format Format Descriptor is encoded. The format is the same as the same field in the Video Stream package.

The function of the Pixel Data Attributes and Raster Operation fields is similar to the same fields in the Bitmap Block Transfer packet described above and is presented in more detail below.

The remaining fields of the “Bitmap Template Fill” package are used to determine the X and Y coordinates of the upper left corner of the window to be filled, the width and height of the window to be filled, the width and height of the template to be used as the fill template , and the horizontal and vertical offsets of the pixel data pattern from the left and top borders, respectively, of the indicated window to be filled. The CRC field of the template (here 2 bytes) contains the 16-bit CRC code of all bytes in the packet from the Packet Length field to the Video format Descriptor. If this CRC generates an error during verification, then the entire packet should be rejected. The CRC field of the pixel data of the template contains a 16-bit CRC code of only the pixel data of the template. If this CRC generates an error during validation, then the pixel data of the template can still be used, but the CRC code error count should be increased. The “Pixel data of the template” field contains raw video information that defines the fill pattern in the format specified by the “Video data format descriptor”.

17. Packets "Read frame buffer"

The Read Frame Buffer Packet package provides a structure, means, or method for selecting, detecting, or defining a rectangular region of a frame buffer in a client that is to be sent back to the master via a reverse link. The format of the returned pixel data is in the native display format, and this format is usually defined in the Data Format Descriptor field in the Video Stream packets sent on the reverse link to the master. The pixel data that is returned to the master device is output from the image buffer whose data is currently being displayed. A client typically uses as many Video Stream packets in as many Reverse Link Encapsulation packets that are needed to return the display area indicated by the Read Frame Buffer packet. Customers who have this feature can indicate it or report this feature using bit 3 of the Client Feature Capability Indicators field in the Client Features package.

The format of the embodiment for the “Read Frame Buffer” packet is illustrated in FIG. As shown in FIG. 27, this type of packet is structured to have Packet Length, Packet Type, hClient ID, Display Data Attributes, X Left Edge, Y Tope Edge (Y top border), X Right Edge (X right border), Y Bottom Edge (Y bottom border), and CRC. In one embodiment, this type of packet is typically identified as a Type 74 packet in a type field.

The 2-byte Packet Length field determines the total number of bytes in the packet, not including the packet length field. In one embodiment, this packet length is set to 16. The 2-byte hClient ID field contains information or values that are reserved for the client identifier, as used above. Since this field is usually reserved for future use, the current value is set to zero, setting the bits to '0' (level or state of logical zero), although it can be used by specialists in the art to transmit the required information.

In one embodiment, the 2-byte Display Data Attributes field has values that determine where the pixel data should be read, and bit 0 selects a frame buffer from which the pixel data should be read. When bit 0 is 0 (logical zero), the pixel data is read from the frame buffer of the secondary (alternate) display indicated by bits 8-11, as described below. When bit 0 is 1 (logical unit), pixel data is read from the frame buffer of the primary display.

In one embodiment, bit 2 of the Display Data Attributes field determines whether the buffer for the frame buffer for the left eye or right eye is the source of data to be read. Typically, bit 2 can only be applied when the primary display supports stereo images. When bit 2 is 0 (logical zero level), then the left eye frame buffer is the data source, but when bit 2 is 1 (logical unit level), then the right eye frame buffer is the data source.

Bit 3 of the Display Data Attributes field determines which buffer — used to update (regenerate) the display or a standalone image buffer — should be the image source for this operation. Bit 3 can also be applied to an alternate display if the alternate display uses a standalone image buffer. However, in this case, the data source from the main image buffer is not supported when the destination of the image is an alternative display, or vice versa. When bit 3 is 0 or a logic zero, the image buffer used to regenerate the display is the data source. When bit 3 is equal to a value of 1 or a logic unit level, the offline image buffer is the data source.

Bits 11-8 of the Display Data Attributes field define the display or alternative location of the client where pixel data should be read. Bit 0 is set to 0 (logical zero) so that the client interprets bits 11-8 as an alternate display number. If bit 0 is not equal to 0, then bits 8-11 are usually set to a value or logical zero level. Bits 1, 4-7, and 12-15 are reserved for future use and are usually set to logic zero or zero values.

In one embodiment, the 2-byte X Left Edge and Y Top Edge fields specify (define) the X coordinate of the left border and the Y coordinate of the upper border of the window on the screen filled with the Pixel Data field, while the X Right Edge and Y Bottom fields Edge defines the X coordinate of the right border and the Y coordinate of the lower border of the updated window.

In one embodiment, the 2-byte CRC field defines or contains the CRC of all bytes in the packet, including the "Packet Length" field.

18. Packages "Status of energy consumption display"

The Display Power State Packet package provides a structure, means, or method for placing a client-specific or related or connected to a client or hardware controller into a low power consumption state when a client, such as a display, is not in use or not in current active use to minimize system power consumption or system resource consumption. A package of this type is most useful for applications of an interface or interface structure and protocol for configurations or external mode operations. In such applications, it is more likely that the external device runs on limited power resources, such as batteries, or has other power limitations and requirements, such as overheating in limited spaces, etc., so that minimum operating conditions during periods or inactivity are desirable, or non-use. In one embodiment, the client indicates the ability to respond to Display Power State Packets using bit 9 of the Client Feature Capability Indicators field in the Client Capabilities packet.

The format of one embodiment for the “Display Power Consumption Status” package is illustrated in FIG. As shown in FIG. 28, in one embodiment, this type of packet is structured to have Packet Length, Packet Type, hClient ID, Power State, and CRC fields. This type of packet is usually identified as a Type 75 packet in a 2-byte type field and uses a pre-selected fixed length of 8 bytes. The 2-byte hClient ID field contains information or values that are reserved for the client identifier, as used above. Since this field is usually reserved for future use, the current value is set to zero, setting the bits to '0' (level or state of logical zero), although it can be used by specialists in the art to transmit the required information.

The Power State field, here 2 bytes long, defines the information used to translate a particular device, piece of hardware or equipment associated with a client, such as a display, into the indicated energy consumption state. When used for displays, bit 0 of this field determines whether the packet is applied to the primary display or alternate display. If bit 0 is 1, then the packet is applied to the main display. If bit 0 is 0, then the packet is applied to the alternate display indicated by bits 11-8. Bit 1 is reserved for future use and is usually set to zero.

Bits 3-2 of the Power State field determine the state of energy consumption by the display selected by bits 11-8 and bit 0. When bits [3: 2] are set to '00', the selected display is not highlighted and should consume the minimum amount of power and it is not guaranteed that the contents of the frame buffer will be retained during this state. When bits [3: 2] are set to '01', the selected display is not highlighted and consumes a relative minimum amount of power and it is guaranteed that the contents of the frame buffer will be maintained during this state. The display may consume more power in this state than in state 00. The client can indicate the ability to maintain state 01 using bit 10 of the Client Feature Capability Indicators field in the Client Capabilities packet. When bits [3: 2] of the Power State field are set to '10', the selected display is highlighted and displays the image from the frame buffer connected to it. The value '11' for bits [3: 2] is a reserved value or state for future use and is not used.

Those skilled in the art will understand that although the most useful for display applications, in accordance with the present invention, the use of this package is not limited to displays only, and there may be other applications, configurations, or situations in which regulation of energy consumption may be necessary or required in in relation to other hardware elements with which MDDI is used or for which the client is managed or exchanged over the communication line. In these situations, the bits disclosed above may have similar functions, but may activate primary and secondary such elements or settings of power levels, etc., as will be understood.

In one embodiment, bits 11-8 of the Power State field form a 4-bit unsigned integer that defines an alternative display to which the power consumption state is applied. Bit 0 is set to a logical zero value so that the client interprets bits 11-8 as an alternative display number. If bit 0 is 1, then bits 11-8 are zero.

Bits 7-4 and bits 15-12 are reserved for future use and should usually be set to a level or logical zero for current applications or projects.

The 2-byte CRC field defines or contains the CRC of all bytes in the packet, including the Packet Length.

The summarized information about which power consumption status of which display is usually supported by the interface structure or protocol is presented in Table VIII below. As can be seen, various combinations of bits 10 and 9 of the “Client Feature Capability” are used to establish, configure, or initiate various of the required power states. A label at the given position of the row and column indicates that the display power consumption state indicated at the top of this column is supported for the specified bit combination in the Client Feature Capability Indicators field. It can be seen that the first and third rows of Table VIII indicate that only the “10” power consumption state is allowed when the client does not have the ability to support the “Display Power Consumption Status” package. Even though the power consumption state of the display cannot be sent to the display, a separate label indicates that the display is in the “always on” state and cannot be placed in the low power consumption state using this set of bits.

Table VIII Bits 9 and 10 of the Client Feature Capability Indicator Energy Consumption State = 00 Energy Consumption State = 01 Energy Consumption State = 10 Bit 9 = 0 and bit 10 = 0 X Bit 9 = 1 and bit 10 = 0 X X Bit 9 = 0 and bit 10 = 1 X Bit 9 = 1 and bit 10 = 1 X X X

19. Packets "Performing a handover to a specific type of mode"

The Perform Type Handoff Packet is a means, structure, or method for a master to use to issue commands to a client to switch to the mode specified in this packet. There must be one interface type setting supported by the client, as described in the Client Features package. The master and client must switch to the specified type of forward and reverse link interface immediately after this packet is sent. The format of one embodiment for a Handoff to a certain type of packet is illustrated in FIG. 29. Host devices and clients that support an interface type other than Type 1 must provide support for this package. It is generally recommended that the master read the “Client and Status Request” packet immediately before it sends the “Perform Handoff to a Specific Type” packet to confirm that the client is in sync with the master.

As shown in FIG. 29, in one embodiment, this type of packet is structured to have Packet Length, Packet Type, Interface Type, Reserved 1, Delay Filler, and CRC. This type of packet is usually identified as a Type 77 packet in a 2-byte type field.

In one embodiment, the “Interface Type” field uses a 1-byte value to confirm the new type of interface to be used or used for the communication line. The value in this field defines or represents the type of interface as follows. Bits 2-0 determine the type of interface to be used on the forward link, with a value of 1 means or determines the transfer of service to Type 1 mode; value 2 - transfer of service to Type 2 mode, value 3 - transfer of service to Type 3 mode and value 4 - transfer of service to Type 4. Bits 5-3 determine the type of interface to be used on the reverse link, and a value of 1 means or defines a handover in Type 1 mode, a value of 2 means a handoff in Type 2 mode, a value of 3 means a handoff in Type 3 mode, and a value of 4 a handoff in Type 4. Values 0, 5-7 are currently reserved for future use.

The Delay Filler field was created as a means, structure, or method to provide sufficient time for the system to prepare or be configured to switch, to use or set to use the settings for a new interface type at the beginning of the package, which immediately follows the packet “Performing a handover to a specific type of mode”. This field contains a group of bytes or 8-bit values that are all set to or equal to a level or logical zero value. The number of bytes used in this field is selected such that this results in the field being equivalent to 64 MDDI_Stb cycles in length. The length of the Delay Filer field is based on the configuration of the forward link interface type, which is 16 bytes for Type 1 forward link interface, 32 bytes for Type 2 interface, 64 bytes for Type 3 interface and 128 bytes when defining or using Type 4 forward line interfaces communication.

The Reserved 1 field (1 byte here) is reserved for future use in transmitting information. The level of all bits in this field is usually set to logic zero. The task of such fields at the present time is to align all subsequent 2-byte fields to the 16-bit address of the word and align 4-byte fields to the 32-bit address of the word. The CRC field (here 2 bytes) contains the 16-bit CRC code of all bytes in the packet, including the Packet Length field.

20. Packets "Resolution direct channel audio"

This Forward Audio Channel Enable Packet provides a structure, method, or tool that allows the master to enable or disable (disable) audio channels in the client. This feature is useful in that the client (display, for example) can disconnect energy from audio amplifiers or similar circuit elements in order to save energy when there is no audio signal to be output through the master device. This is much more difficult to do implicitly, simply using the presence or absence of audio streams as an indicator. The default state when the client system turns on is such that all audio channels are enabled. The format of one embodiment of the Direct Audio Channel Resolution packet is illustrated in FIG. As shown in FIG. 30, this type of packet is structured to have the Packet Length, Packet Type, hClient ID, Audio Channel Enable Mask, and CRC fields. This type of packet is usually identified as a Type 78 packet in a 1-byte type field and uses a pre-selected fixed length of 4 bytes.

21. Packets "Sampling frequency audio reverse link"

This type of package (Reverse Audio Sample Rate Packet) provides a structure, method, or tool that allows a master device to enable or disable audio channels in a client. This feature is useful in that the client can disconnect energy from audio amplifiers in order to conserve energy when there is no audio signal for output by the master. This is much more difficult to implement, implicitly using the presence or absence of audio streams. The default state when the client system is turned on or connected to the master device is such that all audio channels are enabled. An audio system connected to the host device and the client must be ready or capable of outputting audio signals in the prescribed or desired manner within approximately 100 ms or less after the client receives the Reverse Audio Sample Rate packet having at least one of bits in the Audio Channel Enable Mask field, which changes from a state or a value of zero to one. The client indicates the ability to respond to the “Audio Reverse Link Sampling Frequency” packet using the set of values for bit 15 of the Audio Channel Capability field in the “Client Capabilities” packet.

This package allows the master to enable or disable the reverse link audio channel and set the sampling frequency of the audio data for this stream. The master selects a sampling frequency that is determined to be valid in the Client Capabilities packet. If the master selects an invalid sampling frequency, the client will not send an audio stream to the master and the corresponding error, error value or error signal can be sent to the master in the Client Error Report Packet. The master can disable the reverse link audio stream by setting the sampling rate to 255. The default state is assumed when the client system is initially turned on or connected when the reverse link audio stream is disabled. The format in one embodiment for the Reverse Audio Sample Rate packet is illustrated in FIG. As shown in FIG. 31, this type of packet is structured to have the Packet Length, Packet Type, hClient ID, Audio Sample Rate, Reserved 1, and CRC fields. This type of packet is usually identified as a Type 79 packet and uses a pre-selected fixed length of 4 bytes.

22. Service Packages “Digital Content Protection”

This package (Digital Content Protection Overhead Packet) provides a structure, method, or tool that allows the host device and client to exchange messages related to the method of protecting digital content. Two types of content protection are currently under consideration - Digital Transmission Content Protection (DTCP) or High-bandwidth Digital Content Protection (HDCP), with memory reserved for future alternative protection schemes. The method used is specified by the Content Protection Type parameter in this package. The format of the implementation of the service package "Digital Content Protection" is illustrated in Fig. 32. As shown in FIG. 32, this type of packet is structured to have the Packet Length, Packet Type, bClient ID, Content Protection Type, Content Protection Overhead Messages, and CRC fields . This type of package is usually identified as a Type 80 package.

23. Packages "Setting a transparent color and masks"

The Transparent Color and Mask Setup Packet is a structure, method, or tool that is used to determine which color is transparent and to enable or disable (disable) the use of transparent color to display images . In one embodiment, clients or displays that have this capability will report this capability using bit 4 of the Client Feature Capability field in the Client Capabilities packet. When a pixel with a value for a transparent color is written to the bitmap, the color does not change from the previous value. The format of the “Transparent color setting” package is illustrated in FIG. As shown in FIG. 33, in one embodiment, this type of packet is structured to have Packet Length, Packet Type, hClient ID, Display Data Attributes, Reserved 1, Data Format Descriptor, Transparent Color Value colors), Transparent Mask Value, and CRC. This type of packet is usually identified as a Type 81 packet in a 1-byte type field and uses a pre-selected fixed length of 16 bytes.

The hClient ID field is reserved for use as a client identifier in future implementations and is usually set to zero (logical zero bits).

In one embodiment, the 2-byte Display Data Attributes field has values that determine where the transparent color of the pixel is to be applied, and bit 0 selects a display in which the transparent color of the pixel is to be applied. When bit 0 is 0 (logical zero), the transparent color of the pixel is applied in the alternate display indicated by bits 8-11, as described below. When bit 0 is 1 (logical unit), the transparent color of the pixel is applied in the primary display.

In one embodiment, bit 1 selects or determines whether the Transparent Color or Mask field contains a transparent color or a transparent mask. When bit 0 equals 0 (logical zero), the “Transparent color or mask” field contains the transparent color value, which should be used in subsequent raster operations or when decoding the “Video Stream” packet or the “Scalable Video Stream” packet. When bit 0 is 1 (logical unit), the “Transparent color or mask” field contains the value of the transparent mask that should be used in subsequent raster operations or when decoding the “Video Stream” packet or the “Scalable Video Stream” packet.

Bits 11-8 of the Display Data Attributes field define the display or alternative location of the client to which the transparent color of the pixel should be applied. Bit 0 is set to 0 (logical zero) so that the client interprets bits 11-8 as an alternate display number. If bit 0 is not equal to 0, then bits 8-11 are usually set to a value or logical zero level and are ignored.

Bits 7-2 and 15-12 of the Display Data Attributes field are reserved for future use and are usually set to logic zero or zero.

The Reserved 1 field of 2 bytes is reserved for future use. All bits in this field are usually set to zero (level or state of logical zero). In one embodiment, one of the goals of this field is to align all subsequent 2-byte fields to a 16-bit word address and align 4-byte fields to a 32-bit word address.

In one embodiment, the Video Data Format Descriptor field in the Transparent Color Resolution packet uses 2 bytes to determine the format of the transparent color value. 11 illustrates how a "Video Data Format Format Descriptor" is encoded. This format is usually the same as the same field in the Video Stream package.

In one embodiment, the Transparent Color Value field is used to define or assign several bytes (in this example, defined as a Packet Length of 12 for non-meaningful fields and divided by 2 to share with the Transparent Mask field ”) For the pixel value to be used as the transparent color value in subsequent raster operations or when decoding the Video Stream package or the Scalable Video Stream package. The format of this value is specified in the "Video data format descriptor" field. Examples of pixel formats for transparent color are the same as shown above. If the Y Cb Cr format is selected, the transparent color and the transparent mask typically include subfields for Pixel 1 and 2 Cb, Pixel 1 Y, Pixel 1 and 2 Cr, and Pixel 2 Y exactly, as shown previously. The number of bytes assigned to "Transparent color value" is determined by the "Video data format descriptor" field.

In one embodiment, the Transparent Mask Value field is used to define or assign several bytes (in this example, defined as a Packet Length of 12 for non-meaningful fields and divided by 2 to share with the Transparent Mask field ”) For the pixel value to be used as a transparent mask in subsequent raster operations or when decoding the Video Stream package or the Scalable Video Stream package. The format of this value is identical to the “Transparent color value” format, which is defined in the “Video data format descriptor” field. The number of bytes allocated for this field is determined by the "Video data format descriptor" field. The length of this field is identical to the length of the Transparent Color Value field.

In one embodiment, the Transparent Color or Mask Value field uses or assigns 4 bytes for the pixel value to be used as the value or transparent color or transparent mask, as defined by bit 1 of the Display Data Attributes field. The format of this pixel is defined in the "Video data format descriptor" field.

The CRC field uses 2 bytes to contain or express the CRC for all bytes in the packet, including the Packet Length.

24. Packets "Measurement of the delay signal propagation in the forward and reverse directions"

The Round Trip Delay Measurement Packet provides a structure, method, or tool that is used to measure the propagation delay from the host device to the client (display) plus the delay from the client (display) back to master device. This measurement inherently includes the delays that exist in line drivers and receivers and the interconnect subsystem. This measurement is used to set the delay of the complete change and the parameters of the reverse link bit rate divider in the reverse link encapsulation packet described in the general form above. This packet is most useful when the MDDI link is started at the maximum bit rate intended for a particular This packet can be sent in Type 1 mode and at a lower data rate to increase the measurement range of the signal delay in the forward and reverse directions. MDDI_Stb behaves as if all null data were sent in the following fields: both Guard Times, All Zero and Measurement Period. This forces MDDI_Stb to switch at half the data rate so that it can be used as a periodic synchronization signal in the client during the measurement period.

In one embodiment, the client typically indicates the ability to support the Forward and Reverse Measurement of Latency of the Signal Packet by using bit 18 of the Client Feature Capability Indicators field in the Client Capabilities packet. It is recommended that all clients support measurement delays in signal propagation in the forward and reverse directions, but it is possible for the master to know the worst case of signal delays in the forward and reverse direction x based on the maximum delay in the cable and the maximum delays of the driver and the receiver. The master can also know the signal delay in the forward and reverse directions for the MDDI communication line used in internal mode, as this is an aspect of known structural elements (lengths of conductors , such as circuits and characteristics, etc.) of a device that uses this interface.

The format of the packet "Measurement of the delay of the passage of the signal in the forward and reverse directions" is illustrated in Fig. 34. As shown in FIG. 34, in one embodiment, this type of packet is structured to have Packet Length, Packet Type, hClient ID, CRC Parameter, Guard Time 1, Measurement Period, All zeros and Guard Time 2. This type of packet is usually identified as a Type 82 packet and uses a pre-selected fixed length of 200 bits.

The timing diagram of the events that take place during the packet "Measurement of the delay of the passage of the signal in the forward and reverse directions" is illustrated in Fig. 35. In Fig. 35, the master transmits the packet "Measurement of the delay of signal propagation in the forward and reverse directions", indicated by the presence of the Parameter CRC and Strobe Alignment fields, followed by the fields "All zeros 1" and "Guard interval 1". Delay 3502 takes place before the packet reaches the client display device or processing circuit. When the client receives this packet, it transfers 0xff, 0xff, and 30 bytes of the 0x00 pattern exactly as it was practically implemented at the beginning of the “Measurement Period”, as determined by the client. The actual point in time when the client begins to transmit this sequence is delayed from the beginning of the "Measurement Period" from the point of view of the master. The magnitude of this delay is essentially the time it takes for the packet to propagate through line drivers and receivers and the interconnect subsystem (cables, conductors). A similar delay value 3504 is tested by the template for propagation from the client back to the master.

In order to accurately determine the delay time of the signal propagation in the forward and reverse directions, for signals passing to and from the client, the master device counts the number of time periods of bit transmission on the forward link that occur after the start of the "Measurement Period" until the beginning of the 0xff sequence is detected , 0xf, and 30 bytes 0x00 after they arrive. This information is used to determine the amount of time for the signal to travel in the forward and reverse directions when it travels from the host device to the client and back again. When Types 2-4 modes or reverse links are used, the master measures and stores the signal travel time in the forward and reverse directions of all MDDI_Data pairs if the data transfer rate and the time shift of the signal travel delay in the forward and reverse directions are sufficient large to affect the arrival time of each bit individually.

The master and client both set the logic level on the line for both guard times to keep the MDDI_Data lines in a certain state. The enable and disable (inhibit) times of the master and client during both guard times are such that the MDDI_Data signals are always at a real low level for any valid forward and backward signal travel times.

The master and client both set the logic level on the line for both guard times to keep the MDDI_Data lines in a certain state. The enable and disable (inhibit) times of the master and client during both guard time intervals are such that the MDDI_Data signals have real low levels for any actual forward and backward signal travel times.

25. Package "Calibration of the shift in time of the forward link"

In one embodiment, the Forward Link Skew Calibration Packet allows the client or display to calibrate itself for differences in the propagation delay of the MDDI_Data signals relative to the MDDI_Stb signal. Without compensation for the delay time shift, the maximum data rate is usually limited to account for potential changes in the worst case of these delays. It is generally recommended that this packet be sent only when the forward link data rate is set to a transmission rate of approximately 50 Mbps or lower. After sending this packet to calibrate the display, the data transfer rate can be increased to more than 50 Mbps. If the data rate is set too high during the time shift calibration process, the client can synchronize to a bit period offset, which will likely result in a delay shift compensation setting that will “go away” for more than one bit period, resulting in erroneous data synchronization . The highest type of interface data transfer rate or the largest possible type of interface is selected before sending the packet “Direct-line time shift calibration”, so that all existing information bits are calibrated. The client indicates the ability to support the forward link time offset calibration packet using bit 19 of the Client Characteristics Feature Indicators field in the Client Features packet.

Prior to performing a time-shift calibration, the master should not send data faster than the baud rate specified by the Pre-calibration Data Rate Capability field in the Client Features packet. However, after the calibration has been completed, the master can send data at the baud rate determined by the Post-calibration data rate Capability field. It is recommended that the master sends a forward link Time Shift Calibration packet at regular time intervals to correct for changes in the relative delay between different signal pairs due to temperature changes.

One embodiment of a forward link time offset calibration packet format is illustrated in FIG. As shown in Fig. 56, this type of packet is structured to have Packet Length (2 bytes), Packet Type, hClient ID, CRC Parameter, All Zeros 1, Calibration Data Sequence and All Zeros 2. This packet type is usually identified as a Type 83 packet in the type field.

Virtual control panel

Using VCP (Virtual Control Panel) allows the master to install some client management tools in the client. By allowing these parameters to be adjusted using the host device, the user interface in the client can be simplified, since screen images that allow the user to adjust parameters, such as audio level or display brightness, can be generated by the host device software, rather than one or more microprocessors in the client. The master device has the ability to read parameter settings in the client and determine the range of actual values for each control. The client usually has the ability to report back to the master which control parameters can be adjusted.

Control codes (VCP codes) and associated data values, usually indicated, are used to specifically specify the controls and settings in the client. The VCPs in the MDDI specification are expanded to 16 bits to preserve proper data field alignment in package definitions and to maintain additional values that are unique to this interface or future extensions in the future.

26. Package "Request features VCP"

The VCP Feature Packet provides a means, mechanism, or method for the master to request the current settings (settings) of a particular control parameter or all valid control parameters. Typically, the client responds to the VCP with the appropriate information in the VCP Feature Reply Packet. In one embodiment, the client indicates the ability to support the VCP Feature Request packet using bit 13 of the Client Feature Capability Indicators field in the Client Capability packet.

The format of the VCP Feature Request packet in one embodiment is illustrated in FIG. As can be seen in FIG. 69, this type of packet is structured to have the Packet Length, Packet Type, hClient ID, Display Selector, Monitor Control Command Set (MCCS) VCP code (VCP code Monitor Control (MCCS)) and CRC. This type of packet is usually identified in one embodiment as Type 128, which is indicated in a 2-byte type field. The packet length, which determines the total number of bytes in a packet, not including the packet length field, is usually set for this type of packet to be 10 bytes.

The hClient ID field is reserved for use as a client identifier in future implementations and is usually set to zero.

In one embodiment, the 2-byte Display Selector field in the VCP Response Packet defines the display where the VCP Packet should be applied. Bit 0 of the Display Selector field selects the display to which the VCP packet applies. When bit 0 is 0, the VCP packet is applied to the alternate display indicated by bits 11-8 below. If, on the other hand, bit 0 is 1, a logical unit level, then the VCP packet is applied to the primary display. Currently, bits 7-1 of the Display Selector field are reserved for future use and are usually set to zero, or bits are set to a logical zero level.

Bits 11-8 of the Display Selector field use a 4-bit unsigned integer value to determine the alternate display to which the VCP packet will be applied. When bit 0 of the Display Selector field is 0 (logical zero level), the client interprets bits 11-8 as an alternate display number. If bit 0 is not 0, then bits 11-8 are set to zero and will be ignored. Bits 15-12 are reserved for future use and are usually set to zero, or each bit level is set to logic zero.

In one embodiment, the MCCS VCP Code field contains 2 bytes of information that defines the “MCCS VCP Control Code Parameter”. A value between 0 and 255 will return a VCP Feature Response packet, which should be returned with a single entry in the VCP Feature Reply List, matching the specified MCCS code. The MCCS VCP code 65535 (0xffff) requests a VCP Characteristic Response packet with a VCP Characteristic Response List containing the Characteristic Response List element for each client-supported control. Values from 256 to 65534 for this field are reserved for future use and are not currently in use.

The 2-byte CRC field contains the CRC of all bytes in the packet, including the "Packet Length" field.

27. Package "Response with the characteristics of the VCP"

The VCP Feature Reply Packet provides a means, mechanism, or method for the client to respond to a request from the master with the current settings (parameters) of a particular control parameter or all valid control parameters. Typically, the client sends a VCP Characteristic Response packet in response to a VCP Characteristic Request packet. This package is useful for determining the current settings of a specific parameter, for determining the actual range for a particular control (tool), for determining whether a particular client control (tool) is supported, or for determining a set of control tools that a client supports. If a “VCP Feature Request” is sent that refers to a specific (tool) control that is not implemented in the client, then a “Reply with VCP Features” packet is returned with a single “Response List with VCP Features” corresponding to the unrealized control that contains corresponding error code. In one embodiment, the client indicates the ability to support the VCP Feature Response packet using bit 13 of the Client Feature Capability field in the Client Capability packet.

The format of the VCP Characteristic Response packet in one embodiment is illustrated in FIG. As can be seen from Fig. 70, this type of packet is structured to have Packet Length, Packet Type, cClient ID, Display Selector, MCCS Version, Reply Sequence Number, VCP Feature Reply List (VCP) and CRC. This type of packet is usually identified in one embodiment as Type 129, as indicated in the 2-byte type field.

The cClient ID field contains information reserved for the client identifier. This field is reserved for future use and is usually set to zero.

In one embodiment, the 2-byte Display Selection field in the VCP Response Packet defines the display where the VCP Packet should be applied. Bit 0 of the Display Selection field selects the display to which the VCP packet applies. When bit 0 is 0, the VCP packet is applied to the alternate display indicated by bits 11-8 below. If, on the other hand, bit 0 is 1, a logical unit level, then the VCP packet is applied to the primary display. Currently, bits 7-1 of the Display Selection field are reserved for future use and are usually set to zero, or bits are set to a logical zero level.

Bits 11-8 of the Display Selection field use a 4-bit unsigned integer value to determine the alternate display to which the VCP packet applies. When bit 0 of the Display Selection field is 0 (logical zero level), the client interprets bits 11-8 as the alternate display number. If bit 0 is not 0, then bits 11-8 are set to zero and will be ignored. Bits 15-12 are reserved for future use and are usually set to zero, or each bit is set to a logic zero level.

The MCCS Version field contains 2 bytes of information that determine the version of the VESA MCCS specification implemented by the client.

The 2-byte Reply Sequence Number field in the Response with VCP Characteristics packet contains information or data that identifies the sequence number of the Response with VCP Characteristics packets returned by the client. The client returns one or more VCP Characteristic Response packets in response to the VCP Characteristic Request packet with an MCCS control code of 65535. The client can distribute or transmit a response list with characteristics in a plurality of Response Packets VCP specifications. " In this case, the client must assign a sequence number or identifier to each consecutive packet, and the sequence numbers of the “Response with VCP characteristics” packets sent in response to one packet “Request for VCP characteristics” usually start from zero and increase by one. The last element of the “VCP Characteristic Response List” in the last “VCP Characteristic Response” packet should contain a MCCS VCP control code value of 0xffff to identify that this packet is the last and contains the largest sequence number of the returned packet group. If only one “VCP Characteristic Response” packet is sent in response to the “VCP Characteristic Request” packet, then the “Response Number” in this one packet is usually set to zero and the “VCP Characteristic Response List” contains a list item having a VCP code MCCS in the item "List of response with VCP characteristics" equal to 0xffff. The Maximum Value and Present Value (Fig. 71) fields in the packet of the "Response List with VCP Characteristics" are set to zero when the MCCS VCP control code is 0xffff.

The number of characteristics in the List field contains 2 bytes, which determine the number of elements of the “Response List with VCP characteristics” in this packet, while the “List of response with VCP characteristics” field is a group of bytes that contain one or more elements of a "VCP Characteristic Response List". The format of one element of the "VCP Characteristic Response List" in one embodiment is illustrated in FIG.

As shown in FIG. 71, each element of the “VCP Characteristic Response List” has a length of 12 bytes and contains the MCCS VCP Code (VCP MCCS Code), Result Code, Maximum Value, and Present Value fields. value). The 2-byte VCP MCCS Code field contains data or information that identifies the MCCS VCP Control Code Parameter associated with this list item. Only control code values defined in version 2 of the VESA MCCS specification and later are considered valid for this embodiment. The 2-byte Result Code field contains information that identifies an error code related to requesting information regarding the specified VCP MCCS. A value of '0' in this field means that there is no error, while a value of '1' means that the specified control is not implemented in the client. Other values from 2 - 65535 for this field are currently reserved for future use and other applications considered in the prior art, but not yet used.

The 4-byte Maximum Value field defines the highest possible value to which the specified MCCS Control field can be set. If the required control is not implemented in the client, this value is set to zero. If the returned value is less than 32 bits (4 bytes) in length, then the value is converted to a 32-bit integer, leaving the most significant bytes (unused) set to zero. The 4-byte Present Value field contains information that defines the current value of the specified Continuous (C) or Discontinuous Control (NC) VCP MCCS (MCCS VCP Continuous (C) or Non-Continuous (NC) control). If the requested control is not implemented in the client, or if such control is implemented, but is the data type "Table (T)", then this value is set to zero. If the returned value is less than 32 bits (4 bytes) in length than in the MCCS VESA specification, then this value is converted to a 32-bit integer, leaving the most significant (unused) bytes set to zero. If the specified VCP MCCS code corresponds to intermittent control or a table data type, then the Maximum Value field is set or selected to be zero.

28. Package "Setting the characteristics of VCP"

The Set VCP Feature Packet provides a means, mechanism, or method for the master to set VCP control values for both continuous and intermittent client management. In one embodiment, the client indicates this ability to support the VCP Feature Setting package using bit 13 of the Client Feature Capability field in the Client Features package.

The format of the "Set VCP Characteristics" packet in one embodiment is illustrated in FIG. As can be seen from FIG. 72, this type of packet is structured so that it has the Packet Length, Packet Type, hClient ID, Display Selector, VCP MCCS Code, Number of Values in List (Number of Values in list), Control Value List, and CRC. This type of packet is usually identified as a Type 130 packet, as indicated in a 2-byte type field, 20 bytes long, excluding the Packet Length field.

In one embodiment, the hClient ID field again uses a 2-byte value to set or act as a client identifier. This field is reserved for future use and is currently set to zero.

In one embodiment, the 2-byte Display Selector field in the "Set VCP Features" packet determines where to apply the VCP Packet. Bit 0 of the Display Selection field selects the display to which the VCP packet applies. When bit 0 is 0, the VCP packet is applied to the alternate display indicated by bits 11-8 below. If, on the other hand, bit 0 is 1, a logical unit level, then the VCP packet is applied to the primary display. Currently, bits 7-1 of the Display Selection field are reserved for future use and are usually set to zero, or bits are set to logical zero.

Bits 11-8 of the Display Selection field define the alternate display to which the VCP will apply. When bit 0 of the Display Selection field is 0 (logical zero level), the client interprets bits 11-8 as the alternate display number. If bit 0 is not 0, then bits 11-8 are set to zero and will be ignored. Bits 15-12 are reserved for future use and are usually set to zero, or each bit is set to a logic zero level.

The MCCS VCP Code field for the VCP Characterization Package uses 2 bytes of information or values to determine the MCPS VCP control code parameter to be configured. The 2-byte field "Number of values in the list" contains information or values that specify the number of 16-bit values that exist in the "List of control values" field. A "control value list" usually contains one item, unless the MCCS control code refers to a table in the client. In the case of a non-table control, the List of Control Values will contain a value that defines the new value to be written to the control parameter specified by the MCCS VCP Code field. For table-related controls, the data format in the "Control Values List" is determined by the parameter description of the specified VCP MCCS Code. If this list contains values that are larger than one byte, then the least significant byte is transmitted first in a manner that is compatible with the method defined elsewhere in this description. Finally, the 2-byte CRC field contains the 16-bit CRC of all bytes in the packet, including the Packet Length field.

29. Package "Request valid parameters"

The Request Valid Parameter Packet is used as the tool or structure used to request that the client return a Valid Parameter Reply Packet containing a list of parameters supported by the specified NC (intermittent) or Tabular (T) control. This package should only identify intermittent (non-continuous) controls or controls that refer to the table in the client and do not set the value of the MCPS VCP code 65535 (0xffff) to specify all controls. If an unsupported or invalid VCP MCCS code is specified, then the corresponding error value is returned in the "Valid Parameter Response" packet. In one embodiment, the client indicates the ability to support the Request Valid Parameters packet using bit 13 of the Client Feature Capability field in the Client Characteristics Capabilities packet in the Display Capabilities packet.

The format of the Request Valid Parameters packet in one embodiment is illustrated in FIG. As can be seen from FIG. 73, this type of packet is structured to have the Packet Length, Packet Type, hClient ID, Display Selection, VCP MCCS, and CRC fields. This type of packet is usually identified in one embodiment as Type 131, as indicated in the 2-byte type field.

The packet length, which is specified in the 2-byte field Length of the packet, is usually set so as to have the total number of bytes in the packet, not including the packet length field, 8. The hClient ID field again defines the client identifier, but is currently reserved for future use , as is obvious to a person skilled in the art, and is set to zero or a logic zero level.

In one embodiment, the 2-byte Display Selector field in the "Request Valid Parameters" packet determines where to apply the VCP packet. Bit 0 of the Display Selection field selects the display to which the VCP packet applies. When bit 0 is 0, the VCP packet is applied to the alternate display indicated by bits 11-8 below. If, on the other hand, bit 0 is 1, the level is a logical unit, then the VCP packet is applied to the primary display. Currently, bits 7-1 of the Display Selection field are reserved for future use and are usually set to zero, or bits are set to logical zero.

Bits 11-8 of the Display Selection field define the alternate display to which the VCP will apply. When bit 0 of the Display Selection field is 0 (logical zero level), the client interprets bits 11-8 as the alternate display number. If bit 0 is not 0, then bits 11-8 are set to zero and will be ignored. Bits 15-12 are reserved for future use and are usually set to zero, or each bit is set to a logic zero level.

The 2-byte VCP MCCS code field for the Request Valid Parameters packet contains a value that indicates that the VCP MCCS Intermittent Control Code Parameter should be requested. The value in this field should correspond to non-continuous (intermittent) control, which is carried out in the client. Values 256-65535 (0xffff) are usually reserved or treated as invalid, and are treated as unrealized control in the error response. The CRC field, here 2 bytes, contains the CRC of all bytes in the packet, including the Packet Length field.

30. Package "Response about the valid parameters"

The Valid Parameter Reply Packet packet is sent in response to the Valid Parameter Request packet. It is used as a means, method, or structure to identify valid settings for intermittent VCP MCCS control or a control that returns table contents. If the control refers to a table in the client, then the “VCP Parameter Response List” simply contains a given list of consecutive table values that have been requested. If the contents of the table cannot be entered into a single packet "Response about the actual parameters", then the client can be sent a lot of packets with sequential values "Order number of the response." In one embodiment, the client indicates the ability to support the Response on Valid Parameters packet using bit 13 of the Client Characteristics Capabilities field in the Client Capabilities packet.

The master can request the contents of the table as follows: the master sends the VCP Characteristics Setup packet containing the necessary or required parameters, such as a read / write parameter, lookup table offset (TP), and RGB selection; then the Request Valid Parameters packet, which determines the required control, is sent by the master; then the client returns one or more packets "Response about the actual parameters" containing tabular data. This sequence of operations performs a similar function as the table read functions described in the MCCS operating model.

If a specific client parameter is not supported by the client, then in one embodiment, the corresponding field of this package will contain the value 255. For parameters that are used in the client, the corresponding field should contain the value of this parameter in the client.

The actual parameter response packet format for one embodiment is illustrated in FIG. As can be seen from Fig. 74, this type of packet is structured to have Packet Length, Packet Type, cClient ID, Display Selection, VCP MCCS Code, Response Code, Reply Sequence Number, Number Values in List, VCP Parameter Reply List, and CRC. This type of packet is typically identified for one embodiment as Type 132, as indicated in the 2-byte type field.

The cClient ID field is reserved for the future client identifier, as is known from the above description.

In one embodiment, the 2-byte Display Selection field contains information on where to apply the VCP packet. Bit 0 of the Display Selection field selects the display to which the VCP packet applies. If bit 0 is 0, the VCP packet is applied to the alternate display indicated by bits 11-8 below. If, on the other hand, bit 0 is 1, the level is a logical unit, then the VCP packet is applied to the primary display. Currently, bits 7-1 of the Display Selection field are reserved for future use and are usually set to zero, or bits are set to logical zero.

Bits 11-8 of the Display Selection field define the alternate display to which the VCP Packet should apply. When bit 0 is 0 (logical zero level), the client interprets bits 11-8 as the alternate display number. If bit 0 is not 0, then bits 11-8 are set to zero and will be ignored. Bits 15-12 are reserved for future use and are usually set to zero, or each bit has a logic zero level.

In one embodiment, the 3-byte "MCPS VCP Code" packet (MCCS VCP Code Packet) contains a value that defines the non-continuous "VCP MCCS Control Code Parameter" that is described by this packet. If an invalid VCP MCCS control code is specified by the Request Valid Parameters package, then the same invalid parameter value will be defined in this field with the corresponding value in the Response Code field. If the "MCCS Control Code" is invalid, then the "VCP Parameter Response List" will be zero length.

The “Response code” field contains 2 bytes of information or values that specify the nature of the response related to the request for information regarding the specified “VCP MCCS Control”. If the value in this field is 0, then it is considered that there is no error for this data type, and they send the last packet "Response about the actual parameters" in the sequence having the highest "Order number of the response". If the value in this field is 1, then it is considered that there is no error, but other packets "Reply about the valid parameters" that have large sequence numbers will be sent. If the value in this field is 2, then the specified control is considered as not implemented in the client. If the value in this field is 3, then the specified control is not a continuous (intermittent) control (it is a continuous control that always has a valid set of all values from zero to its maximum value). Values for this field, set between 4 and 65535, are reserved for future use and are generally not used.

The 2-byte Reply Sequence Number field identifies the sequence number of the Response for Valid Parameters packets returned by the client. The client returns one or more packets "Response about the actual parameters" in response to the packet "Request valid parameters". A client may distribute a "VCP Parameter Response List" in a plurality of "Valid Parameter Response" packets. In this latter case, the client will assign a sequence number to each consecutive packet and set the “Response Code” to 1 for all but the last packet in the sequence. The last packet, “Response on Valid Parameters” in the sequence will have the largest “Sequence Number of the Response”, and the “Response Code” contains the value 0.

The 2-byte field “Number of Values in the List” defines the number of 16-bit values that exist in the “VCP Parameter Response List”. If the "Response code" is not equal to zero, then the "Number of values in the list" parameter is zero. The VCP Parameter Response List field contains a list of 0 to 32760 2-byte values that indicate a set of valid values for the non-continuous control indicated by the MCCS Control Code field. Non-continuous control code definitions are specified in the MCCS VESA specification. Finally, in this embodiment, the CRC field contains a 16-bit CRC code of all bytes in the packet, including the "Packet Length" field.

Scalable Video Stream Images

An MDDI or protocol mechanism, structure, means, or method provides support for scalable video stream images that allow the master to send an image to a user that is scaled as larger or smaller than the original image and the scalable image is copied to the main image buffer. A brief overview of the scalable video stream functionality and related protocol support is provided elsewhere in this description. The ability to support scalable video streams is determined by or in the Scaled Video Stream Capability Packet itself, which is sent in response to the Request Specific Status Packet.

The title of the Scalable Video Stream package described below is slightly different from the simpler Video Stream package, whose title contains the full context needed to display the image. The Scalable Video Stream package uses the installation package to determine the window size and position in the source and destination, and the separate Scalable Video Stream package to transmit pixel data. The client allocates the internal memory associated with each stream in order to save the stream parameters from the installation package and part of the pixel data associated with each stream. The amount of memory required for each stream will vary depending on the size of the source and destination images and the values specified in the installation package. For this reason, the protocol is designed to allow the client to dynamically allocate memory to allocate the memory associated with each scalable video stream.

It is useful to send the stream to a video display having a size inherent in the program source and have the scale and position of the image on the display to display the image in a manner suitable for a particular end use. Real-time scaling of multiple video images is complex enough to support this feature optional in the client.

31. The package "Features scalable video stream"

The “Scalable Video Stream Features” package defines the image characteristics of the scalable video stream source in the client or used by the client. The format of the “Scalable Video Stream Capabilities” packet is shown in general form in FIG. As can be seen from Fig. 75, in one embodiment, the “Scalable Video Stream Capabilities” package is structured to have the Packet Length, Packet Type, cClient ID, Max Number of Streams (maximum number of streams), Source Max X Size (maximum size by X source), Source Max Y size (maximum size by Y source), RGB Capability (Monochrome Capability), Reserved 1, Y Cr Cb Reserved, Reserved 2, and CRC . The packet length in one embodiment is fixed and equal to 20 bytes, as indicated in the length field, including the 2-byte cClient ID field, which is reserved for use by the client identifier, otherwise set to zero, and the CRC field. In one embodiment, the client indicates the ability to support the “Scalable Video Stream Capabilities” packet using the parameter value 143 in the “Valid Parameter Response List” in the “Valid Status Response List” packet.

The 2-byte field “Maximum number of streams” contains a value for identifying the maximum number of simultaneous scalable video streams that can be assigned simultaneously. In one embodiment, the client must reject the request to allocate a scalable video stream if the maximum number of scalable video streams has already been allocated (assigned). If less than the maximum number of scalable video streams is assigned, then the client may also reject the distribution request based on other resource restrictions in the client.

Fields Maximum size in X and Y of the source (2 bytes) determine the values for the maximum width and height, respectively, of the source image of the scalable video stream, expressed as the number of pixels.

The RGB Capability field uses values to determine the number of resolution bits that can be displayed in RGB format. If the scalable video stream cannot use the RGB format, then this value is set to zero. The word “RGB Capability” consists of three separate unsigned values: bits 3-0 determine the maximum number of bits of blue (intensity of blue) in each pixel, bits 7-4 determine the maximum number of bits of green (intensity of green) in each pixel, and bits 11-8 determine the maximum number of red bits (red intensity) in each pixel, while bits 15-12 are reserved for future use to determine future capabilities and are usually set to zero.

The 1-byte field "Possibility of monochrome representation" contains a value that determines the number of resolution bits that can be displayed in a single-color (monochrome) format. If the scalable video stream cannot use the single-color format, then this value is set to zero. Bits 7-4 are reserved for future use and should therefore be set to zero ('0') for current applications, although this may change after some time, as is obvious to those skilled in the art. Bits 3-0 determine the maximum number of halftone bits (gray levels) that may exist in each pixel. These four bits make it possible to determine that each pixel contains from 1 to 15 bits. If this value is zero, then the monochrome format is not supported by the scalable video stream.

The Reserved 1 field (1 byte here) is reserved for future use to provide values related to the information or data of the Scalable Video Stream package. Therefore, at present, all bits in this field are set equal to the logical '0'. One purpose of this field is to align all subsequent 2-byte fields to a 16-bit word address and align 4-byte fields to a 32-bit word address.

The 2-byte “Y Cb Cr Capability” field contains values that specify the number of resolution bits that can be displayed in the Y Cb Cr format. If the scalable video stream cannot use the YCb Cr format, then this value is zero. The word “Capabilities Y Cb Cr” consists of three separate unsigned values: bits 3-0 determine the maximum number of bits that specify the Cr sample; bits 7-4 determine the maximum number of bits that specify a sample of Cb; bits 11-8 determine the maximum number of bits that specify a sample of Y; and bits 15-12 are reserved for future use and are usually set to zero.

The 1-byte Capability bits field contains a set of flags that identify the capabilities associated with the scalable video stream. These flags are defined as follows: bit 0 covers the pixel data in the “Scalable Video Stream” packet, which can be in a packed format. An example of packed and byte-aligned pixel data is shown above in FIG. 13. Bit 1 is reserved for future use and is usually set to zero; bit 2 is also reserved for future use and is set to zero; bit 3 covers scaled video streams that can be specified in the color map data format. The same color map table is used for those scalable video streams that are used for the main image buffer and image planes with an alphabetical cursor. The color map is configured using the Color Map package described elsewhere in this description; and bits 7-4 are reserved for future use and are usually set to zero.

The Reserved 2 field (1 byte here) is reserved for future use to provide values related to the information or data of the Scalable Video Stream package. Therefore, at present, all bits in this field are set equal to the logical '0'. One purpose of this field is to align all subsequent 2-byte fields to a 16-bit word address and align 4-byte fields to a 32-bit word address.

32. Package “Installation of scalable video stream”

The Scaled Video Stream Setup Packet provides a tool, structure, or method used to determine the parameters of a scalable video stream, and the client uses this information to allocate RAM for buffering and scaling the image. The stream can be freed (redistributed) by sending this packet with the fields “Image size in X” and “Image size in Y” equal to zero. Scalable video streams that have been released can be redistributed later with the same or different stream parameters. In one embodiment, the client indicates the ability to support the Install Scalable Video Stream Packet using the parameter value 143 in the Valid Parameter Response List in the Valid State Response List packet and using a nonzero value in the Maximum Streams box in the packet "Features scalable video stream."

The format of the package "Installation scalable video stream" is shown in General view on Fig. As can be seen from FIG. 76, in one embodiment, the “Set Scalable Video Stream Installation” package is structured to have the Package Length, Package Type, hClient, Stream ID, Video Data Format Descriptor fields. , Pixel Data Attributes, X Left Edge (X left border), Y Top Edge (Y upper border), X Right Edge (X right border), Y Bottom Edge (Y lower border), X Image Size ( Image Size by X), Y Image Size and CRC.

The 2-byte “Packet Length” field defines the total number of bytes in the packet, not including the packet length field. In one embodiment, this packet length is set to 24. The 2-byte “Packet Type” field uses a value of 136 to identify the packet as a “Set Scalable Video Stream” packet. The 2-byte hClient ID field is reserved for future use as a client identifier, and usually all bits are set to a logical zero value for the time being or until the protocol user determines which identifier values should be used, as may be known.

The Stream Identifier field uses 2 bytes to specify a unique identifier for the stream identifier. This value is assigned by the master and has values from zero to the maximum value of the "Flow Identifier" specified in the "Client Features" packet. The master must carefully monitor the use of “Stream ID” values to ensure that each active thread is assigned a unique value and that threads that are no longer active are freed or reassigned.

In one embodiment, the Video Data Format Descriptor field uses 2 bytes to specify the format of each pixel in the pixel data in the current stream in the current packet. The pixel data format must obey at least one of the valid formats for the image plane with the alphabet cursor, which can be defined in the Alphabet Cursor Image Capabilities package or another predetermined image template that is usually defined in the other packages described above. A “video data format descriptor” defines a pixel format only for the current packet and does not imply that the constant format will continue to be used during the lifetime of a particular video stream. 12 illustrates an embodiment of how the “Video Data Format Descriptor” is encoded, and as described above for other packets.

For example, as can be seen from FIG. 12A-12D and for use in one embodiment, when the bits [15:13] are '000', then the video data consists of an array of monochrome pixels, where the number of bits per pixel is determined by bits 3-0 of the word "Video format format descriptor". Bits 11-4 are usually reserved for future use or applications and are set to zero in this situation. When bits [15: 13] are instead equal to '001', then the video data consists of an array of color pixels, where each sets a color from a color map (palette). In this situation, bits 5-0 of the word "Video format descriptor" determine the number of bits per pixel, and bits 11-6 are usually reserved for future use or applications and are set to zero. When bits [15:13] are instead equal to the values of '010', then the video data consists of an array of color pixels, where the number of bits per red pixel is determined by bits 11-8, the number of bits per green pixel is determined by bits 7- 4 and the number of bits per blue pixel is determined by bits 3-0. In this situation, the total number of bits in each pixel is the sum of the number of bits used for red, green, and blue.

However, when the bits [15:13] instead are equal to the values or the string '011', as shown in Fig. 12D, then the video data consists of an array of video data in YCbCr 4: 2: 2 format with luminance and color information, where the number of bits in per pixel, the luminance signal (Y) is determined by bits 11–8, the number of bits of the Cb component is determined by bits 7–4, and the number of bits of the Cr component is determined by bits 3–0. The total number of bits in each pixel is the sum of the number of bits used for red, green, and blue. The components Cb and Cr are sent at half the transmission rate from the speed for Y. In addition, the video samples in the “Pixel data” part of this packet are organized as follows: Cbn, Yn, Crn, Yn + 1, Cbn + 2, Yn + 2, Crn +2, Yn + 3, ..., where Cbn and Cm are associated with Yn and Yn + 1, and Cbn + 2 and Crn + 2 are associated with Yn + 2 and Yn + 3, and so on. Yn, Yn + 1, Yn + 2, and Yn + 3 are the brightness values of four consecutive pixels in one row from left to right.

For all four formats described above, bit 12, which is indicated by “P” in the drawings, determines whether the “Pixel data” samples are really packed or aligned pixel data. A value of '0' in this field indicates that each pixel in the Pixel Data field is aligned byte with the byte boundary of MDDI. A value of '1' indicates that each pixel and each color in each pixel in the “Pixel Data” is packed next to the previous pixel or color in the pixel, leaving no unused bits.

In one embodiment, the 2-byte “Pixel Data Attributes” field has values that are interpreted as follows: bits 1 and 0 are reserved for future use as long as they are set to logical zero, and bit 2 indicates whether the “Pixel data” is actually interlaced format. When bit 2 is 0, then “Pixel Data” is in a standard progressive format. The line number (Y coordinate of the pixel) increases by 1 when moving from one line to the next. When bit 2 is 1, then “Pixel Data” is in interlaced format. The line number (Y coordinate of the pixel) increases by 2 when moving from one line to the next.

In one embodiment, bit 3 indicates whether the “Pixel Data” is in an alternate pixel format. This is similar to the standard interlaced mode allowed by bit 2, but with vertical rotation instead of horizontal rotation. When bit 3 is 0, “Pixel Data” is generated or placed in a standard progressive format. The column number (X coordinate of the pixel) is incremented by 1 when each successive pixel is received. When bit 3 is 1, then “Pixel data” is generated or placed in an alternative pixel format. The column number (X coordinate of the pixel) is incremented by 2 when each pixel is received.

Bits 4-15 are also reserved for future use, and are usually set to logic level or logical zero for current applications or constructs.

33. Package "Confirmation scalable video stream"

The Scaled Video Stream Acknowledgment Packet allows the user to acknowledge receipt of the Set Up Scalable Video Stream Packet. The client can indicate the ability to support the “Confirmation of scalable video stream” packet by means of the parameter value 143 in the “Response list about the actual parameter” in the packet “Response list of the actual state” and by the nonzero value in the field “Maximum number of streams” in the packet “Scalable stream capabilities” video".

The format of the "Confirmation of the scalable video stream" packet is shown in general form in Fig.77. As can be seen from FIG. 77, in one embodiment, the “Scalable Video Stream Confirmation” packet is structured to have the Packet Length, Packet Type, cClient ID (Client ID), Stream ID (Stream ID), ACK Code (ACK Code) fields. ) and CRC. The 2-byte “Packet Length” field is used to determine the total number of bytes, excluding the packet length field, with a value of 10 for this packet type, while the value of the “Packet Type” field 137 identifies the packet as a “Scalable Video Stream Confirmation” packet .

The 2-byte cClient ID field is reserved for future use by the client ID and is usually set to zero. The 2-byte “Stream ID” field defines a unique identifier for the stream ID. It is the same value that was assigned by the master in the Set Up Scalable Video Stream Package.

The 2-byte Ack Code field provides values containing a code that describes the result of an attempt to update the specified scalable video stream. In one embodiment, these codes are defined as follows:

0 - attempt to assign a stream was successful.

1 - attempt to free the thread was successful.

2 - Invalid attempt to assign a thread ID that has already been allocated.

3 - Invalid attempt to release a thread ID that has already been released.

4 - the client does not support scalable video streams.

5 - stream parameters are incompatible with the ability of the client.

6 - the value of the "Flow Identifier" is greater than the maximum value allowed by the client.

7 - not enough resources available in the client to assign the specified stream.

The 2-byte CRC field contains the CRC of all bytes in the packet, including the "Packet Length" field.

34. Scalable Video Stream Package

The Scalable Video Stream package is used to transmit the pixel data associated with a particular scalable video stream. The size of the area indicated by this package is determined by the “Install Scalable Video Stream” package. The client can indicate the ability to support the “Scalable video stream” package using the parameter values 143 in the “Valid parameter response list” in the “Valid status response list” packet and using the response on the successful assignment of the scalable video stream in the Ack Code field (confirmation code) Confirmation of scalable video stream package.

The format of one embodiment of the “Scalable Video Stream” package is shown in general form in FIG. As can be seen from Fig. 78, the “Scalable Video Stream” packet is structured so that it has the Packet Length, Packet Type, hClient ID, Stream ID, Pixel Data Attributes, Pixel Count (Pixel Count) fields. ), CRC Parameter, Pixel Data and CRC Pixel Data. The 2-byte Packet Type field uses a value of 18 to identify the packet as a Scalable Video Stream packet. The hClient ID field is reserved for the client identifier and is usually set to zero. As before, the 2-byte “Stream Identifier” field defines a unique identifier for the stream identifier. This value is indicated by the master in the "Install Scalable Video Stream" package and confirmed in the "Confirm Scalable Video Stream" package.

In one embodiment, the 2-byte “Pixel Data Attributes” field has values that define the routing of the pixel data and the update of the display or the location of the buffers. These values in one embodiment are interpreted as follows: bits 1 and 0 select a display where pixel data should be routed. For bit values of '11' or '00', pixel data is directed to or displayed for both eyes, for bit values of '10', pixel data is sent only to the left eye, and for bit values of '01', pixel data is directed only to the right eye.

Bits 7 and 6 are the Display Update bits that define the image buffer where pixel data should be written. The effect of “Frame Update Bits” is described in more detail elsewhere in the description. When bits [7: 6] are '01', the pixel data is written to the offline image buffer. When bits [7: 6] are '00', the pixel data is written to the image buffer used to regenerate the display. When bits [7: 6] are '11', pixel data is written to all image buffers. If bits [7: 6] are '10', this is treated as an invalid value. These bits are currently reserved for future use. In this situation, the pixel data will be ignored and will not be written to any of the image buffers. Bits 15-14 and 11-8 are reserved for future use and are usually set to a level or logical zero value.

In one embodiment, bits [13:12], or 13 and 12, are used to determine whether the pixels of the destination (destination) should be written to the destination location when they refer to a transparent color and a transparent mask. When bits [13:12] are equal to value or values 00, then transparent color is not used. The resulting destination pixel is written to the location of the destination pixel without considering the value of the transparent color or the transparent mask. Transparent color is determined by the “Set transparent color and mask” package. The value or values 01 for bits [13:12] are reserved for future use and are generally not used or are not considered a reliable condition. When bits [13:12] are equal to the value or values of 10, the destination pixels are written to the destination location, unless the result of the logical AND operation of the source image pixel and the transparent mask is equal to the transparent color, in which case the resulting pixel is not written to the destination pixel location . When bits [13:12] are equal to the value or values of 11, the destination pixels are not written to the location of the destination pixel, unless the result of the logical AND operation of the source image pixel and the transparent mask is equal to the transparent color, in which case the resulting pixel is written to the pixel location addressee.

The 2-byte field “Number of pixels” defines the number of pixels in the field “Pixel data” below. The 2-byte “CRC Parameter” field has a CRC code of all bytes from “Packet Length” to “Number of Pixels”. If this CRC field gives a validation error, then the entire packet is discarded. The 2-byte Pixel Data field contains raw video information that needs to be scaled and then displayed. The data is formatted in the manner described by the Video Data Format Descriptor field. Data is passed line by line at a time as defined above.

The 2-byte “Pixel Data CRC” field contains only the “Pixel Data” fields CRC. If this CRC field gives an error during verification, then the "Pixel data" can still be used, but the value of the CRC code error counter is incremented.

35. Package "Request for a specific state"

The Request Specific Status Packet package provides a means, mechanism, or method for the host device to request that the client send the capabilities or status packet back to the host device as specified in this packet. The client returns a packet of the specified type in the next “Reverse Link Encapsulation” packet. The client will usually set bit 17 in the Client Feature Capability field in the “Client Capabilities” packet if the client is able to respond to the “Request a specific state” packet A convenient way for the master to determine all types of status packets that the client can return or transmit is to use the "Valid Status Response List" packet described elsewhere in the description, the Client may indicate the ability to respond with the "Response List of the Actual Status" packet using bit 21 of the "Client Features Capabilities" field in the "Client Capabilities" packet.

The format of one embodiment of the "Request for a specific state" packet is shown in general form in Fig. 79. As can be seen from FIG. 79, the “Specific Status Request” packet is structured to have the “Packet Length”, “Packet Type”, hClient ID, Status Packet ID, and CRC fields.

The packet length field determines the total number of bytes in the packet, not including the packet length field, and is usually set to 10 for this type of packet. A Packet type of 138 identifies the packet as a “Specific State Request” packet. The Client Identifier field (2 bytes) is reserved for future use for the client identifier and is set to zero so far, while the 2-byte Status Packet Identifier field determines the type of functionality or status packet that the client is about to send to the master . Typical package types are:

66 - Package "Client Features" sent by the client.

133 - The “Alphabet Cursor Image Capabilities” packet sent by the client.

139 - The “Valid Status Response List” packet is sent by the client, which identifies the exact types of capability and status packets that the client can send.

141 - Package “Client Personal Opportunities” sent by client.

142 - Client Error Report Packet sent by client.

143 - The “Scalable Video Stream Features” packet sent by the client.

144 - Package "Client Identification Information" sent by the client.

Package types 56-63 may be used for identifiers of a manufacturer-defined capability and status.

The CRC field again contains the CRC of all bytes in the packet, including the Packet Length.

36. Package "List of response about the actual state"

The Valid Status Reply List Packet provides the host device with a structure, means, or method of having packets with a status list and the capabilities that the client is able to return. The client can indicate the ability to support the package "List of response about the actual state", using bit 21 of the field "Features of the client characteristics" in the package "Client capabilities".

The format of one embodiment of the “Valid Status Response List” packet is shown in a general form in FIG. 80. As can be seen from Fig. 80, the package "List of response about the actual state" is structured so that it has the fields Packet Length, Packet Type, cClient ID, Number of Values in List, Valid Parameter Reply List valid parameters) and CRC. The packet length for this type of packet is usually set to a value of 10, and a type value of 139 identifies the packet as a "Valid Status Response" packet. The cClient ID field is reserved for future use as a client identifier and is usually set to zero. The 2-byte field “Number of Values in the List” determines the number of elements in the next “Response List on Valid Parameters”.

The Valid Parameter Reply List field contains a list of 2-byte parameters that specify the types of packets about the functionality or state that the client can send to the master. If the client indicated that he can respond to the “Request a specific state” packet (using bit 21 of the “Client characteristics capabilities” field in the “Client capabilities” packet), then he is able to send at least the “Client capabilities” packet (Package Type = 66) and the package "List of response about the actual state" (Package Type = 139). The types of packet that can be sent by the client and can be included in this list, together with their respective assignments for the purposes of one embodiment, are as follows:

66 - Package "Customer Features".

133 - Package "Features of the image of the alphabetical cursor."

139 - Packet "Valid Status Response List" that identifies the exact types of capability and status packets that the client can send.

141- Package "Personal display capabilities."

142 - Package "Report client errors."

143 - Package "Features scalable video stream."

144 - Package "Customer Identification Information".

145 - Package "Features alternative display."

Package types equal to 56-63 may be used for identifiers of manufacturer-defined capabilities and status.

The CRC field contains the CRC of all bytes in the packet, including the Packet Length.

37. Package "Personal display capabilities"

The Personal Display Capability Packet provides a set of parameters that describe the capabilities of a personal display device, such as a head-mounted display or display glasses. This enables the master to customize the display information according to the specific capabilities of the client. The client, on the other hand, indicates the ability to send the “Personal Display Capability” packet using the corresponding parameter in the “Response List of Valid Parameters” in the packet “Response List of Valid Parameters”.

The format of one embodiment of the “Personal Display Capabilities” package is shown in a general view in FIG. As can be seen from FIG. 81, the “Personal Display Capability” package is structured so that it has the Package Length, Package Type, cClient ID, Sub-Pixel Layout, Pixel Shape, Horizontal Field of View (Horizontal Field of View), Vertical Field of View, Visual Axis Crossing, Lft./Rt. Image (Overlapping Left / Right Image), See Through, Maximum Brightness, Optical Capability, Minimum IPD (Maximum IPD), Maximum IPD (Maximum IPD), Points of IFeld of Curvature List ( List of points of the field of curvature) and CRC. In one embodiment, the value of the Packet Length field is set to 68. The Packet Type value of 141 identifies the packet as a “Personal Display Capability” packet. The cClient ID field is reserved for future use and is set to zero so far.

In one embodiment, the “Sub-pixel location” field determines the physical placement of the sub-pixel from top to bottom and from left to right, using values: 0 - to indicate that the placement of the sub-pixel is not defined; 1 - to indicate a red, green, blue strip; 2 - to indicate the blue, green, red strip; 3 - to indicate a quad pixel having a 2-by-2 sub-pixel layout with red at the top left, blue at the bottom right, and two green sub-pixels, one at the bottom left and the other at the top right; 4 - to indicate a quad pixel having a 2-by-2 sub-pixel layout with a red sub-pixel in the lower left, blue in the upper right, and two green sub-pixels, one in the upper left and the other in the lower right; 5 - to indicate the Delta (Triad); 6 - to indicate a mosaic with overlapping red, green and blue (for example, a liquid crystal display on silicon (LCOS) with alternating color fields); and with values from 7 to 255, usually reserved for future use.

In one embodiment, the Pixel Shape field defines the shape of each pixel, which consists of sub-pixels of a specific configuration, using a value of: 0 to indicate that the shape of the sub-pixel is not defined; 1 - to indicate a circle; 2 - to indicate the square; 3 - to indicate a rectangle; 4 - to indicate the oval; 5 - to indicate an ellipse; and with values from 6 to 255 reserved for future use in indicating the required forms, as obvious to those skilled in the art.

In one embodiment, a 1-byte Horizontal Field of View (HFOV) field defines a horizontal field of view in increments of 0.5 degrees (for example, if HFOV is 30 degrees, this value is 60). If this value is zero, then the HFOV is undefined.

In one embodiment, a 1-byte Vertical Field of View (VFOV) field defines a vertical field of view in increments of 0.5 degrees (for example, if VFOV is 30 degrees, this value is 60). If this value is zero, then VFOV is undefined.

In one embodiment, the 1-byte “Visual Axis Intersection” (focal length) field defines the crosshair of the visual axes in increments of 0.01 diopters (1 / m) (for example, if the focal length is 2.22 meters, this value is 45) . If this value is zero, then the value "Intersection of the visual axis" is not defined.

In one embodiment, the 1-byte Left / Right Image Overlap field determines the percentage of overlap of the left and right image. The acceptable percent overlap range is from 1 to 100. Values from 101 to 255 are invalid and should not usually be used. If this value is zero, then the image overlap is not defined.

In one embodiment, the 1-byte See Through field defines the percentage of transparency of the image. The valid transparency range in percent is from 0 to 100. Values from 101 to 254 are invalid and should not be used. If this value is 255, then the percentage of transparency is not defined. The 1-byte Maximum Brightness field defines the maximum brightness in increments of 20 nits (for example, if the maximum brightness is 100 nits, this value is 5). If this value is zero, then the maximum brightness is not defined.

In one embodiment, the 2-byte “Optical Capability Flags” field contains various fields that define the optical capabilities of the display. These bit values are usually assigned with bits 15-5 reserved for future use and are usually set to logic zero. Bit 4 selects the Eye Glass Focus Adjustment with a value of '0', which means the display has no focus adjustment for the eyes, and a value of '1', which means that the display has a focus setting for the eyes. Bits 3-2 select the Binocular Function according to the following: a value of 0 means that the display is binocular and can only display 2-dimensional (2D) images; 1 means the display is binoculars and can display 3-dimensional (3D) images; 2 means the display is a monocular, and 3 reserved for future use. Bits 1-0 select "Left-Right Field Curvature Symmetry" with a value of 0, meaning that the curvature of the field is not defined. If this field is zero, then all field curvature values from A1 to E5 are set to zero, except for point C3, which determines the focal length of the display, or should be set to zero to indicate that the focal length is not determined. A value of 1 means that the Left and Right displays have the same symmetry; 2 means that the Left and Right displays are mirrored with respect to the vertical axis (column C); and 3 reserved for future use.

In one embodiment, the 1-byte Inter-Pupillary Distance (IPD) Minimum field defines the minimum interpupillary distance in millimeters (mm). If this value is zero, then the minimum interpupillary distance is not defined. The 1-byte Inter-Pupillary Distance (IPD) Maximum field defines the maximum interpupillary distance in millimeters (mm). If this value is zero, then the maximum interpupillary distance is not determined.

The Points of Field Curvature List contains a list of 25 2-byte parameters that determine the focal length in thousandths of diopters (1 / m) in the range from 1 to 65535 (for example, 1 is 0.001 diopters, and 65535 - 65.535 diopters). These 25 elements in the “Field Curvature Point List” are labeled A1-E5, as shown in FIG. 82. Points should be evenly distributed over the active area of the display. Column C corresponds to the vertical axis of the display, and line 3 corresponds to the horizontal axis of the display. Columns A and E correspond to the left and right borders of the display, respectively. And lines 1 and 5 correspond to the upper and lower boundaries of the display, respectively. The order of 25 points on the list is: A1, B1, C1, D1, E1, A2, B2, C2, D2, E2, A3, B3, C3, D3, E3, A4, B4, C4, D4, E4, A5, B5, C5, D5, E5.

The CRC field contains the CRC of all bytes in the packet, including the "Packet Length" field.

38. Package “Client Error Report”

The Client Error Report Packet acts as a mechanism or tool to allow the client to list operational errors on the host device. The client can detect a wide range of errors during its normal operation as a result of receiving some commands from the master. Examples of these errors include: the client may have been instructed to work in a mode that it does not support, the client may have received a packet containing some parameters that are outside the set or outside the capabilities of the client, the client may have been instructed to enter mode in the wrong order. The Client Error Reporting package can be used to detect errors during normal operation, but is most useful for the system designer and integrator to diagnose problems in the development and integration of client and master systems. The client indicates his ability to send the “Client Error Report” packet using the parameter value equal to 142 in the “Response List of Valid Parameters” in the “Response List of Valid Parameters” packet.

The format of one embodiment of the “Client Error Reporting” package is illustrated in general terms in FIG. As can be seen from FIG. 83, the “Client Error Report” packet is structured to have the Packet Length, Packet Type, cClient ID, Number of List Items, Error Code List, and CRC fields. A Package Type value of 142 identifies the package as a Client Error Reporting packet. The cClient ID field is reserved for future use and, for now, is usually set to zero. The “Number of list items” field (2 bytes) determines the number of items in the next “List of error codes”. The “List of error codes” field (8 bytes here) is a list containing one or more elements of the “List with error report”. The format of one “Error Report List” item is illustrated in FIG. 84.

In one embodiment, as shown in FIG. 84, each “Error Report List” entry is exactly 4 bytes long and has a structure in one embodiment comprising: a 2-byte Display Error Code field, which defines the type of error being reported, the 2-byte Error Sub-code field, defines a greater level of detail regarding the error defined by the Client Error Code package. The specific definition of each “Customer Error Code” is determined by the manufacturer of the client. An error sub-code should not be defined for each “Display error code”, and in cases where the “Error sub-code” is not defined, this value is set to zero. The specific definition of each “Sub-error code” is determined by the customer’s manufacturer.

39. Package “Client Identification Information”

The Client Identification Packet allows the user to return identification information in response to a Request for a Specific Status packet. In one embodiment, the client indicates the ability to send the “Client Identity Information” packet using a parameter value of 144 in the “Valid Parameter Response List” in the “Valid Parameter Response List” packet. This is useful for the master to be able to determine the name of the manufacturer of the client device and the model number by reading this data from the client. This information can be used to determine if the client has special features that cannot be described in the Client Features package. There are two possible ways, means or mechanism for reading identification information from a client. One of them is the use of the “Client Features” package, which contains fields similar to the fields in the basic EDID structure (support for displays with an extended identification system). Another way is to use the “Client Identification Information” package, which contains a richer set of information compared to the corresponding fields in the “Client Features” package. This allows the master to identify manufacturers who have not been assigned a 3-character EISA code, and allows alphanumeric characters to be included in the serial numbers.

The format of one embodiment of the “Client Identity Information” package is illustrated in a general way in FIG. As can be seen from FIG. 85, the “Client Identification Information” package is structured so that it has the fields Package Length, Package Type, cClient ID, Week of Mfr, Year of Mfr. (Year of manufacture), Length of Mfr Name, Length of Product Name, Length of Serial Number, Manufacturer Name String, Product Name String product), Serial Number String, and CRC.

The 2-byte Packet Length field contains a value that identifies the packet as a Client Identity Information packet. This value is selected equal to 144 in one embodiment. The cClient ID field (2 bytes) is again reserved for future use by the client identifier and is usually set to zero. The CRC field (2 bytes) contains the 16-bit CRC of all bytes in the packet, including the "Packet Length" field.

The 1-byte field “Production Week” contains a value that determines the week of manufacture of the display. In at least one embodiment, this value is in the range of 1 to 53, if supported by the client. If this field is not supported by the client, then it is usually set to zero. The 1-byte field “Year of manufacture” contains a value that determines the year of manufacture of the client (display). This value is equal to the displacement since 1990 as a starting point, although other base years may be used. Years in the range from 1991 to 2245 can be expressed by this field. Example: Year 2003 corresponds to the value of 13 “Year of manufacture”. If this field is not supported by the client, it must be set to zero.

The fields “Manufacturer name length”, “Product name length”, and “Serial number length” each contain 2-byte values that define the length of the “Manufacturer name string” field, including any zero termination or empty placeholders, the field length “ Product name string ”, which includes any null termination or empty placeholders, and the length of the“ Serial number string ”field, which includes any null termination or empty placeholders, respectively.

The fields “Manufacturer name string”, “Product name string” and “Serial number string” each contain a variable number of bytes indicated by the fields “Manufacturer name length”, “Product name” and “Serial number”, respectively, which contain a string of ASCII characters, which identify the manufacturer, product name, and alphanumeric display serial number, respectively. Each of these lines ends with at least one space character.

40. Package “The possibility of an alternative display”

The Alternate Display Capability Packet is used as a means, structure, or method to indicate the possibility of alternative displays connected to an MDDI client controller. It is sent in response to the “Request a specific state” packet. Upon request, the client device sends an Alternate Display Capability packet for each alternate display that is supported. If the client has more than one alternate display, then the client must send, form, or provide multiple “Alternate Display Capability” packets, one for each display, in response to a single “Request a specific state” packet, although some configurations may use multiple “Request Alternate Display” packets specific condition ”if necessary, although this is less effective. The client can send the “Alternative Display Capability” packet in a way that can be called “inconsistent order” based on the value of the “Number of Alternative Displays” field. The client can indicate the ability to send the “Alternative Display Capability” packet by the value of parameter 145 in the “Valid Parameter Response List” in the “Valid Parameter Response List” packet.

For MDDI systems used in internal mode, it may be a general rule to have more than one display connected to the MDDI client controller. An example of an application is a mobile phone with a large display on the inside of the hinged cover and a smaller display on the outside. It is not necessary for an internal mode client to return the “Alternative Display Capability” packet for two possible reasons. First, the master device may already be programmed or otherwise informed of these capabilities during manufacture, as they are used in a conventional device or enclosure. The second - due to the assembly of these two parts, the client cannot be easily disconnected or disconnected from the connection with the master device, and the master device may contain a hard-coded copy of the client’s capabilities or at least know that they do not change when replaced in the client, otherwise could happen.

The “Number of alternative displays” field in the “Client Features” package is used to indicate that more than one display is connected, and the “Alternative Display Features” package reports the possibility of each additional display. The video stream packet contains 4 bits in the Pixel Data Attributes field to address each alternate display in the client device.

The format of one embodiment of the “Alternative Display Capability” package is illustrated in a generic manner in FIG. As can be seen from FIG. 86, the “Alternative Display Capability” package is structured to have the Package Length, Package Type, cClient ID, Alt Display Number, Reserved 1, Bitmap Width, Bitmap Height, Display Window Width, Display Window Height, Color Map RGB Width, RGB Capability (RGB Capability), Monochrome Capability (Monochrome Capability Display), Reserved 2, Y Cb Cr Capability, Bayer Capability (Reserved Bayer Capability), Reserved e 3, Display Feature Capability and CRC. A Package Type value of 145 identifies the package as an Alternate Display Capability packet. The cClient ID field is currently reserved for the client identifier for future use and is usually set to zero, usually setting the bits to a logical zero level.

The Number of Alternative Displays field uses 1 byte to indicate the identification information of the alternative display with an integer ranging from 0 to 15. The first alternative display is usually indicated by the number 0, and other alternative displays are identified by the unique number of Alternative Displays, with the highest value being used. is the total number of alternative displays minus 1. Values greater than the total number of alternative displays minus 1 are not used. Example: a mobile phone having a primary display and a caller ID display connected to the MDDI client has one alternative display, so that the “Number of alternative displays” for displaying the caller ID is zero and the “Number of alternative displays” field in the “Client Features” package "has a value of 1.

The Reserved 1 field (1 byte) is reserved for future use. Therefore, all bits in this field are currently set to zero or equal to a logical zero level. In one embodiment, one purpose of having this field present in the packet is to align all subsequent 2-byte fields to the 16-bit address of the word and align all 4-byte fields to the 32-bit address of the word.

The Bitmap Width field uses 2 bytes, which define the width of the bitmap, expressed as the number of pixels. The Bitmap Height field uses 2 bytes, which determine the height of the bitmap, expressed as the number of pixels. The “Display window width” field uses 2 bytes, which determine the window width on the display screen, expressed as the number of pixels. The "Display window height" field uses 2 bytes, which determine the height of the window on the display screen, expressed as the number of pixels.

The RGB Color Map Width field uses 2 bytes, which determine the number of bits of the red, green, and blue color components that can be displayed in the visual display of the Color Map (palette). A maximum of 8 bits for each color component (red, green, and blue) can be used. Even though 8 bits of each color component are sent in the Color Map packet, only the least significant bits of each color component specified in this field are used. If the display client cannot use the color map format (palette), then this value is zero. The word "RGB color map width" consists of three separate unsigned values:

Bits 3-0 determine the maximum number of blue bits in each pixel with values from 0 to 8, considered valid. Bits 7-4 determine the maximum number of green bits in each pixel with values from 0 to 8, considered valid. Bits 11-8 determine the maximum number of red bits in each pixel with values from 0 to 8, considered valid. Bits 14-12 are reserved for future use and are usually set to zero. Bit 15 is used to indicate the ability of the client to accept pixel color map data in a packed or unpacked format. When bit 15 has a logical unit level, this indicates that the client can receive the pixel data of the color map in either packed or unpacked format. If bit 15 is set to logical zero, this indicates that the client can accept pixel color map data only in an unpacked format.

The RGB Capability field uses 2 bytes to determine the number of resolution bits that can be displayed in RGB format. In one embodiment, if the client cannot use the RGB format, then this value is set to zero. The word “RGB Capability” consists of three separate unsigned values: bits 3-0 determine the maximum number of bits of blue (intensity of blue) in each pixel, bits 7-4 determine the maximum number of bits of green (intensity of green) in each pixel, and bits 11-8 determine the maximum number of red bits (red intensity) in each pixel. Bits 14-12 are reserved for future use and set to zero. Bit 15 is used to indicate the ability of a client to accept RGB pixel data in a packed or unpacked format. When bit 15 is set to a logical unit level, this indicates that the client can accept RGB pixel data in either packed or unpacked format. If bit 15 is set to logical zero, this indicates that the client can only accept RGB pixel data in an unpacked format.

The 1-byte Monochrome Display Capability field contains a value or information to determine the number of resolution bits that can be displayed in single-color format. If the client cannot use the monochrome display format, then this value is set to zero. Bits 6-4 are reserved for future use and are usually set to zero. Bits 3-0 determine the maximum number of halftone bits (gray levels) that may exist in each pixel. These four bits make it possible to specify that each pixel contains from 1 to 15 bits. If the value is zero, then the monochrome format is not supported by the client. When bit 7 is set to one, this indicates that the client can receive monochrome pixel data in either packed or unpacked format. If bit 7 is set to zero, this indicates that the client can only accept single-color pixel data in an unpacked format.

The Reserved 2 field is a 1 byte wide field reserved for future use, and usually has all the bits in this field set to a logic zero level. In one embodiment, one purpose of having this field in a packet is to force the subsequent 2-byte fields to align with the 16-bit word address and align the 4-byte fields with the 32-bit word address.

The 2-byte “Capability Y Cb Cr” field defines the number of resolution bits that can be displayed in YCb Cr format. If the client cannot use the YCb Cr format, then this value is zero. The word “Capability Y Cb Cr” consists of three separate unsigned values: bits 3-0 specify the maximum number of bits that define the Cb sample, bits 7-4 specify the maximum number of bits that define the Cr sample, bits 11-8 specify the maximum number bits that define the sample Y, and bits 14-12 are reserved for future use and set to zero. Bit 15, when set to one, indicates that the client can receive Y Cb Cr pixel data in either packed or unpacked format. If bit 15 is set to zero, this indicates that the client can only accept Y Cb Cr pixel data in an unpacked format.

The 2-byte “Bayer Format Capability” field determines the number of resolution bits, a group of pixels and the pixel order that can be transmitted in Bayer format. If the client cannot use the Bayer format, then this value is set to zero. The “Bayer format capability” field consists of the following values: bits 3-0 determine the maximum number of intensity (brightness) bits that exist in each pixel, bits 5-4 determine the pattern of a group of pixels that may be required. Bits 8-6 determine the ordering of pixels that is required, and bits 14-9 are reserved for future use and set to zero. Bit 15, when set to one, indicates that the client can receive pixel data in Bayer format or in packed or unpacked format. If bit 15 is set to zero, this indicates that the client can only accept pixel data in Bayer format in an unpacked format.

The Reserved 3 field, 2 bytes here, is reserved for future use. All bits in this field are therefore usually set to either a logical zero level or a value of 0. In one embodiment, the current goal of having this field in a packet is to align the subsequent 2-byte fields to the 16-bit address of the word and align the 4-byte fields to the 32-bit address of the word.

The Display Feature Capability Indicators field, which uses 4 bytes here, contains a set of flags that indicate whether specific features (capabilities) are supported in the alternate display. A bit set to one indicates that a specific or predefined feature is supported, and a bit set to zero indicates that the feature is not supported.

In one embodiment, the “Display Characteristics Capabilities” field uses 4 bytes, which contain a set of flags that indicate specific features in the alternate display that are supported. A bit set to a logical unit level indicates that this feature is supported, while a bit set to a logic zero indicates that a feature is not supported. In one embodiment, the value for bit 0 indicates whether the Block Block Forwarding packet is supported (packet type 71). The value for bits 1, 2, and 3 indicates whether the Fill Bitmap Area Fill packet (packet type 72), the Fill Bitmap Template packet (packet type 73), or the Read Frame Buffer packet (packet type 74) are supported, respectively . The value for bit 4 indicates whether the alternate display has the ability to make one color transparent using the Transparent Color Resolution package.

In this embodiment, the value of bit 10 of the “Display Characteristic Capability” field indicates whether the alternative display has the ability to maintain the power consumption state 01 by the display. The display power consumption state is set using bits [3: 2] of the Power State field of the “Display Power Consumption Status” packet described above. The power consumption state 01 by the display is a state where the selected display is not illuminated and consumes the least amount of power, if at all, and the frame buffer contents are usually guaranteed or reasonably ensured so as to be stored during this state.

The value for bit 13 of the “Display Characteristics Capability” field indicates whether the alternative display has the ability to set one or more video parameters while supporting VCP feature packets: VCP Feature Request packet, VCP Characteristic Response packet, VCP Characteristic Setup packet , the package "Request for valid parameters" and the package "Response on valid parameters" The value for bit 14 indicates whether the alternative display has the ability to write pixel data to a standalone display frame buffer, as illustrated in Fig. 88A. If this bit is set equal to the level of a logical unit, then the display update bits (bits 7 and 6 of the "Pixel data attributes" field in the "Video stream" packet) can be set to the value '01'.

The value for bit 15 of the “Display Characteristic Capability” field indicates when the alternate display has the ability to write pixel data only to the display frame buffer currently used to regenerate the displayed image, as illustrated in FIG. If this bit is set to a logical unit, then the “Display update” bits (bits 7 and 6 from the “Pixel data attributes” field in the “Video stream” packet) can be set to the value '00'. The value for bit 16 indicates when the alternate display has the ability to write pixel data from a single Video Stream packet to all the buffers of the display frame, as illustrated in FIG. If this bit is set equal to the level of a logical unit, then the “Display update” bits (bits 7 and 6 from the “Pixel data attributes” field in the “Video stream” packet) can be set to the value '11'.

In one embodiment, the value for bit 21 of the “Display Characteristic Capability” field indicates when the alternate display has the ability to use the Raster Operation field in the Block Block Transfer of the Bitmap packet (packet type 71), the Fill in the Bitmap Region packet (type packet 72), and the packet "Fill the bitmap template" (packet type 73), if these packets are supported by an alternative display, as defined by bits 0, 1 and 2 or this field. In one embodiment, if bit 21 has a logic level or value of zero and packets are supported, then the alternate display does not have the ability to use the Raster Operation field and the alternate display usually only has the ability to copy or write to the pixel locations indicated by these packets.

In one embodiment, bits 9-5, 11, 12, 20-17, and 31-22 of the “Capability of Display Features” field are currently reserved for future use or alternative purposes useful to system designers, and are typically set to zero or level logical zero.

In one embodiment, the 2-byte CRC field contains the 16-bit CRC of all bytes in the packet, including the "Packet Length" field.

41. “Access to Registers” packages

The Register Access Packet package provides either the master or client with a means, mechanism, or method of accessing the configuration and status registers at the opposite end of the MDDI link. Registers are likely to be unique for each display or device controller. These registers already exist in many displays that require configurations of installation parameters, operating modes, and have other useful and necessary settings. The Access to Registers package allows the master or MDDI client to write to the register and request to read the register using the MDDI communication line. When a host or client requests a register read, the opposite end must respond by sending register data in a packet of the same type, but also by indicating that it is data read from a particular register using the Read / Write Info field records). The “Register Access” package can be used to read or write multiple registers, setting the register index to be greater than 1. The client indicates the ability to support the “Register Access” package using bit 22 of the Client Feature Capability field in the “Client Features” package " The client will use the encapsulation packet to send the “Register Access” packet, thus representing what appears as a packet within the packet's configuration or structure.

The format of one embodiment of the “Access to Registers” package is illustrated in general terms in FIG. As can be seen from FIG. 87, the “Register Access” packet is structured so that it has the Packet Length, Packet Type, bClient ID, Read / Write Info or information, Register Address fields , Parameter CRC, Register Data List and Register Data CRC (CRC Register Data). The Packet Type 146 value identifies the packet as a “Register Access” packet. The bClient ID field is reserved for future use and is currently usually set to zero.

In one embodiment, the 2-byte “Read / Write Information” field serves as a mechanism for specifying a specific packet or as a type of packet for writing, or reading, or responding to reading, and provides an index (counter) of data values.

Bits 15-14 act as “Read / Write Flags”. If these bits [15:14] are '00', then this packet contains data that must be written to the register addressed by the Register Address field. The data that must be recorded in the indicated registers is contained in the "List of register data" field. If bits [15:14] are '10', then this is a request for data from one or more registers addressed by the Register Address field. If bits [15:14] are '11', then this packet contains the data that was requested in response to the “Register Access” packet, which has bits [15:14] of the “Read / Write Flags” set to '10' . The “Register Address” field contains the register address corresponding to the first element of the “Register Data List”, and the “Register Data List” field contains data that has been read to this address or addresses. If bits [15:14] are '01', they are treated as an invalid value, this value is reserved for future use and is not currently used, but those skilled in the art will understand how to use it for future applications.

Bits 13: 0 use an unsigned 14-bit integer to determine the number of 32-bit “Register Data” elements to be transferred to the “Register Data List” field. If bits 15:14 are equal to '00', then bits 13: 0 determine the number of 32-bit register data elements that are contained in the “Register data list” field that must be written to the registers starting from the register indicated by the “Register address” field ". If bits 15:14 are '10', then bits 13: 0 determine the number of 32-bit register data elements that the receiver sends to the device requesting the registers to be read. The “Register Data List” field in this package does not contain any elements and has zero length. If bits 15:14 are equal to '11', then bits 13: 0 determine the number of 32-bit register data elements to be read from the registers contained in the Register Register List field. Bits 15:14 are not currently set to '01', which are considered invalid values, and are otherwise reserved for future purposes or applications.

The Register Address field uses 4 bytes to indicate the address of the register to which writing should be made or from which reading should be made. To address registers whose address is less than 32 bits, the most significant bits are set to zero.

The 2-byte CRC Parameter field contains the CRC of all bytes from the Packet Length field to the Register Address. If this CRC cannot be verified, then the entire packet is discarded.

The “Register Data List” field contains a list of 4-byte register data values that should be written to client registers, or values that have been read from client device registers.

The 2-byte “Register Data CRC” field contains only the “Register Data List” CRC fields. If this CRC cannot be verified, then “Register Data” can still be used, but the number of erroneous CRC codes is increasing.

D. CRC packages

CRC fields appear at the end of packets and sometimes after some more critical parameters in packets, which may have a significant data field, and thus there is an increased likelihood of errors during transmission. In packages that have two CRC fields, the CRC code generator, when only one is used, is reinitialized after the first CRC code, so that CRC code calculations after a long data field are not affected by the parameters at the beginning of the packet.

It is unlikely for packets containing many bit errors to form a good CRC. The probability of finding a 'good' CRC code on an error packet approaches 7.6x10 ^-6 on very long packets containing many errors. According to the design, the MDDI link will have a very low or zero error rate. The CRC is intended to be used to monitor link health, and is not intended to detect errors on specific packets in order to determine if packets should be retransmitted.

In an exemplary embodiment, the polynomial used to calculate the CRC code is known as CRC-16, or X16 + X15 + X2 + X0. A typical implementation of a CRC code generator and a verification unit 3600 used to implement the invention is illustrated in FIG. In FIG. 36, the CRC register 3602 is initialized to 0x0001 only until the transmission of the first bit of the packet, which is an input on the Tx_MDDI_Data_Before_CRC line, then the bytes of the packet are shifted to the register starting from the first least significant bit. It should be noted that the number of register bits in this drawing correspond to the order of the polynomial used, and not to the position of the bits used by MDDI. It is more efficient to shift the CRC code register in one direction, and this leads to the fact that bit 15 of the CRC code appears at bit position 0 of the CRC MDDI field and bit 14 of the code of the CRC register at bit position 1 of the CRC field MDDI, etc., until bit position 14 of MDDI is reached.

For example, if the package content for the “Client and Status Request” packet is: 0x000c, 0x0046, 0x000, 0x0400, 0x00, 0x00, 0x0000 (or presented as a sequence of bytes: 0x0c, 0x00, 0x46, 0x00, 0x00, 0x00, 0x00, 0x04 , 0x00, 0x00, 0x00, 0x00), and are served using the inputs of the multiplexers 3604 and 3606 and the 3608 AND circuit, the resulting CRC output code on the Tx_MDDI_Data_With_CRC line is 0xd9aa (or represented as a sequence 0xaa, 0xd9).

When the CRC code generator and the verification unit 3600 is configured as a CRC verification unit, the CRC code received on the Rx_MDDI_Data line is supplied to the 3604 multiplexer and the XOR gate 3612 and is a bit and bit-by-bit is compared a bit with the value found in the CRC code register using logic element 3610 OR NOT, logic element 3608 AND and logic element 3614 I. If there are any errors that are output by logic element 3614 AND, CRC increases once for each packet that contains a CRC code error, by under for prison output of NAND gate 3614 to the input of register 3602. Note that the exemplary circuit shown in the diagram of Figure 36 may issue more than one erroneous CRC code signal within a predetermined window CHECK_CRC_NOW (see. Fig.37B). Therefore, the CRC code error counter usually only counts the first case of CRC error within each interval when CHECK_CRC_NOW is active. If configured as a CRC code generator, the CRC terminates the CRC code register when it matches the end of the packet.

The timing for input and output signals and enable signals is illustrated graphically in FIG. 37A and 37B. The generation of the CRC code and the transmission of the data packet is illustrated in FIG. 37A with the state (0 or 1) of the Gen_Reset, Check_CRC_Now, Generate_CRC_Now and Sending_MDDI_Data signals together with the Tx_MDDI_Data_Before_CRC and Tx_MDDI_Data_With_CRC signals. Receiving a data packet and checking the CRC value is illustrated in FIG. 37B with the state of the Gen_Reset, Check_CRC_Now, Generate_CRC_Now and Sending_MDDI_Data signals together with the CRC and RX_MDDI_DATA error signals.

E. "Overload" error code for CRC packet code

Whenever only when data packets and CRC are transmitted between the master and the client, no error codes are provided. The only mistake is the loss of synchronization. Otherwise, it is necessary to wait for the idle time of the communication line due to the lack of a good data transmission path or pipeline and then set the communication line to its original state and continue to work. Unfortunately, this is time consuming and partly ineffective.

For use in one embodiment, a new technique has been developed in which a portion of the CRC for packets is used to transmit error code information. This is shown in general terms in FIG. That is, one or more error codes are generated by processors or devices that process the transmission of data that indicate specific predetermined errors or defects that may occur during processing of an exchange or communication line. When an error is encountered, the corresponding error code is generated and transmitted using bits for the CRC packet code. That is, the CRC value is overloaded, or overwritten, by the required error code, which can be detected at the receiving end by an error monitoring unit or a check unit that monitors the values of the CRC field. For those cases in which the error code matches the CRC value for some reason, an error supplement is transmitted to prevent confusion.

In one embodiment, in order to provide a robust error warning and detection system, the error code may be transmitted several times using a sequence of packets, usually all that were transmitted or sent after the error was detected. This happens until the condition (state) that creates the error is removed from the system, at this moment the correct CRC bits are transmitted without encumbrance (overload) with another value.

This CRC overload technique provides a much faster response to system errors by using a minimum of additional bits or fields.

As shown in FIG. 66, a CRC rewriting mechanism or device 6600 is shown using an error signal detector or means 6602, which may form part of another circuit described above or known that detects the presence or existence of errors in a communication link or exchange process. A generator or tool 6604 for generating an error code that can be generated as part of another scheme or uses a technique, such as a lookup table, to store pre-selected error messages, generates one or more error codes to indicate specific predetermined errors or defects that were detected as having a place. It can be easily understood that devices 6602 and 6604 can be configured as a single circuit or device, as required, or as part of a programmed sequence of steps for other known processors and elements.

A comparator or CRC value comparator 6606 is shown to check if the selected (s) code or error codes are the same as the transmitted CRC value. If this is the case, then a generator or code generator or code completion device is used to ensure that error codes are supplemented so that an error is not made as the original template or CRC code value and does not confuse or complicate the operation of the detection circuit. The selector or item of tool or device 6610 select the error code then selects the error code or value that you want to insert, or write over, or their corresponding addition, accordingly. The rewriter or means 6612 or the mechanism for rewriting the CRC error code is a device that receives the data stream, packets and the required codes to be inserted, and overwrites the corresponding or suitable CRC values to transmit the required error codes to the receiver.

As mentioned above, the error code can be transmitted several times using a sequence of packets, so that the rewrite unit 6612 can use memory elements to maintain copies of the codes during processing or select these codes from previous elements or other known memory cells that can be used to store or hold their values as necessary, or as required.

The generalized processing that is implemented in the rewriting mechanism of FIG. 66 is shown in more detail in FIG. 67A and 67B. In Fig. 67A, an error, one or more, is detected in step 6702 in the data or exchange process, and an error code is selected in step 6704 to indicate this state. At the same time or at the appropriate time, the CRC value to be replaced is checked in step 6706 and compared with the desired error code in step 6708. The result of this comparison, as described above, is a determination as to whether this required code is or other characteristic (representing) values the same as the current CRC value. If so, the processing proceeds to step 6712, where the addition, or in some cases another representing value that is required, is selected as the code to insert. When it is determined which error codes or values are to be inserted in steps 6710 and 6714, this corresponding code is selected for insertion. These steps are illustrated as separate for the purpose of clarity, but are usually the only choice based on the result of decision block 6708. Finally, at step 6716, the corresponding values are overwritten to the location of the CRC code for transmission with the packets being processed.

On the packet receiving side, as shown in FIG. 67B, packet CRC values are monitored at step 6722. Typically, CRC values are monitored by one or more processes in the system to determine if an error has occurred in the transmission of data and whether to request retransmission of the packet or packets or deny further operations, etc., some of which are described above. As part of this control, this information can also be used to compare values with known or pre-selected error codes or representing values and to detect the presence of errors. Alternatively, a separate error detection and monitoring process may be implemented. If it turns out that the code is present, it is retrieved or otherwise registered at step 6724 for further processing. At step 6726, a determination can be made as to whether it is actually the actual code or addition, in which case an additional step 6728 is used to convert this value to the desired code value. In either case, the resulting extracted code, padding, or other recovered values is then used to detect which error occurred from the transmitted code at step 6730.

V. Link Inactivity

An MDDI link can enter an idle state (hibernation mode) quickly and wake up from inactivity quickly. This responsiveness (responsiveness) allows the communication system or device to enter the MDDI communication line into an idle state often to reduce power consumption, as it can wake up again very quickly for use. In one embodiment, when a client wakes up from inactivity for the first time in external mode, he does it at a data rate and with gating clock pulses, which is compatible with a transmission rate of 1 Mbps, i.e. the MDDI_Stb pair should switch at a frequency of 500 kHz. As soon as the characteristics of the client have been detected or communicated to the host device, then the host device can wake up the communication line usually up to any transmission speed - from 1 Mbps to the maximum transfer speed with which the client can work. Clients in internal mode can wake up at any frequency with which both the master and the client can work. This also usually applies the first time the client wakes up in internal mode.

In one embodiment, when the communication line awakens from inaction, the host device and the client exchange a pulse train. These pulses can be detected using low-speed line receivers, which consume only the part of the current that the differential receivers require in order to receive signals at the maximum communication line speed. The communication link may be awakened by either the master or the client, so the wake-up protocol is designed to handle a possible contention that may occur if both the master and the client try to wake up at the same time.

During the idle state, the differential drivers MDDI_Data and MDDI_Stb are locked (disabled) in the high-impedance state, and the differential voltage across all differential pairs is zero volts, while the communication line is or remains inactive. Line differential receivers used to detect a sequence of pulses during waking up from inactivity have a predetermined voltage offset. In one embodiment, the threshold between logical unit and logical zero levels in these receivers is approximately 125 mV. This forces the non-excited differential pair to be considered as having a logic zero level during the sequence of awakening the communication line. However, as one skilled in the art understands, the normal level of the logical unit provided by the differential master is still interpreted as the level of the logical unit by differential receivers having an offset of 125 mV. An example of the behavior of a special low-power differential receiver with a bias of 125 mV compared to a standard differential receiver with a zero input bias is illustrated in Fig. 38. The waveform is not representative of a typical MDDI signal, but is presented here only to clarify or illustrate the difference between the two types of differential receivers.

To enter the Hibernation State, the master sends 64 cycles of MDDI_Stb after the CRC code for the Link Shutdown packet. The master device blocks (inhibits) the output signal MDDI_Data0 of the master device in the range from 16 to 56 cycles MDDI_Stb (including the propagation delay of the prohibition of the output signal) after the CRC code. The master finishes sending 64 MDDI_Stb clock cycles after the CRC code for the Link Shutdown packet before it initiates the wake-up sequence. In one embodiment, the wake-up initiated by the master is determined when the master is forced to wait at least 100 ns after MDDI_Data0 reaches a reliable level of logic one before generating a pulse on MDDI_Stb. In one embodiment, the client waits at least 60 MDDI_Stb clocks after the CRC code for the Link Shutdown packet before it drives MDDI_Data0 to the logical unit level to try to wake up the master.

In order to "wake up" from a State of Inaction, several actions or processes are taken. When the client, here the display, needs data or exchange, service, from the master, it generates a request pulse, driving the MDDI_Data0 line to the state of the logical unit for about 70 to 1000 μs, while MDDI_Stb is inactive, and saves MDDI_Data0 at the logical unit level state for approximately 70 MDDI_Stb cycles (ranging from 60 to 80) after MDDI_Stb becomes active, although other periods may be used if necessary. The client then disables (blocks) the MDDI_Data0 master, placing it in a high impedance state.

If MDDI_Stb is active during inactivity, although this is unlikely, then the client can only set MDDI_Data0 to a logical unit state for approximately 70 MDDI_Stb cycles (in the range of 60 to 80). This action causes the master to start or restart data traffic on the forward link (208) and request the client about its status.

The master must detect the presence of a request pulse from the client (using a low-power differential receiver with an offset of +125 mV) and start the start sequence by first setting MDDI_Stb to logic zero and MDDI_Data0 to a high logic level for at least about 200 ns. And then, during the switch, MDDI_Stb continues to drive MDDI_Data0 to a logical unit level for about 150 MDDI_Stb clocks (range 140 to 160) and to a logic zero for about 50 MDDI_Stb clocks. A client should not send a service request impulse if it detects MDDI_Data0 in a logical unit state for more than 80 MDDI_Stb clock cycles. When a client detects MDDI_Data0 at the logical unit level for 60 to 80 MDDI_Stb clocks, it starts looking for the interval where the master drives MDDI_Data0 to a logic zero level for 50 MDDI_Stb clocks. After the master device drives MDDI_Data0 to a logic level of zero for a duration of 50 clock cycles MDDI_Stb, then the master starts sending packets over the communication line. The first packet sent is the Sub-Frame Header packet. The client begins to view the Sub-Frame Header packet after MDDI_Data0 is at logical zero for 40 clock cycles MDDI_Stb in an interval of 50 clock cycles. The nature of the choice of times and tolerances of time intervals related to inaction processing, and the startup sequence are described below. (See Fig. 68A-C below.)

The master can initiate awakening by first enabling MDDI_Stb and at the same time energizing it to logic zero. MDDI_Stb should not be set equal to the level of a logical unit until pulses are issued, as described below. After the signal MDDI_Stb reaches the logic zero level, the master enables MDDI_Data0 and simultaneously sets it to the level of the logical unit. MDDI_Data0 should not be set to a logic zero level during the waking process up to the interval where it is set to a logical zero level during an interval of 50 pulses MDDI_Stb, as described below. The master must wait at least 200 ns after MDDI_Data0 reaches a reliable logical unit level before issuing pulses to MDDI_Stb. This time dependence occurs during the worst-case resolution delays of the output signal. This essentially ensures that the client has enough time to fully resolve its MDDI_Stb receiver after it is woken up by the logical unit level at MDDI_Data0, which is set by the master.

An example of processing steps for a typical non-contention customer service request event 3800 is illustrated in FIG. 39A, where events are labeled for convenience of illustration using characters A, B, C, D, E, F, and G. The process starts at point A when the lead the device sends a “Link Shutdown” packet to the client device to inform it that the link will go into an idle state with low power consumption. In the next step, the master device enters an idle state with low power consumption by inhibiting the driver MDDI_Data0 and setting the driver MDDI_Stb to a logic zero state, as shown at point B. MDDI_Data0 is excited to a logic zero level through a high-impedance bias circuit. After a period of time, the client sends a service request impulse to the master device, driving MDDI_Data0 to the logical unit level, as can be seen at point C. The master device still provides a logic zero level using the high-impedance bias circuit, but the master device in the client sets the communication line to logical unit level. Within 50 μs, the master device recognizes the service request pulse and outputs the level of the logical unit to MDDI_Data0 by resolving its master device, as can be seen at point D. The client then stops trying to issue a service request pulse, and the client puts its master device in a high impedance state as can be seen at point E. The master device drives MDDI_Data0 to a logic zero level for 50 μs, as shown at point F, and also starts generating MDDI_Stb in a manner compatible with ovnem logic zero on MDDI_Data0. The client begins to view the Sub-Frame Header packet after MDDI_Data0 is Boolean for 40 MDDI_Stb cycles. After setting MDDI_Data0 to logic zero and setting MDDI_Stb for 50 μs, the master starts transmitting data on the forward link, sending a “Sub-frame header” packet, as shown at point G.

A similar example is illustrated in FIG. 39B, where a service request is issued after the restart link sequence has started, and events are re-marked using symbols A, B, C, D, E, F and G. This represents a worst-case scenario, where the impulse or request signal from the client arrives most closely to damage the Sub-Frame Header packet. The process starts at point A, when the host device re-sends the “Link Shutdown” packet to the client device to inform it that the link will go into an idle state with low power consumption. In the next step, the master device enters an idle state with low power consumption by turning off the MDDI_Data0 driver and setting the MDDI_Stb driver to a logic zero level, as shown at point B. As before, MDDI_Data0 is driven to a logic zero level by a high-impedance bias circuit. After a period of time, the master starts the restart (re-initiation) sequence of the communication line by driving MDDI_Data0 to the logical unit level within 150 μs, as can be seen at point C. Before the expiration of 50 μs after the restart of the communication line, the display also sets MDDI_Data0 to a duration of 70 μs, as can be seen at point D. This is because the display has a need to request a service from the master and does not recognize that the master has already begun the sequence restart the communication line. The client then stops trying to set the impulse of the service request, and the client puts its driver in a high impedance state, as can be seen at point E. The master continues to drive MDDI_Data0 to the level of a logical unit. The master drives MDDI_Data0 to a logic zero level for 50 μs, as shown at point F, and also starts generating MDDI_Stb in a manner compatible with the logic zero level on MDDI_Data0. After setting MDDI_Data0 to logic zero and driving MDDI_Stb for 50 μs, the master starts transmitting data on the forward link, sending a Sub-Frame Header packet, as shown at point G.

From the above description, it can be seen that the preceding solution includes a master device that goes through two states as part of the waking sequence. During the first state, the master sets the MDDI_Data0 signals to a high level for 150 μs and then sets the MDDI_Data0 signals to a low level for 50 μs, at the same time activating the MDDI_Stb line, and then starts transmitting MDDI packets. This process works well to improve the current state in terms of achievable data rates using the MDDI device and methods. However, as indicated above, an ongoing need is to improve performance in terms of reducing the response time to conditions or the ability to more quickly choose the next step or processing, achieved by the ability to simplify processing or elements.

Applicants have proposed a new approach to wake-up processing and synchronization, according to which the master uses clock cycle-based clocking to switch signals. In this configuration, the master starts switching MDDI_Stb from 0 to 10 μs after the master sets the high-level signal MDDI_Data0 at the beginning of the wake-up sequence and does not wait until the signal is set to low. During the wakeup sequence, the master switches MDDI_Stb as if the signal MDDI_Data0 was always logic zero. This effectively removes the client-side time tracking concept, and the master changes from the previous 150 µs and 50 µs periods during the first two states to 150 clock cycles and 50 clock cycles during these periods.

The master device now becomes responsible for driving this data line to a high level and within 10 clock cycles begins to transmit a gating signal, as if the data line was zero. After the master device has set the data line at a high level for 150 clock cycles, the master device drives the data line at a low level for 50 clock cycles, while continuing to transmit the strobe signal. After both of these processes have completed, the master may begin to transmit the first Sub-Frame Header packet.

On the client side, the client implementation can now use these generated clocks to calculate the number of clock cycles during which the data line is first high and then low. The number of clock cycles that must occur in both the data line set to high is 150 and the data line set to low is 50. This means that for the correct wake-up sequence the client must be able to count at least 150 consecutive clock cycles of the data line having a high level, followed by at least 50 consecutive clock cycles of the data line having a low level. Once these two conditions are met, the client can begin to search for a unique word in the first sub-frame. The break in this template is used as the basis for returning the counters to the initial state, in which the client again searches for the first 150 consecutive clock cycles of the data line at a high level.

The implementation of the client according to the invention for waking up based on a master device from an idle state is very similar to the case of an initial start, except that the transmission speed should not start from a value of 1 Mbit / s, as described above. Instead, the transmission rate may be set to resume at any previous transmission rate that was active when the communication link entered an idle state. If the master starts transmitting the strobe signal as described above, the client should be able to recalculate at least 150 consecutive high-level data line cycles, followed by at least 50 consecutive low-level data line cycles. Once these two conditions have been met, the client can begin to search for a unique word.

The implementation of a client according to the invention for waking based on a client from an idle state is similar to waking based on a master device, except that it starts with the client initiating a data line. The client can asynchronously energize the data line without synchronization to awaken the master. Once the master recognizes that the data line has been driven to a high level by the client, it can begin its wake up sequence. The client can count the number of clock cycles generated by the master, starting or continuing its waking process. As soon as the client counts 70 consecutive clock cycles during which the data has a high level, it can stop setting a high level on the data line. At this point, the master should also set a high level of data. The client can then count the other 80 consecutive high-level data line cycles to reach 150 high-level data line cycles, and can then search for 50 low-level data line cycles. Once these three conditions have been met, the client can begin to search for a unique word.

An advantage of this new implementation of awakening processing is that it eliminates the need for a measuring device. Whether it is a generator or a capacitor discharge circuit or other similar known device, the client no longer needs such external devices to determine the trigger condition. This saves money and circuit area when implementing controllers, counters, etc. on the network card of the client device. While this may not be as beneficial to the client, for a master, this technique may also simplify the master in terms of the very high density logic (VHDL) used for the main circuits. The power consumption of using data and strobe lines as a wakeup notification and measurement source will also be lower since no external circuitry should work as basic elements in order to wait for a wake based on the master. The number of cycles or cycles used is exemplary, and other periods may be used, as is obvious to those skilled in the art.

To clarify and illustrate the operation of this new technique, the synchronization of MDDI_Data0, MDDI_Stb, and various operations regarding clock cycles are shown in Figs. 68A, 68B and 68C.

An example of the processing steps for a typical Master-initiated wake-up without conflicts (contests) is illustrated in FIG. 68A, where events are again tagged for convenience of illustration using symbols A, B, C, D, E, F and G. The process starts at point A, when the host device sends the “Link Shutdown” packet to the client device to inform it that the link will go into an idle state with low power consumption. In the next step, at point B, the master device switches MDDI_Stb for approximately 64 clock cycles (or as required by the system design) to allow client processing to be completed before the MDDI_Stb switchover stops, which stops the restored clock signal in the client device. The master also initially sets MDDI_Data0 to logic zero and then disables the generation of MDDI_Data0 in the range of 16 to 48 clock cycles (usually including the propagation delay of the output mute) after the CRC code. It may be necessary to transfer the high-speed receivers for MDDI_Data0 and MDDI_Stb in the client to the low power consumption state some time after 48 cycles after the CRC code and to the next step (C). The client puts its high-speed receivers for MDDI_Data0 and MDDI_Stb into an idle state at any time after the rising edge of the 48th measure of MDDI_Stb after the CRC code in the “Link Shutdown” packet. It is recommended that the client transfer their high-speed receivers for MDDI_Data0 and MDDI_Stb to the idle state in front of the rising edge of the 64th clock cycle of MDDI_Stb after the CRC code in the “Link Shutdown” packet.

The master device enters an idle state with low power consumption at a point or step C by turning off the master devices MDDI_Data0 and MDDI_Stb and putting the master controller in an idle state with low power consumption. You can also set the master MDDI_Stb to logic zero (using a high-impedance bias circuit) or continue switching during the idle state as required. The client is also inactive with a low power consumption level.

After a period of time, the master starts the reset (restart) sequence of the communication line at point D, enabling the output signals of the master device MDDI_Data0 and MDDI_Stb. The master device drives (sets) MDDI_Data0 to the level of a logical unit and MDDI_Stb to a level of logical zero for such a long time that it would be necessary for the master devices to fully resolve their respective output signals. The master typically waits approximately 200 nanoseconds after the output signals reach the required logic levels (MDDI_Data0 reaches a reliable level of logical units and MDDI_Stb reaches a reliable level of logic zero) before issuing pulses to MDDI_Stb. This gives the client time to prepare to receive high-speed pulses on MDDI_Stb. The client first detects an awakening pulse using a low-power differential receiver having an input bias voltage of +125 mV.

After the master devices have been enabled and MDDI_Data0 has been brought to the logical unit level, the master starts switching MDDI_Stb for 150 clock cycles MDDI_Stb, as can be seen at point E. The master device drives MDDI_Data0 to a logic zero level for 50 cycles, as shown at point F, and the client begins to search for the "Sub-frame header" packet after MDDI_Data0 is at logical zero for 40 MDDI_Stb clock cycles. The master starts transmitting data on the forward link, sending a Sub-Frame Header packet, as shown at point G.

An example of processing steps for a typical client-initiated non-contentious wakeup is illustrated in FIG. 68B, where events are re-tagged for convenience in illustration using characters A, B, C, D, E, F, G, H and I. As before, the process starts at point A, when the master sends the “Link Shutdown” packet to inform the client that the link will transition to a low power state.

At point B, the master device switches MDDI_Stb for approximately 64 clock cycles (or as required by the system design) to allow client processing to complete before the MDDI_Stb switch stops, which stops the restored synchronization in the client device. The master also initially sets MDDI_Data0 to logic zero and then turns off the MDDI_Data0 output in a range of 16 to 48 clock cycles (usually including the propagation delay of the output mute) after the CRC code. It may be necessary to transfer the high-speed receivers for MDDI_Data0 and MDDI_Stb in the client to a low power consumption state some time after 48 clock cycles after the CRC code and until the next step (C).

The master device enters an idle state with low power consumption at point or step C by turning off the master devices MDDI_Data0 and MDDI_Stb and puts the master controller in the idle state with low power consumption. You can also set the MDDI_Stb master to logic zero (using a high-impedance bias circuit) or continue to switch during the idle state as required. The client is also inactive with a low power consumption level.

After a period of time, the client begins the sequence of rebooting (restarting) the communication line at point D by resolving the MDDI_Stb receiver and also providing an offset in the MDDI_Stb receiver to ensure that the state of the received version of MDDI_Stb is the logical zero level in the client before the master allows (unlocks ) its master MDDI_Stb. It is required for the client to enable the offset immediately before the resolution of the receiver, in order to guarantee the reception of a reliable differential signal and to prohibit erroneous signals as required. The client allows (unlocks) the master device MDDI_Data0, at the same time setting the logical level of unity on the MDDI_Data0 line. It is allowed for MDDI_Data0 and MDDI_Stb to be enabled simultaneously if the time for resolving the offset and resolution of the standard differential receiver MDDI_Stb is less than 200 ns.

Within approximately 1 ms, point E, the master recognizes the impulse of the service request from the client, and the master starts the communication line reset (restart) sequence by enabling the output signals of the master device MDDI_Data0 and MDDI_Stb. The master device sets MDDI_Data0 to the logical unit level and MDDI_Stb to the logical zero level until it is required for the master devices to enable their respective output signals. The master typically waits approximately 200 nanoseconds after these output signals reach the required logic levels before issuing pulses to MDDI_Stb. This gives the client time to prepare for the appointment.

When the master devices are enabled and MDDI_Data0 is set to the logical unit level, the master starts issuing pulses on MDDI_Stb for a duration of 150 clock cycles MDDI_Stb, as can be seen at point F. When the client recognizes the first pulse on MDDI_Stb, it disables the offset in its MDDI_Stb receiver . The client continues to drive MDDI_Data0 to the logical unit level for 70 clock cycles of MDDI_Stb and turns off its master MDDI_Data0 at point G. The master continues to drive MDDI_Data0 to the level of the logical unit for 80 additional pulses MDDI_Stb and sets MDDI_Data0 to logic zero at point H.

As can be seen at points G and H, the master sets MDDI_Data0 to a logic zero level for 50 clock cycles, and the client begins to search for the Sub-frame header packet after MDDI_Data0 is logic zero for 40 clock cycles MDDI_Stb. After setting MDDI_Stb for a duration of 50 clocks, the master starts transmitting data on the forward link, sending a Sub-Frame Header packet, as shown at point I.

An example of processing steps for a typical master-initiated wake-up contest with a client who is a client who also wants to “wake up” the communication line is illustrated in FIG. 68C. Events are re-tagged for ease of illustration using the characters A, B, C, D, E, F, G, H, and I. As before, the process starts at point A when the host sends the “Link Shutdown” packet to to inform the client that the communication line will go into a low power consumption state, proceeds to step B, where MDDI_Stb switches for approximately 64 clock cycles (or as required for the system design) to allow the client to complete the processing that must be completed, and then - to point C, where the master input um in an idle state with low power consumption by shutting down devices defining MDDI_Data0 and MDDI_Stb and transferring the master controller in an idle state with low power consumption. After a period of time, the master starts the restart sequence of the communication line at point D, resolving the output signal of the driver MDDI_Data0 and MDDI_Stb, and starts switching MDDI_Stb for a duration of 150 clock cycles MDDI_Stb, as can be seen at point E.

For up to 70 clock cycles MDDI_Stb after point E, here point F, the client has not yet recognized that the master is currently setting MDDI_Data0 to the logical unit level, so the client also sets MDDI_Data0 to the logical unit level. This is because the client wants to request the service, but does not recognize that the master device with which he is trying to contact has already begun the restart sequence of the communication line. At point G, the client stops exciting MDDI_Data0 and puts its driver in a high impedance state by turning off its output. The master continues to drive MDDI_Data0 to the logical unit level for 80 additional clock cycles.

The master sets MDDI_Data0 to a logic zero level for 50 clock cycles, as shown at point H, and the client begins to search for the Sub-Frame Header packet after MDDI_Data0 is logic zero for 40 MDDI_Stb clock cycles. The master starts transmitting data on the forward link, sending a Sub-Frame Header packet, as shown at point I.

VI. Electrical Interface Specifications

In exemplary embodiments, the data is encoded in a non-return-to-zero (NRZ) format using a data gate signal or a DATA-STB format that allows synchronization information to be embedded in strobe signals and data. Synchronization can be restored without a complex phase-locked loop. Data is transmitted over a bi-directional differential communication line, typically implemented using a wireline cable, although other conductors, printed conductors, or transmission elements may be used as described above. The gate signal (STB) is transmitted over a unidirectional communication line, which is excited only by the master. The gate signal switches the value (0 or 1) whenever there is an opposite state, 0 or 1, which remains the same on the data or signal line.

An example of how a data sequence, such as the bits "1110001011, can be transmitted using DATA-STB encoding (strobe data), is shown in graphical form in Fig. 40. In Fig. 40, a DATA 4002 signal is shown in the upper line of the timing diagram signal, and the STB signal 4004 is shown in the second line, each time aligned accordingly (common starting point). Over time, when there is a change in the state occurring on the DATA line 4002 (signal), then the STB line 4004 (signal) maintains the previous state, so the state of the first is '1' and of the DATA signal corresponds to the state of the first '0' for the STB signal, its initial value.However, if or when the state or level of the DATA signal does not change, then the STB signal switches to the opposite state, or '1' in this example, as is the case 40, where DATA provides a different value of '1'. That is, there is one and only one transition per bit cycle between DATA and STB. Therefore, for the STB signal, there is again a transition, this time to '0', when the DATA signal remains at '1' and stores this level or value, when the DATA signal level changes appears at '0'. When the DATA signal remains at '1', the STB signal switches to the opposite state, or '1' in this example, etc., when the DATA signal changes or stores levels or values.

After receiving these signals, an EXCLUSIVE OR (XOR) operation is performed on the DATA and STB signals to generate a clock signal (clock signal) 4006, which is shown at the bottom of the timing chart for relative comparison with the desired data signals and gating. An example of a circuit used to generate DATA and STB output signals or signals from input data in a master device and then recover or re-capture data from DATA and STB signals in a client is illustrated in FIG. 41.

If there is a change in state encountered on DATA, then the STB retains its previous state. However, the STB switches to the opposite state if the DATA does not change. In other words, between DATA and STB there is a path MDDI_Data0 +/- and there is always one and only one transition to a bit cycle. At the receiving end of the communication, a clock signal (CLK signal in FIG. 40) is generated by performing an EXCLUSIVE OR operation on DATA and STB. The use of data-strobe encoding has an advantage over conventional systems that use data and a synchronization signal, since encoded data-strobe signals are approximately twice as tolerant of shear delay as compared to systems using data and a synchronization signal. The time shift in MDDI_Stb +/- can be caused by differences in the delays on the path through the master devices and receivers in the host device and client, as well as differences in delays through the connections MDDI_Data0 +/- and MDDI_Stb +/-. Quantitative analysis of clocking, which is affected by time shift, and other shortcomings in the paths MDDI_Data0 +/- and MDDI_Stb +/- are described in more detail below.

For Type 2, Type 3, and Type 4 modes, MDDI_Data0 +/- and MDDI_Stb +/- works in the same way as with Type 1, where they have the property of having one and only one transition per bit cycle. Other MDDI_Data signals transmit data with the same bit rate and phase as MDDI_Data0. The restored synchronization in the client created after the EXCLUSIVE OR operation for MDDI_Data0 +/- and MDDI_Stb +/- is also used to fetch MDDI_Data1 +/- - MDDI_Data7 +/-.

An exemplary circuitry used to generate DATA and STB from input data and then recover input from DATA and STB is illustrated in FIG. 41. 41, a transmission part 4100 is used to generate and transmit the original DATA and STB signals along an auxiliary (intermediate) signal transmission path 4102, while a reception part 4120 is used to receive signals and recover data. As shown in FIG. 41, in order to transmit data from the host device to the client, a DATA signal is supplied to two D-flip circuit elements 4104 and 4106 together with a clock signal for switching circuits. The outputs (Q) of the two trigger circuits are then divided into a differential pair of signals MDDI_Data0 +, MDDI_Data0- and MDDI_Stb +, MDDI_Stb-, respectively, using two differential line drivers 4108 and 4110 (voltage mode). A three-input EXCLUSIVE NOT - OR (XNOR) circuit, a circuit or logic element 4112 is connected to receive the DATA and output signals of both triggers, and generates an output signal that provides input to the second trigger, which in turn generates MDDI_Stb + signals , MDDI_Stb-. For convenience, the XNOR gate has an inversion circle to indicate that it is actually inverting the output Q of the trigger that the Gate forms.

In the receiving part 4120 in FIG. 41, the signals MDDI_Data0 +, MDDI_Data0- and MDDI_Stb +, MDDI_Stb- are received by each of the two differential line receivers 4122 and 4124 that generate single output signals from the differential signals. The output signals of the amplifiers are then supplied to each of the inputs of the two-input XOR elements, circuitry or logic element 4126, which generates a clock signal. This clock signal is used to switch each of the two D-flip-flop circuits 4128 and 4130, which receive a delayed version of the DATA signal through delay element 4132, one of which (4128) generates data '0' values and the other (4130) - '1' values data. The clock also has an independent output from the XOR gate. Since the synchronization information is distributed between the DATA and STB lines, no signal transitions between states occur faster than in half a clock cycle. Since the synchronization is reproduced using DATA and STB signal processing via EXCLUSIVE OR, the system essentially allows approximately twice the time offset between the input data and the synchronization signal compared to the situation when the clock signal is sent directly over a single dedicated data line.

The delay elements in the data recovery circuit illustrated in Fig. 41 or Fig. 57 are more challenging to implement than the synchronous data collection circuitry commonly used for a conventional data-synchronization communication line, but data-strobe coding can approximately double the transmission speed data without the need to use time delay shift calibration. Critical propagation delays of elements of a data recovery scheme are simple to achieve, since they are relative to other delays in the same scheme. This can easily be implemented in a custom circuit, for example, with simple logic elements in the circuit of an I / O keypad, since it is only necessary to create delays of some paths that are greater than delays on another path.

The MDDI_Data0, MDDI_Stb + and MDDI_Stb- pairs are used in differential mode to maximize resistance to the negative effects of noise. Each differential pair is terminated by a parallel terminator (termination) with the impedance of the cable or conductor used to transmit the signals. Typically, all parallel terminators reside on the client device. They are located near the differential receiver for forward link traffic (data sent from the host device to the client), but they are located on the driver end of the cable or other conductors or transmitting elements for return traffic (data sent from the client to the host device). For reverse traffic, the signal is issued by the client, reflected by the receiver with high impedance (impedance) in the master and terminated in the client. As described herein, reverse data or reverse link data can be transmitted or sent at data rates greater than the inverse of the “forward and reverse signal transmission times” in the cable. Conductors or signals MDDI_Stb + and MDDI_Stb- are issued only by the master.

An exemplary configuration of elements used to implement drivers, receivers, and terminators (terminators) for signal transmission as part of the proposed MDDI is illustrated in FIG. 42A. This example interface utilizes a low voltage sensitivity of 200 mV here, with a power swing of less than 1 V and low power consumption. The driver of each signal pair has a differential current output. When receiving MDDI packets, the MDDI_Data and MDDI_Stb pairs use a conventional differential receiver with a differential voltage threshold of zero volts. In the idle state, the outputs of this master device are prohibited, and the resistors of the parallel terminal load "lower" the differential voltage on each signal pair to zero volts. During the idle state, the special receiver on the MDDI_Data0 pair has a positive differential offset threshold voltage of 125 mV, which causes the line receiver in the idle state to interpret the non-excited signal pair as a logic zero level.

The differential voltage of a differential pair is defined as the voltage difference on a positive (+) signal minus the voltage on a negative (-) signal. The names of the signals of the differential pair end with either "+" or "-", which indicates the positive or negative signal of the pair, respectively. The current at the output of the driver of the differential pair is defined as the current flowing from the positive (+) output. The current passing through the negative (-) output of the differential driver is always equal in magnitude but opposite in direction compared to the current flowing through the positive (+) output of the same differential driver.

A schematic example diagram of a driver in differential current mode used to implement some embodiments of the invention is illustrated in FIG. 42B. A switchable differential output stage "directs" the current source to either the positive or negative output of the driver. A voltage source of 0.35 V keeps the output voltage, measured relative to earth, always at 0.35 V or more.

Sometimes a master or client can simultaneously drive a differential pair to a logical unit or logical zero level to guarantee a valid logical level on a pair when the direction of the data flow changes (from the master to the client or from the client to the master). The output voltage range and specifications of the output signal are still satisfied with simultaneously excited output signals that are excited to the same logic level. In some systems, it may be necessary to drive a small current into a differential couple with an end load in order to create a small bias voltage at some points in time during the idle state and when the communication line awakens from the idle state. In these situations, the allowed bias circuits with current bias excite current levels, referred to as: I _ESD-and-Rx - input current of the internal ESD diode of the differential receiver with a typical value of I _ESD-and-Rx ≤ 1 μA; I _Tx-Hi-Z - differential output signal of the driver in a high impedance state with a typical value of I _Tx-Hi-z ≤ 1 μA; and I _external-ESD - leakage through external ESD protection diodes with a typical value of I _external-ESD ≤ 3 μA.

Each of these leakage currents is illustrated in FIG. Circuits for “raising” the voltage and “lowering” the voltage must achieve the minimum differential voltage in the leakage conditions in the worst cases described above, when they all occur simultaneously. The total current leakage is ≤ 4 μA for internal operation without external ESD protection diodes and ≤ 10 μA for external operation with external ESD protection (against electrostatic discharge).

The electrical parameters and characteristics of the differential line drivers and line receivers are described for one exemplary embodiment in Tables IXa-IXd. Functionally, the master transmits the logic level at the input directly to the positive terminal and the inverse input signal to the negative terminal. The delay from input to output is well matched to the differential line, which is excited differentially. In most implementations, the output voltage swing is smaller than the input swing to minimize power consumption and electromagnetic radiation. In one embodiment, there is a minimum voltage swing of about 0.5 V. However, other values may be used, as may be known to those skilled in the art, and the inventors expect a lower value in some embodiments, depending on design constraints.

Line differential receivers have the same characteristics as a high-speed voltage comparator. In Fig. 41, an input without a circle indicates a positive input, and an input with a circle indicates a negative input. An output is a logical unit if: (V _input +) - (V _input -) is greater than zero. Another way of describing this is a differential amplifier with a very large (virtually infinite) gain with the output signal cut off at logical voltage levels of 0 and 1.

The time delay shift between different pairs must be minimized in order to use the differential transmission system at the highest potential speed.

Table IXa
Master transmitter electrical specifications Parameter Description Min Max Units V _output-range Permitted output voltage range of the master device of the master device with respect to the ground of the master device 0.35 1,6 AT I _{OD +} High-level current of the differential output signal of the driver, corresponding to the level of a logical unit (during excitation of a transmission line with an end load) 2.5 4,5 mA I _OD- The current of the low level of the differential output signal of the driver, corresponding to the level of logical zero (during excitation of the transmission line with the final load) -4.5 -2.5 mA t _Rise-Fall Rise and fall times (between 20% and 80% of the amplitude) of the driver output signal, measured in differential mode 425 Note 1 ps t _{shift pair} The shift between the positive and negative output signals of the same differential pair (time shift inside the pair) 125 ps t _{differential-shift} Peak shift in delay time between one differential pair and any other differential pair See above ps t _{jitter master} The maximum jitter of the clock in the master, which is used to generate the output signals MDDI_Data and MDDI_Stb 0.21 * t _BIT t _A Jitter, bit boundary to center mark 0 t _B -283 ps t _B-TPO-DRVR Jitter, bit limit to minimum output level 0 See above ps Note 1: The maximum rise and fall times are the smallest of or 30% of the interval for transmitting one bit on one differential pair or 100 ns

Table IXb
Customer Transmitter Electrical Specifications Parameter Description Min Max Units V _{output-Range Ext.} Allowed range of client output voltage relative to client ground (external mode) 0 1.25 AT V _{output-range internally} Allowed range of client output voltage relative to client ground (internal mode) 0.11 1,6 AT I _{OD +} High-level current of the differential output signal of the driver, corresponding to the level of a logical unit (during the excitation of equivalent "voltage-boosting" and "voltage-reducing" circuits that exist in the host device and the client) 2.5 4,5 mA I _OD- The current of the low level of the differential output signal of the driver, corresponding to the level of logical zero (during the excitation of the equivalent "increase voltage" and "lower voltage" circuits that exist in the host device and the client) -4.5 -2.5 mA Z _{out client} Minimum differential output impedance of MDDI_Data masters in a client device (Note 2) 1,0 kohm t _Rise-Fall Rise and fall times (between 20% and 80% of the amplitude) of the driver output signal, measured in differential mode 425 Note 1 ps t _{shift pair} Time shift between the positive and negative output signals of the same differential pair (shift within the pair) 125 ps t _{differential-shift} Peak shift in delay time between one differential pair and any other differential pair See above ps t _A Jitter, bit boundary to center mark 0 t _B -283 ps t _B-TP4-DRVR Jitter, bit limit to minimum output level 0 See above ps Note 2: The minimum impedance of the client driver is set, since the impedance of the driver is parallel to the 100 Ohm termination differential resistor (terminator) in TP4 (test point 4), which affects the total cable termination impedance when the client sends data to the master device.

Table IXc
Customer Receiver Electrical Specifications Parameter Description Min Type of. Max Unit V _{IT +} High threshold differential receiver input voltage. Above this differential voltage, the input signal is interpreted as a logic unit level. 0 fifty mV V _IT Low threshold differential receiver input voltage. Below this differential voltage, the input signal is interpreted as a logic zero level. -fifty 0 mV V _{IT +} High threshold differential input voltage of the receiver (offset for waking up from sleep mode (hibernation)). Above this differential voltage, the input signal is interpreted as a logic unit level. 125 175 mV V _IT Low threshold differential input voltage of the receiver (offset for waking up from sleep mode (hibernation)). Below this differential voltage, the input signal is interpreted as a logic zero level. 75 125 mV V _{input range} Allowed receiver input voltage range with respect to client ground 0 1.65 AT R _term Value of parallel termination resistance 98 one hundred 102 Ohm I _in Input leakage current -10 10 μA C _pad Contact pad capacity relative to customer land (Note 1) 5 pF C _diff Capacitance between two signals of a differential pair (Note 1) one pF t _{skew-pair-INT} The time shift caused by the differential receiver between the positive and negative inputs of the differential receiver of the same differential pair (shift within the pair). Internal mode 250 ps t _{skew-pair-EXT} Time shift within a pair, external mode fifty ps t _{differential-shift} Peak shift in delay time between one differential pair and any other differential pair See above ps t _A Jitter, bit boundary to center mark t _B -38.5 ps t _{B-TP4-RCVR-INT} Jitter, bit boundary to the minimum input level. (Internal mode) 0 See above ps t _{B-TP4-RCVR-EXT} Jitter, bit boundary to the minimum input level. (External mode) 0 See above ps

Table IXd
Master receiver electrical specifications Parameter Description Min Type of. Max Unit V _{IT +} High threshold differential receiver input voltage (not biased). Above this differential voltage, the input signal is interpreted as a logic unit level. 0 fifty mV V _IT Low threshold differential receiver input voltage (not biased). Below this differential voltage, the input signal is interpreted as a logic zero level. -fifty 0 mV V _{IT +} High threshold differential input voltage of the receiver (offset for waking up from sleep mode (hibernation)). Above this differential voltage, the input signal is interpreted as a logic unit level.   125 175 mV V _IT Low threshold differential input voltage of the receiver (offset for waking up from sleep mode (hibernation)). Below this differential voltage, the input signal is interpreted as a logic zero level. 75 125   mV V _{input range} The allowed input voltage range of the receiver with respect to the ground of the master 0 1.65 AT I _in Input leakage current (excluding inactivity bias) -10 10 μA C _pad Contact pad capacity relative to the ground of the master 5 pF C _diff Capacitance between two differential pair signals one pF t _skew-pair The time shift caused by the differential receiver between the positive and negative inputs of the differential receiver of the same differential pair (shift within the pair). 250 ps t _{skew-pair-EXT} Shift inside the pair, external mode fifty ps t _A Jitter, bit boundary to center mark t _B -38.5 ps t _{B-TP0-RCVR-INT} Jitter, bit boundary to the minimum input level. (Internal mode) See above ps t _{B-TP0-RCVR-EXT} Jitter, bit boundary to the minimum input level. (External mode) See above ps

42, the host controller 4202 and the display client or controller 4204 are shown transmitting packets on a communication link 4206. The master controller uses a sequence of three masters 4210, 4212 and 4214 to receive the DATA and STB signals of the master to be transmitted, as well as to receive client data signals to be transmitted, while the client uses three masters 4230, 4232, and 4234. The master device responsible for passing the DATA (4212) of the master uses the enable input signal to enable the activation of the communication link, usually only when transmission from the master is required about the device to the client. Since the STB signal is formed as part of the data transmission, no additional enable signal is used for this driver (4212). The inputs of each of the DATA and STB client signal receivers (4232, 4230) have impedances (impedances) of the terminal loads or resistors 4218 and 4220, respectively included in them. The driver 4234 in the client controller is used to prepare data signals transmitted from the client to the master, where the driver 4214 on the input side processes the data.

Special receivers (master devices) 4216 and 4236 are connected or connected to the DATA lines and generate or use a voltage offset of 125 mV, described above, as part of the idle state control described elsewhere in the description. Offsets cause line receivers to inactive interpret unexcited signal pairs as a logic zero level.

The aforementioned drivers and impedances can be formed as discrete components or as part of a circuit module, or as specialized integrated circuits (ASICs), which act as more cost-effective solutions to an encoder or decoder.

It can be easily seen that power is transmitted to the client device, or display, from the master device using the signals labeled HOST_Pwr and HOST_Gnd over a pair of conductors. The HOST_Gnd part of the signal acts as a reference ground and a return path or power signal for the client device. The HOST_Pwr signal acts as a power supply to the client device, which is excited by the master. In an exemplary configuration for low power applications, the client device is allowed to consume 500 mA. The HOST_Pwr signal may be provided from portable power sources, such as, but not limited to, batteries or a lithium-ion battery pack residing in the host device, and may vary from 3.2 to 4.3 V with respect to HOST_Gnd.

VII. Time characteristics

A. Overview

The stages and signal levels used to enter an idle state (hibernation) (no service is requested, desired or required) and providing a service for a client from a host device initiated by either the host device or the client are illustrated in FIG. 43A, 43B and 43C, respectively. In FIG. 43A, 43B, and 43C, the first part of the illustrated signals shows a “Link Shutdown” packet transmitted from the host device, and the data line is then set to a logic zero state using a high impedance bias circuit. No data is transmitted by the client or the master, which have their master device disabled (blocked). The sequence of strobe pulses for the MDDI_Stb signal line can be seen below, since MDDI_Stb is active during the package "Shutdown communication line". As soon as this packet completes, the logic level changes to zero since the master drives the bias circuit and logic to zero. This represents the end of the transmission of a previous signal or service from the host device, could have occurred at any time in the past and is included in order to indicate the termination of the previous service and the state of the signals before the service began. If required, for example, a signal can be sent only to set the communication line in proper condition without the 'known' prior exchange attempted by this master.

As shown in FIG. 43A and described above for the “Link Shutdown” packet, in the idle state with low power consumption, the MDDI_Data0 driver is locked in the high impedance state starting from the 16th to the 48th clock or MDDI_Stb pulses after the last bits of the All Zeros field in the “Link Shutdown” packet. For Type-2, Type-3, or Type-4 communication lines, the MDDI_Data1 - MDDI_DataPwr7 signals are also brought into a high impedance state at the same time that the MDDI_Data0 driver is disabled (blocked). As described in the definition of the All Zeros field, MDDI_Stb switches within 64 cycles (or as required for system design) after the least significant bit of the CRC field of the “Link Shutdown” packet to allow the client to complete the processing to be completed, and facilitates an orderly shutting down the client controller. One cycle is a transition from low to high, followed by a transition from high to low or a transition from high to low, followed by a transition from low to high. After the All Zeros field is sent, the master devices MDDI_Stb and NMDI_DATA0 in the master are disabled and the master enters an idle state with low power consumption. After a certain period of time has elapsed, the master device starts the reset sequence of the communication line, as shown in FIG. 43B and 43C, by resolving the lines or outputs of the drivers MDDI_Data0 and MDDI_Stb, and starts switching MDDI_Stb as part of a wakeup request initiated by either the master or client.

As shown in FIG. 43B, after some time has passed and when the output signals from the master devices for MDDI_Data0 and MDDI_Stb have been prohibited, the master device initiates a service or waking up from the idle state by resolving its master device MDDI_Stb for the time indicated by t _{stb-data -enbl} , during which the line is energized to logic zero until it is fully resolved and then resolving its master MDDI_Data0. The master device stores MDDI_Stb at logical zero after MDDI_Data0 reaches a high level or logical unit level, which occurs during the time period indicated by t _{client-startup} . At the end of the t- _{client-startup} time period, the master then switches the signal or line MDDI_Stb. The master sets the MDDI_Data0 line to a high level, a logical unit level, while the client does not drive MDDI_Data0 for the time period indicated by t _restart-high , and then sets MDDI_Data0 to a low level, or to a logic zero level, for a period of time denoted by t _restart-low . After that, the forward link traffic first starts with the Sub-frame Header packet and then the forward link traffic packets are transmitted. The MDDI_Stb signal is active for a period of time t _restart-low and the subsequent sub-frame header packet.

As shown in FIG. 43C, after a certain period of time has elapsed when the output signal from the master devices for MDDI_Data0 and MDDI_Stb is prohibited, the client initiates a service or wakeup request from the idle state by resolving the offset in the receiver or the output signal MDDI_Stb for the time indicated by t _{stb- data-enbl} , as described above, before the master resolves its master MDDI_Stb. The client then resolves its master device MDDI_Data0 for the time indicated by t _host-detect , during which the line is set to logic zero before the master device MDDI_Stb starts switching.

A certain period of time elapses or may be necessary before the master detects a request during t _host-detect , after which the master responds by holding MDDI_Stb at logic zero for the period indicated by t _stb-startup before the master starts switching MDDI_Stb using a link start sequence by driving MDDI_Data0 to a logic unit level or a high level for a time period t _restart-high . When the client recognizes the first pulse on MDDI_Stb, it inhibits the offset in its MDDI_Stb receiver. The client continues to drive MDDI_Data0 to the level of a logical unit for the period indicated by t _{client-detect} , until it detects the master device that drives the line. At this moment, the client withdraws the request and prohibits its master device MDDI_Data0, so that the output signal from the client again grows to the logical zero level, and the master device is the exciting MDDI_Data0. As before, the master continues to drive MDDI_Data0 to the logical unit level for the t _restart-high time period and then sets the MDDI_Data0 communication line to low for the t _restart-low time period, after which the forward link traffic starts again with the packet " Subframe Title ". The MDDI_Stb signal is active for a period of time t _restart-low and the subsequent sub-frame header packet.

Table X shows characteristic time points or processing periods during the various periods described above, and the ratios for the approximate minimum and maximum data rates, where:

t _bits = 1 / (Link data rate), where Link data rate is the bit rate of one data pair.

Table X Parameter Description Min Type of. Max Units measuring 1 / t _BIT-min-perf Low-Speed Data Rate 0.001 1,1 Mbps 1 / t _BIT-max-perf The maximum range of the data rate of the communication line for the device, external 0.001 400 Mbps 1 / t _BIT-max-perf The maximum range of the data rate of the communication line for the device, internal 0.001 550 Mbps Reverse Link Data Rate 0,0005 fifty Mbps t _BIT The period of one bit of data direct line of communication, external mode 2.5 10 ⁶ ns t _BIT Single Bit Data Period, Internal 1.8 10 ⁶ ns t _restart-high The duration of the high level of the restart pulse of the communication line of the master device 140 150 160 Tact Stb t _restart-low The duration of the low pulse level of the restart of the communication line of the master device fifty fifty fifty Tact Stb t _{stb-data-enabl} MDDI_Stb fully resolved to MDDI_Data0 permitted link restart sequence 0 μs t _{client-startup} Time for the master to hold MDDI_Stb at logic zero after MDDI_Data0 reaches a high logic level 200 ns t _host-detect Time from high level MDDI_Data0 to switch MDDI_Stb 0 1000 μs t _{client-detect} Time for the client to detect MDDI_Data0 on the runtime device at a high logical level 60 80 Tact Stb t _stb-startup Time for the master to hold MDDI_Stb at logic zero before the master starts switching MDDI_Stb 200 ns

It will be apparent to those skilled in the art that the functions of the individual elements illustrated in FIG. 41 and 42 are well known, and the function of the elements in FIG. 42A is confirmed by the timing diagram in FIG. 43A, 43B and 43C. Details regarding the termination sequences and resistors for the idle state, which are illustrated in Fig. 42A, were omitted in Fig. 41, since this information is not necessary to describe how to perform encoding of the strobe data and restore synchronization from it.

B. Timing diagrams data-strobe forward link

The switching characteristics for transmitting data in a straight line from a driver that drives the output signal are shown in Table XI-1. Table XI presents a tabular form of the required minimum and maximum values, which should take place depending on typical times for some signal transitions. For example, a typical length of time to go from the beginning to the end of a data value (output '0' or '1'), the transition from Data0 to Data0, called t _{tdd- (host-output)} (output signal from the host device), is t _tbit , while the minimum time is approximately t _tbit -0.5 ns and the maximum is approximately t _tbit +0.5 ns. The relative gap between the transitions to Data0, other data lines (DataX) and strobe lines (Stb) is illustrated in Fig. 44, which shows the transitions Data0 to Strobe, Strobe to Strobe, Strobe to Data0, Data0 to non-Data0, non-Data0 to non-Data0, non-Data0 in the Strobe and Strobe in non-Data0, which are designated as 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)} respectively.

Table XI-1 Parameter Description Min Type of. Max Unit t _{tdd- (host-output)} Transition Data0 to Data0 t _tbit -0.5 t _tbit t _tbit +0.5 ns t _{tds- (host-output)} Transition Data0 to Strobe t _tbit -0.8 t _tbit t _tbit +0.8 ns t _{tss- (host-output)} Going Strobe to Strobe t _tbit -0.5 t _tbit t _tbit +0.5 ns t _{tsd- (host-output)} Go Strobe to Data0 t _tbit -0.8 t _tbit t _tbit +0.8 ns t _{tddx- (host-output)} Transition Data0 to non-Data0 t _tbit ns t _{tdxdx- (host-output)} Transition of non-Data0 to non-Data0 t _tbit -0.5 t _tbit t _tbit +0.5 ns t _{tdxs- (host-output)} Transition of Non-Data0 to the Strobe t _tbit ns t _{tsdx- (host-output)} Going Strobe to Non-Data0 t _tbit ns

Typical MDDI timing diagram requirements for an input signal from a client receiver for the same signals transmitting data on a forward link are shown in Table XI-2. Since the same signals are described, but with a time delay, a new drawing is not required to illustrate the characteristics of the signal or the meaning of the corresponding notation, as will be appreciated by those skilled in the art.

Table XI-2 Parameter Description Min Type of. Max Units t _{tdd- (client-input)} Transition Data0 to Data0 t _tbit -1.0 t _tbit t _tbit +1.0 ns t _{tds- (client -input)} Transition Data0 to Strobe t _tbit -1.5 t _tbit t _tbit +1.5 ns t _{tss- (client -input)} Going Strobe to Strobe t _tbit -1.0 t _tbit t _tbit +1.0 ns t _{tsd- (client -input)} Go Strobe to Data0 t _tbit -1.5 t _tbit t _tbit +1.5 ns t _{tddx- (client-output)} Transition Data0 to non-Data0 t _tbit ns t _{tdxdx- (client-output)} Transition of non-Data0 to non-Data0 t _tbit ns t _{tdxs- (host-output)} Transition of Non-Data0 to the Strobe t _tbit ns t _{tsdx- (host-output)} Going Strobe to Non-Data0 t _tbit ns

FIG. 45 and 46 illustrate the presence of a delay in the response, which may occur when the master device disables or enables the master device of the master device, respectively. In the case where the master sends some packets, for example, the “Reverse Link Encapsulation” packet or the “Measure forward and reverse signal delay” packet, the master disconnects the line driver after the required packets are sent, such as “ Parameter CRC "," Strobe Alignment "and" All Zeros ", illustrated in Fig. 45 as transmitted. However, as shown in Fig. 45, the line status does not necessarily instantly switch from '0' to the desired high value although this is potentially achievable with some control circuits or elements, it requires a period of time called the “master inhibitor inhibit delay period” to give a response. While this can occur almost immediately, this time period is 0 nanoseconds (ns), it can easily be stretched over a slightly longer period of time from 10 ns as the required maximum length of the time period that occurs during periods packets "Guard interval 1" or "Change to the opposite 1".

From FIG. 46, you can see the change in signal level that occurs when the master device of the master device is enabled (unlocked) for transmitting a packet, such as a “Reverse Link Encapsulation” packet or a “Measurement of signal delay in forward and reverse directions” packet. Here, after periods of the "Protective time interval 2" or "Change to opposite 2" packets, the master device of the master device is unlocked and begin to set the level, here it is '0', and this value is approached or reached during the time called the period of the “Resolution delay of the master device ", which takes place during the re-enable period of the driver before the first packet being sent.

A similar process takes place for drivers and signal transmissions for the client device, here - the display. General recommendations for the duration of these periods and their respective ratios are illustrated in table XII below.

Table xii Description Min Max Unit Master Prohibition Delay Delay 0 10 ns Master Delay Resolution 0 2.0 ns Display driver inhibit inhibit delay 0 10 ns Display driver delay 0 2.0 ns

 C. Times for enabling and disabling the output of the master and client

Switching characteristics and relative timing for the enable and disable times of the output of the host device and the client or operations related to the structure and period of the Reverse Link Encapsulation packet are illustrated in FIG. 48. Functions or operations of the output signal of the master device are marked as: t _host-enable for the _enable time of the output signal of the master device, t _host-disable for the time for _{inhibit the} output signal of the master device, t _{client-enable} for the _enable time of the output signal of the client, and t _{client-disable} for client output inhibit time. Typical transition times for some signals are described below. The minimum period for these operations may be zero nanoseconds, with typical or maximum values determined based on the design of the system using the interface, possibly of the order of 8 nanoseconds or more.

General recommendations for the duration of these periods (enable / disable times of the master and client) and their respective ratios are illustrated below in Table XIII.

Table XIII Parameter Description Min Type of. Max Units t _host-enable Master output resolution time 0 24 * t _BIT ns t _host-disable Master output inhibit time, total field duration Change to the opposite 1 0 24 * t _BIT ns t _{client-enable} Client output signal resolution time, total duration of the field “Change to the opposite 1” 0 24 * t _BIT ns t _{client-disable} Client output inhibition time, measured from the end of the last bit of the “Change to opposite 2” field 0 24 * t _BIT ns

Viii. Implementation of control of the communication line (operation of the controller of the communication line)

A. State Machine Packet Processor

Packets transmitted over the MDDI link are sent very quickly, usually with a transfer rate of about 300 Mbps or more, for example 400 Mbps, although lower speeds are, of course, necessary if necessary. This type of bus or transmission line is too large to control currently commercially (economically) available general purpose microprocessors or the like. Therefore, a practical implementation for performing this type of signal transmission should use a programmable state machine to analyze the input stream of packets in order to form packets that are transmitted or forwarded to the corresponding audiovisual subsystem for which they are intended. Such devices are well known and employ circuits typically specialized for a limited number of operations, functions, or states in order to achieve the desired high speed or very high speed operation.

Generic (general purpose) controllers, processors, or processing elements can be used to more appropriately perform actions on or manipulate certain information, such as the management or state of packets, which require lower speed. When such packets (controls, states, or other predetermined packets) are received, it is recommended that the state machine transmit them through a data buffer or similar processing element to a general-purpose processor so that the packets can be acted upon to provide the desired result (effect) in while audio and visual packets are passed on to their respective destination for action. If in the future microprocessors or other universal controllers, processors or processing elements will be manufactured in order to achieve the possibility of processing higher data rates, the states or state machine described below can also be implemented using software control for such devices, usually such as programs stored on storage elements or means.

A general-purpose processor function can be implemented in some embodiments, taking advantage of the processing power or excessive clock cycles available for microprocessors (central processing units) in computer applications or controllers, processors, digital signal processors (DSPs), specialized circuits, or specialized integrated circuits (ASIC) available in wireless devices, similar to how some modems or GPUs use processing power ENTRAL processors available in computers to perform some functions and reduce the complexity and cost of the hardware. However, such sharing or application of a clock cycle can adversely affect the processing speed, synchronization, or the entire operation of such elements, so that in many applications specialized circuits or elements are preferred for such general processing.

In order for the image data to be viewed on the display (microdisplay), or for reliable reception of all packets sent by the master, the processing of the client signals is synchronized with the clocking of the forward link channel. That is, signals reaching the client and client circuits must be substantially synchronized in time in order for proper signal processing to occur. An enlarged state diagram achieved by the signal for one embodiment is shown in the illustration of FIG. 49. 49, possible forward link synchronization “states” for state machine 4900 are shown divided into categories, such as one ASYNC FRAMES STATE 4904 (asynchronous frame state), two ACQUIRING SYNC STATES 4902 and 4906 (synchronization capture states), and three IN- SYNC STATES 4908, 4910, and 4912 (states in synchronism).

As shown by the initial step or state 4902, the display or client, such as a presentation device, starts operation in the preselected “no synchronization” state and searches for a unique word in the first “Sub-frame Header” packet that is detected. It should be noted that this state without synchronization represents the setting (setting) of the minimum exchange or setting (setting) of the "transition to emergency mode", in which the Type 1 interface is selected. When a unique word is found during the search, the client saves the sub-frame length field. There is no verification of CRC code bits for processing with respect to this first frame or until synchronization is obtained. If the length of this sub-frame is zero, then processing the synchronization state accordingly proceeds to state 4904, marked here as the “asynchronous frames” state, which indicates that synchronization has not yet been achieved. This processing step is marked as the met condition cond 3, or state 3, in FIG. 49. Otherwise, if the frame length is greater than zero, then the processing of the synchronization state proceeds to state 4906, where the interface state is set to "found one synchronization frame". This processing step is marked as the met condition cond 5, or state 5, in FIG. 49. In addition, if the state machine sees a frame header packet and a good definition of the CRC code for a frame length greater than zero, the processing proceeds to the "found one synchronization frame" state. This is flagged as cond 6, or state 6, in FIG. 49.

In each situation in which the system is in a state other than “no synchronization”, if a packet with a good CRC result is detected, then the interface state changes to state 4908 “in synchronism”. This processing step is marked as the met condition cond 1, or state 1, in FIG. 49. On the other hand, if the CRC in any packet is incorrect, then the processing of the synchronization state proceeds or returns to state 4902 of the "NO SYNC FRAME" interface (there is no synchronization frame). This part of the processing is marked on the state diagram of Fig. 49 as a met condition cond 2, or state 2.

B. Capture time for synchronization

The interface can be configured to place (enable) a number of “synchronization errors” before deciding that the synchronization is lost and return to the “NO SYNC FRAME” state. According to Fig. 49, as soon as the state machine has reached the "IN-SYNC STATE" state and no errors have been found, this means that the result cond 1 is continuously received, and remains in the "IN-SYNC" state. However, as soon as one result of cond 2 is detected, the processing changes state to state 4910 "one-sync-error" (one synchronization error). At this moment, if processing leads to the discovery of another result of cond 1, then the state machine returns to the in-sync state (in synchronism), otherwise it encounters another result of cond 2 and enters state 4912 "TWO-SYNC-ERRORS" (two sync errors). Again, if cond 1 occurs, processing returns the state machine to the "IN-SYNC" state. Otherwise, when another cond 2 state is encountered, the state machine returns to the no-sync state (no synchronization). It is also clear that if the interface should meet the “Shutdown of the communication line” packet, then this will force the communication line to complete the data transfer and return to the “no-sync frame” state (there is nothing to synchronize with) that is labeled as the occurring condition cond 4, or state 4, in the state diagram according to Fig. 49.

It is understood that repeated “false copies” of the unique word are possible, which may appear at some fixed location within the sub-frame. In this situation, it is very unlikely that the state machine will synchronize with the sub-frame, since the CRC for the "Sub-frame header" packet must also be reliable during processing in order for the MDDI processing to go into the "IN-SYNC" state (in synchronism )

The sub-frame length in the Sub-frame Header packet can be set to zero to indicate that the master will only transmit one sub-frame before the link is completed and the MDDI is put in or configured to an inactive idle state . In this case, the client should immediately receive packets on the forward link after detecting the Sub-Frame Header packet, since only a single sub-frame is sent before the communication line goes into an idle state. In normal or typical operations, the sub-frame length is nonzero, and the client only processes the forward link packets, while the interface is in those states that are collectively shown as “IN-SYNC” states in FIG. 49.

The client device in external mode can be connected to the master device, while the master device is already transmitting the data sequence in a straight line. In this situation, the client must synchronize to the master. The time required for the client to synchronize to the forward link signal is variable depending on the size of the sub-frame and the data rate on the forward link. The probability of detecting a “false copy” of a unique word as part of random, or more random, data in the forward link is greater when the sub-frame size is large. At the same time, the ability to recover from false detection is lower, and the time required to complete this is large when the data rate on the forward link is lower.

For one or more embodiments, it is recommended or understood that the MDDI master must take some additional steps to ensure that the MDDI reverse link is stable before it stops transmitting on the forward link to switch to low power consumption mode or to fully shut down the communication line.

One of the problems that can occur is that if the master device uses an incorrect measurement of the signal transmission time in the forward and reverse directions, it can cause the failure of all subsequently received data transmission on the reverse link from the client, even if the direct the link seems "very good." This can happen if the host device tries to send the packet “Measurement of the signal delay in the forward and reverse directions” when the client is not in synchronism with the forward link or due to a critical change in the ambient temperature, which causes a corresponding large change in the propagation delay of the differential drivers and receivers, which affects the delay in the signal flow in the forward and reverse directions.An unstable contact of a cable or connector can also cause If the client temporarily loses synchronization and then restores synchronization, during this time he may skip receiving the packet “Measurement of the delay of signal passage in the forward and reverse directions”. Subsequent reverse link packets cannot be decoded properly by the master.

Another type of problem that can occur is when the client temporarily loses synchronization and the master sends the “Shut Down Link” packet before the client is able to restore synchronization. The master will be inactive while the client is unable to enter in the idle state, because it has not received the “Shutdown of the communication line” packet and does not have a synchronization signal, since the communication line is inactive.

One technique or embodiment used to overcome such problems is to have a master device that ensures that the client is in sync with the forward link before the link goes into an idle state. If the MDDI master is unable to provide this or does not have such an opportunity, so that when it "loses" power, or the communication line is suddenly interrupted, or a failure occurs due to separation, rupture or disconnection of the cable, conductor or connector that occurs during operation , then the master should first try to ensure that the client is in sync before starting the process of measuring the signal transmission time in the forward and reverse directions or sending the “Reverse Link Encapsulation” packet.

The master can observe the CRC Error Count field in the Client Request and Status Request packet sent by the client to determine the integrity of the forward link. This packet is requested by the master from the client. However, in the event of a serious communication failure or failure, this request will most likely be left unanswered, as the client will not be able to properly decode this packet or, possibly, even receive it as a whole. The request for receiving the CRC Error Count, using the sending of the Client and Status Request packet sent in the Reverse Link Encapsulation packet, acts as the first integrity check, a kind of first line of defense. In addition, the master can send a packet “Measurement of the delay of signal propagation in the forward and reverse directions” to confirm whether or not the assumption regarding the client that has lost synchronization is valid. If the client does not respond to the packet “Measurement of the delay of signal propagation in the forward and reverse directions ", the master concludes that the client is out of synchronism, and can then begin the process of returning to synchronism.

It is generally recommended that the master continuously monitor the CRC Error Count value in the client by periodically sending the Reverse Link Encapsulation packet to the client with bit 1 of the Reverse Link Flags field set to 1 in order to require the client to return the packet “ Client and Status Request ”to the master.

Once the host device concludes that the client has most likely lost synchronization with the forward link, it waits for the next sub-frame header before attempting to send any packets other than placeholder packets. This is done in order to provide the client with enough time to discover or search for one unique word contained in the Sub-frame Header package. After that, the master can assume that the client has reset itself because it could not find a unique word in the correct location. At this point, the master can track the Sub-frame Header packet with the Forward and Reverse Measurement Delay packet. If the client still does not respond correctly to the Forward and Reverse Measurement Delay of the Signal Packet packet, the master the device can repeat the re-synchronization process. The correct answer is one in which the client sends the specified sequence back to the master in the "Measurement period" field of the packet "Measurement of the delay of the signal in the forward and reverse directions." If this sequence is not accepted, then attempts to receive reverse link data in the Reverse Link Encapsulation packet will fail. A long-term failure of this nature may indicate some other system error that must be resolved in some other way and is not part of the synchronization communication lines at this moment.

However, if after the “Forward and Reverse Directional Measurement Delay” packet is successful, the host device still sees corrupted data or no response in the “Reverse Link Encapsulation” packets, it is recommended that the host device confirms that the selection of the reverse link data is correct by re-sending the packet "Measurement of the delay of the signal in the forward and reverse directions." If this is unsuccessful after a series of attempts, it is recommended in one embodiment that the master would decrease the reverse link data rate by increasing the value of the reverse link rate divider.

It is recommended that the master performs Link Failure Detection and possibly the steps for re-synchronizing the link described above before putting the MDDI link in an idle state. This will usually ensure that the “Measurement of the signal delay forward and reverse” packet performed when the restart of the communication line is later restarted is successful. If the host device has no reason to suspect a communication line failure and the client has sent the correct response to the packet " Encapsulation of the reverse link ”and the zero value is the number of errors of the CRC code of the forward link, the master may assume that everything is working or is functioning in an appropriate or appropriate way (there is no failure uu communication, for example), and continue the process of reducing power / idle consumption.

Another way in which the master can check for synchronization is for the master to send a forward and reverse measurement of the signal delay and confirm the response from the client is correct. If the master responds to the answer, it is reasonable to assume that the client successfully interprets forward link packets.

C. Initialization

As described above, during the “start-up”, the host device configures the forward link so that it operates at or below the required minimum, or desired, data rate of 1 Mbps and configures the sub-frame length and media frame rate accordingly way for this application. That is, both the forward and reverse links start working using the Type 1 interface. These parameters are usually supposed to be used only temporarily, while the master determines the possibility or the required configuration for the display of the client (or another type of client device). The master sends or transmits the Sub-frame Header packet on the forward link, followed by the Reverse Link Encapsulation packet, which has a 'Request Flags' bit '0' set to unity (1) to request that the display or the client responded with the “Client Features” package. As soon as the display captures the synchronization on (or c) the forward line (s) of communication, it sends the packet “Client Features” and the packet “Client Request and Status” on the reverse link or channel.

The host device checks the contents of the Client Capabilities packet to determine how to reconfigure the communication line for the optimal or desired level of efficiency. The master checks the Protocol Version and Minimum Protocol Version fields to confirm that the master and client use protocol versions that are compatible with each other. Protocol versions are usually stored as the first two parameters of the Client Features package so that compatibility can be determined even when other protocol elements cannot be compatible or are fully understood as compatible.

In the internal mode, the master can know the client parameters in advance without the need to receive the "Client Features" packet. The communication line can be launched at any data rate at which both the master and the client can work. In many embodiments, the system designer is most likely to choose the ability to run the link at the maximum achievable data rate to speed up data transfer, but this is not required and may not be used in many situations. For operation in internal mode, the frequency of the strobe pulses used during the restart of the communication line from the inactivity sequence will usually be compatible with this desired transmission rate.

D. CRC code processing

For all types of packages, the state machine for processing packets ensures that the CRC code verification unit is controlled appropriately or properly. This also leads to an increase in the CRC code error counter when comparing the CRC code results in one or more errors and it resets the CRC code counter at the beginning of each processed sub-frame.

E. Alternative synchronization loss check

While the above-described sequences of steps or states work to provide higher data rates or speeds, applicants have found that an alternative arrangement or change in the conditions that the client uses to announce that there is a loss of synchronization with the master device may be effectively used to achieve even higher data rates or performance. The new proposed embodiment has the same basic structure, but with altered conditions for changing states. Additionally, a new counter is being implemented to help implement a sub-frame synchronization check. These steps and conditions are presented with reference to FIG. 63, which illustrates a number of conditions and conditions used in establishing the operations of a method or state machine. Only parts of the "ACQUIRING-SYNC STATES" (synchronization capture state) and "IN-SYNC STATES" (synchronization state) are shown for clarity. In addition, since the resulting states are essentially the same as the state machine itself, they use the same numbering. However, the conditions for changing states (and the operation of the state machine) vary somewhat, so that all are renumbered for clarity between the two figures (1, 2, 3, 4, 5, and 6 compared with 61, 62, 63, 64, and 65) for convenience in identifying differences. Since the ASYNC FRAME state (asynchronous frame) is not considered in this description, one state (4904) and one state (6) are no longer used in the drawing.

In Fig. 63, the system or client (for display or presentation) starts when the state machine 5000 is in the preselected state 4902 "no synchronization", as in Fig. 49. The first state change for changing states from the no synchronization state 4902 occurs in condition 64, which is a synchronization pattern detection. Assuming that the CRC of the sub-frame header is also transmitted in this packet (condition 61 is satisfied), the state of the packet processing state machine can be changed to state 4908 in-sync (in synchronism). A synchronization error, condition 62, will cause the state machine to transition to state 4910, and a second appearance for state 4912. However, it was found that any error in the CRD code of the MDDI packet will cause the state machine to transition from state 4908 (in synchronism) to state 4910 with one synchronization error . Another error when receiving the CRC code of any MDDI packet will cause a transition to state 4912 with two synchronization errors. A packet decoded with the correct CRC value will force the state machine to return to state 4908 in-sync (in synchronism).

It has been changed that it is necessary to use a CRC value or discovery for "every" packet. That is, it is necessary for the state machine to look at the CRC value for each packet in order to detect a loss of synchronization instead of only observing the "Sub-frame header" packets. In this configuration or process, synchronization loss is not detected using a unique word and only the CRC value of the sub-frame header.

This new interface implementation allows the MDDI link to detect synchronization failures much faster and therefore also recover from them more quickly.

To make this system more robust (stable), the client must also add or use a sub-frame counter. The client then checks for the presence of a unique word at the moment when it is expected to arrive or occur in the signal. If a unique word is not found at the right time, the client can recognize that a synchronization failure has occurred, much faster than if it had to wait for several time intervals or periods (here three) of the packet, which were longer than the length of the sub-frame. If checking for a unique word indicates that it is not present, in other words, that the synchronization is incorrect, then the client can immediately announce the loss of synchronization of the communication line and switch to the no-sync state (no synchronization). The process of checking for the presence of an appropriate unique word adds condition 65 (cond 65) to the state machine, indicating that the unique word is incorrect. If the sub-frame packet is expected to be received on the client and does not match, the client can immediately go to state 4902 “no synchronization”, saving additional time, waiting for many synchronization errors (condition 62), which are usually encountered when passing through states 4910 and 4912.

This change uses an additional counter or count function in the client core to count the length of the sub-frame. In one embodiment, a countdown function is used, and the transmission of any packet that is currently being processed is interrupted to check for a unique sub-frame word if the counter value is reset. Alternatively, the counter may count with increasing count value, and this value is compared with the desired maximum or specific required value at the moment the current packet is checked. This process prevents the client from decoding packets that are incorrectly received in the client with unusually large packet lengths. If the sub-frame length counter must interrupt some other packet that is being decoded, a loss of synchronization can be determined, since no packet should cross the border of the sub-frames.

IX. Package processing

For each type of packet described above that the state machine accepts, it takes a specific processing step or sequence of steps to implement the interface. Forward link packets are typically processed according to the exemplary processing shown in Table XIV below.

Table XIV  Package type Batch Processing State Machine Response Sub-Frame Header (SH) Confirms a good packet, captures the sub-frame length field, and sends the packet parameters to the general-purpose processor. Filler (Filler, F) Ignores data Video Stream (VS Stream) Interprets the “Video data format descriptor” and other parameters, unpacks the packed pixel data when necessary, converts the pixels in the color map, if necessary, and writes the pixel data to the appropriate locations in the bitmap Audio Stream (AS Stream) Sends audio sample rate settings to an audio sample synchronization generator, extracts audio samples of a given size, decompresses audio sample data when necessary, and routes the audio samples to the corresponding FIFO audio sample buffer Color Map (CM) Reads the size and offset settings of the color map and writes color map data to the color map memory or storage location. Reverse Link Encapsulation (REL) Facilitates sending packets in the opposite direction at the appropriate time. Flags of the reverse link are checked and the “Client Features” packets are sent, if necessary. Client Request and Status Packets are also sent if necessary. Client Capability Sends this type of packet when requested by the master using the Reverse Link Flags field of the Reverse Link Encapsulation packet. Keyboard (Keyboard, K) Transmits these packets to and from the general-purpose processor (a), which communicates with a device such as a keyboard, if present, and uses it as required. Pointing Device (PD) Transmits these packets to and from a general-purpose processor (a), which exchanges a device such as a pointing device, if present, and uses it as required. Link Shutdown (Link Shutdown, LS) Records that the actual link is shutting down and informing the general-purpose processor. Client Request and Status (CRS, Client Request and Status) Sends this packet as the first packet in Reverse Link Encapsulation. Bitmap Block Transfer (BPT, Bitmap Block Transfer) Interprets packet parameters, such as “Video data format descriptor”, determines which pixels to transmit first, and transmits pixels in the bitmap in the required manner. Bitmap Area Fill (BAF, Bitmap Area Placeholder) Interprets the package parameters, converts the pixels in the color map, if necessary, and writes pixel data to the appropriate places in the bitmap. Bitmap Pattern Fill (BPF, Bitmap Pattern Placeholder) It interprets the parameters of the packet, unpacks the packed pixel data, if necessary, converts the pixels in the color map, if necessary, and writes the pixel data to the appropriate places in the bitmap. Communication Link Channel (CLC) Sends this data directly to a general-purpose processor. Wake-up from hibernation The special purpose state machine controls the low level functions of sending and detecting the awakening sequence. Perform Type Handoff, Performing an Interface Type Service (PTH) Switch It can act on such packets either directly or by transmitting them to a general-purpose processor, also issuing a command to the hardware to submit to a change in mode.

X. Reverse link data rate reduction

Applicants have observed that some of the parameters used for the communication controller of the host device can be adjusted or configured in some way to achieve maximum or more optimized (scaled) reverse link data rate, which is very desirable. For example, during the time used to transmit the Reverse Data Packets field of the Reverse Link Encapsulation packet, the MDDI_Stb signal pair is switched to synchronize the periodic data with half the forward link data rate. this is because the host controller's line controller generates the MDDI_Stb signal, which corresponds to the MDDI_Data0 signal, as if all zeros were sent.The MDDI_Stb signal is transmitted from the master to the client, where it uses I to generate a clock signal for transmitting the reverse link data from the client, with which the return data is sent back to the master device. An illustration of the typical delay values encountered for signal transmission and processing on the forward and reverse paths in a system using MDDI is illustrated in FIG. 50. In FIG. 50, a sequence of delay values of 1.5 ns, 8.0 ns, 2.5 ns, 2.0 ns, 1.0 ns, 1.5 ns, 8.0 ns and 2.5 ns are shown. near processing parts for Stb +/- generation, cable transmission - client, client receiver, sync generation Nala, the timing signal, generated Data0 +/-, transmission on the cable - the master device and the master receiver, respectively.

Depending on the forward link data rate and the signal processing delays experienced, it may take longer than one clock cycle of the MDDI_Stb signal for the effect of “signal passing in the forward and reverse directions” or setting events that must be completed, which leads to the use of unwanted time intervals or cycles (cycles). To get around this problem, the “reverse link bit rate divider” allows you to span multiple clock cycles of the MDDI_Stb signal over a single bit on the reverse link. This means that the reverse link data rate is lower than the forward link rate.

It should be noted that the actual duration of delays in the passage of the signal through the interface may differ depending on each specific host-client system or the hardware used. Although not required, each system can usually be made to work better by using the “Measure forward and reverse signal delay” package to measure the actual delay in the system so that the reverse link rate divider can be set to the optimal The master can support either the main data sampling rate, which is simpler, but works at a slower speed, or an advanced data sampling frequency, which is I’m more complex, but supports higher reverse link data rates.The ability of a client to support both methods is considered the same.

The forward and reverse transmission time delay is measured when the master sends the “Forward and Reverse Measurement Delay” packet to the client. The client responds to this packet by sending a sequence of units back to the master inside, or during, a pre-selected measurement window in this packet, called the Measurement Period field. The detailed timing diagram of this measurement has been described above. Delay in forward and reverse signal transmission time It is used to determine the baud rate at which reverse link data can be safely selected.

The measurement of the delay time of signal transmission in the forward and reverse directions consists of determining, detecting, or counting the number of synchronization intervals of the forward link data taking place between the beginning of the Measurement Period field and the beginning of the time period when the response sequence 0xff, 0xff, 0x00 is received back in the master from the client. It should be noted that it is possible that a response from a client can be received on a small part of the synchronization period of the forward link before the value of the measurement account is about to increase. If this unmodified value is used to calculate the reverse link bit rate divider, this can cause bit errors on the reverse link due to unreliable data sampling. An example of this situation is illustrated in FIG. 51, where signals representing MDDI_Data in the master device, MDDI_Stb in the master device, synchronizing the forward link data inside the master device and counting the delay, then write the resulting pixel to the destination pixel location, illustrated in graphical form. In Fig. 51, a response sequence was received from the client to a portion of the forward link cycle before the delay count was about to increase from 6 to 7. If the delay is taken to be 6, then the master will retrieve the reverse link data only after a bit transition or possibly in the middle of a bit junction. This can lead to erroneous sampling in the master. For this reason, it is recommended that the measured delay is usually increased by one before it is used to calculate the reverse link rate divider.

The reverse link bit rate divider is the number of MDDI_Stb clocks that the master must wait before sampling the reverse link data. Since MDDI_Stb is clocked at a transmission rate that is half the forward link transmission rate, the corrected measurement of the transmission time delay of the signal in the forward and reverse directions should be divided by 2 and then rounded to the next larger integer. Expressed as a formula, this relation looks like:

For this example, this is equal to:

If the forward and backward signal delay measurement used in this example was 7 as opposed to 6, then the reverse link rate divider would also be 4.

The reverse link data is selected by the master on the rising edge of the reverse link synchronization signal. There is a counter or similar known circuit or devices present in both the master and the client (display) to generate a reverse link synchronization signal. The counters are initialized so that the first rising edge of the reverse link synchronization signal occurs at the beginning of the first bit in the Reverse Link Packets field of the Reverse Link Encapsulation packet. This is illustrated for the example given below in FIG. 52A. Counters are incremented for each rising edge of the MDDI_Stb signal, and the number of counts that occur until they reset to their initial state is set by the Reverse Rate Divisor parameter (reverse link encapsulation rate divider) in the Reverse Link Encapsulation packet. Since the signal MDDI_Stb is switched at half the forward link transmission rate, the reverse link transmission rate is equal to half the forward link transmission rate divided by the reverse link transmission rate divider. For example, if the forward link bit rate is 200 Mbps and the reverse link bit rate divider is 4, then the reverse link data rate is expressed as:

An example showing the synchronization of MDDI_Data0 and MDDI_Stb signal lines in the Reverse Link Encapsulation Packet is illustrated in FIG. 52, where the packet parameters used for illustration have the meanings:

Package Length = 1024 (0x0400) Field length "Change to the opposite 1" = 1 Package Type = 65 (0x41) Field length "Change to the opposite 2 = 1 Reverse Link Flags = 0 Reverse Link Rate Divider = 2 CRC Parameter = 0xdb43 All zeros are 0x00

Packet data between the Packet Length and CRC Parameter fields:

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

The first reverse link packet returned from the client is the “Client and Status Request” packet, which has Packet Length 7 and Packet Type 70. This packet starts with the values 0 × 00, 0 × 46 ... bytes, etc. However, only the first a byte (0 × 07) is shown in Fig. 52. This first reverse link packet is time shifted by almost one reverse link clock cycle in the drawing to illustrate the actual reverse link delay.Perfect waveform with zero delay in signal transmission time in the forward and reverse directions ezhdu master and the client is shown by the dotted line.

The least significant byte of the CRC Parameter field is transmitted with the preceding packet type, and then the All Zeros field. The strobe from the master device switches from one to zero and back to one when the data level from the master device changes, forming wider pulses. When the data switches to zero, the strobe switches at a higher frequency, only a change in the data on the data line causes a change near the end of the alignment field. The strobe switches at a higher frequency for the remainder of the drawing due to fixed levels of 0 or 1 data signal for extended periods of time and transitions falling on the pulse pattern (edge).

The reverse link clock for the master remains at zero until the end of the “Change to 1” period when the clock starts to accommodate reverse link packets. The arrows at the bottom of the drawing indicate when data is being selected, as will become apparent from the rest of the description. The first byte of the transmitted packet field (here 11000000) is shown starting after the field "Change to the opposite 1", and the signal level in the line is stabilized from the prohibition (blocking) of the master device of the master device. The delay in the passage of the first bit, and as seen for the third bit, can be seen in the dashed lines for the data signal (Data).

In FIG. 53, typical values of the reverse link bit rate divider based on the forward link data rate can be seen. The actual divider of the reverse link transmission rate is determined by measuring the forward and reverse signal transmission for the communication link to ensure correct operation of the reverse link. The first region 5302 corresponds to the safe operation region, the second region 5304 corresponds to the marginal efficiency region, while the third region 5306 indicates settings at which operation is unlikely to be ensured properly.

The measurement of the time delay of the signal transmission in the forward and reverse directions and the settings of the divider of the reverse link transmission rate are the same as when working with any of the "Interface Type" settings either on the forward or reverse link, since they are expressed and used in the number of units of actual synchronization periods, instead of the number of bits transmitted or received.

As a rule, the largest possible divider of the reverse link transmission rate is equal to half the number of bits that can be sent in the measurement window in the packet "Measurement of the delay of signal transmission in the forward and reverse directions" using the Type 1 interface, or for this example:

An improved reverse link data sampling method can also be used as an alternative, which allows the bit return time to be shorter than the signal transmission time in the forward and reverse directions. For this technique, the master device not only measures the signal transmission time in the forward and reverse directions, but can also determine the time shift (phase) of the response from the client relative to the “ideal” client bit boundary and the zero-delay communication line. Knowing the response phase of the client device, the master can determine a relatively safe time to sample the reverse link data bits from the client. The measurement of the time delay of the forward and reverse signal transmission indicates to the master the location of the first bit of the reverse link data relative to the start of the Reverse Data Packets field.

One embodiment of an example of an advanced reverse link data sample is illustrated in graphical form in FIG. 52B. An ideal reverse link data signal with zero forward and reverse signal transmission times is shown as a dashed waveform. The actual travel time of the signal in the forward and reverse directions between 3.5 and 4 clock cycles of MDDI_Stb can be observed as the difference in the delay between the solid line of the waveform and the ideal one. This is the same delay that can be measured using the Measurement of the signal delay in the forward and reverse directions packet, and can be the measured value of the signal transmission time in the forward and reverse directions, equal to 7 transmission times of the forward link bit. In this embodiment, the reverse link data bits are 2 MDDI_Stb pulses of a duration equal to 4 bit times of the forward link, which corresponds to a reverse link bit rate divider of 2. For For advanced reverse link data sampling, it is convenient to use a preselected reverse link bit rate divider of 2 instead of calculating it as described in the present description.This seems to be essentially the best choice for advanced reverse link data sampling, since an ideal sampling point can be easily determined using the usual measurements described above.

The ideal sampling point for reverse link data can be easily calculated by taking the remainder of the total forward and reverse signal transmission times divided by the number of forward link ticks per reverse link bit or the forward and reverse signal delay directions modulo the number of ticks of the forward link per bit of the reverse link. Then either 1 or 2 is subtracted to get a safe point remote from the data transition. In this example, 7 mod 4 = 3, then 3-1 = 2 or 3-2 = 1. The safe sampling point is either 1 or 2 transmission times of the forward link bit from the edge of the “ideal” bit boundary for zero signal transmission time in forward and reverse directions. The drawing shows a sampling point in 2 transmission periods of a straight line bit from an ideal bit boundary, as indicated by a sequence of vertical arrows at the bottom of the timing diagram. The first sampling point is the first ideal bit boundary after the measured signal transmission delay in the forward and reverse directions plus the offset for safe sampling. In this example, the measurement of the signal delay in the forward and reverse directions is 7, so the next ideal bit boundary is the transmission time of the 8th bit, then plus either 1 or 2 for the safe sampling point, so the first bit should be selected either in 9, or 10 forward bit transmission time after the start of the “Reverse Link Data Packets” field

Xi. Reverse and guard time intervals

The field "Change to the opposite 1" in the package "Encapsulation of the reverse line of communication" allows you to simultaneously allow time to prohibit (disable) the master devices of the master device and enable the master devices of the client. and in the opposite direction "allows overlapping of the master device and the client, so the driver of the client can be enabled before the driver of the interface master is disabled. Field" Changing to the opposite 2 "in the package" Encapsulation of the reverse line of communication "allows you to completely transfer the data in the previous field from the client before the master devices of the master device are allowed. The "Protective time interval 2" field provides a time value or period that allows the client and master devices to be excited simultaneously to a logic zero level. The fields "Protective time interval 1" and "Protective time interval 2" are usually filled with pre-set or pre-selected values for durations of periods of time that are not supposed to be adjusted. Depending on the interface hardware used, these values can be developed using empirical data and tuned in some cases to improve performance.

"Change to the opposite 1"

Several factors contribute to determining the length of the Turn-Around 1 field (Change to the opposite 1), and these are the forward link data rate, the maximum inhibit time of the MDDI_Data master devices in the master device, and the resolution time of the client master device, which is usually the same. as the time of prohibition of the master device. The length of the field "Change to the opposite 1" is selected equal to 24 * t _BIT (Table XIII). The length in the number of bytes of the forward link (PLC) of the Turn-Around 1 field is determined using the "Interface Type" factor and calculated using the ratio:

where the Interface Type Factor is 1 for Type 1, 2 for Type 2, 4 for Type 3, and 8 for Type 4.

"Reverse 2"

Factors that determine the length of time typically used for “Change to the opposite 2” are the delay in transmitting the signal in the forward and reverse directions of the communication line, the maximum inhibit time of the master devices MDDI_Data in the client, and the resolution time of the master device in the master, which is set as the same as the barring time of the client master. The maximum resolution time of the driver in the master device and the time that the driver of the driver is disabled are determined elsewhere in the description. The time delay of signal transmission in the forward and reverse directions is measured in units of t _BIT . The minimum length specified in the number of bytes of the forward link of the field "Change to the opposite 2" is calculated according to the ratio:

For example, a Type 3 straight link with a forward and reverse signal transmission delay of 10 clock cycles of the forward link usually uses the “Change to the opposite 2” delay:

XII. Alternative reverse link timing relationships

While the use of synchronization and guard intervals described above is intended to provide an interface with a high data rate, applicants have found a method for accounting for reverse link bit lengths that are shorter than the forward and backward signal travel times by changing reverse link clock detection.

As described above, the previous approach to the allocation of time intervals of the reverse link is such that the number of clock cycles is calculated from the last bit of the "Protective time interval 1" of the reverse link clock packet, until the first bit is selected on the rising edge of the clock signal input / output. He (they) is (are) the clock signal (s) for the point in time of input and output for MDDI. The calculation of the reverse link bit rate divider is then given by:

Это обеспечивает ширину в битах, равную задержке прохождения сигнала в прямом и обратном направлениях, которая приводит к очень надежной обратной линии связи. Однако обратная линия связи показана как способная запускаться быстрее или с более высокой скоростью передачи данных, преимуществом чего изобретатели и захотели воспользоваться. Новая предлагаемая методика позволяет использовать дополнительные возможности интерфейса, чтобы достигнуть более высоких скоростей.

This provides a width in bits equal to the delay of the signal in the forward and reverse directions, which leads to a very reliable reverse link. However, the reverse link is shown as being able to start faster or with a higher data transfer rate, an advantage which the inventors wanted to take advantage of. The new proposed technique allows you to use additional features of the interface to achieve higher speeds.

This is done if there is a master device that counts the number of clock cycles until a unit is selected, but the master device selects the data line along the rising and falling edges during the reverse link clock packet. This allows the master to select the most useful or even optimal sampling point within the reverse link bit to ensure that the bit is stable. That is, in order to find the most useful or optimal rising edge in order to sample data during reverse link encapsulation packets of the reverse traffic. The optimal sampling point depends on both the reverse link divider and whether the first unit was detected on a rising edge or falling edge. The new clocking method allows the master to only search for the first edge of the 0 × FF 0 × FF 0 × 00 pattern sent by the client to clock the reverse link to determine where to sample in the “Reverse Link Encapsulation” packet.

Examples of an upcoming reverse link bit and how this bit will search for various dividers of the reverse link bit rate are illustrated in FIG. 64, along with a series of clock cycles that have occurred from the last bit of the “Guard Time Interval 1”. In Fig. 64, it can be seen that if the first edge occurs between a rising edge and a falling edge (marked as rising / falling), the optimum sampling point for the reverse link transmission rate divider equal to one, the optimal sampling point is the edge of the clock cycle labeled 'b' as it is the only rising edge that occurs within the reverse link bit period. For a reverse link rate divisor of two, the optimal sampling point is probably still the leading edge of the clock cycle 'b', since the edge 'c' of the clock is closer to the bit boundary than 'b'. For a divider of the reverse link transmission rate of four, the optimal sampling point is probably the edge 'd' of the clock cycle, since it is closer to the trailing edge of the reverse link bit, where the value was probably stabilized.

Returning Fig. 64, if, however, the first edge occurs between the falling and rising edges (marked as falling / rising), the optimal sampling point for the reverse link transmission rate divider equal to one is the sampling period sampling front 'a', since there is a single rising edge within the transmission period of the reverse link bit. For a divider of the reverse link transmission rate of two, the optimal sampling point is the edge 'b', and for a divisor of the reverse link transmission rate of four, the optimal sampling point is the edge 'c'.

It can be seen that when the dividers of the reverse link transmission rate become larger and larger, it becomes easier to establish or select the optimal sampling point, since this should be a rising edge, which is closest to the middle.

The master can use this technique to find the number of rising edges of the clock before the rising edge of the packet data of the synchronization data is observed on the data line. Then it can be decided on the basis of whether there is a front between a rising and falling edge or between a falling and rising edge and what is the divider of the reverse link transmission rate, how many additional clock cycles need to be added to the quantity counter to reasonably ensure that this bit is always gets as close to the middle as possible.

Once the master has selected or determined the number of clock cycles, it can “examine” the various reverse link rate dividers with the client to determine if a particular reverse link rate divider will work well. The master (and the client) can start with a divisor of one and check the CRC of the reverse link status packet received from the client to determine if these reverse link bit rates are operating properly for data transmission. If the CRC gives an error, there is probably a quantization (sampling) error and the master can increase the reverse link rate divider and try to re-request the status packet. If the second requested packet was damaged, the divider can be increased again and the request is made again. If this packet is decoded correctly, this reverse link rate divider can be used for all future reverse link packets.

This method is effective and useful, since the reverse link clocking should not change from the initial estimate of the clocking of the signal flow in the forward and reverse directions. If the forward link is stable, the client must continue to decode the forward link packets, even if there are reverse link failures. Of course, it is still the responsibility of the master to install a reverse link divider for the communication link, since this method does not guarantee a good return link. In addition, the divider will depend primarily on the quality of synchronization, which is used to generate the I / O clock. If this clock has a significant amount of jitter, there is a high probability of a quantization error. This probability of error increases with the number of clock cycles in the delay of the signal in the forward and reverse directions.

This implementation seems to work best for Type 1 reverse link data, but it can be a problem for Type 2 - Type 4 reverse link data due to a time shift between the data lines, possibly being too large to start the line communication with the transmission rate that works best for just one pair of data. However, the data transfer rate probably should not be reduced to the previous method even for Types 2 - Type 4 during operation. This method may also work best if duplicated on each data line to select the ideal or optimal location of the synchronization sample. If they occur at the same sampling time for each data pair, this method may continue to work. If they occur at different sampling periods, two different approaches can be used. The first is to select the desired or more optimized sample location for each data point, even if it is not the same for each data pair. The master can then restore the data stream after sampling all the bits from the set of data pairs: two bits for Type 2, four bits for Type 3 and eight bits for Type 4. Another possibility is to increase the reverse bit rate divider for the master communication lines, so that the data bits for each data pair can be selected on the same clock edge.

Xiii. Line delay and time shift effects

The delay shift on the forward link between the MDDI_Data and MDDI_Stb pairs may limit the maximum possible data rate if delay time offset compensation is not used. Differences in delay that cause a timing shift due to controller logic, line drivers and receivers, and cables and connectors are described below.

A. Timeline Analysis of a Communication Line Limited by Timeshift (MDDI Type -1)

1. Example of delay and time shift of a Type 1 communication link

A typical interface diagram, similar to that shown in Fig. 41, is illustrated in Fig. 57 for a communication line of a Type 1 interface. In Fig. 57, exemplary or typical values for propagation delay and time shift are shown for each of several processing or interaction steps for a direct interface MDDI Type 1 communication lines. A shift in the delay between MDDI_Stb and MDDI_Data0 causes a distortion in the duty cycle of the output clock signal, as shown in FIG. 58. In some cases, this makes the setup time for the RXFF stage very short. The data at the input of the D-trigger of the trigger stage (RXFF) of the receiver using the triggers 5728, 5732 changes slightly after the clock edge so that they can be reliably selected. This drawing shows two cascaded delay lines 5732a and 5732b used to solve two different problems with creating this time relationship. In actual implementation, they can be combined into a single delay element.

A timing diagram of data, Stb, and synchronization recovery on a Type 1 communication link for exemplary signal processing through an interface are illustrated in FIG. 58.

A complete shift in time delay, which is significant, usually arises or comes from the sum of the shift in time in the following stages: trigger (TXFF) of the transmitter with triggers 5704, 5706; master device (TXDRVR) of the transmitter with master devices 5708, 5710; cable 5702; receiver (RXRCVR) lines in the receiver with receivers 5722, 5724; and an EXCLUSIVE OR (RXXOR) receiver logic. Delay 1 5732a must match or exceed the delay of the logic gate EXCLUSIVE OR 5736 in the RXXOR cascade, which is determined by the ratio:

t _{PD-min (Delay 1)} ≥ t _{PD-max (XOR)}

It is desirable to fulfill this requirement, so that the input signal of the D-flip-flop 5728, 5732 of the receiver does not change until the synchronization input signal is supplied to it. This is done if the interim storage time of RXFF is zero.

The task or function of Delay 2 is to compensate for the intermediate storage time of the RXFF trigger according to the ratio:

t _{PD-min (Delay 2)} = t _{H (RXFF)}

In many systems, this time will be zero, since the intermediate storage time is zero and, of course, in this case the maximum delay “Delay 2” can also be zero.

The worst case of a contribution to the time shift in the XOR cascade of the receiver occurs in case of data latency / early arrival of the gate, where Delay 1 is the maximum value and the synchronization output signal from the XOR logic gate arrives as early as possible, according to the relation:

t _{SKEW-max (RXXOR)} = t _{PD-max (Delay 1)} - t _{PD-min (XOR)}

In this situation, data can change between two bit periods n and n + 1 very close to the point in time when bit n + 1 is synchronized in the trigger of the receiver.

The maximum data rate (minimum bit period) of the MDDI Type 1 communication line is a function of the maximum time shift that occurs in all master devices, cable and receivers in the MDDI communication line, plus the complete installation of data in the RXFF cascade. The total delay shift in the communication line up to the output of the RXRCVR cascade can be expressed as:

t _{SKEW-max (LINK)} = t _{SKEW-max (TXFF)} + t _{SKEW-max (TXDRVR)} + t _{SKEW-max (cable)} + t _{SKEW-max (RXRCVR)}

where the "cable" represents a plurality of conductors, or interconnects, or wires and the corresponding delay, and the minimum bit period is specified as:

t _BIT-min = t _{SKEW-max (COMMUNICATION LINE)} + 2 * t _B-TP4 + t _Asymmetry + t _{SKEW-max (RXXOR)} + t _{jitter-lead device} + t _{PD-max (Delay 2)} + t _{SU (RXFF)}

In the example illustrated in FIG. 57 for external mode, t _{SKEW-max (COMMUNICATION LINE)} = 1000 ps and the minimum bit period can be expressed as:

t _BIT-min = 1000 + 2 * 125 + 625 + 125 + 200 + 0 + 100 = 2300 ps

or approximately 434 Mbps. In the example shown in FIG. 57 for the internal mode, t _{SKEW-max (COMMUNICATION LINE)} = 500 ps and the minimum bit period can be expressed as:

t _BIT-min = 500 + 2 * 125 + 625 + 125 + 200 + 0 + 100 = 1800 ps

or approximately 555 Mbps.

If the master uses the Delay Time Shift Calibration package, then there are additional requirements for delay asymmetry, delay time shift and jitter of the synchronization signal in the master, which are determined by the requirement for maximum delay asymmetry and jitter of the synchronization signal for the master with asymmetry calibration :

t _{Asymmerty-TXFF} + t _{Asymmetry-TXDRVR} + t _{jitter-lead device} ≤ 1000 ps, and

requirement for maximum delay time shift for a master with a time shift calibration:

t _Skew-TXFF + t _Skew-TXDRVR ≤ 1000 ps

B. Link Timeline Analysis for MDDI Type 2, 3, and 4

A typical interface diagram, similar to that shown in Figs. 41 and 57, is illustrated in Fig. 59 for communication lines of Type 2, 3, and 4 interfaces. Additional elements are used in the TXFF (5904), TXDRVR (5908), RXRCVCR (5922), and RXFF cascades (5932, 5928, 5930) to perform additional signal processing. In Fig. 59, exemplary or typical values for propagation delay and time shift are shown for each of several processing or processing steps through the MDDI Type 2 forward link interface. In addition to the delay shift between MDDI_Stb and MDDI_Data0 affecting the duty cycle of the synchronization output signal There is also a shift between both of these two signals and the other MDDI_Data signals. The data at the D-input of stage B (RXFFB) of the receiver, consisting of triggers 5928 and 5930, changes immediately after the clock edge, so that they can be reliably selected. If MDDI_Data1 arrives earlier than MDDI_Stb or MDDI_Data0, then MDDI_Data1 must be delayed so that they can be selected by at least the amount of time delay offset.

To do this, the data is delayed using the delay line Delay 3. If MDDI_Data1 arrives later than MDDI_Stb and MDDI_Data0, and they are also delayed by Delay 3, then the point where MDDI_Data1 is changing moves closer to the next edge of the clock. This process determines the upper limit of the data rate of the MDDI Type 2, 3, or 4 communication link. Some exemplary different possibilities for the time relationship or time offset of two data signals and MDDI_Stb relative to each other are illustrated in FIGS. 60A, 60B and 60C.

To reliably sample data in RXFFB, when MDDI_DataX arrives as early as possible, Delay 3 is set according to the relation:

t _{PD-min (Delay 3)} ≥ t _{SKEW-max (COMMUNICATION LINE)} + t _{H (RXFFB)} + t _{PD-max (XOR)}

The maximum link speed is determined by the minimum allowable bit period. It is most affected when MDDI_DataX arrives as late as possible. In this case, the minimum allowed tact (cycle) time is defined by the relation:

t _BIT-min = t _{SKEW-max (COMMUNICATION LINE)} + t _{PD-max (Delay 3)} + t _{SU (RXFFB)} + t _{PD-min (XOR)}

The upper limit of the speed of the communication line is then equal to:

t _{PD-max (Delay 3)} = t _{PD-min (Delay 3)}

and, given this assumption, receive:

t _{BIT-min (lower limit)} = 2 * t _{SKEW-max (COMMUNICATION LINE)} + t _{PD-max (XOR)} + t _{SU (RXFFB)} + t _{H (RXFFB)}

In the example given above, the lower boundary of the minimum bit period is defined by the relation:

t _{BIT-min (lower limit)} = 2 * (1000 + 2 * 125 + 625 + 200) + 1500 + 100 + 0 = 5750 ps,

which is approximately 174 Mbps.

This is much slower than the maximum data rate that can be used with a Type 1 communication line. The ability to automatically compensate for a time shift for an MDDI delay significantly reduces the effect that this time delay shift has on the maximum link speed factor is times "on the front" of installing reliable data. The calibrated shift between MDDI_Data0 and MDDI_Stb is:

t _{SKEW-max (calibrated)} = 2 * t _{TAP-SPACING-max} ,

and the minimum bit period is:

t _{BIT-min-Calibrated} = t _{SKEW-max (Calibrated)} + 2 _{* t B-TP4 + t Asymmetry} + t _{jitter-host apparatus} + t _{SKEW-max (RXAND + RXXOR) + t SU} (RXFF)

where "TB" or t _B represents the jitter (shift) of the signal from the bit boundary to the minimum output level. Asymmetry simply refers to the asymmetric nature of the internal delay through or the differential receivers themselves. "TP4" is associated with or effectively defined for electrical characteristics and testing purposes as a connection or interface (pins) of an MDDI controller device in the client) for differential drivers and line receivers for the client. This represents a convenient or predetermined point from which the signal delay is measured and characterized for the communication link in the rest of the system. In one embodiment, the maximum value of the parameter t _B in TP4 is determined by the relation t _{Differential-Skew-TP4-DRVR-EXT} = 0.3 * t _BIT for external mode and t _{Differential-Skew-TP4-DRVR-INT} = 0.6 * t _BIT for internal mode for client transmitters; and t _{B-TP4-RCVR-EXT} = 0.051 * t _BIT + 175 ps for external mode for client receivers.

The TP4 tag is simply useful in numbering various control points (TP) in the interface and communication lines. In one embodiment, this control point location is determined to be the same for both internal and external modes. There is a corresponding “TP0” reference point for, or associated with, the terminals (pins) of the connection or interface of the MDDI controller device in the master device, which contains differential drivers and communication line receivers. In this embodiment, the maximum value of the parameter T _B in TP0 is determined by the relation t _{B-TP0-RCVR-INT} = 0.051 * t _BIT +50 ps for internal mode, and t _{B-TP0-RCVR-EXT} = 0.051 * t _BIT + 175 ps for external mode for master receivers; and t _B-TP0 = 0.102 * t _BIT for the transmitters of the host device.

In the example shown in FIG. 59, t _{SKEW-max (Data0-Stb-Calibrated)} = 300 ps and the minimum bit period is:

t _{BIT-min-Calibrated} = 300 + 2 * 125 + 625 + 200 + 175 + 100 = 1650 ps,

which is approximately 606 Mbps.

In order to reliably sample data in RXFFB, when MDDI_Data1 arrives as early as possible, the associated programmable delay is tuned to optimal parameters with an accuracy of one element, and an additional delay of one element is added for security. The maximum speed of the communication line is determined by the minimum resolvable bit period. It is most affected when MDDI_Data1 arrives as late as possible. In this case, the minimum allowable cycle time (cycle) is:

t _{BIT-min-Data1-Calibrated} = 2 * t _{TAP-Spacing-max} + 2 * t _TA-TP4 ,

where "TA" or t _A represents signal jitter from the bit boundary to the midline.

In the example of FIG. 59, the lower bound of the minimum bit period based on the MDDI_Data1 sample is:

t _{BIT-min-Data1-Calibrated} = 2 * 150 + 2 * 125 = 550 ps.

In one embodiment, a typical total delay time for a shift in delay time, delay asymmetry and jitter of the synchronization signal in the master mode transmitter for the internal mode can be defined as:

t _{Asymmerty-TXFF} + t _{Asymmetry-TXDRVR} + t _Skew-TXFF + t _Skew-TXDRVR +

+ t _{jitter-master} = 0.467 * (t _BIT - 150 ps),

and for external mode like:

t _{Asymmerty-TXFF} + t _{Asymmetry-TXDRVR} + t _Skew-TXFF + t _Skew-TXDRVR +

+ t _{jitter-master} = 0, TBD * (t _BIT -150TBD ps),

while the typical total delay time for a shift in the delay time, the asymmetry of the delay and the setup time in the client device (t _B-TP4 ) for the internal mode is:

t _{Asymmerty-RXRCVR} + t _{Asymmetry-RXXOR} + t _Skew-RXRCVR + t _Skew-RXXOR + t _setup-RXFF = 0.307 * (t _BIT -150 ps),

and for external mode:

t _{Asymmerty-RXRCVR} + t _{Asymmetry-RXXOR} + t _Skew-RXRCVR + t _Skew-RXXOR + t _setup-RXFF - 0, TBD * (t _BIT -TBD ps),

where the term TBD is a “flexible” label to place space for future defined values, which should depend on many well-understood characteristics and operational requirements for external connections.

A typical interface diagram for an embodiment for a MDDI Type 2 forward link, similar to that of FIG. 59, with a delay time shift compensation circuit is illustrated in FIG. Additional elements are used after the RXRCVCR stage, namely selectable delay elements 6102 and 6104 along with calibration input drivers 6106 and 6108, which are connected to AND gates 6112 and 6114, respectively, whose outputs are in turn connected to the XOR logic gate (EXCLUSIVE OR) 6116. The XOR 616 logic gate then provides the input for the RXFFA stage, as shown. These elements are used to carry out additional signal processing. The drivers 6108 and 6106 take into account the calibration for the signal paths, while the delay elements 6102 and 6104 take into account the selectable delay values that must be entered or used for the signal paths for the output signals of the drivers 5724 and 5924, respectively.

In this example, delay variables 6102 and 6104 are used to adjust the relative arrival times of strobe signals and data. Alignment of the time of arrival of these signals allows you to set in advance the data at the input of D-flip-flops (5728, 5730, 5928, 5930) in the receiver. When the client device receives the Calibration Data Sequence field of the forward link time offset calibration packet, a simple state machine can check simultaneous transitions on all differential pair signals to determine the optimal adjustable delay settings. The state machine can use an algorithm sequential approximation to correct variable delays to find the point at which data can be safely selected, and then adjust Calculation Data Sequence contains a large number of simultaneous transitions on all differential pairs, in order to guarantee reliable operation (it can be one element less on the MDDI_Stb path and one element more on the MDDI_Data path). operation.

In the example of FIG. 61, the lower bound of the minimum bit period based on the MDDI_Data1 sample is:

_{t BIT-min-Data1-Calibrated} = 2 * 150 + 2 * 125 = 550 ps

This is a significant improvement over clocked non-calibrated communication lines for MDDI_Data1. However, one potential determining factor for the maximum data rate for a link with a calibrated time delay delay will usually be limited by the ability to match the delay between MDDI_Stb and MDDI_Data0, as can be seen in the above example. There are many possible improvements to the delay compensation architecture described above, such as providing fine tuning for Delay 5 in FIG.

When delay time offset compensation is used, there is usually an upper limit to the amount of differential time offset that is allowed or allowed at the output of the master device of the master. This is defined above for both internal and external modes. Without this limitation, there may exist an extremely large range for the magnitude of the differential time shift, which requires correction in the client device for leading devices that operate at very low data rates. Since the primary use of time shift compensation is to reduce the delay shift to allow devices to operate at higher speeds, the maximum delay time shift limit is usually determined by the system or device designers for master devices that use delay time shift compensation. The total amount of time shift compensation that is used in the client device is the sum of the following three parameters. The maximum differential time shift at the output of the master device of the master device, which is the maximum delay time shift for the TXFF + TXDRVR stages in Fig. 61; the maximum differential time shift in the interconnect subsystem from TP0 (control point 0) to TP4 (control point 4), which is the maximum delay time shift in the cable stage stage in FIG. 61; and the maximum differential time shift in the client between the inputs of the differential receiver and the data sampling circuit. This last parameter is the maximum delay time shift from the inputs of the RXRCVR stages to the inputs of the RXFFA and RXFFB stages in Fig. 61.

Xiv. Description of the physical layer interconnects

The physical connections used to implement the interface of the present invention can be implemented using commercially available components, such as component number 3260-8S2 (01), which is manufactured by Hirose Electric Company Ltd., on the master side, and component number 3240-8P -C, which is manufactured by Hirose Electric Company Ltd., is on the client device side. Exemplary interface pin assignments or pinouts for these connectors used with Type-1 / Type-2 interfaces are listed in Table XV.

Table XV Signal Name Pin number Signal Name Pin number MDDI_Pwr one MDDI_Gnd eleven MDDI_Stb + 2 MDDI_Stb- 12 MDDI_Data0 + four MDDI_Data0- fourteen MDDI_Data1 + 6 MDDI_Data1- 16 MDDI_Data2 + 8 MDDI_Data2- eighteen MDDI_Data3 + 10 MDDI_Data3- twenty MDDI_Data4 + 9 MDDI_Data4- 19 MDDI_Data5 + 7 MDDI_Data5- 17 MDDI_Data6 + 5 MDDI_Data6- fifteen MDDI_Data7 + 3 MDDI_Data7- 13 Screen

The screen is connected to HOST_Gnd in the host interface, and the screen drain wire in the cable is connected to the connector screen in the client. However, the shield and drain wire are not connected to the circuit ground inside the client.

Interconnect elements or devices are selected or designed to be small enough for use with mobile communications or computing devices such as PDAs and cordless phones or handheld gaming devices so that they are not intrusive or unaesthetic compared to the relative size of the device. Any connectors and cable connections should be long enough to be used in a typical consumer environment and take into account the small size, especially for cable connection, and have a relatively low cost. Transmission elements must provide data and strobe signals, which are NRZ differential data (without returning to zero) having a transmission rate of up to approximately 450 Mbps for Type 1 and Type 2 and up to 3.6 Gbps for version 8- bit parallel Type 4.

For internal-mode applications, either there are no connectors in the same sense as for the conductors used, or such connectors tend to be very miniaturized. One example is the “connectors” with zero insertion power for receiving integrated circuits or elements hosting either the client device or the host device. Another example is when the host device and the client are constantly on network circuit boards with different connection conductors and have pins or contacts protruding from the enclosures that are soldered to the contacts on the conductors for interconnecting integrated circuits.

меньшей или равной длине

Другой клиент (или клиенты в некоторых случаях) тогда расположены или подсоединены "в конце" ответвления от кабеля, которое расположено между концом и ведущим устройством, что указано здесь на Фиг.99 как "Местоположение В". Фиг.99 также показывает в общем виде, как такие оконечные нагрузки линии передачи определяются для использования в вариантах осуществления специалистами в данной области техники. Те, кто использует устройство или способы различных вариантов осуществления изобретения, должны реализовать такие конфигурации посредством ограничения длины оконечных нагрузок в линии передачи, чтобы в общем случае гарантировать, что качество сигнала удовлетворяет любым ограничениям или требованиям, чтобы поддерживать соответствующую высокоскоростную операцию и свободную от ошибок (или с минимальным их количеством) линию связи при рассмотрении минимального времени нарастания выходного сигнала задающего устройства и скоростного фактора линий передачи.When looking at the connection of two clients, for example, for the previously described internal mode, attention should be paid to the cabling, connections and some factors in the placement of the primary client for more suitable data transfer and exchange. Connections or cables connecting clients form transmission lines that are substantially terminal free, as illustrated in the configuration illustrated in FIG. In Fig. 99, a master device 9902 is shown connected through a conductor 9904, which branches into two terminal loads, here terminal terminal 1 and terminal terminal 2, which supply or transmit signals from the terminal device to clients at locations A and B, respectively. Again, solely for the purpose of illustration, and not as a limitation of any embodiments or applications of the invention, clients are shown here as being part connected to, associated with or otherwise exchanged with LCD controllers or LCD display elements or panels. When these two client devices are connected in internal mode, the primary client device, which receives and transmits signals to MDDI_Data pairs and is located together with load resistors (impedances), must be located or connected "at the end" of the cable, which is indicated here on Fig as a "Location A" and with a length

less than or equal to length

The other client (or clients in some cases) is then located or connected "at the end" of the cable branch, which is located between the end and the master device, which is indicated here in Fig.99 as "Location B". 99 also shows in a general way how such transmission line terminations are determined for use in embodiments by those skilled in the art. Those using the device or methods of various embodiments of the invention should implement such configurations by limiting the length of the terminal loads on the transmission line in order to generally ensure that the signal quality satisfies any restrictions or requirements in order to maintain an appropriate high-speed operation and free from errors ( or with a minimum number of them) a communication line when considering the minimum rise time of the output signal of the driver and the speed Ktorov transmission lines.

Xv. Work

The essence of the general steps taken in processing data and packets during operation of the interface using the embodiments of the present invention is illustrated in Figs. 54A and 54B, together with a brief overview of the hardware of the packet processing interface according to Fig. 55. In these drawings, the process begins at step 5402 with the determination of whether the client and the master are connected using the communication path, here is the cable. This can be accomplished by performing a periodic polling by the master using software or hardware that detects the presence of connectors or cables or signals at the inputs on the master (as is seen for USB interfaces), or other known methods. If there is no client connected to the master, then it can simply enter a standby state of some predetermined duration, depending on the application, enter an idle state (hibernation), or be deactivated in anticipation of future use, which may require the client took measures for the reactivation of the master device. For example, when the master device is constantly located on a device such as a computer, the user may have to click on the on-screen icon or request a program a frame that activates the processing in the master to search for a client Again, simple insertion into USB connections can activate the processing of the master depending on the capabilities and configuration of the master or the resident software of the master.

As soon as the client is connected to the master device or vice versa, or is detected as present, or the client or master device sends the appropriate packets requiring service, at steps 5404 and 5406. The client can send either a “Client Service Request” packet or a Status packet in step 5404. It should be noted that the operation of the communication line, as described above, may be pre-completed or it may be in idle mode, so this may not be a complete initialization of the communication line, which follows behind it. Once the communication link is synchronized and the master is trying to communicate with the client, the client also provides the Client Capabilities packet to the master, as in step 5408. The master can now begin to determine the type of support, including the transfer rates, that the client can provide.

Typically, the host device and the client also agree on the type (frequency / speed) of the service mode to use, for example Type 1, Type 2, etc., at step 5410. Once the service type is set, the host device can begin to transmit information. In addition, the host device may use the forward and reverse delay measurement packets to optimize the synchronization of the communication link in parallel with other signal processing, as shown in step 5411.

As described above, all transmissions begin with the Sub-frame Header packet shown as being transmitted at step 5412, followed by the data type, here are the video and audio stream packets and placeholder packets shown as being transmitted at step 5414. Audio and the video data must be pre-prepared or converted into packets, and placeholder packets are inserted where necessary, or it is desirable to fill in the required number of bits for media frames. The host device may send packets, such as a forward link audio channel resolution packet, to activate audio devices. In addition, the master can transmit commands and information using the other packet types described above, here shown as transmitting Color Map, Block Bitmap, or others, at step 5416. In addition, the host and client can exchange data related to the keyboard or pointing devices using appropriate packages.

During operation, one of several different events may occur that will cause the host device or client to require a different data rate or type of interface mode. For example, a computer or other device that is exchanging data may encounter load conditions when processing data, which causes a slow decline in the preparation or presentation of packages. The client device receiving the data could change the specialized AC power source to a more limited battery power source and either not be able to switch so quickly to data, processing instructions with ease, or not be able to use the same degree of resolution or color depth with more limited settings regarding power. Alternatively, the limiting condition may be reduced or disappeared, allowing any device to transmit data at higher speeds. If this is more desirable, a request may be made for a change to a higher bit rate mode.

If these or other types of known conditions occur or change, the master or client may detect them and try to reconcile the interface mode. This is shown in step 5420, where the master sends the “Request Handoff to Specific Type” packets to the client requesting the handoff to another mode, the client sends “Interface Type Confirmation” packets, confirming that the change is being sought, and the master sends “ Performing a handover to a certain type of mode ”to perform a change to the specified mode.

Although not requiring a specific processing order, the client and the host can also exchange packets related to data destined for or received from pointing devices, keyboards, or other user-type data input devices associated primarily with the client, although such elements may also be present on the master side. These packets are typically processed using an element such as a general-purpose processor, rather than a state machine (5502). In addition, some of the instructions described above will also be processed by a general-purpose processor (5504, 5508).

After the exchange of data and commands between the host device and the client, at some point in time, a decision is made as to whether additional data should be transmitted or the host device or the client is going to stop serving the transmission. This is shown at step 5422. If the communication line should either enter an idle state or its operation must be completely completed, the master sends the “Complete communication line” packet to the client and both sides complete the data transfer.

Packets transmitted by the above processing operations will be transmitted using the master devices and receivers described above with respect to the client controllers and the master. These line drivers and other logic elements are connected to the state machine and general purpose processors described above, as illustrated in a brief overview with reference to FIG. 55. In Fig. 55, the state machine 5502 and general-purpose processors 5504 and 5508 can be further connected to other elements not shown, for example, a specialized USB interface, memory elements, or other components permanently outside the communication line controller with which they interact, including , but not limited to, a data source and video control chip for view display devices.

These processors and the state machine provide control of the permission and prohibition of the master devices, as described above with respect to guard time intervals, etc., in order to guarantee the effective establishment or interruption of the communication line and packet transmission.

Xvi. Display Frame Buffers

Video buffering requirements are excellent for moving video images compared to computer graphics. “Pixel data” is most often stored in the local frame buffer in the client, so that the image on the client can be regenerated locally.

When a full-blown video is displayed (almost every pixel in the display changes in each media frame), it is usually preferable to store the incoming pixel data in one frame buffer, while the image on the display is regenerated from the second frame buffer. More than two display buffers can be used to eliminate visible artifacts, as described below. When a full image has been received in one frame buffer, then the roles of the buffers may change, and then the recently received image is used to regenerate (update) the display, and another buffer is filled with the next image frame. This concept is illustrated in FIG. 88A, where pixel data is written to a standalone image buffer by setting the “Display Update” bits to “01”.

In other applications, the master should only modify a small portion of the image without the need to redraw the entire image. In this situation, it is desirable to write new pixels directly to the buffer used to update the display, as illustrated in detail in FIG.

In applications that have a fixed image with a small video window, the simplest thing is to write this fixed image to both buffers (display update bits are “11”), as shown in FIG. 88C, and subsequently write the pixels of the moving image to a stand-alone buffer by setting display update bits equal to "01".

The following rules describe the useful manipulation of buffer pointers, while at the same time writing new information to the client and regenerating (updating) the display. There are three buffer pointers: current_fill indicates the buffer currently populated with MDDI data. Just_filled points to the buffer that was filled with the most recent (most recent). Being_displayed points to the buffer currently used to regenerate the display. All three buffer pointers can contain values from 0 to N-1, where N is the number of display buffers and N ≥ 2. Arithmetic over buffer pointers is the operation of taking the module "mod N", i.e. when N = 3 and current_fill = 2, increasing current_fill sets current_fill to 0. In the simple case, when N = 2, just_filled is always a complement to current_fill. At each border of the MDDI Media Frame (“Sub-frame Header” package with Sub-frame Count field (“number of sub-frames”) equal to zero), the following operations are performed in the indicated order: just_filled is set to current_fill and current_fill is set to current_fill + 1.

The MDDI Video Stream packets update the buffers according to the following structure or methodology: when the Display Update bits are '01', the pixel data is written to the buffer indicated by current_fill; when the "Display Update" bits are '00', the pixel data is written to the buffer specified by just_filled; and when the “Display Update” bits are “11”, the pixel data is written to all buffers. The display is regenerated from the buffer indicated by the being_displayed pointer. After the display has regenerated the last pixel in one frame refresh period and before it starts to regenerate the first pixel in the next frame regeneration period, the display refresh process performs the operation of setting the being_displayed value to just_filled.

Packets with the Pixel Data Attribute field contain a pair of Display Update bits that specify the frame buffer where the pixel data should be written. The Client Features package has three additional bits that indicate which combination of Display Update bits are supported in the client. In many cases, computer-generated images must be incrementally updated based on user input or output (received) from information received from the computer network. The combinations “00” and “11” of the “Display update” bits support this mode of operation, resulting in pixel data being written to the displayed frame buffer or to both frame buffers.

When placing video images, FIG. 89 illustrates how video images are displayed using a pair of frame buffers when video data is transmitted over the MDDI link with Display Update bits equal to “01”. After the boundary of the media frame is detected on the MDDI link, the display regeneration process will begin the regeneration from the next frame buffer when the regeneration process for the frame currently being regenerated is completed.

An important assumption regarding FIG. 89 is that the image is received from the host device as a continuous stream of pixels that are transmitted in the same order that the client uses to read the pixels from the frame buffer to regenerate the display (usually top left , reading line by line, in the lower right corner of the screen). This is an important detail in cases where the "Display Regeneration" and "Image Transfer" operations refer to the same frame buffer.

It is necessary that the display regeneration frame rate be greater than the image transmission frame rate to avoid displaying partial images. FIG. 90 shows how image fragmentation can occur at a slow display regeneration rate, that is, display regeneration is slower than image transmission.

In an image that contains a combination of computer graphics and moving video images, the pixel video data may occupy a small portion of the media frame. This can be significant in situations where the operation of the regeneration of the display and image transfer refer to the same frame buffer. These situations are indicated by shaded shading in FIG. 91, where the pixels read from the display regeneration buffer may be pixels written back to the buffer two frames, or they may correspond to a frame immediately written to the same frame buffer.

Using three frame buffers in the client will solve the problem of a small window when competing for access to the frame buffer, as shown in Fig. 92.

However, there still remains a problem if the display refresh rate is less than the transmission rate of the media frames over the MDDI link, as shown in FIG.

Using a single buffer for moving video is somewhat problematic, as shown in FIG. When the display is regenerated faster than transferring the image to the buffer, the updated image will sometimes show the upper part of the recorded frame, and the lower part of the image will be the frame transmitted earlier. When display regeneration is faster than image transmission (preferred mode of operation), more frequent cases of frames showing a similar image splitting will occur.

Xvii. Multiple customer support

The current version of the protocol is shown as not directly supporting many client devices. However, most packages contain a reserved Client Identifier field, which can be used to address specific client devices in a system with multiple clients. For many applications, this Client ID or these Client IDs is currently set to zero. The Sub-Frame Header package also contains a field to indicate whether the host device supports a system with multiple clients. Therefore, there is a way in which multiple client devices can probably be connected and addressed in future applications of the MDDI or protocol to help system designers plan future compatibility with many client host devices and clients.

In systems having multiple clients, it is convenient for clients to be connected to the host device using a serial connection of clients, or using hubs, as shown in Fig. 95, or using a combination of these methods, as shown in Fig. 96. It may also be useful for the master to display some error messages in order to manage connected clients, for example, error messages when one or more clients requiring address 0 are connected, which should not be the case for systems with multiple clients when such displays are waiting that will be installed or already installed to work as a sole client.

Xiii. application

In addition to the formats, structures, and contents described above for the various packages used to implement the architecture and protocol for embodiments of the invention, more detailed field contents or operations are provided below for some types of packages. They are presented here to further clarify their respective uses or operations, to enable those skilled in the art to more easily understand and use the invention for a variety of applications. Only a few of the fields not yet described are described below. In addition, these fields are presented with exemplary definitions and values with respect to the embodiments presented above. However, such values should not be construed as limitations of the invention, but should represent one or more embodiments used to implement the interface and protocol, and not all embodiments should be implemented together or simultaneously. In other embodiments, other values may be used to achieve the desired presentation of the data or data transfer rate results, as should be understood by those skilled in the art.

A. For Video Stream packages

In one embodiment, the Pixel Data Attributes field, here 2 bytes, has a sequence of bit values that are interpreted as follows. Bits 1 and 0 select how display pixel data is routed. For bit values' 11 ', pixel data is displayed to or for both eyes, for bit values' 10', pixel data is sent only to the left eye, and for bit values' 01 ', pixel data is sent only to the right eye, and for bit values' 00 'the pixel data is sent to an alternative display, as may be set by bits 8-11, described below. If the primary display, either in use or manipulated by the client, does not support stereo or some form of display, then these commands cannot be effectively implemented to have the impact as required by the display. In this situation or configuration, the client must send the pixel data to the primary display regardless of the bit values or for any of the combinations of bits '01', '10' or '11', since the resulting commands or control cannot be performed by the display. It is recommended, but not required, in the embodiments that the value '11' is used to address the primary display for those clients that do not support stereo imaging.

Bit 2 indicates whether the pixel data is interlaced with a value of '0', meaning that the pixel data is in the standard progressive scan format and that the line number (Y coordinate of the pixels) increases by 1 when moving from one line to the next. When this bit is set to '1', the pixel data is in interlaced format, and the line number increases by 2 when moving from one line to the next. Bit 3 indicates that the pixel data is in alternating (optional) pixel format. This is similar to the standard interlaced mode enabled by bit 2, but the interlace is vertical instead of horizontal. When bit 3 is '0', the pixel data is in a standard progressive format, and the column number (X coordinate of the pixels) is incremented by 1 when each subsequent pixel is received. When bit 3 is '1', the pixel data is in an additional pixel format, and the column number is incremented by 2 when each pixel is received.

Bit 4 indicates whether the pixel data refers to a display or camera, as when data is being transmitted to or from an internal display for a cordless telephone or similar device or even a laptop computer, or to other devices as described above, or data is being transmitted to or from a camera ( s) built-in or directly connected to the device. When bit 4 is '0', pixel data is transmitted to or from the display frame buffer. When bit 4 is '1', pixel data is transmitted to or from camera (s) or some type of video device, such devices are known in the art.

Bit 5 is used to indicate when the pixel data contains the next consecutive row of pixels in the display. Here, the case where bit 5 is set to '1' is considered. When bit 5 is set to '1', then the parameters X of the Left border, Y of the Upper border, X of the Right border, Y of the lower border, X Starts and Y Starts are not defined and are ignored by the client. When bit 15 is set equal to the level of a logical unit, this indicates that the pixel data in this packet is the last row of pixels in this image. Bit 8 of the Client Feature Capability Indicators field in the Client Features package indicates whether this feature is supported.

Bits 7 and 6 are “Display Update” bits that specify the image buffer where pixel data should be written. More specific actions are described elsewhere in the description. For bit values of '01', pixel data is written to the offline image buffer. For bit values of '00', pixel data is written to the image buffer used to regenerate the display. For bit values of '11', pixel data is written to all image buffers. Bit values or a combination of '10' are treated as an invalid value or designation, and pixel data is ignored and not written to any of the image buffers. This value may be used for future interface applications.

Bits 8-11 are used to determine an alternate display or display location where pixel data should be directed. Bits 0 and 1 are set to '00' so that the display client interprets bits 8-11 as an alternate display number. If bits 0 and 1 are not equal to '00', then bits 8-11 are set equal to the logic zero level.

Bits 13 and 12 are used to determine whether the pixels of the destination should be recorded at the locations of the destination when they refer to a transparent color and a transparent mask. For bits [13:12] that have a value or equal to 00 (two levels of logical zero), transparent color is not used. The resulting destination pixel is recorded at the location of the destination pixel without considering a transparent color value or a transparent mask. Transparent color is determined by the Transparent Color Resolution package described elsewhere. The value 01 (logical zero levels, logical unit) for bits [13:12] represents or is a reserved value that is currently set aside for future use and is not commonly used. When bits [13:12] are set to 10 (logical unit, logical zero), the resulting destination pixel is written to the location of the destination pixel, unless the result of the logical AND operation on the source image pixel and transparent mask is equal to the transparent color, then the resulting pixel Do not write to the destination pixel location. When bits [13:12] have a value of 11 (two logical units), the resulting destination pixel is not written to the location of the destination pixel, unless the result of the logical AND operation on the source image pixel and transparent mask is equal to the transparent color, in this case the resulting pixel recorded at the location of the destination pixel.

Bit 14 is reserved for future use and is usually set to a logic zero level. Bit 15, as described, is used with bit 5, and setting bit 15 to a logical unit indicates that the pixel row in the Pixel Data field is the last pixel row in the data frame. The next Video Stream packet, having bit 5 set to a logical unit, will correspond to the first pixel row of the next video frame.

The 2-byte fields “X Beginnings” and “Y Beginnings” define the absolute coordinates of the X and Y points (X Beginnings, Y Beginnings) for the first pixel in the “Pixel data” field. The 2-byte fields “X Left border”, “Y of the Top border” define the X coordinate of the left border and the Y coordinate of the upper border of the screen window filled with the “Pixel data” field, while the fields “X of the Right border” and “Y of the lower border "determine the X coordinate of the right border and the Y coordinate of the lower border of the updated window.

The Pixel Count field (2 bytes) sets the number of pixels in the Pixel Data field below.

The CRC Parameter field (2 bytes) contains the CRC of all bytes from "Packet Length" to "Number of Pixels". If this CRC fails to validate, then the entire packet is discarded.

The Pixel Data field contains raw video information that must be displayed and formatted in the manner described by the Video Data Format Descriptor field. Data is transmitted one “row” at a time, as described herein. When bit 5 of the Pixel Data Attributes field is set to a logical unit level, then the Pixel Data field contains exactly one row of pixels, with the first transmitted pixel corresponding to the leftmost pixel and the last transmitted pixel corresponding to the most right pixel.

The “Pixel data CRC” field (2 bytes) contains a 16-bit CRC of pixel data only. If checking the CRC code for these values gives an error, then the pixel data can still be used, but the count value of the erroneous CRC codes increases.

B. For Audio Stream Packages

In one embodiment, the Audio Channel ID field (1 byte) uses an 8-bit unsigned integer value to identify the particular audio channel to which audio data is sent by the client device. Physical audio channels are specified in or mapped to physical channels using this field as values 0, 1, 2, 3, 4, 5, 6, or 7, which indicate left front, right front, left rear, right rear, front center, sub- woofer, left surround sound and right surround sound channels respectively. The Audio Channel Identifier value 254 indicates that a single stream of digital audio sampled samples has been sent to both the left front and right front channels. This simplifies exchanges for applications such as where the stereo headphone is used for voice communication, the application of the performance extension used on PDAs, or other applications where a simple user interface generates alerts. Values for the identifier field, ranging from 8 to 253 and 255, are currently reserved for use where new design solutions require additional designations, as suggested by those skilled in the art.

The Reserved 1 field (1 byte) is usually reserved for future use and has all the bits in this field set to zero. One of the functions of this field is to force all subsequent 2-byte fields to be aligned to the 16-bit address of the word and to force 4-byte fields to be aligned to the 32-bit address of the word.

The Audio Sample Count field (2 bytes) determines the number of audio samples in this packet.

Field "Bits for sampling and packaging" contain 1 byte, which determines the format of the packaging of audio data. In one embodiment, the format commonly used is for 4-0 bits, which should determine the number of bits per PCM audio sample. Bit 5 then sets whether or not Digital Audio Data samples are packed. As mentioned above, FIG. 12 illustrates the difference between packed and byte aligned audio samples. A value of '0' for bit 5 indicates that each PCM audio sample in the Digital Audio Data field is aligned byte with the interface byte border, and a value of '1' indicates that each subsequent PCM audio sample is packed next to the previous audio sample . This bit is valid only when the value specified in bits 4-0 (the number of bits per PCM sample of audio) is not a multiple of eight. Bits 7-6 are reserved for use where system designs require additional notation, and are usually set to zero.

The Audio Sample Rate (Audio Byte Frequency) field (1 byte) sets the PCM frequency of the audio sample. This format used is set to 0 to indicate a frequency of 8000 samples per second (w / s, w / s), a value of 1 indicates 16000 w / s, a value of 2 for 24000 w / s, a value of 3 for 32000 w / s, a value of 4 is for 40,000 bps, a value of 5 is for 48,000 bps, a value of 6 is for 11025 bps, a value of 7 is for 22050 bps and a value of 8 is for 44100 bps, respectively, with values from 9 to 255 reserved for future use, so that they are currently set to zero.

The CRC Parameter field (2 bytes) contains the 16-bit CRC of all bytes from "Packet Length" to "Audio Sampling Frequency". If this CRC gives an error with the appropriate check, then the entire packet is rejected. The Digital Audio Data field contains raw audio samples to be played back and usually take the form of a linear format as unsigned integers. The Audio Data CRC field (2 bytes) contains the 16-bit CRC of audio data only. If this CRC gives a verification error, then audio data can still be used, but the count of erroneous CRC codes is increased.

C. For User Defined Stream Packages

In one embodiment, a 2-byte Stream ID Number field is used to identify a particular user-defined stream. The contents of the Stream Parameters and Stream Data fields are typically specified by the MDDI equipment manufacturer. The 2-byte field "Stream parameter CRC" contains the 16-bit CRC of all stream parameter bytes, from "Packet length" to the "Audio encoding" byte. If this CRC gives an error during verification, then the entire packet is rejected. Both the Stream Parameters and CRC Stream Parameter fields can be rejected if they are not necessary for the final MDDI application, that is, they are considered optional. The 2-byte field "stream data CRC" contains only the stream data CRC. If this CRC gives an error when checking accordingly, then the use of stream data is optional, depending on the requirements of the application. Using a stream of data in relation to a CRC that is good usually requires stream data to be buffered until the CRC is confirmed as good. The CRC erroneous code count value increases if the CRC generates an error.

D. For Color Card packages

The 2-byte hClient ID field contains information or values that are reserved for the client ID, as used above. Since this field is usually reserved for future use, the current value is set to zero by setting the bits to '0'.

The 2-byte Color Map Item Count field uses values to specify the total number of 3-byte color map items that are contained in the Color Map Data field or color map table entries that exist in Map Data colors "in this package. In this embodiment, the number of bytes in the “Color Map Data” is 3 times the “Number of Elements of the Color Map” value. The "Number of color map elements" value is set to zero so as not to send color map data. If the "Color Map Size" is zero, then the Color Map Offset value is usually still sent, but it is ignored by the display. The Color Map Offset field (4 bytes) defines the offset of the Color Map Data in this packet from the beginning of the color map table in the client device.

The 2-byte CRC Parameter field contains the CRC of all bytes from Packet Length to Audio Encoding byte. If this CRC gives an error during verification, then the entire packet is rejected.

For the Color Map Data field, the width of each location of the color map is indicated by the Color Map Item Size field, where in one embodiment, the first part determines the value of blue, the second part determines the value of green and the third part determines the value of red. The Color Map Size field defines the number of 3-byte elements of the color map table that exist in the Color Map Data field. If one color map cannot be entered into one packet "Video data format and color maps", then a full color map can be determined by sending many packets with different "Color map data" and "Color map offset" in each packet. The number of bits of blue, green, and red in each color map data element is usually the same as defined in the "RGB Color Map Width" field in the "Display Capabilities" packet.

The 2-byte “Color Map Data CRC” field contains the CRC of only “Color Map Data”. If this CRC gives an error while checking, then the "Color Card Data" can still be used, but the value of counting the erroneous CRC codes increases.

Each color map data element must be transmitted in the order: blue, green, red, and the least significant bit of each component is transmitted first. The individual red, green, and blue components of each color map element are packaged, but each color map element (the least significant bit of the blue component) must be aligned on the byte boundary. 97 illustrates an example of color map data elements with 6 bits of blue, 8 bits of green, and 7 bits of red. For this example, the "Color map element size" in the "Color map" package is 21 and the "RGB color map width" field in the "Client Features" package is 0x0786.

E. For Reverse Link Encapsulation Packets

The CRC Parameter field (2 bytes) contains the 16-bit CRC of all bytes from Packet Length to Reverse Length. If this CRC gives an error during verification, then the entire packet is rejected.

In one embodiment, the Reverse Link Flags (1 byte) field contains a set of flags to request information from the client and determine the type of reverse link. If a bit (for example, bit 0) is set equal to the level of a logical unit, then the master device requests the specified information from the client, but if the bit is set equal to the level of logical zero, then the master device does not need information from the client. Bit 0 is used to indicate when the master device requires the Client Capabilities packet, which is typically sent by the client to the master in the Reverse Data Packets field. Bit 1 is used to indicate when the master device requires the packet. “Client and Status Request”, which is sent by the client to the master in the Reverse Data Packets field. The remaining bits (here bits 2-7) are reserved for future use and are set to zero. However, more bits may be used as necessary to set flags for the reverse link.

The Reverse Rate Divisor field (1 byte) defines the number of MDDI_Stb clock cycles that occur with respect to the clock signal of the reverse link data. The reverse link data synchronization frequency is equal to the forward link data synchronization frequency divided by twice the reverse link rate Divider. The reverse link data rate refers to the synchronization frequency of the reverse link data and the type of interface on the reverse link. In this embodiment, for a Type 1 interface, the reverse link data rate is equal to the reverse link clock cycle; for Type 2, Type 3 and Type 4 interfaces, the reverse link data rates are doubled, quadrupled, and eight times the reverse link data signal communication accordingly.

The "All Zeros 1" field contains a group of bytes, here 8, whose value is set to zero by setting the bits to logical zero, and is used to ensure that all MDDI_Data signals have a logic zero level for enough time to allow the client to start restoring synchronization using MDDI_Stb only, until the master line switches off during the Turn-Around 1 field. In one embodiment, the “All Zeros 1” field is greater than or equal to the number of byte transmission times in a straight line th link at a delay in signal transmission time in forward and reverse directions along the cable.

Field "Length Change to the opposite 1" (1 byte) sets the total number of bytes that are allocated for the field Turn-Around 1 ("Length Change to the opposite 1"), setting the first period of change to the opposite. The Turn-Around 1 field uses the number of bytes specified by the Change Length 1 parameter that are assigned to enable the MDDI_Data line drivers in the client to be allowed before the line drivers in the master are disabled. The client resolves its MDDI_Data line drivers for bit 0 of the Turn-Around 1 field, and the master disables its output signals so that it is completely disabled until the last bit of the Turn-Around 1 field. The MDDI_Stb signal behaves as if MDDI_Data0 had a level logical zero during the entire Turn-Around 1 period. A more complete description of the procedure for setting the Turn-Around 1 field is given above.

The Reverse Data Packets field contains a sequence of data packets transmitted from the client to the master. The client can send placeholder packets or drive MDDI_Data lines to a state or logic zero when it has no data to send to the master. In this embodiment, if the MDDI_Data lines are energized to zero, the master interprets this as a packet with zero length (invalid length) and the master does not receive any additional packets from the client for the duration of the current reverse link encapsulation packet.

Field "Turn-Around 2 Length" (1 byte) defines the total number of bytes that are allocated for Turn-Around 2, to establish the second period of the Change to the opposite. The recommended Turn-Around 2 length is equal to the number of bytes required to delay the signal forward and backward plus the time it takes the master to enable its MDDI_Data masters. “Length Reversal 2” may also be a value greater than the minimum required or calculated value to provide sufficient time to process reverse link packets in the master.

Field Turn-Around 2 (Change to the opposite 2) consists of the number of bytes, which is specified by the parameter "Length Change to opposite 2". The master waits for at least the forward and reverse delay time before it resolves its MDDI_Data line drivers during Turn-Around 2. The master resolves its MDDI_Data line drivers so that they are usually fully resolved to the last bit Turn-Around 2, and the client forbids its outputs so that they are usually completely prohibited until the last Turn-Around 2 bit. The purpose of the Turn-Around 2 field is to allow the transfer or transfer of the remaining amount of data in the Reverse Data field Packets from the customer. With changes in various systems that implement the interface and in the value of the distributed safety factor, it is possible that neither the master nor the client will generate MDDI_Data signals to a logic zero level during some parts of the Turn-Around 2 field period, as can be seen by line receivers in or on the master. The MDDI_Stb signal behaves as if MDDI_Data0 was equal to a logic zero level during essentially the entire Turn-Around 2 period. The Turn-Around 2 setup is described above.

The Reverse Data Packets field contains a sequence of data packets transmitted from the client to the master. As indicated above, placeholder packets are sent to fill in the remaining space that is not used by other types of packages.

The All Zeros 2 field contains a group of bytes (8 in this embodiment) whose values are set to zero by setting the bits to logical zero and is used to ensure that all MDDI_Data signals are logic zero for sufficient time, in order to allow the client to start restoring synchronization using both MDDI_Data0 and MDDI_Stb after enabling the master devices on the master line after the Turn-Around 2 field.

F. For Customer Features Packages

As illustrated for one embodiment, the Protocol Version field uses 2 bytes to specify the protocol version used by the client. The initial version is currently set to one and will change over time as new versions are created, as you may know, while the Minimum Protocol Version field uses 2 bytes to set the minimum protocol version, which the client can use or interpret. In this case, a null value is also a valid value. The Pre-Calibration Data Rate Capability field (2 bytes) sets the maximum data transfer rate with which the client can receive on each data pair on the forward link before calibrating the time shift of the forward link, and set in the form of millions of bits per second (Mbps). If the client supports the Straight Line Time Shift Calibration packet, then the value in the Post-Calibration Data Rate Capability field indicates the data rate that the client is able to provide after performing the time shift calibration.

In one embodiment, the Interface Type Capability field (1 byte) specifies the interface types that are supported on the forward and reverse links. A bit set to '1' indicates that the specified interface type is supported, and a bit set to '0' indicates that the specified type is not supported. Host devices and clients must support at least Type 1 on the forward and reverse links. There is no requirement to support a continuous range of interface types. For example, it may be perfectly valid to support only Type 1 and Type 3, but not Type 3 and Type 4 in an interface. It is also not necessary for the forward and reverse links to work with the same type of interface. However, when the communication link goes out of sleep, both the forward and reverse links should start in Type 1 mode until other modes can be negotiated, selected, or otherwise approved for use by both the master and the client.

Supported interfaces are indicated in one embodiment by selecting bit 0, bit 1, or bit 2 to select a mode or Type 2 (2 bits), Type 3 (4 bits), or Type 4 (8 bits) on the forward link, respectively; and bit 3, bit 4 or bit 5 to select a mode or Type 2, Type 3 or Type 4 on the reverse link, respectively; with bits 6 and 7 reserved and usually set to zero at this time.

In one embodiment, the Number Alt Displays field in the Client Capabilities packet uses 1 byte, the value of which can vary from 0 to 16, with values from 17 to 255 that are usually reserved for future use and not used to indicate or report that more than one display is connected, and the Alternate Display Features package reports the capabilities of each additional display. The Number Alt Displays field uses 1 byte to indicate the identification information of the alternate display, with the first alternate display usually indicated as 0 and the other alternate displays identified by the unique values of the Alt Display Number field, where the highest value used is the total number of alternate displays minus 1 (starting from the value 0).

The Post-Calibration Data Rate Capability field uses 2 bytes in one embodiment to specify the maximum data rate at which the client can receive on each data pair on the MDDI forward link after performing a shift calibration in forward link time. This bit rate is also defined in millions of bits per second (Mbps). If the client device does not support the Straight Line Time Shift Calibration packet, then this field is set to zero.

The Bitmap Width and Height fields, each with 2 bytes, define the width and height of the bitmap, in pixels, respectively. The Display Window Width field uses 2 bytes, which define the width of the window on the display screen, expressed as the number of pixels.

The Display Window Height field uses 2 bytes, which specify the height of the window on the display screen, expressed as the number of pixels.

The Color Map Size field uses 4 bytes to specify the maximum number of table elements that exist in the color map table in the client. If the client cannot use the color map format, then this value is set to zero.

The Color Map RGB Width field uses 2 bytes, which specify the number of bits of the red, green, and blue components that can be displayed in the Color Map (palette) display mode. A maximum of 8 bits for each color component (red, green, and blue) can be used. Even though 8 bits of the component of each color are sent in the Color Map packet, only the least significant bits of the component of each color specified in this field are used. If the display client cannot use the color map format (palette), then this value is zero.

The RGB Capability field (2 bytes) defines the number of resolution bits that can be displayed in RGB format. If the display cannot use the RGB format, then this value is zero. The word RGB Capability consists of three separate unsigned values, where: bits 3-0 specify the maximum number of bits of blue, bits 7-4 determine the maximum number of bits of green and bits 11-8 determine the maximum number of bits of red in each pixel. Bits 14-12 are currently reserved for future use and are usually set to zero. Bits 14-12 are reserved for future use and are usually set to zero. Bit 15, when set equal to the level of a logical unit, indicates that the client can receive RGB pixel data in either packed or unpacked format. If bit 15 is set to a logic level of zero, this indicates that the client can only accept RGB pixel data in an unpacked format.

The Monochrome Capability field (1 byte) is used in one embodiment to determine the number of resolution bits that can be displayed in a single-color (monochrome) format. If the display cannot use monochrome, then this value is set to zero. Bits 7-4 are reserved for future use and are thus set to zero. Bits 3-0 determine the maximum number of halftone bits that may exist for each pixel. These four bits make it possible to set values from 1 to 15 for each pixel. If this value is zero, then the monochrome format is not supported by the display.

The Y Cr Cb Capability field (2 bytes) defines the number of resolution bits that can be displayed in the Y Cr Cb format. If the display cannot use the YCr Cb format, then this value is set to zero. The word Y Cr Cb Capability consists of three separate unsigned values, where: bits 3-0 determine the maximum number of bits in the Cb sample, bits 7-4 determine the maximum number of bits in the Cr sample, bits 11-8 determine the maximum number of bits in the Y sample , and bits 15-12 are currently reserved for future use and set to zero.

The Bayer Capability field uses 1 byte to determine the number of resolution bits, groups of pixels, and the order of pixels that can be transmitted in Bayer format. If the client cannot use the Bayer format, then this value is zero. The “Bayer Format Opportunity” field consists of the following values: bits 3-0 determine the maximum number of intensity (brightness) bits that exist in each pixel, while bits 5-4 determine the pixel group pattern that is required, while bits 8-6 specify the ordering of pixels that is required; moreover, bits 14-9 are reserved for future use and are usually set to zero at present. Bit 15, when set equal to the level of a logical unit, indicates that the client can receive Bayer pixel data in either packed or unpacked format. If bit 15 is set to zero, this indicates that the client can only accept Bayer pixel data in an unpacked format.

In one embodiment, the Client Feature Capability field uses 4 bytes in one embodiment, which contain a set of flags that indicate specific features in the client that are supported. A bit set equal to the level of a logical unit indicates that this feature is supported, while a bit set to a level of logical zero indicates that this feature is not supported. In one embodiment, the value for bit 0 indicates whether the Block Block Forwarding packet is supported (packet type 71). The value for bits 1, 2, and 3 indicates whether the Fill Bitmap Area Fill packet (packet type 72), the Fill Bitmap Template packet (packet type 73), or the Read Frame Buffer packet (packet type 74) are supported, respectively . The value for bit 4 indicates whether the client is able to support the “Set transparent color and mask” package, while the values for bits 5 and 6 indicate whether the client can receive audio in unpacked or packed format, respectively, and the value for bit 7 indicates whether the client can send a reverse link video stream from the camera. The value for bit 8 indicates whether the client has the ability to receive a full line of pixel data and ignore the display addressing, which is determined by bit 5 of the Pixel Data Attributes field in the Video Stream packet, and the client can also detect frame synchronization or end video frame data using bit 15 of the "Pixel data attributes" field.

The value of bit 9 indicates whether the client has the ability to interpret the packet “Request a specific state” and respond with a packet “List of response about the actual state”. The client can indicate the ability to return an additional status in the field "List of the response about the valid parameters" in the package "List of the response about the actual state", as described above. The value of bit 10 indicates whether the client has the ability to maintain state 1 of the power consumption of the display. The display power consumption state is set using bits [3: 2] of the Power State field of the Display Power Consumption Status packet described above. The display power consumption state 1 is a state where the selected display is not highlighted and consumes the minimum amount of power, if any, and it is usually guaranteed that the contents of the frame buffer will be maintained during this state.

The value for bits 11 and 12 indicates when the client is communicating with either the pointing device and can send and receive the "Data of the pointing device" packets, or with the keyboard and can send and receive the "Keyboard data" packets, respectively. The value for bit 13 indicates whether the client has the ability to set one or more audio or video parameters while supporting packets with VCP characteristics: packet "Request VCP characteristics, packet" Response with VCP characteristics, packet "Setting VCP characteristics", packet "Request valid parameters "And the package" Answer about the actual parameters. "The value for bit 14 indicates whether the client has the ability to write pixel data in a standalone display frame buffer, which is illustrated in Fig. 88A. If this bit is set to nical unit, then bits "display update" (bits 7 and 6 of the field in the Pixel Data Attributes package "video stream") may be set equal to the value '01'.

The value for bit 15 indicates when the client has the ability to write pixel data only to the display frame buffer currently used to update the displayed image, as illustrated in FIG. If this bit is set to a logical unit, then the Display Update bits (bits 7 and 6 from the Pixel Data Attributes field in the Video Stream packet) can be set to '00'. The value for bit 16 indicates when the client has the ability to write pixel data from a single Video Stream packet to all display frame buffers, as illustrated in FIG. If this bit is set equal to the level of a logical unit, then the display update bits (bits 7 and 6 from the Pixel data attributes field in the Video Stream packet) can be set to the value '11'.

In one embodiment, the value for bit 17 indicates when the client has the ability to respond to the “Request a specific state” packet, the value for bit 18 indicates when the client has the ability to respond to the “Measure forward and reverse delay” packet, and the value for bit 19 indicates when the client has the ability to respond to the packet “Calibration of the forward link time offset.” In one embodiment, the value for bit 20 indicates when the client has the ability to respond to the packet "Status of power consumption by the display."

In one embodiment, the value for bit 21 indicates when the client has the ability to use the Raster Operation field of the “Fill Bitmap Area” packet (packet type 72), the Fill Bitmap Template packet (packet type 73), or the packet “ Read Frame Buffer "(packet type 74), if these packets are supported by the client, as specified by bits 0, 1, and 2 or this field. In one embodiment, if bit 21 has a logic level or value of zero and packets are supported, then the client does not have the ability to use the Raster Operation field and the client only has the ability to copy or write to the pixel locations indicated by these packets.

The value for bit 22 indicates whether the client has the ability to respond to the Register Access packet. Bits 23-31 are currently reserved for future use or alternative designations used by system designers, and are usually set to zero or logical zero.

The Minimum Sub-frame Rate field (2 bytes) defines the minimum sub-frame rate in frames per second. The minimum frequency of sub-frames saves the period of updating the state of the client, sufficient for reading some sensors or pointing devices in the client.

The Audio Buffer Depth field (2 bytes) defines the depth of the adaptive buffer in the display that is allocated to each audio stream.

The Audio Channel Capability field, in this embodiment using 2 bytes, contains a group of flags that indicate which audio channels are supported by the client or device connected to the client. A bit set to one indicates that the channel is supported, and a bit set to zero indicates that the channel is not supported. Bit positions are assigned to different channels, for example, bit positions 0, 1, 2, 3, 4, 5, 6, and 7 in one embodiment indicate left front, right front, left rear, right rear, front center, sub-woofer, left surround sound and right surround sound channels respectively. Bits 8-14 are currently reserved for future use and are usually set to zero. In one embodiment, bit 15 is used to indicate whether the client provides support for the “Direct Channel Audio Channel Resolution” packet. In this case, bit 15 is set to a logical unit level. If, however, the client is not capable of disabling audio channels as a result of the “ "Direct link audio channel resolution" or if the client does not support audio capability, then this bit is set to the level or value of logical zero.

The 2-byte Audio Sample Rate Capability field for the forward link contains a set of flags to indicate the ability of the client device with respect to the audio sampling rate. Bit positions are assigned to different speeds, respectively, for example, bits 0, 1, 2, 3, 4, 5, 6, 7 and 8 are assigned to frequencies of 8000, 16000, 24000, 32000, 40000, 48000, 11025, 22050 and 44100 samples per second ( w / s), respectively, with bits 9-15 reserved for future or alternative frequency applications, as required, so that they are currently set to '0'. Setting a bit value for one of these bits to '1' indicates that this particular sampling rate is supported, and setting a bit to '0' indicates that this particular sampling frequency is not supported.

The 2-byte Audio Sample Resolution field for the forward link determines the number of bits per sample of audio that are sent to the client in the Audio Stream packet.

The 2-byte Mic Audio Sample Resolution field for the reverse link sets the number of bits to the audio samples sent to the master device by the microphone in the Audio Stream packet.

The 2-byte Mic Sample Rate Capability field for the reverse link contains a set of flags that indicate the capability related to the sampling frequency of the audio microphone in the client device. For MDDI purposes, the microphone of the client device is configured to at least support at least 8000 samples per second. The bit positions for this field are assigned to different frequencies with bit positions 0, 1, 2, 3, 4, 5, 6, 7 and 8, for example, used to represent 8000, 16000, 24000, 32000, 40000, 48000, 11025, 22050 and 44100 samples per second (w / s), respectively, with bits 9-15 reserved for future or alternative frequency applications, as required, so that they are currently set to '0'. Setting a bit value for one of these bits to '1' indicates that this particular sampling rate is supported, and setting a bit to '0' indicates that this particular sampling frequency is not supported. If no microphone is connected, then each of the Mic Sample Rate Capability bits is set to zero.

The Keyboard Data Format field (1 byte here) determines whether the keyboard is connected to the client system and the type of keyboard that is connected. In one embodiment, the value set by bits 6-0 is used to determine the type of keyboard that is connected. If the value is zero (0), then the keyboard type is considered unknown. For a value of 1, the keyboard data format is considered a standard PS-2 type. Values in the range of 2 to 125 are not currently used, being reserved for use by system designers and interface developers or product developers, to identify a specific keyboard or input device for use with MDDI and associated clients or host devices. A value of 126 is used to indicate that the keyboard data format is user-defined, while a value of 127 is used to indicate that the keyboard cannot be connected to this client. In addition, bit 7 can be used to indicate whether the keyboard can communicate with the client. The intended use of this bit is to indicate when the keyboard can communicate with the client using a wireless line. Bit 7 can be set to zero if bits 6-0 indicate that the keyboard cannot be connected to the client. Therefore, for one embodiment, when the value of bit 7 is 0, the keyboard and client cannot exchange, while if the value of bit 7 is 1, the keyboard and client confirm that they can communicate with each other.

The Pointing Device Data Format field (here 1 byte) determines whether the pointing device is connected to the client system and the type of pointing device that is connected. In one embodiment, the value set by bits 6-0 is used to determine the type of pointing device that is connected. If this value is zero (0), then the type of pointing device is considered unknown. For value 1, the data format of the pointing device is considered to be the standard type of PS-2. Values in the range of 2 to 125 are not currently used, being reserved for use by system designers and interface developers or product developers, to identify a specific pointing device or data input device for use with MDDI and associated clients or master devices. A value of 126 is used to indicate that the data format of the pointing device is determined by the client, while a value of 127 is used to indicate that the pointing device cannot be connected to this client. In addition, bit 7 may be used to indicate whether the indicating device can communicate with the client. The intended use of this bit should indicate when the keyboard can communicate with the client using a wireless line. Bit 7 can be set to zero if bits 6-0 indicate that the pointing device cannot be connected to the client. Therefore, for one embodiment, when the value of bit 7 is 0, the pointing device and the client cannot exchange, while if the value of bit 7 is 1, the pointing device and the client confirm that they can communicate with each other.

The Content Protection Type field (2 bytes) contains a set of flags that indicate the type of digital content protection that the display supports. Currently, bit position 0 is used to indicate when DTCP is supported, and bit position 1 is used to indicate when HDCP is supported, while bit positions 2-15 are reserved for use with other protection schemes, as required or available, so that they currently set to zero.

The Mfr Name field (here 2 bytes) contains the 3-character EISA identifier of the manufacturer, packaged in three 5-bit characters in the same way as in the VESA EDID specification. The letter 'A' is represented as 00001 in binary form, the letter 'Z' is represented as 11010 in binary form, and all letters between 'A' and 'Z' are represented as consecutive binary values that correspond to the alphabetical sequence between 'A' and 'Z '. The most significant bit of the Mfr Name field is unused and is usually set to a logical zero at present, until it is used in future implementations. For example, the manufacturer represented by the string "XYZ" will have a Mfr Name value of 0x633a. If this field is not supported by the client, it is usually set to zero. The Product Code field uses 2 bytes containing the product code assigned by the display manufacturer. If this field is not supported by the client, it is usually set to zero.

The fields Reserved 1, Reserved 2 and Reserved 3 (here 2 bytes each) are reserved for future use in transmitting information. All bits in this field are currently set to logic zero. The purpose of such fields at present is to align all subsequent 2-byte fields to the 16-bit address of the word and align 4-byte fields to the 32-bit address of the word.

The Serial Number field uses 4 bytes in this embodiment to specify the serial number of the display in numerical form. If this field is not supported by the client, it is usually set to zero. The Week Manufacture field uses 1 byte to determine the week of manufacture of the display. This value usually ranges from 1 to 53, if supported by the client. If this field is not supported by the client, it is set to zero. Field Year Manufacture (year of manufacture) has 1 byte, which determines the year of manufacture of the display. This value is equal to the offset from 1990. Years in the range from 1991 to 2245 can be expressed by this field. Example: Year 2003 corresponds to the value 13 of the Year Manufacture field. If this field is not supported by the client, it is set to zero.

The CRC field (2 bytes here) contains the 16-bit CRC of all bytes in the packet, including the "Packet Length" field.

G. For packages "Client request and status"

The Reverse Link Request field (3 bytes) sets the number of bytes that the client needs on the reverse link in the next sub-frame in order to send information to the master.

The CRC Error Count field (1 byte) indicates how many erroneous CRC code values have occurred since the beginning of the media frame. The CRC code value is discarded when the Sub-frame Header packet is sent with a sub-frame value of zero. If the actual number of CRC code errors exceeds 255, then these values are usually saturated with a value of 255.

The Capability Change field uses 1 byte to indicate a change in client capabilities. This can happen if the client connects a peripheral device, such as a microphone, keyboard or display, or for some other reason. When bits [7: 0] are 0, then the opportunity has not changed since the last “Client Features” packet was sent. However, when bits [7: 0] are from 1 to 255, the possibility has changed. The Client Features package is tested to discover new display features.

The Client Busy Flags field uses 2 bytes to indicate that the client is performing a specific function and is not ready to accept another packet related to this function. A bit set equal to the level or value of a logical unit indicates that a particular function is currently being executed by the client and that the corresponding function in the client is busy. If the corresponding function in the client is ready, the bit is set to logical zero. The client must return a busy state (multiple bits equal to one) for all functions that are not supported in the client.

In one embodiment, these bytes are interpreted according to the following relationships. If bit 0 is '1', then the block transfer function of the bitmap is busy, while if bit 1 is '1', then the fill function of the bitmap area is busy, and if bit 2 is '1', then the bit pattern fill function The cards are busy. At the same time, if bit 3 is '1', then the graphics subsystem is busy performing an operation that requires the use of a frame buffer in the client. Other graphic functions that require the use of a frame buffer cannot begin until this bit is set to a logical unit.

Bits 4–15 currently remain reserved for future use and are usually set to a logical unit or state level to indicate a busy state if these bits are assigned in the future.

H. For “Bitmap Block Transfer” packages

The Window Upper Left Coordinate X Value and Y Value fields (the X value and the Y value of the upper left coordinate of the window) use 2 bytes each to specify the X and Y coordinates of the upper left corner of the window to be moved. The Window Width and Height fields use 2 bytes each to determine the width and height of the window that should be moved. The Window X Movement and Y Movement fields use 2 bytes each to specify the number of pixels by which the window should be moved horizontally and vertically, respectively. Typically, these coordinates are configured so that positive values for X cause the window to move to the right and negative values for Y cause the window to move to the left, while positive values for Y cause the window to move down and negative values cause the window to move up.

I. For packages "Filling the area of the bitmap"

In one embodiment, the 2-byte Pixel Data Attributes field has values that determine where the pixel data should be updated, with bits 1 and 0 select a display where the pixel data should be updated. If the primary display in the client does not support stereo images, then the client can affect the pixel data in the primary display for one of the bit combinations 01, 10, or 11. It is recommended that a value of 11 be used to address the primary display in clients that do not support the stereo display capability. When bits [1: 0] have values 11 (logical unit, logical unit), pixel data is updated in the frame buffer of both the left and right eyes, if bits [1: 0] have values 10 (logical unit, logical zero), pixel data is only updated in the left eye frame buffer. When bits [1: 0] are set to 01 (logical zero, logical unit), the pixel data is updated only in the frame buffer of the right eye. When bits [1: 0] are set to 00 (logical double zero), the pixel data is updated in the frame buffer of the alternate display indicated by bits 8-11 below.

In one embodiment, bit 4 of the Pixel Data Attributes field determines whether the buffer for the left eye or the right eye is the image source for this operation. Bit 4 applies only when bits [1: 0] are not 00, which are typically implemented to mean that the data source from the main frame buffer is not supported when the destination of the image is one of the alternative displays. Bit 4 is used to distinguish or assign frame buffers between the left and right eyes as a data source. The use of bit 4 is also limited when the client supports raster operations with respect to the indicated displays, as indicated by bit 21 of the Client Feature Capability Indicators field in the Client Features packet or bit 21 of the Display Feature Capability Indicators field in the Alternative Display Features packet. During use, if bit 4 is 0 (logical zero level), then the left eye frame buffer is the data source, but when bit 2 is 1 (logical unit level), then the right eye frame buffer is the data source.

Bit 5 of the Pixel Data Attributes field determines whether the buffer is used to regenerate the display, or whether the stand-alone image buffer is going to be the input for the raster operation as the destination image for this operation. Bit 5 can also be applied to an alternate display if the alternate display uses a standalone image buffer. However, the data source from the main image buffer is not supported when the image destination is an alternate display, or vice versa. In use, if bit 5 is 0 or a logic zero, the image buffer used to regenerate the display is the data source. When bit 5 is a value of 1 or a logic unit level, the offline image buffer is the data source.

Bits 7 and 6 of the Pixel Data Attributes field act as the Display Update bits, which specify the frame buffer where the pixel data should be updated or written. The effect of the "Frame Update" bits is described in more detail above. When bits [7: 6] are equal to '01' (logical zero, logical unit), the pixel data is written to the autonomous frame buffer. When bits [7: 6] are '00' (boolean logic zero), the pixel data is written to the frame buffer used to regenerate the display. When bits [7: 6] are '11' (two logical units), pixel data is written to all frame buffers. If bits [7: 6] are '10', this is treated as an invalid value. These bits are currently reserved for future use. In this situation, the entire command is ignored and no frame buffers are updated.

Bits 11-8 of the Pixel Data Attributes field specify an alternate display or alternate client location where the pixel data should be updated. Bits 0 and 1 are set to 00 (logical double zero) so that the client interprets bits 11-8 as an alternative display number. If bits 1 and 0 are not equal to 00, then bits 8-11 are usually set equal to the value or level of logical zero. Bits 2 and 3 and 12-15 are reserved for future use and should usually be set to a level or logical zero value.

In one embodiment, the 2-byte Raster Operation field defines how to combine pixels at the source and destination locations to generate new pixel values that need to be written to the destination image location. Raster operations determine how two different rectangular areas of equal size in the frame buffer are combined together. The destination image area is also one of two images that are combined together. The second of the two images is called the original image (source). If the client does not support the Raster Operation field, which is defined in the Client Capabilities packet, then the master typically sends this packet with bits 3-0 equal to 3, and the client ignores bits 3-0.

In one embodiment, bits 3-0 are used to set the actual raster operation, using or setting them equal to one of the values shown in Table XVI below to select the corresponding operation indicated next to this value. That is, each indicated bit value [3: 0] given in the first column leads to the operation indicated in the second column, and is further defined in the third column for clarification.

Table XVI The value of the bits [3: 0] Values stored at destination Definition 0 0 one source & destination logical operation AND 2 source & ~ destination source AND (not destination) 3 source four ~ source & destination (not source) And destination 5 destination no operation 6 source ^ destination logical operation EXCLUSIVE OR 7 source | destination logical operation OR 8 ~ (source | destination) not (source OR destination) 9 ~ (source ^ destination) not (source EXCLUSIVE OR destination) 10 ~ (destination) not (destination) eleven source | ~ destination source OR (not destination) 12 ~ source not source 13 ~ source | destination (not source) OR destination fourteen ~ (source & destination) not (source AND destination) fifteen All units

Bits 9-8 are used to specify whether to record the pixels of the destination (destination) at the locations of the destination when they refer to a transparent color. Bit 4 of the Client Feature Capability Indicators field in the Client Capabilities package indicates whether or not the ability to transparent color and transparent mask by the client is supported. Similarly, bit 4 of the Display Feature Capability Indicators field in the Alternate Display Capabilities package indicates whether the ability to transparent color and transparent mask is supported by the specified alternate display. When the transparent color and transparent mask are not supported, then the raster operation behaves as if bits [9: 8] were set to 00. The operation indicated by bits [9: 8] is applied whether or not the raster operation is supported by the client device. If the client does not support raster operations, then the resulting value of the destination pixel, which should be considered for the operation specified by bits [9: 8], is equal only to the value of the original pixel. This behavior is the same with bits [3: 0] set to 3.

When the value of bits [9: 8] is 00, then the transparent color is not used. The resulting destination pixel is written to the location of the destination pixel without considering the value of the transparent color or the transparent mask. Transparent color is determined by the "Set transparent color and mask" package. The value of bits [5: 4], equal to 01, is currently reserved for future use and is usually not used. When the value of bits [5: 4] is 10, the resulting pixel is not written to the location of the destination pixel, if the resulting destination pixel, calculated using the raster operation, the result of the logical AND source pixel with a transparent mask is equal to the transparent color. Otherwise, it is written to the destination pixel location. When the value of bits [9: 8] is 11, the resulting pixel is written to the location of the destination pixel if the resulting destination pixel calculated by the raster operation is equal to a transparent color. Otherwise, the resulting pixel is not written to the destination pixel location.

Bits 15 to 10 and 7 to 4 are reserved for future use and therefore are usually set to a value or logical zero level.

J. For Fill Bitmap Template Packages

In one embodiment, the Window Upper Left Coordinate X Value and Y Value fields (X value and Y value of the upper left coordinate of the window) in the Fill Bitmap Template packet use 2 bytes each to specify the X and Y coordinates of the upper left corner of the window, which must be filled. The Window Width and Height fields use 2 bytes each to determine the width and height of the window according to the fill pattern. The Horizontal Pattern Offset field (2 bytes) defines the horizontal offset of the pixel data pattern from the left border of the specified window that needs to be filled. The value to be set must be less than the value in the "Template Width" field. The Vertical Pattern Offset field (2 bytes) determines the vertical offset of the pixel data pattern from the top border of the specified window that needs to be filled. The value to be set must be less than the value in the Pattern Height field.

In one embodiment, the 2-byte Pixel Data Attributes field has values that specify where the pixel data is about to be updated, with bits 1 and 0 selecting a display where the pixel data is to be updated. If the primary display in the client does not support stereo images, then the client can affect the pixel data in the primary display for one of the bit combinations 01, 10, or 11. It is recommended that a value of 11 be used to address the primary display in clients that do not support the stereo display capability. When bits [1: 0] have values 11 (logical unit, logical unit), pixel data is updated in the frame buffer of both the left and right eyes, if bits [1: 0] have values 10 (logical unit, logical zero), pixel data is updated in the frame buffer of the left eye only. When bits [1: 0] are set to 01 (logical zero, logical unit), the pixel data is updated in the frame buffer of the right eye only. When bits [1: 0] are set to 00 (logical double zero), the pixel data is updated in the frame buffer of the alternate display indicated by bits 8-11 below.

Bits 3-2 are reserved for future use and should be set to zero.

Bit 4 determines whether the buffer for the left eye or the right eye is input to a raster operation as the destination image for this operation. Bit 4 applies only when bits [1: 0] are not equal to 00, meaning that the original data from the main image buffer is not supported when the destination of this image is one of the alternative displays. Bit 4 is usually also applied only when the client supports raster operations on specified displays, as indicated by bit 21 of the Client Feature Capability Indicators field in the Client Features packet or bit 21 of the Display Feature Capability Indicators field in the Alternative Display Capabilities packet. When bit 4 is 0, the left eye frame buffer is the data source, and when bit 4 is 1, the right eye frame buffer is the data source.

Bit 5 determines whether the buffer is used to regenerate the display or whether the stand-alone image buffer acts as input to the raster operation as the destination image for this operation. Bit 5 can also be applied to an alternate display if the alternate display uses a standalone image buffer. This is not supported for source data from the main image buffer when the destination of the image is one of the alternative displays, or vice versa. When bit 5 is 0, the image buffer used to update the display is the data source, and when bit 5 is 1, the offline image buffer is the data source.

Bits 7 and 6 from the Pixel Data Attributes field act as the Display Update bits, which define the image buffer where the pixel data should be updated or recorded. The effect of the frame update bits is described in more detail above. When bits [7: 6] are '01' (logical zero, logical unit), the pixel data is updated in a standalone image buffer. When bits [7: 6] are '00' (two logical zeros), the pixel data is written to the image buffer used to update the display image. When bits [7: 6] are '11' (two logical units), the pixel data is updated in all image buffers. If bits [7: 6] are '10', this is treated as an invalid value. These bits are currently reserved for future use. In this situation, the entire command is ignored and no frame buffers are updated.

Bits 11-8 of the Pixel Data Attributes field define the display or location (address) of the alternative client where the pixel data should be updated. Bits 0 and 1 are set to 00 (logical double zero) for the client to interpret bits 11-8 as an alternate display number. If bits 1 and 0 are not equal to 00, then bits 8-11 are usually set equal to the value or level of logical zero. Bits 3 and 2 and 12 to 15 are reserved for future use and are usually set to a level or logical zero value.

In one embodiment, the 2-byte Raster Operation field determines how to combine pixels at the source and destination (destination) locations to generate new pixel values that must be written to the destination image location. Raster operations determine how two different rectangular areas of equal size in the frame buffer are combined together. The destination image area is also one of two images that are combined together. The second of the two images is called the source image. If the client does not support the Raster Operation field, as defined in the Client Capabilities packet, then the master typically sends this packet with bits 3-0 equal to 3, and the client ignores bits 3-0.

In one embodiment, bits 3-0 are used to determine the actual raster operation by using or setting them equal to one of the values shown in Table XVII below to select the corresponding operation shown next to this value. That is, each value indicated in bits [3: 0] listed in the first column leads to the operation indicated in the second column, and is further defined here for clarification in the third column.

Table XVII The value of the bits [3: 0] Values stored at destination Definition 0 0 one source & destination logical operation AND 2 source & ~ destination source AND (not destination) 3 source four ~ source & destination (not source) And destination 5 destination no operation 6 source ^ destination logical operation EXCLUSIVE OR 7 source | destination logical operation OR 8 ~ (source | destination) not (source OR destination) 9 ~ (source ^ destination) not (source EXCLUSIVE OR destination) 10 ~ (destination) not (destination) eleven source | ~ destination source OR (not destination) 12 ~ source not source 13 ~ source | destination (not source) OR destination fourteen ~ (source & destination) not (source AND destination) fifteen All units

Bits 9-8 are used to specify whether to record the pixels of the destination (destination) at the locations of the destination when they refer to a transparent color. Bit 4 of the Client Feature Capability Indicators field in the Client Capabilities package indicates whether or not the ability to transparent color and transparent mask by the client is supported. Similarly, bit 4 of the Display Feature Capability Indicators field in the Alternate Display Capabilities package indicates whether the ability to have a transparent color and a transparent mask is supported by the specified alternate display. When the transparent color and transparent mask are not supported, then the raster operation behaves as if bits [9: 8] were set to 00. The operation indicated by bits [9: 8] is applied whether or not the raster operation is supported by the client device. If the client does not support raster operations, then the resulting value of the destination pixel, which should be considered for the operation specified by bits [9: 8], is equal only to the value of the original pixel. This behavior is the same with bits [3: 0] set to 3.

When the value of bits [9: 8] is 00, then the transparent color is not used. The resulting destination pixel is written to the location of the destination pixel without considering the value of the transparent color or the transparent mask. Transparent color is determined by the "Set transparent color and mask" package. The value of bits [5: 4], equal to 01, is currently reserved for future use and is usually not used, although it is available for establishment by specialists in this field of technology with appropriate use. When the value of bits [5: 4] is 10, the resulting pixel is not written to the location of the destination pixel, if the resulting destination pixel calculated using the raster operation — the result of the logical AND source pixel with a transparent mask — is equal to the transparent color. Otherwise, it is written to the destination pixel location. When the value of bits [9: 8] is 11, the resulting pixel is written to the location of the destination pixel if the resulting destination pixel calculated by the raster operation is equal to a transparent color. Otherwise, the resulting pixel is not written to the destination pixel location.

Bits 15 to 10 and 7 to 4 are reserved for future use and therefore are usually set to a value or logical zero level.

In one embodiment, the 2-byte CRC Parameter field in the Fill Bitmap Template packet contains the CRC of all bytes from “Packet Length” to “Video Format Descriptor”. If this CRC gives an error during validation, then the entire packet is rejected. The "Pixel data of the template" field contains raw video information that defines the fill pattern in the format specified by the "Video data format descriptor." The data is packed in bytes, and the first pixel of each row should be aligned on the byte boundary. The fill pattern data is transmitted line by line at a time. Field "CRC of pixel data of the template" for the package "Fill the bitmap template" uses 2 bytes, which contain CRC only pixel data of the template. If this CRC gives an error while checking, then the pixel data of the template can still be used, but the count of erroneous CRC codes should be increased.

K. For Direct Audio Channel Resolution Packages

The Audio Channel Enable Mask field (1 byte) contains a group of flags that indicate which audio channels should be allowed in the client. A bit set to one enables the corresponding channel, and a bit set to zero disables (disables) the corresponding channel. Bits 0-5 define channels 0-5, which address the left front, right front, left rear, right rear, front center and subwoofer channels, respectively. Bits 6 and 7 are reserved for future use and, for now, are usually set to zero.

L. For Reverse Audio Sample Rate Packets

The Audio Sample Rate field (1 byte) sets the sampling rate for digital audio. The values for this field are assigned to different speeds with values of 0, 1, 2, 3, 4, 5, 6, 7, and 8, used to indicate 8000, 16000, 24000, 32000, 40000, 48000, 11025, 22050 and 44100 samples in second (w / s), respectively, with bits 9-254 reserved for use with alternative frequencies, as required, so that they are currently set to '0'. A value of 255 is used to prohibit reverse link audio stream.

The Sample Format field (1 byte) defines the format of the digital audio samples. When bits [1: 0] are '0', the digital audio samples are in a linear format, when they are 1, the digital audio samples are in μ-Law format, and when they are 2, the digital audio samples are in A-Law format . Bits [7: 2] are reserved for alternative use in designating audio formats, as required, and are usually set to zero.

M. For Digital Content Protection Utility Packages

The Content Protection Type field (1 byte) defines the method of protecting digital content that is used. A value of '0' indicates Digital Transmission Content Protection (DTCP), while a value of 1 indicates Broadband Digital Content Protection (HDCP). The range of values from 2 to 255 is not currently defined, but reserved for use with alternative protection schemes, as required. The Content Protection Overhead Messages field is a variable-length field containing content protection messages sent between the master and the client.

N. For packets "Measurement of the delay of the signal passage in the forward and reverse directions"

The 2-byte Packet Length field determines the total number of bytes in the packet, not including the packet length field, and in one embodiment is selected to have a fixed length of 159. The 2-byte Packet Type field, which identifies this type of packet with a value of 82, identifies the packet as a packet “Measurement of the delay of the signal transmission in the forward and reverse directions.” The hClient ID field (as before) is reserved for future use as a client identifier and usually set tsya zero.

In one embodiment, the CRC Parameter field (2 bytes) contains a 16-bit CRC of all bytes from "Packet Length" to "Packet Type". If this CRC generates an error during verification, then the entire packet is rejected.

The "Protective Time Interval 1" field (64 bytes here) is used to enable the line masters MDDI_Data in the client to be allowed before the line masters in the master are disabled. The client resolves its line drivers MDDI_Data for bit 0 of the "Guard Time Interval 1", and the master removes the resolution of its drivers of the line to be completely disabled until the last bit of the "Guard Interval 1". The master and the client both excite (set) a logic zero level during the "Guard time interval 1" when they are not prohibited. Another purpose of this field is to ensure that all MDDI_Data signals are logic zero for a sufficient time to allow the user to start restoring synchronization or clock using only MDDI_Stb, before the master devices on the line disconnect.

The Measurement Period field is a 64-byte window used to allow the user to respond with two bytes 0xff and 30 bytes 0x00 at half the data rate used on the forward link. This data rate corresponds to a Divider of the reverse link transmission rate of 1. The client returns this response immediately at the moment when it senses the beginning of the "Measurement period" field. This response from the client will be received in the master device exactly equal to the delay of signal transmission in the forward and reverse directions of communication plus the logical delay in the client after the start of the first bit of the "Measurement period" field in the master device.

The All Zeros 1 field (2 bytes) contains zeros to enable overlapping (overlapping) of the MDDI_Data line drivers in the master and client, so that MDDI_Data is always energized (set). The master permits the master devices of the MDDI_Data line during bit 0 of the "All Zeros 1" field, and the client also continues to excite the signal to a logic zero level, as it did at the end of the "Measurement period" field.

The value of the "Protective Time Interval 2" field (64 bytes) allows the overlapping of the "Measurement Period" field set by the client when the delay in the signal transmission in the forward and reverse directions is equal to the maximum value that can be measured in the "Measurement Period". The client disables its line drivers in bit 0 of the "Guard Time Interval 2", and the master resolves its drivers in the line immediately after the last bit of the "Guard Interval 2". The master and client both set the logic level to zero during "Guard interval 2" when they are not locked. Another purpose of this field is to ensure that all MDDI_Data signals are logic zero for sufficient time to allow the user to start restoring the clock using both MDDI _DATA0 and MDDI_Stb after resolving the line drivers for the master.

O. For packets "Calibration of the shift in time of the forward link”

In one embodiment, the CRC Parameter (2 bytes) field contains a 16-bit CRC of all bytes from "Packet Length" to "Packet Type". If this CRC generates an error during verification, then the entire packet is rejected.

The All Zeros 1 field uses 8 bytes to ensure that there will be transitions to MDDI_Stb at the beginning of the Calibration Data Sequence field. Typically, these bytes use 8-bit unsigned integers equal to zero. It also provides enough time for the core client logic to change the mode of the clock recovery circuit from using an EXCLUSIVE OR (XOR) for MDDI_0 and MDDI_Stb to simply use the MDDI_Stb or MDDI_Stb signal as the restored synchronization signal.

The Calibration Data Sequence field contains a data sequence that causes the MDDI_Data signals to switch in each data period. The Calibration Data Sequence field length is determined by the interface used on the forward link. During the processing of the calibration data sequence, the MDDI master controller sets all MDDI_Data signals equal to the strobe signal. The client synchronization signal recovery scheme should use only MDDI_Stb instead of MDDI_Stb XOR MDDI_Data0 to restore data synchronization, while the Calibration Data Sequence field is received by the client. Depending on the exact phase of the MDDI_Stb signal at the beginning of the Calibration Data Sequence field, this “Calibration Data Sequence” will usually be one of the following based on the Interface Type used when this packet is sent:

Type 1 - (data sequence 64 bytes) 0xaa, 0xaa ... or 0x55, 0x55 ...

Type 2 - (data sequence 128 bytes) 0xcc, 0xcc ... or 0x33, 0x33 ...

Type 3 - (data sequence 256 bytes) 0xf0,0xf0 ... or 0x0f, 0x0f ...

Type 4 - (data sequence 512 bytes) 0xff, 0x00, 0xff, 0x00 ... or 0x00, 0xff, 0x00, 0xff ...

The All Zeros 2 field uses 8 bytes to provide sufficient time for the core client logic to change the mode of the synchronization recovery circuit back to its original state, from using the MDDI_Stb signal as a restored synchronization signal to using the result of the XOR operation for MDDI_0 and MDDI_Stb. Typically, these bytes use 8-bit unsigned integers equal to zero.

An example of the possible waveforms MDDI_Data and MDDI_Stb for an interface of both Type 1 and Type 2 is illustrated in Figures 62A and 62B, respectively.

XIX. Conclusion

While various embodiments of the present invention have been described above, it should be understood that they were presented by way of example only and not limitation. Thus, the breadth and scope of the present invention should not be limited by any of the above exemplary embodiments, but should be determined only in accordance with the following claims and their equivalents.

Claims (30)

1. A method of retrieving reverse transmission data for each data channel from a plurality of data channels in a system with a digital interface of a mobile data transmission system (CIMS, MDDI), the method comprising the steps of:
send a forward and reverse signal delay measurement packet from the host device to the client device;
send a pulse inside the measurement window in the packet measuring the delay of the signal in the forward and reverse directions to the master device from the client device for each data channel;
measuring the delay of signal propagation in the forward and reverse directions of the SIMS system by detecting a pulse sent inside the measurement window in the packet for measuring the delay in signal propagation in the forward and reverse directions for each data channel;
determine the phase of the sent pulse;
save the measured delay of the signal in the forward and reverse directions of each channel;
determine the time to start sampling the reverse transmission data sent by the client device based on the measured signal delay in the forward and reverse directions of each data channel and the phase of the sent pulse sent in response by the client device relative to the bit boundary in the measurement window. 2. The method according to claim 1, wherein the step of measuring the propagation delay of the signal in the forward and reverse directions comprises measuring the propagation delay from the host device to the client device and from the client device to the host device. 3. The method according to claim 1, further comprising determining a transmission rate divider over the communication line in the reverse link encapsulation packet based on the measured forward delay of the signal in the forward and reverse directions. 4. A system for retrieving reverse data for each data channel from a plurality of data channels in a system with a digital interface of a mobile data transmission system (CIMS, MDDI), comprising:
means for sending a packet measuring the delay of the signal in the forward and reverse directions from the host device to the client device;
means for sending a pulse inside the measurement window in the packet measuring the delay of the signal passage in the forward and reverse directions to the host device from the client device for each data channel;
means for measuring the delay of signal propagation in the forward and reverse directions in the CIMS system by detecting a pulse sent inside the measurement window in the packet for measuring the delay in signal propagation in the forward and reverse directions for each data channel;
means for determining the phase of the sent pulse;
means for storing the measured signal delay in the forward and reverse directions of each channel;
means for determining the start time of the retransmission data sent by the client device based on the measured signal delay in the forward and reverse directions of each data channel and the phase of the sent pulse sent in response by the client device relative to the bit boundary in the measurement window. 5. The system according to claim 4, in which the means for measuring the propagation delay of the signal in the forward and reverse directions comprises means for measuring the propagation delay from the host device to the client device and from the client device to the host device. 6. The system according to claim 4, further comprising means for determining a divider of the transmission rate of the communication line in the encapsulation packet of the reverse communication line based on the measured signal propagation delay in the forward and reverse directions. 7. A processor for retrieving postback data for each data channel from a plurality of data channels in a system with a digital interface of a mobile data transmission system (CIMS, MDDI), configured to:
sending a packet measuring the delay of the signal in the forward and reverse directions from the host device to the client device;
sending a pulse inside the measurement window in the packet measuring the delay of the signal passage in the forward and reverse directions by the client device to the master device for each data channel;
measuring the delay of signal propagation in the forward and reverse directions in the CIMS system by detecting a pulse sent inside the measurement window in the packet for measuring the delay of signal propagation in the forward and reverse directions for each data channel;
determining the phase of the sent pulse;
save the measured delay of the signal in the forward and reverse directions of each channel;
determining a start time for retransmission data sent by the client device based on the stored signal delay in the forward and reverse directions of each data channel. 8. The processor according to claim 7, in which the processor is further configured to measure propagation delay from the host device to the client device and from the client device to the host device. 9. The processor according to claim 7, the processor is further configured to determine a divider of the transmission rate of the communication line in the encapsulation packet of the reverse communication line based on the measured signal propagation delay in the forward and reverse directions. 10. A method for determining a data transfer rate between a master device and a client device in a system with a digital interface of a mobile data transmission system (CIMS, MDDI), the method comprising the steps of:
selecting the minimum pre-calibration data rate that the client device can support;
requesting a package of client capabilities by the master device from the client device,
performing a time shift calibration of the forward link to optimize the link to operate at said data rate;
determining a maximum data rate based on a data rate value in a client capabilities packet and a forward offset time shift calibration, and
functioning at a certain maximum data rate. 11. A system for determining the data transfer rate between a master device and a client device in a system with a digital interface of a mobile data transfer system (CIMS, MDDI), comprising:
means for selecting a minimum pre-calibration data rate that the client device can support;
means for requesting a package of client capabilities by the master device from the client device,
means for performing a time-shift calibration of the forward link for optimizing the link for operating at said data rate;
means for determining a maximum data rate based on a data rate value in a client capability packet and calibrating a time shift of a forward link and
means for functioning at a certain maximum data rate. 12. A processor for retrieving postback data for each data channel from a plurality of data channels in a system with a digital interface of a mobile data transmission system (CIMS, MDDI), configured to:
determining the optimal data transfer rate between the master device and the client device in a system with a digital interface of a mobile data transfer system (CIMS, MDDI);
selecting the minimum pre-calibration data rate that the client device can support;
request a package of client capabilities by the master device from the client device,
performing a time-shift calibration of the forward link to optimize the link to operate at said data rate;
determining a maximum data rate based on a data rate value in a client capability packet; and
forcing the system to operate at a certain maximum data rate. 13. A device for connecting two client devices to the host device in the internal mode of the system with a digital interface for a mobile data transfer system (CIMS, MDDI), comprising:
a first termination at a first location at the end of the cable with a first length equal to L _stub1 ;
a first client device having transmission and reception capabilities at said first location;
a second termination at a second location on said cable with a second length equal to L _stub2 ;
a second client device containing only reception capabilities at said second location, the first length and the second length being determined based on the minimum rise time of the driver output signal and the speed factor of at least one transmission line. 14. A method of connecting two client devices to a master device in an internal mode of a system with a digital interface of a mobile data transmission system (CIMS, MDDI), comprising the steps of:
providing a first termination at a first location at the end of the cable with a first length equal to L _stub1 ;
connecting a first client device having transmission and reception capabilities to said first location;
providing a second termination at a second location on said cable with a second length equal to L _stub2 ;
connecting a second client device containing reception capabilities only to said second location, the first length and the second length being determined based on the minimum rise time of the driver output signal and the speed factor of at least one transmission line. 15. The method of claim 14, further comprising optimizing the first length and second length for a predetermined quality signal. 16. A method for determining a maximum data rate of a preliminary time shift calibration in a communication system with a digital interface of a mobile data transmission system (CIMS, MDDI), the method comprising the steps of:
operating at a first working data rate between the client device and the master, the first working data rate being a safe working data rate,
sending a reverse link encapsulation packet from the host device to the client device requesting the client device capability packet;
transmitting the capabilities package of the client device from the client device to the master device, while the capabilities package of the client device contains the value of the maximum data rate of the preliminary calibration of the time shift, and
operate by means of a master device at a second working data rate, wherein the second working data rate is a data rate equal to or lower than the maximum data rate of the preliminary calibration of the time shift. 17. The method according to clause 16, in which the first working data rate is a data rate equal to or less than the safe working data rate. 18. The method according to clause 16, in which the value of the safe working data rate is in the range from 0.001 and 1 Mbps. 19. A system for determining the maximum data rate of the preliminary calibration of the time shift in a communication system with a digital interface of a mobile data transmission system (CIMS, MDDI), comprising:
means for operating at a first working data rate between the client device and the master device, wherein the first working data rate is a safe working data rate,
means for sending a reverse link encapsulation packet from the host device to the client device requesting the client device capabilities packet;
means for transmitting a capabilities package of the client device from the client device to the host device, wherein the capabilities package of the client device contains a value of the maximum data rate of the preliminary time offset calibration, and
means for operating by means of a master device at a second working data rate, wherein the second working data rate is a data rate equal to or lower than the maximum data rate of the preliminary time-shift calibration. 20. The system of claim 19, wherein the first working data rate is a data rate equal to or less than the safe working data rate. 21. The system according to claim 19, in which the value of the safe working data rate is in the range of 0.001 and 1 Mbit / s. 22. A processor configured to:
determining the maximum data rate of the preliminary calibration of the time shift in a communication system with a digital interface of a mobile data transmission system (CIMS, MDDI),
force said system to operate at a first working data rate between the client device and the master device, wherein the first working data rate is a safe working data rate,
implement sending a reverse link encapsulation packet from the host device to the client device requesting the client device capabilities packet;
to implement the transmission of the package of capabilities of the client device from the client device to the master device, while the package of capabilities of the client device contains the value of the maximum data rate of the preliminary calibration of the time shift, and
force said system by means of a master device to operate at a second working data rate, wherein the second working data rate is a data rate equal to or less than the maximum data rate of the preliminary time shift calibration. 23. The processor of claim 22, wherein the first operating data rate is a data rate equal to or less than the safe operating data rate. 24. The processor according to item 22, in which the value of the safe working data rate is in the range from 0.001 and 1 Mbit / s. 25. A method for determining a maximum operating data rate after calibrating a time shift in a communication system with a digital interface of a mobile data transmission system (CIMS, MDDI), the method comprising the steps of:
sending a time-shift calibration packet from the host device to the client device;
adjust the calibration of the shift in time through the client device;
sending a packet of capabilities of the client device from the client device to the master device, while the packet of capabilities of the client device contains the value of the maximum working data rate after calibrating the time shift, and
the operating data rate is selected by means of the master device, wherein the operating data rate is a data rate equal to or lower than the maximum operating data rate after calibrating the time shift. 26. The method of claim 25, further comprising the step of sending the host device a reverse link encapsulation packet to the client device requesting the capabilities packet of the client device. 27. A system for determining a maximum operating data rate after calibrating a time shift in a communication system with a digital interface of a mobile data transmission system (CIMS, MDDI), the system comprising:
means for sending a time-shift calibration packet from the host device to the client device;
means for performing adjustment of the calibration of the shift in time through the client device;
means for sending a capabilities package of the client device from the client device to the master device, wherein the capabilities package of the client device contains the value of the maximum working data rate after calibrating the time offset, and
means for selecting an operating data rate by the master, wherein the operating data rate is a data rate equal to or less than the maximum operating data rate after calibrating the time shift. 28. The system of claim 27, further comprising means for sending a reverse link encapsulation packet to the client device requesting a capabilities packet of the client device by the host device. 29. A processor configured to:
determining the maximum working data rate after calibrating the time shift in a communication system with a digital interface of a mobile data transmission system (CIMS, MDDI),
implement sending a time-shift calibration packet from the host device to the client device;
implement the adjustment of the calibration of the shift in time through the client device;
implement sending a package of capabilities of the client device from the client device to the master device, while the package of capabilities of the client device contains the value of the maximum working data rate after calibrating the time shift, and
implement the choice of the operating data transfer speed by means of the master device, while the working data transfer rate is the data transfer rate equal to or lower than the maximum working data transfer rate after calibrating the time shift. 30. The processor according to clause 29, in which the processor is further configured to implement the sending of the encapsulation packet of the reverse link to the client device requesting the capabilities of the client device by the host device.

Images