Instrument display system and instrument display method based on vehicle-mounted Bluetooth screen projection

Abstract

The invention discloses an instrument display system and an instrument display method based on vehicle-mounted Bluetooth screen projection. The instrument display system comprises an instrument end broadcast and maintenance module which is used for broadcasting a capability configuration file through Bluetooth; the capability configuration file comprises display capability data and processing limitation data; the mobile phone end self-adaptive content preprocessing and situational encoding module is used for carrying out preprocessing and situational encoding on the content to be projected according to the display capability data and the processing limitation data after receiving the capability configuration file to obtain a data packet; and the instrument end data stream analysis and direct rendering module is used for performing data stream analysis and direct rendering display after receiving the data packet. Through the above mode, the compatibility of the Bluetooth screen projection scheme and the user experience can be improved.

Description

Technical Field

[0001] This application relates to the technical field of instrument display, and particularly to an instrument display system and an instrument display method based on in-vehicle Bluetooth screen mirroring. Background Art

[0002] Currently, the screen mirroring of mobile phone content in in-vehicle infotainment systems mainly relies on WIFI wireless screen mirroring technology and uses video stream transmission protocols such as H.264. Although this method can provide good picture quality and smoothness, it has high requirements for the processor performance, memory bandwidth, and WIFI hardware cost of the in-vehicle host (especially the instrument system). For economy models or low-cost instrument solutions, the cost and power consumption of the WIFI screen mirroring solution are unacceptable.

[0003] As a low-cost alternative solution, Bluetooth screen mirroring has gradually attracted attention. Existing Bluetooth screen mirroring mostly compresses the mobile phone screen content (such as navigation screens) into static picture formats such as JPG and then transmits them to the instrument display via Bluetooth. The problems with this method are as follows:

[0004] 1. Difficulty in balancing generality and efficiency: JPG is a general format, and its compression efficiency is not high for specific instrument display scenarios (such as a large number of solid colors and repetitive icons), and there is still a certain overhead for decoding at the instrument end.

[0005] 2. Bottleneck in processing dynamic content: For dynamically changing navigation screens or video content, frequently transmitting a sequence of JPG pictures poses a great pressure on the Bluetooth bandwidth and the instrument processing ability, making it difficult to ensure smoothness.

[0006] 3. Resource limitations at the instrument end: Low-cost instruments usually use microcontrollers (MCUs) with limited resources, whose Flash reading speed, memory size, and CPU processing ability are all limited, and it is difficult to perform complex image decoding and real-time rendering tasks. Although there are pre-compression and pre-compilation solutions for static UI elements of the instrument (such as converting pictures into a specific binary format and directly loading them into RAM), this is not applicable to the dynamic content of mobile phone screen mirroring.

[0007] 4. Lack of unified standards and negotiation: Existing Bluetooth screen mirroring lacks a unified negotiation mechanism for content formats, compression methods, display capabilities, etc. between the mobile phone and the instrument, resulting in poor adaptability and expandability. Summary of the Invention

[0008] The instrument display system and the instrument display method based on in-vehicle Bluetooth screen mirroring provided by this application can improve the compatibility and user experience of the Bluetooth screen mirroring solution.

[0009] In a first aspect, the present application provides an instrument display system based on in-vehicle Bluetooth screen mirroring. The instrument display system includes: an instrument-side broadcast and maintenance module for broadcasting its capability profile via Bluetooth; the capability profile includes display capability data and processing limit data; a mobile phone-side adaptive content preprocessing and context encoding module for, after receiving the capability profile, preprocessing and context encoding the content to be screen mirrored according to the display capability data and processing limit data to obtain data packets; and an instrument-side data stream parsing and direct rendering module for performing data stream parsing and direct rendering display after receiving the data packets.

[0010] Among them, the instrument-side broadcast and maintenance module includes: a multi-level summary and hierarchical broadcast unit for using the most core and general capability information of the instrument side as a first-level summary, generating a second-level summary according to the capability profile, and then broadcasting the first-level summary and the second-level summary using multiple groups of broadcast events; a dynamic capability broadcast and context awareness unit for dynamically updating the profile ID or summary it broadcasts when the display capability of the instrument side changes; and a general attribute profile service unit for sending the capability profile to the mobile phone side after a connection is established between the mobile phone side and the instrument side.

[0011] Among them, the mobile phone-side adaptive content preprocessing and context encoding module includes: a content awareness and semantic extraction unit for performing content understanding and semantic extraction on the content to be screen mirrored; a dynamic generation and optimization unit of instruction stream for dynamically selecting and combining basic primitive instructions according to the capability profile; and a context adaptive differential update strategy unit for performing differential update based on the content type, performing differential update based on the differential granularity of the instrument processing capability, and performing intelligent key frame insertion during the differential update process.

[0012] Among them, the content awareness and semantic extraction unit is further used for, when performing navigation screen mirroring, performing navigation path recognition, icon and symbol recognition, and text content extraction and optimization on the content to be screen mirrored.

[0013] Among them, the dynamic generation and optimization unit of instruction stream is further used for dynamically performing instruction selection, parameter optimization, and instruction compression.

[0014] Among them, the instrument-side data stream parsing and direct rendering module includes: a data stream parsing engine unit for, according to the data packet type identifier, calling the corresponding parsing logic to parse primitive instructions, parse palette index data, and parse differential data packets; and a rendering and display unit for directly sending the content of the rendered frame buffer to the display controller for display.

[0015] Among them, the instrument display system further includes: a Bluetooth communication optimization and synchronization mechanism module, which is used for dynamically negotiating Bluetooth connection parameters between the mobile phone side and the instrument side, as well as fragmenting, acknowledging, and controlling the traffic of application layer data packets, and performing frame synchronization and timestamp embedding, and synchronizing and calibrating the instrument side.

[0016] Among them, the Bluetooth communication optimization and synchronization mechanism module includes: a Bluetooth connection parameter dynamic negotiation unit, which is used for dynamically negotiating Bluetooth connection parameters between the mobile phone side and the instrument side according to the data type to be transmitted and the refresh rate requirement in the instrument capability profile after the initial connection between the mobile phone side and the instrument side; an application layer data packet fragmentation, acknowledgment, and traffic control unit, which is used for intelligently fragmenting according to the atomicity of instructions, and setting an acknowledgment mechanism for key data packets at the application layer; and during operation, the instrument side feeds back the occupancy of its buffer to the mobile phone side so that the mobile phone side can adjust the sending rate.

[0017] Among them, the instrument display system further includes: an evaluation module, which is used for evaluating the overall screen mirroring efficiency according to the screen mirroring content, encoded data, bandwidth occupancy rate, instrument side load, communication and display synchronization quality, and instrument capability adaptation degree.

[0018] In a second aspect, the present application provides an instrument display method based on in-vehicle Bluetooth screen mirroring, which is applied to the instrument display system provided in the first aspect. The method includes: the instrument side broadcasts its capability profile through Bluetooth; the capability profile includes display capability data and processing limit data; after receiving the capability profile, the mobile phone side preprocesses and context-encodes the content to be screen mirrored according to the display capability data and processing limit data to obtain data packets; after receiving the data packets, the instrument side performs data stream parsing and direct rendering display.

[0019] The beneficial effects of this application are as follows: Different from the prior art, the instrument display system and method based on in-vehicle Bluetooth screen mirroring provided by this application include: an instrument-side broadcast and maintenance module for broadcasting its capability profile via Bluetooth; the capability profile includes display capability data and processing limit data; a mobile-phone-side adaptive content preprocessing and context encoding module for preprocessing and context encoding the content to be screen-mirrored according to the display capability data and processing limit data after receiving the capability profile to obtain a data packet; an instrument-side data stream parsing and direct rendering module for performing data stream parsing and direct rendering display after receiving the data packet. That is, the instrument display system and method based on in-vehicle Bluetooth screen mirroring provided by this application can efficiently transmit the dynamic screen content (especially navigation, multimedia, etc.) of the mobile phone to the resource-constrained vehicle instrument system under the limited bandwidth of Bluetooth, and can minimize the decoding and rendering complexity of the screen-mirrored data received by the instrument side, enabling it to be smoothly displayed on a low-cost MCU, and establishing a dynamic capability negotiation mechanism between the mobile phone and the instrument, enabling the mobile phone to adaptively optimize the format and data volume of the screen-mirrored content according to the actual display capability and processing limit of the instrument side, and can improve the compatibility and user experience of the Bluetooth screen mirroring solution, enabling it to adapt to instruments with different performances and different types of screen-mirrored content. Description of the Drawings

[0020] To more clearly illustrate the technical solutions in the embodiments of this application, the following will briefly introduce the drawings required for use in the description of the embodiments. Obviously, the following drawings are only some embodiments of this application. For those of ordinary skill in the art, without creative efforts, other drawings can also be obtained based on these drawings. Among them:

[0021] Figure 1 It is a schematic structural diagram of an embodiment of the instrument display system based on in-vehicle Bluetooth screen mirroring provided by this application;

[0022] Figure 2 It is a schematic structural diagram of an embodiment of the instrument-side broadcast and maintenance module provided by this application;

[0023] Figure 3 It is a schematic structural diagram of an embodiment of the mobile-phone-side adaptive content preprocessing and context encoding module provided by this application;

[0024] Figure 4 It is a schematic structural diagram of an embodiment of the instrument-side data stream parsing and direct rendering module provided by this application;

[0025] Figure 5 It is a schematic structural diagram of another embodiment of the instrument display system based on in-vehicle Bluetooth screen mirroring provided by this application;

[0026] Figure 6 It is a schematic structural diagram of an embodiment of the Bluetooth communication optimization and synchronization mechanism module provided by the present application;

[0027] Figure 7 It is a schematic structural diagram of another embodiment of the instrument display system based on in-vehicle Bluetooth screen mirroring provided by the present application;

[0028] Figure 8 It is a schematic flowchart of an embodiment of the instrument display method based on in-vehicle Bluetooth screen mirroring provided by the present application. Detailed implementation manners

[0029] Next, the technical solutions in the embodiments of the present application will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of the present application. It can be understood that the specific embodiments described herein are only used to explain the present application, rather than limiting the present application. Additionally, it should be noted that for the sake of description, only parts related to the present application rather than all structures are shown in the drawings. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of the present application.

[0030] Referring to "embodiment" herein means that the specific features, structures, or characteristics described in conjunction with the embodiment may be included in at least one embodiment of the present application. The phrase appears at various positions in the specification and does not necessarily refer to the same embodiment, nor is it an independent or alternative embodiment mutually exclusive with other embodiments. Those skilled in the art explicitly and implicitly understand that the embodiments described herein may be combined with other embodiments.

[0031] Refer to Figure 1 , Figure 1 It is a schematic structural diagram of an embodiment of the instrument display system based on in-vehicle Bluetooth screen mirroring provided by the present application. The instrument display system 100 includes: an instrument-side broadcast and maintenance module 10, a mobile-phone-side adaptive content preprocessing and context encoding module 20, and an instrument-side data stream parsing and direct rendering module 30.

[0032] The instrument-side broadcast and maintenance module 10 is used to broadcast its capability profile via Bluetooth; the capability profile includes display capability data and processing limit data.

[0033] In some embodiments, refer to Figure 2 , the instrument-side broadcast and maintenance module 10 includes: a multi-level summary and hierarchical broadcast unit 11, a dynamic capability broadcast and context awareness unit 12, and a general attribute profile service unit 13.

[0034] The multi-level summary and hierarchical broadcast unit 11 is used to take the most core and general ability information at the meter end as the first-level summary, generate a second-level summary according to the ability profile, and then broadcast the first-level summary and the second-level summary using multiple groups of broadcast events.

[0035] Multi-level summary and hierarchical broadcast of the ability profile:

[0036] First-level summary (for quick discovery and preliminary screening): The meter end can encode the most core and general ability information (e.g., "supports basic screen mirroring", "supports navigation instruction stream") into extremely short identifiers or bit masks and put them into the main broadcast data packet (Advertising Data, AD) of BLE. This part of the data will be broadcast frequently at a short broadcast interval (e.g., 100ms - 250ms) to ensure that the mobile phone end can quickly discover and preliminarily judge whether the meter supports the basic screen mirroring function it needs.

[0037] Second-level summary / Profile ID (for connection decision): For a more detailed set of capabilities, such as the specific instruction set version number supported, screen resolution level, color depth level, etc., a unique "profile ID" or a more detailed summary can be generated. This ID / summary can be placed in the scan response data packet (Scan Respnse Data) of BLE, or using the idea of CPBIS, broadcast through multiple groups of broadcast events (MultipleAdvertising Sets).

[0038] Application of multiple groups of broadcast events: Modern BLE chips support configuring multiple independent broadcast sets. The meter end can configure:

[0039] A high-frequency, low-power broadcast set for broadcasting the first-level summary to attract the mobile phone end to connect.

[0040] One or more low-frequency, more information-rich broadcast sets (e.g., using a longer broadcast interval, such as 500ms - 1s) to announce different profile IDs or key ability parameters respectively. For example, one broadcast set may announce the "economy mode profile" (low refresh rate, low color depth), and another may announce the "performance mode profile" (higher refresh rate, higher color depth, if the meter supports dynamic switching or has multiple fixed modes).

[0041] When the mobile phone end is scanning, it can selectively listen to and parse these different broadcast sets according to its own screen mirroring requirements and power consumption strategy.

[0042] The Dynamic Capability Broadcast and Context Awareness Unit 12 is used to dynamically update the profile ID or digest it broadcasts when the display capability at the instrument end switches. The capabilities at the instrument end are not static. For example, when the instrument end switches from displaying a simple clock to requiring auxiliary navigation display, its requirements for and processing capabilities of the screen mirroring data may change. At this time, the instrument end can dynamically update its broadcast profile ID or digest, or even switch to a different set of broadcast parameters. The mobile phone end senses this change through continuous (low-power) scanning or through a specific mechanism after connection, and thus adaptively adjusts the screen mirroring strategy.

[0043] The General Attribute Profile Service Unit 13 is used to send the capability profile to the mobile phone end after the mobile phone end and the instrument end establish a connection. The complete and detailed capability profile (including all supported instructions, specific palette values, exact buffer sizes, etc.) is still read through the General Attribute Profile Service Unit 13 after the mobile phone end and the instrument end establish a connection. The broadcast phase is mainly used for efficient discovery, initial screening of capabilities, and connection guidance. This hierarchical mechanism avoids carrying too much information in the limited broadcast packets.

[0044] In some embodiments, the Mobile Phone End Adaptive Content Preprocessing and Context Encoding Module 20 is used to preprocess and context-encode the content to be screen mirrored according to the display capability data and processing limit data after receiving the capability profile, obtaining data packets.

[0045] Refer to Figure 3 The Mobile Phone End Adaptive Content Preprocessing and Context Encoding Module 20 includes: a Content Awareness and Semantic Extraction Unit 21, a Dynamic Generation and Optimization Unit 22 of the instruction stream, and a Context-Adaptive Differential Update Strategy Unit 23.

[0046] The Content Awareness and Semantic Extraction Unit 21 is used to perform content understanding and semantic extraction on the content to be screen mirrored.

[0047] Among them, the Content Awareness and Semantic Extraction Unit 21 is also used to perform navigation path recognition, icon and symbol recognition, and text content extraction and optimization on the content to be screen mirrored when performing navigation screen mirroring.

[0048] In some embodiments, after the mobile phone end captures the screen content, it not only performs pixel-level analysis, but also tries to perform deeper content understanding and semantic extraction (especially during specific applications such as navigation screen mirroring). For example:

[0049] Navigation path recognition: Identify the vectorized navigation path line, rather than simply treating it as a bunch of pixels.

[0050] Icon and Symbol Recognition: Recognize common UI icons (such as turning arrows, point-of-interest markers, etc.). If the instrument side has a pre-set corresponding vector icon library or bitmap library, the mobile phone only needs to transmit the icon ID and position parameters.

[0051] Text Content Extraction and Optimization: Directly extract the text string instead of transmitting it as an image. If the instrument supports a specific font, transmit the text and font ID; if not, the mobile phone side will pre-render the text into small bitmap blocks and highly compress them (e.g., monochrome bitmap or indexed color bitmap).

[0052] The dynamic generation and optimization unit 22 of the instruction stream is used to dynamically select and combine basic primitive instructions according to the capability profile.

[0053] Among them, the dynamic generation and optimization unit 22 of the instruction stream is also used to dynamically perform instruction selection, parameter optimization, and instruction compression.

[0054] The mobile phone side dynamically selects and combines "basic primitive instructions" according to the capability profile obtained from the instrument side.

[0055] Instruction Selection: If the instrument side supports the "draw arc" instruction, give priority to using this instruction; otherwise, the mobile phone side may need to disassemble the arc into multiple short straight-line instructions.

[0056] Parameter Optimization: Parameters such as coordinates and colors of all instructions will be adapted and quantified according to the resolution and color palette of the instrument.

[0057] Instruction Compression: For repeated instruction sequences or instructions with specific patterns, a further compression mechanism can be designed (e.g., defining macro instructions).

[0058] The context-adaptive differential update strategy unit 23 is used to perform differential updates based on the content type, perform differential updates based on the differential granularity of the instrument processing ability, and perform intelligent key frame insertion during the differential update process.

[0059] Differential Based on Content Type: For map scrolling, the differential data is mainly the displacement of pixel blocks and the pixel data of the newly loaded area. For the state change of UI elements (such as button highlighting), the differential data may be the color update instruction of the element.

[0060] Differential Granularity Based on Instrument Processing Ability: If the instrument processing ability is weak, the mobile phone side may choose to send larger but more easily parsed differential blocks, or reduce the frequency of differential updates. Conversely, smaller and more refined differential data can be sent to pursue higher picture quality.

[0061] Key-frame intelligent insertion: When there are too many accumulated differential updates, or when the mobile device detects that the instrument may be out of sync (e.g., through instrument feedback or timeout mechanism), a complete key-frame will be actively sent (using instruction stream or highly optimized full-size bitmap) for synchronization.

[0062] In some embodiments, the instrument-side data stream parsing and direct rendering module 30 is used to perform data stream parsing and direct rendering display after receiving a data packet.

[0063] In some embodiments, referring to Figure 4 , the instrument-side data stream parsing and direct rendering module 30 includes: a data stream parsing engine unit 31 and a rendering and display unit 32.

[0064] The data stream parsing engine unit 31 is used to call the corresponding parsing logic according to the data packet type identifier, parse primitive instructions, parse palette index data, and parse differential data packets. Call the corresponding parsing logic according to the data packet type identifier.

[0065] Parse primitive instructions: Directly interpret the instructions and draw graphics at the corresponding positions in the frame buffer (Framebuffer).

[0066] Parse palette index data: Combine the current palette to restore the index data to pixel color values and write them into the frame buffer.

[0067] Parse differential data packets: Update specific areas of the frame buffer according to differential information.

[0068] The rendering and display unit 32 is used to directly send the content of the rendered frame buffer to the display controller for display. Since the received data is already highly optimized or instruction-based, the instrument-side MCU mainly performs simple logical judgments, memory copying (DMA), and basic drawing operations, avoiding complex mathematical operations and decoding processes. The content of the rendered frame buffer is directly sent to the display controller for display.

[0069] Referring to Figure 5 , the instrument display system 100 includes: an instrument-side broadcast and maintenance module 10, a mobile device-side adaptive content preprocessing and context encoding module 20, an instrument-side data stream parsing and direct rendering module 30, and a Bluetooth communication optimization and synchronization mechanism module 40.

[0070] The instrument-side broadcast and maintenance module 10, the mobile device-side adaptive content preprocessing and context encoding module 20, and the instrument-side data stream parsing and direct rendering module 30 are as described in the above embodiments and will not be elaborated here.

[0071] The Bluetooth communication optimization and synchronization mechanism module 40 is used to perform dynamic negotiation of Bluetooth connection parameters between the mobile phone side and the instrument side, as well as fragmentation, confirmation and flow control of application layer data packets, frame synchronization and timestamp embedding, and synchronization calibration of the instrument side.

[0072] Frame and timestamp mechanism for "quasi-symbol-level" synchronization:

[0073] Frame synchronization: The mobile phone side precisely controls the sending rhythm of data packets (especially a series of data packets representing a frame update) according to the negotiated refresh rate.

[0074] Timestamp embedding: Each key data packet or the data packet representing the start of a frame will carry the sending timestamp of the mobile phone side.

[0075] Instrument side synchronization calibration: After receiving the timestamped data packet, the instrument side can perform the following operations: evaluate network jitter and latency. And adjust the internal rendering clock according to the timestamp to ensure the smoothness of the video playback. If the arrival times of multiple consecutive frames deviate too much from the expected values, it can be considered "out of sync" with the mobile phone side, and a "synchronization refresh" (i.e., request a new key frame) is requested from the mobile phone.

[0076] Although this mechanism does not directly operate on the physical layer symbols of BLE, it simulates precise timing control similar to symbol-level synchronization at the application layer, ensuring the fluency and consistency of dynamic content.

[0077] In some embodiments, refer to Figure 6 , the Bluetooth communication optimization and synchronization mechanism module 40 includes: a dynamic negotiation unit 41 for Bluetooth connection parameters and a fragmentation, confirmation and flow control unit 42 for application layer data packets.

[0078] The dynamic negotiation unit 41 for Bluetooth connection parameters is used to dynamically negotiate Bluetooth connection parameters between the mobile phone side and the instrument side after the initial connection between the mobile phone side and the instrument side, according to the data type to be transmitted and the refresh rate requirements in the instrument capability profile. For example, after the initial connection, the mobile phone side and the instrument side will negotiate more appropriate BLE connection parameters (Connectin Interval, Slave Latency, SupervisinTimeut) according to the data type to be transmitted (such as static UI elements, low-frame-rate navigation, or simple animations with a higher frame rate) and the refresh rate requirements in the instrument capability profile. For example, for high refresh rate requirements, an attempt will be made to negotiate a shorter Connectin Interval; for low refresh rates or static content, the Interval and Slave Latency can be appropriately increased to reduce power consumption.

[0079] The Application Layer Packet Fragmentation, Acknowledgment, and Flow Control Unit 42 is used to perform intelligent fragmentation according to the atomicity of instructions, and for critical data packets, an acknowledgment mechanism is set at the application layer; and during runtime, the meter terminal feeds back the occupancy of its buffer to the mobile phone terminal so that the mobile phone terminal can adjust the sending rate.

[0080] Intelligent fragmentation is mainly reflected in that due to the limitation of the BLE ATT MTU (Maximum Transmission Unit), larger primitive instruction data or bitmap blocks need to be fragmented. The mobile phone terminal will perform intelligent fragmentation according to the atomicity of instructions (for example, a complete drawing instruction should not be split into two packets that need to be acknowledged separately, unless the instruction itself supports streaming parsing).

[0081] Selective Acknowledgment and Retransmission (Applicatin Layer Selective ACK / NACK) is mainly reflected in that for critical data packets (such as the start packet of a key frame, important configuration instructions), an acknowledgment mechanism at the application layer can be implemented. After successfully receiving and parsing a critical data packet, the meter terminal sends a short ACK to the mobile phone terminal. If the mobile phone terminal does not receive the ACK within the timeout period, it will retransmit. This is more controllable than relying on the retransmission of the BLE link layer.

[0082] Flow control based on the meter buffer is mainly reflected in that the meter terminal can declare the size of its receive buffer in its capability profile. And during runtime, it feeds back the occupancy of its buffer (such as "buffer full", "buffer available") to the mobile phone terminal through GATT Ntification or a specific response packet. The mobile phone terminal adjusts the sending rate accordingly to avoid data overflow at the meter terminal causing lag or crash.

[0083] See Figure 7 , the meter display system 100 includes: a meter terminal broadcast and maintenance module 10, a mobile phone terminal adaptive content preprocessing and context encoding module 20, a meter terminal data stream parsing and direct rendering module 30, a Bluetooth communication optimization and synchronization mechanism module 40, and an evaluation module 50.

[0084] The meter terminal broadcast and maintenance module 10, the mobile phone terminal adaptive content preprocessing and context encoding module 20, the meter terminal data stream parsing and direct rendering module 30, and the Bluetooth communication optimization and synchronization mechanism module 40 are as described in the above embodiments and will not be elaborated here.

[0085] In some embodiments, the evaluation module 50 is used to perform an effectiveness evaluation of the overall screen mirroring according to the screen mirroring content, encoded data, bandwidth occupancy rate, meter terminal load, communication and display synchronization quality, and meter capability adaptation degree.

[0086] For example, the effectiveness evaluation can be performed through the following formula:

[0087] E_ScreenMirroring = [(C_Content × Q_Encoding) / (B_BandwidthOccupancy × P_MeterLoad)] × S_Synchronization × A_Adaptation

[0088] Where:

[0089] E_ScreenMirroring (Overall Screen Mirroring Efficiency): A comprehensive indicator representing the overall effect of the Bluetooth screen mirroring solution, the higher the better. It combines the richness of the screen mirroring content, transmission efficiency, meter-side processing efficiency, and user experience (smoothness, stability).

[0090] C_Content (Complexity and Value of Screen Mirroring Content):

[0091] Definition: Refers to the complexity of the original content that needs to be screen mirrored on the mobile phone side (e.g., static image vs. dynamic navigation vs. simple animation) and the immediate value of this content to the user.

[0092] Influence: The more complex or valuable the content, the greater the contribution to the "numerator" of the screen mirroring efficiency, but it also poses higher requirements for subsequent processing and transmission.

[0093] Parameter Examples (Qualitative or Quantitative): Content type (static = 1, simple dynamic = 2, complex dynamic = 3), information density, change frequency.

[0094] Q_Encoding (Adaptive Encoding Quality and Compression Ratio):

[0095] Definition: Measures the effect of the "adaptive content preprocessing and context encoding module" on the mobile phone side. It represents the balance between the information retention degree and data compression degree after encoding the original content while meeting the meter capabilities.

[0096] Influence: The higher the encoding quality (less information loss) and the higher the compression ratio (smaller data volume), the greater the contribution to the screen mirroring efficiency.

[0097] Parameter Examples:

[0098] Compression Ratio: Original data size / Encoded data size.

[0099] Information Fidelity: Visual similarity to the original image (e.g., PSNR, but more focused on key information rather than pixel-level perfection), or the accuracy of the instruction stream in expressing the original semantics.

[0100] Instruction Rate: The proportion of original pixels successfully converted into primitive instructions.

[0101] B_BandwidthOccupancy (Actual Bluetooth Bandwidth Occupancy Rate):

[0102] Definition: Refers to the percentage or absolute rate of the actual bandwidth occupied by the encoded data stream in the Bluetooth channel.

[0103] Impact: The lower the occupancy rate, the higher the transmission efficiency and the smaller the negative impact on the overall performance (as the denominator).

[0104] Parameter examples: Average data transmission rate (kbps), peak data transmission rate, proportion of valid data packets transmitted per unit time.

[0105] P_ Instrument Load (Instrument-side Processing Load):

[0106] Definition: Refers to the CPU occupancy rate, memory consumption, etc. generated when the instrument MCU parses and renders the received data stream.

[0107] Impact: The lower the load, the higher the instrument processing efficiency and the smaller the negative impact on the overall performance (as the denominator).

[0108] Parameter examples: Average instrument CPU occupancy rate (%), peak CPU occupancy rate, peak memory occupancy (KB), average time to render one frame (ms).

[0109] S_ Synchronization (Communication and Display Synchronization Quality):

[0110] Definition: Measures the effect of the "Bluetooth Communication Optimization and Quasi-Symbol-Level Synchronization Mechanism" and represents the timing consistency and smoothness between the mobile phone transmission and the instrument display.

[0111] Impact: The higher the synchronization quality, the smoother the user experience and the higher the overall performance (as a multiplicative factor).

[0112] Parameter examples:

[0113] Average frame delay: The average time from when the mobile phone sends a frame to when the instrument displays the frame.

[0114] Frame jitter: The degree of change in frame delay.

[0115] Frame loss rate: The proportion of frames lost at the instrument side due to timeouts or inability to process in time.

[0116] Success rate of application layer data packet confirmation.

[0117] A_ Adaptation (Instrument Capability Adaptation Degree):

[0118] Definition: Measures the effectiveness of the "Intelligent Broadcasting and Discovery Mechanism of Instrument-Side Capability Profiles" and the matching degree of encoding on the mobile phone side according to this configuration.

[0119] Impact: The higher the adaptation degree, the more the data sent by the mobile phone conforms to the capabilities of the instrument, the smoother the operation of the entire system, and the higher the overall performance (as a multiplicative factor).

[0120] Parameter examples:

[0121] Capability matching score: The degree of matching between the encoding strategy selected by the mobile phone and the optimal capability configuration of the instrument broadcast (e.g., whether the instruction set supported by the instrument is fully utilized, whether the refresh rate limit is exceeded, etc.).

[0122] Dynamic configuration update response time: The time for the mobile phone to sense and adjust the strategy if the instrument capabilities change.

[0123] Interpretation and meaning of the formula:

[0124] Core efficiency numerator (C_content × Q_encoding): Represents "what you want to project and how well you prepare it". The more valuable the content and the better the encoding (retaining information while significantly compressing), the higher the theoretical projection value.

[0125] Core cost denominator (B_bandwidth occupancy × P_instrument load): Represents "the cost of achieving this projection". The greater the Bluetooth bandwidth occupancy and the more difficult the instrument processing, the more the actual efficiency will be discounted.

[0126] Experience and matching factor (S_sync × A_adaptation): Represents "whether the whole process is smooth and well-matched". Good synchronization ensures the viewing experience, and high adaptability ensures that the system will not have problems due to mismatched capabilities. These two factors directly affect the final effect perceived by the user.

[0127] It does not simply evaluate a single technical point, but attempts to integrate the contributions of multiple interrelated technical modules into a framework. It introduces relatively abstract but crucial factors for the final effect such as "content complexity and value", "encoding quality and compression ratio", "synchronization quality", "adaptability", etc., and tries to give examples of observable or indirectly evaluable parameters. And through the relationship between multiplication and division, it reflects the positive or negative impact of different factors on the overall efficiency, as well as the restrictive relationship between them (e.g., high-quality encoding can reduce bandwidth occupancy and instrument load).

[0128] This "formula" can be used in the following situations:

[0129] Design goal: When designing and optimizing the system, the goal is to maximize the numerator, minimize the denominator, and optimize the synchronization and adaptation factors.

[0130] Performance bottleneck analysis: If the E_projection is not ideal, by analyzing each component in the formula, it is possible to locate whether it is a content encoding problem, a bandwidth problem, an instrument processing bottleneck, or a synchronization / adaptation issue.

[0131] Trade-off decisions: For example, to support more complex content (increase C_content), a stronger encoding algorithm (increase Q_encoding) may be required, but this may increase the processing time on the mobile device slightly. Or, for extremely low instrument load (reduce P_instrument load), some compromises may need to be made in the encoding quality (Q_encoding).

[0132] See Figure 8 , Figure 8 is a schematic flowchart of an embodiment of the instrument display method based on in-vehicle Bluetooth screen mirroring provided by this application. Applied to the instrument display system 100 of this application, the method includes:

[0133] Step 81: The instrument side broadcasts its capability profile via Bluetooth; the capability profile includes display capability data and processing limit data.

[0134] Step 82: After receiving the capability profile, the mobile device preprocesses and contextually encodes the content to be screen-mirrored according to the display capability data and processing limit data to obtain data packets.

[0135] Step 83: After receiving the data packets, the instrument side performs data stream parsing and direct rendering display.

[0136] In an application scenario, the user uses the navigation App on the mobile device and selects to screen-mirror to the vehicle instrument.

[0137] The instrument side broadcasts its display capability profile in the "navigation mode" via BLE (e.g., 320x240 resolution, 16-bit color depth, supports rectangle / line / text commands, supports palette A, maximum refresh rate 15fps).

[0138] The mobile device connects to the instrument side and obtains this profile.

[0139] The mobile navigation App obtains the current navigation view (map, route, turning arrow, road name text).

[0140] The adaptive content preprocessing module on the mobile device performs the following processes:

[0141] Quantize the color of the map background and perform RLE compression according to the instrument resolution and palette A.

[0142] Convert the route line into a series of "draw line" commands.

[0143] Convert the turning arrow (if it is a vector) into a "draw polygon" command or a small indexed bitmap.

[0144] Convert the road name text into a "draw text" command (using the instrument's preset font or transmitting a small font pattern).

[0145] Encapsulated into a data packet, which contains initial map data and a series of drawing instructions.

[0146] The data packet is sent to the instrument via Bluetooth.

[0147] The lightweight parsing and rendering module on the instrument side performs the following processes: parse the data packet, first draw the RLE-compressed map background. Then sequentially execute the instructions of "drawing lines", "drawing polygons / bitmaps", and "drawing text" to synthesize a complete picture in the frame buffer.

[0148] When the navigation map scrolls or the path is updated, the mobile phone calculates the difference from the previous frame: only send the pixel data of the changed area (optimized according to palette A) or the updated primitive instructions (such as new text, lines). The instrument side receives the differential data packet and only updates the corresponding part of the frame buffer.

[0149] The instrument side refreshes the display at a rate of 15fps.

[0150] Through the above solution, even on low-cost instruments, a relatively smooth and clear Bluetooth navigation screen projection can be achieved.

[0151] In summary, the present application has the following beneficial effects:

[0152] The broadcast and maintenance module 10 on the instrument side can lay the foundation for "customization on demand".

[0153] Problems to be solved: The lack of adaptability, the problem of the mobile phone "blindly" projecting the screen.

[0154] Serve the whole through the following ways:

[0155] For example, information symmetry: By the instrument actively broadcasting its display capabilities (resolution, color depth, supported instruction set, refresh rate, etc.) and processing limitations (buffer size, processing level, etc.), the mobile phone can "know itself and the enemy" before or at the beginning of the connection. This breaks the unknown state of the mobile phone about the capabilities of the receiving end in traditional screen projection.

[0156] For example, decision-making basis: After the mobile phone obtains these capability parameters, it has clear optimization goals and constraint conditions. It knows what format the content should be converted into, what data volume, and what refresh rate so that the instrument can "handle it" and "display it well".

[0157] For example, personalized service: If the instrument supports multiple working modes (such as broadcasting different profile IDs through the CPBIS idea), the mobile phone can select the most matching instrument capability mode for connection and screen projection according to the requirements of the current screen projection content (for example, navigation requires paths and text, and video requires smooth pixel updates).

[0158] In short, this step is the "scout", which provides crucial intelligence for subsequent "precision strikes" (content preprocessing) and "efficient transportation" (communication optimization). Without this step, subsequent optimizations would be aimless.

[0159] The mobile device adaptive content preprocessing and context encoding module 20 can achieve the core of "lightweight transmission" and "instrument burden reduction".

[0160] Problems to be solved: Bluetooth bandwidth bottleneck and weak processing ability of the instrument side.

[0161] Serve the whole through the following means:

[0162] For example, capacity configuration: This step directly utilizes the instrument capacity configuration file obtained in the previous step. The preprocessing and context encoding of the mobile phone are completely carried out around the specific capabilities of the instrument. For example, if the instrument only supports 16 colors and specific drawing instructions, the mobile phone will convert a 24-bit true color complex image into a 16-color indexed image and try to extract the graphic elements that can be described by these instructions.

[0163] For example, significant data compression: Through means such as color quantization, graphic element extraction and instructionization, and differential encoding, the original pixel-level image data is converted into an "instruction stream" or "differential data packet" with stronger semantics and smaller data volume. This directly alleviates the Bluetooth bandwidth pressure. Instead of transmitting "heavy" original pixels, "lightweight" descriptive information or change amounts are transmitted.

[0164] For example, extremely simple decoding on the instrument side: Since the data has been "tailored" for the instrument, almost no complex decoding operations are required after the instrument side receives it. Parsing the instruction stream (such as drawing lines, drawing rectangles) or applying differential data (updating specific pixel areas) is a low-load operation for a low-cost MCU. This solves the core problem of the weak processing ability of the instrument.

[0165] For example, dynamic content processing: Through differential encoding and key frame mechanisms, dynamic content such as navigation map scrolling and UI element changes can be effectively processed, rather than simply transmitting static pictures one by one, improving the display effect of dynamic content.

[0166] In short, this step is the "central kitchen", which carefully cooks the "complex ingredients (original screen content)" into "easy-to-digest and nutritious (lightweight and easy to parse)" "dishes (instruction stream / differential packet)" according to the "taste and digestion ability (capacity configuration)" of the "diners (instrument side)".

[0167] The Bluetooth communication optimization and synchronization mechanism module 40 can ensure the "stable and smooth" last mile.

[0168] Problems to be solved: The problems of the reliability and real-time performance of Bluetooth transmission, and the smoothness of dynamic content display.

[0169] Serve the whole in the following ways:

[0170] For example, efficient and reliable transmission: Through mechanisms such as dynamic negotiation of BLE connection parameters, application layer packet fragmentation, selective acknowledgment and retransmission, etc., it is ensured that the lightweight data carefully encoded by the mobile phone can be stably and efficiently delivered to the instrument. This guarantees that the achievements of the first two optimizations can be successfully implemented.

[0171] For example, avoiding instrument overload: Based on the flow control mechanism of the instrument buffer, it prevents the mobile phone from sending data too fast, resulting in buffer overflow of the instrument, thus avoiding jams or even crashes and ensuring the stability of the system.

[0172] For example, smooth visual experience: The frame pacing and timestamp mechanisms enable the mobile phone to control the rhythm of data sending, and the instrument can also calibrate the rendering clock according to the timestamp. This ensures that even in the case of certain jitter in the wireless channel, the instrument can display dynamic images as smoothly and synchronously as possible, improving the final user experience.

[0173] In short, this step is the "intelligent logistics system", which ensures that the "dishes" prepared by the "central kitchen" can be delivered to the "diners" on time, intact, and in rhythm, and will not choke the "diners".

[0174] The overall logical closed loop is as follows:

[0175] The instrument side "states" what it can do (ability broadcast).

[0176] The mobile phone side "understands" and "prepares" the most suitable content as needed (adaptive preprocessing and encoding).

[0177] The mobile phone side then "smoothly" sends the content to the instrument side through the "optimized" channel (communication optimization and synchronization).

[0178] In summary, the instrument display system 100 and the instrument display method provided by this application can efficiently transmit the dynamic screen content (especially navigation, multimedia, etc.) of the mobile phone side to the resource-constrained vehicle instrument system under the limited bandwidth of Bluetooth, and can minimize the decoding and rendering complexity of the instrument side for the received projection data, enabling it to be smoothly displayed on a low-cost MCU, and establishing a dynamic capability negotiation mechanism between the mobile phone and the instrument, enabling the mobile phone to adaptively optimize the format and data volume of the projection content according to the actual display capabilities and processing limitations of the instrument side, and can improve the compatibility and user experience of the Bluetooth projection solution, making it adaptable to instruments with different performances and different types of projection content.

[0179] In several embodiments provided in the present application, it should be understood that the disclosed methods and devices can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For example, the division of the modules or units is only a logical function division. In actual implementation, there may be other division methods. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed.

[0180] If the integrated unit in the above other embodiments is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) or a processor (prcessr) to execute all or part of the steps of the methods described in various embodiments of the present application. The foregoing storage medium includes: various media such as USB flash drives, mobile hard disks, read-only memories (ROM, Read-Only Memory), random access memories (RAM, Random Access Memory), magnetic disks, or optical discs that can store program codes.

[0181] The above are only the embodiments of the present application, and do not limit the patent scope of the present application. Any equivalent structure or equivalent process transformation made by using the content of the specification and drawings of the present application, or directly or indirectly applied in other related technical fields, shall be equally included in the patent protection scope of the present application.

Claims

1. An instrument display system based on in-vehicle Bluetooth screen mirroring, characterized in that The instrument display system includes: An instrument - side broadcast and maintenance module, which is used to broadcast its capability profile via Bluetooth; the capability profile includes display capability data and processing limit data; A mobile - side adaptive content pre - processing and context encoding module, which is used to pre - process and context - encode the content to be screen - cast according to the display capability data and processing limit data after receiving the capability profile, and obtain data packets; An instrument - side data stream parsing and direct rendering module, which is used to perform data stream parsing and direct rendering display after receiving the data packets.

2. The instrument display system according to claim 1, characterized in that, The instrument - side broadcast and maintenance module includes: A multi - level summary and hierarchical broadcast unit, which is used to use the most core and general capability information of the instrument side as the first - level summary, generate a second - level summary according to the capability profile, and then broadcast the first - level summary and the second - level summary using multiple groups of broadcast events; A dynamic capability broadcast and context awareness unit, which is used to dynamically update the configuration file ID or summary it broadcasts when the display capability of the instrument side changes; A general attribute profile service unit, which is used to send the capability profile to the mobile side after establishing a connection between the mobile side and the instrument side.

3. The instrument display system according to claim 1, characterized in that, The mobile - side adaptive content pre - processing and context encoding module includes: A content awareness and semantic extraction unit, which is used to perform content understanding and semantic extraction on the content to be screen - cast; A dynamic generation and optimization unit of the instruction stream, which is used to dynamically select and combine basic primitive instructions according to the capability profile; A context - adaptive differential update strategy unit, which is used to perform differential update based on the content type, perform differential update based on the differential granularity of the instrument processing ability, and perform intelligent key - frame insertion during the differential update process.

4. The instrument display system according to claim 3, wherein The content awareness and semantic extraction unit is further used to perform navigation path recognition, icon and symbol recognition, and text content extraction and optimization on the content to be screen - cast when performing navigation screen - casting.

5. The instrument display system according to claim 3, characterized in that, The dynamic generation and optimization unit of the instruction stream is further used to dynamically perform instruction selection, parameter optimization, and instruction compression.

6. The instrument display system according to claim 1, wherein, The instrument - side data stream parsing and direct rendering module includes: A data stream parsing engine unit, which is used to call the corresponding parsing logic according to the data packet type identifier, parse primitive instructions, parse palette index data, and parse differential data packets; A rendering and display unit, which is used to directly send the content of the rendered frame buffer to the display controller for display.

7. The instrument display system according to claim 1, wherein The instrument display system further includes: A Bluetooth communication optimization and synchronization mechanism module, which is used to perform dynamic negotiation of Bluetooth connection parameters between the mobile side and the instrument side, as well as perform application - layer data packet fragmentation, confirmation and flow control, and perform frame synchronization and timestamp embedding, and instrument - side synchronization calibration.

8. The instrument display system according to claim 7, wherein, The Bluetooth communication optimization and synchronization mechanism module includes: A dynamic negotiation unit of Bluetooth connection parameters, which is used to dynamically negotiate Bluetooth connection parameters between the mobile side and the instrument side according to the data type to be transmitted and the refresh rate requirement in the instrument capability profile after the initial connection between the mobile side and the instrument side; The application layer data packet fragmentation, confirmation and flow control unit is used to perform intelligent fragmentation according to the atomicity of instructions, and for critical data packets, a confirmation mechanism is set at the application layer; and during operation, the meter end feeds back the occupancy of its buffer to the mobile phone end so that the mobile phone end can adjust the sending rate.

9. The instrument display system according to any one of claims 1-8, characterized in that, The meter display system further includes: An evaluation module for evaluating the overall screen mirroring performance according to the screen mirroring content, encoded data, bandwidth occupancy rate, meter end load, communication and display synchronization quality, and meter capability adaptation degree.

10. An instrument display method based on in-vehicle Bluetooth screen mirroring, characterized in that, Applied to the meter display system according to any one of claims 1-9, the method includes: The meter end broadcasts its capability profile via Bluetooth; the capability profile includes display capability data and processing limit data; After receiving the capability profile, the mobile phone end preprocesses and context-encodes the content to be screen mirrored according to the display capability data and processing limit data to obtain data packets; After receiving the data packets, the meter end performs data stream parsing and direct rendering display.

Images