Catton detection method, cockpit device, medium and product

Abstract

The application discloses a stall detection method, a cockpit device, a medium and a product. The method is executed by a cockpit device with a first WIFI chip and a second WIFI chip. The method comprises the following steps: the first WIFI chip performs wireless communication with a mobile device through a wireless channel; in the case that the wireless communication is stalled, the second WIFI chip listens to at least one wireless frame in the wireless channel, and the wireless frame is used to determine the stall reason. First, since the second WIFI chip is integrated in the cockpit device, it is not necessary for a staff to manually build an external test environment and separately deploy a sniffing auxiliary device. Second, the channel listening and wireless frame collection are started only after the stall fault occurs, so it is not necessary for the device to run a packet capture program for a long time without interruption, the total amount of wireless frame data collection is greatly reduced, and the problem of cyclic coverage of new and old wireless frame data is avoided.

Description

Technical Field

[0001] This application relates to the field of smart cockpit technology, and in particular to a lag detection method, cockpit equipment, medium, and product. Background Technology

[0002] As the intelligent cockpit host in the car's center console, the in-vehicle infotainment system can connect to a mobile phone, projecting and synchronizing the phone's content onto the in-vehicle screen. During wireless communication between the mobile phone and the in-vehicle infotainment system, frequent stuttering issues such as screen delay, audio-visual asynchrony, and frequent disconnections occur, severely impacting the user experience of in-vehicle connectivity.

[0003] In this related technology, staff manually set up a test environment and used auxiliary sniffing equipment to capture wireless sniffing packet capture logs until the lag recurred. The cause of the lag was then analyzed based on the captured wireless sniffing packet capture logs.

[0004] However, due to the low probability of reproducing the lag, the packet capture script needs to be run continuously for a long time. Due to the limited storage capacity of the packet capture file, the old packet capture logs will be continuously overwritten by the new packet capture logs, which makes it easy to lose the critical wireless data when the lag occurs, making it difficult to accurately locate the root cause of the lag and resulting in low troubleshooting efficiency. Summary of the Invention

[0005] This application provides a method for detecting stuttering, a cockpit device, a medium, and a product. The technical solution provided by this application includes the following aspects.

[0006] According to one aspect of the embodiments of this application, a lag detection method is provided, the method being performed by a cockpit device having a first WIFI chip and a second WIFI chip, the method comprising: The first WIFI chip communicates wirelessly with the mobile device via a wireless channel; In the event of a lag in the wireless communication, the second WIFI chip listens to at least one wireless frame in the wireless channel, and the wireless frame is used to determine the cause of the lag.

[0007] According to one aspect of the embodiments of this application, a cockpit device is provided, the cockpit device including a first WIFI chip and a second WIFI chip; The first WIFI chip communicates wirelessly with the mobile device via a wireless channel; In the event of a lag in the wireless communication, the second WIFI chip listens to at least one wireless frame in the wireless channel, and the wireless frame is used to determine the cause of the lag.

[0008] According to one aspect of the embodiments of this application, a computer device is provided, the computer device including a processor and a memory, the memory storing a computer program, the computer program being loaded and executed by the processor to implement the above-described stuttering detection method.

[0009] According to one aspect of the embodiments of this application, a computer-readable storage medium is provided, wherein a computer program is stored in the computer-readable storage medium, the computer program being loaded and executed by a processor to implement the above-described stuttering detection method.

[0010] According to one aspect of the embodiments of this application, a computer program product is provided, the computer program product including a computer program stored in a computer-readable storage medium, and a processor reading from the computer-readable storage medium and executing the computer program to implement the above-described stuttering detection method.

[0011] The technical solution provided in this application can bring the following beneficial effects: The stuttering detection method provided in this application involves controlling a second Wi-Fi chip in the cockpit device to listen to the corresponding wireless channel and collect wireless frames when a stutter occurs in the wireless communication between the first Wi-Fi chip in the cockpit device and the mobile device. Compared with the aforementioned related technologies, firstly, since the second Wi-Fi chip is integrated inside the cockpit device, there is no need for staff to manually build an external test environment or deploy separate sniffing auxiliary equipment, saving manual operation steps such as on-site debugging, wiring, and configuring packet capture scripts, thus reducing the manpower cost and operational threshold for fault diagnosis. Secondly, this application uses event-triggered packet capture, only initiating channel listening and collecting wireless frames after a stuttering fault occurs, eliminating the need for the device to run the packet capture program continuously for a long time, significantly reducing the total amount of wireless frame data collected, avoiding the problem of a large number of logs continuously occupying storage space and the problem of new and old logs being overwritten cyclically, and ensuring that the key interactive wireless frames corresponding to the moment of stuttering are completely retained, thus preventing the loss of key data due to stuttering from the root cause. Attached Figure Description

[0012] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0013] Figure 1 This illustration shows an application scenario diagram of the stuttering detection method provided by an exemplary embodiment of this application; Figure 2 A flowchart of a stuttering detection method provided in an exemplary embodiment of this application is shown; Figure 3 A flowchart of a stuttering detection method provided in an exemplary embodiment of this application is shown; Figure 4 A flowchart of a stuttering detection method provided in an exemplary embodiment of this application is shown; Figure 5 An analysis diagram of the causes of stuttering provided in an exemplary embodiment of this application is shown; Figure 6 A schematic diagram of the architecture of a stuttering detection system provided in an exemplary embodiment of this application is shown; Figure 7 A structural block diagram of a cockpit device provided in an exemplary embodiment of this application is shown; Figure 8 A structural block diagram of a computer device provided in an exemplary embodiment of this application is shown. Detailed Implementation

[0014] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0015] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0016] The terminology used in this application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. The singular forms “a,” “the,” and “the” used in this application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any and all possible combinations of one or more of the associated listed items.

[0017] It should be understood that although the terms first, second, etc., may be used in this application to describe various information, this information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of this application, a first parameter may also be referred to as a second parameter, and similarly, a second parameter may also be referred to as a first parameter. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to determination."

[0018] It should be noted that this application may display prompts, pop-ups, or output voice messages before and during the collection of user data. These prompts, pop-ups, or voice messages are used to inform the user that their data is being collected. This ensures that the application only begins the steps for collecting user data after receiving confirmation from the user regarding the prompt or pop-up; otherwise (i.e., without user confirmation), the steps for collecting user data end, meaning no user data is collected. In other words, all user data collected in this application is collected with the user's consent and authorization, and the collection, use, and processing of this user data must comply with the relevant laws, regulations, and standards of the relevant countries and regions.

[0019] First, let me introduce the relevant terms and concepts used in this application: Short-range communication refers to a communication method that transmits data over a relatively short distance. When the distance between electronic devices is less than a certain range, they can communicate using short-range communication. Examples of short-range communication methods include Bluetooth, NFC (Near Field Communication), and Wi-Fi (Wireless Fidelity). In this application, short-range communication may also be referred to as near-field communication or short-range communication.

[0020] Wireless Fidelity (WIFI) connection methods include WIFI station (sta) and WIFI P2P (peer) connections. to Peer (point-to-point) mode. Specifically, the Wi-Fi Station mode refers to electronic devices establishing Wi-Fi connections with other devices through an Access Point (AP), i.e., conducting Wi-Fi communication. The electronic device acts as a station. In other words, in this Wi-Fi station mode, all communication between electronic devices needs to be forwarded through the AP. The Wi-Fi P2P mode refers to multiple electronic devices communicating directly point-to-point using Wi-Fi technology, forming a P2P network (also called a P2P group, which includes a group owner and at least one group client). The group owner can be understood as equivalent to the aforementioned wireless access point (or router), and the group client as equivalent to the aforementioned station.

[0021] Figure 1This illustration shows an application scenario diagram of the stuttering detection method provided in an exemplary embodiment of this application. The application scenario includes: a cockpit device 110 and a mobile device 120.

[0022] Cockpit device 110 is a terminal device fixedly installed inside the cockpit, while mobile device 120 is an external device carried by the user. Cockpit device 110 can wirelessly connect to mobile device 120 via short-range communication, enabling device interaction. For example, both cockpit device 110 and mobile device 120 are terminal devices supporting screen mirroring protocols; the screen display content of mobile device 120 can be mirrored to the display screen of cockpit device 110. Figure 1 As shown, the content displayed on the screen of mobile device 120 is synchronously displayed on the display screen of cockpit device 110; for example, video and / or audio from video and music applications on mobile device 120 can be synchronously played on cockpit device 110; furthermore, control of applications such as maps, phone calls, text messages, and music on mobile device 120 can be transferred to cockpit device 110, supporting the control of applications on mobile device 120 through cockpit device 110, such as searching maps, making calls, sending text messages, turning music on / off / switching, etc. Simultaneously, cockpit device 110 can also provide hotspot services for mobile device 120.

[0023] In practice, the cockpit equipment 110 can be multimedia and network-connected electronic devices inside various manned work cabins. Taking a vehicle as an example, the cockpit equipment 110 can be an in-vehicle central control entertainment host, in-vehicle instrument panel, AR-HUD (Augmented Reality Head-Up Display), rear-seat entertainment display screen, in-vehicle T-BOX (Telematics Box), and other electronic devices. The mobile device 120 can be a smartphone, tablet computer, PC (Personal Computer), game console, and other electronic devices.

[0024] Figure 2 A flowchart illustrating a stuttering detection method provided in an exemplary embodiment of this application is shown. The method is performed by a cockpit device having a first Wi-Fi chip and a second Wi-Fi chip, and includes: Step 220: The first WIFI chip communicates wirelessly with the mobile device through the wireless channel.

[0025] In this embodiment, the cockpit device includes two Wi-Fi chips: a first Wi-Fi chip and a second Wi-Fi chip. The first Wi-Fi chip, as the main chip, is used to establish wireless communication with the mobile device, enabling interaction between the cockpit device and the mobile device. This includes projecting the navigation application interface of the mobile device onto the cockpit device's display screen, or playing music from the mobile device via Bluetooth speakers in the cockpit device. The second Wi-Fi chip, as an auxiliary chip, is used to implement other auxiliary functions. Here, the Wi-Fi chip refers to a wireless network card chip or a WLAN (Wireless Local Area Network) chip, which is a semiconductor device responsible for implementing Wi-Fi wireless communication functions.

[0026] Below is a brief introduction to the composition and working principle of a WIFI chip.

[0027] A Wi-Fi chip consists of a radio frequency (RF) front-end, a baseband processor, a MAC (Media Access Control) layer controller, memory, and interfaces. The RF front-end processes analog wireless signals, including power amplification and filtering. The baseband processor processes data signals, such as error correction coding and encryption / decryption. The MAC layer controller manages the Wi-Fi protocol, determining when data transmission occurs and how to handle network conflicts. The memory and interfaces buffer data and connect to electronic devices via interfaces such as USB (Universal Serial Bus), PCIe (Peripheral Component Interconnect Express), and SDIO (Secure Digital Input / Output).

[0028] The communication capabilities of a Wi-Fi chip are primarily determined by the underlying protocols it supports and the operating channel. The underlying protocols determine data transmission speed and performance, while the operating channel determines the signal frequency band and interference resistance. The Wi-Fi chip supports the IEEE (Institute of Electrical and Electronics Engineers) 802.11 protocol, including 802.11b / g, 802.11a, 802.11n (Wi-Fi 4), 802.11ac (Wi-Fi 5), 802.11ax (Wi-Fi 6 / 6E), and 802.11be (Wi-Fi 7). The Wi-Fi chip encapsulates service data according to the data structure specified by the IEEE 802.11 protocol, resulting in a wireless frame containing a frame header, QoS (Quality of Service) control field, payload, and checksum. The Wi-Fi chip operates in the 2.4GHz, 5GHz, and 6GHz unlicensed frequency bands.

[0029] In one optional implementation, the first WIFI chip built into the cockpit device is configured to work in wireless access point mode, broadcasting wireless network signals on a factory-preset wireless channel. Mobile devices (such as mobile phones, tablets, etc.) search for, authenticate, and access the wireless network in WIFI site STA mode. The first WIFI chip and the mobile device complete the transmission and reception of IEEE 802.11 wireless frames through the wireless channel corresponding to the wireless network to carry various wireless service data transmissions such as screen projection audio and video, device control, and data interaction.

[0030] For example, the first Wi-Fi chip in the cockpit equipment is factory-configured to use the 5GHz 36 channel, which is the standardized channel number 36 in the 5GHz band. Data transmitted by the cockpit equipment and mobile devices is packaged and encoded into digital wireless frames by their respective Wi-Fi chips based on their supported IEEE 802.11 MAC protocol. These frames are then modulated to obtain analog wireless signals. Subsequently, the analog wireless signals are transmitted via the antenna in the Wi-Fi chip onto the radio frequency spectrum corresponding to the 5GHz 36 wireless channel.

[0031] The working principle of a WIFI chip is to bidirectionally convert, send, and receive digital signals from electronic devices and wireless analog signals transmitted over the air.

[0032] For example, taking the establishment of a Wi-Fi screen mirroring connection between the cockpit device and a mobile device as an example, the process of bidirectional signal conversion, transmission, and reception between the first Wi-Fi chip in the cockpit device and the mobile device is explained: When a mobile device transmits screen-projection audio and video data to the cockpit device, the processor in the mobile device generates screen-projection related service data. The mobile device's built-in Wi-Fi chip encapsulates and encodes the service data to obtain wireless frames as digital signals. The Wi-Fi chip then modulates the wireless frames to obtain high-frequency wireless analog signals, which are then transmitted via the antenna in the Wi-Fi chip to the radio frequency spectrum corresponding to the wireless channel. The first Wi-Fi chip in the cockpit device captures the airborne wireless analog signals with the aid of its matching antenna, demodulates and decodes the wireless analog signals to restore the original screen-projection service data, and transmits the service data to the cockpit device's display screen for image decoding and display output.

[0033] When the cockpit device sends navigation and control commands to the mobile device, the process is executed in reverse: the cockpit device generates service data, which is encapsulated and encoded by the first WIFI chip to obtain a wireless frame as a data signal. The wireless frame is then modulated to obtain a wireless analog signal, which is transmitted to the radio frequency spectrum corresponding to the wireless channel. The WIFI chip in the mobile device receives the wireless analog signal, demodulates it to recover a digital signal, and then decodes the digital signal to recover the service data, which is then handed over to the mobile device to perform the corresponding screen projection control operation.

[0034] Step 240: If there is a lag in the wireless communication between the first WIFI chip and the mobile device, the second WIFI chip listens to at least one wireless frame in the wireless channel, and the wireless frame is used to determine the cause of the lag.

[0035] In this embodiment of the application, when the wireless communication between the first WIFI chip and the mobile device experiences a stutter, the intuitive manifestations to the user at the application layer include at least one of the following: dropped frames in the screen projection, screen delay and ghosting, audio and video asynchrony, delayed response of the cockpit screen after swiping the mobile phone interface, frequent buffering when playing videos, static or repeated screen tearing, slow updates of navigation information, significant delay in turning prompts or road condition map refresh, stuttering when the mobile device and the cockpit device exchange control commands or address messages, delay in the execution of interactive operations such as changing songs on the steering wheel and answering calls, or even short-term disconnection leading to screen projection application crashes and multimedia playback interruptions.

[0036] In some embodiments, when a user perceives a lag in the interaction between the mobile device and the cockpit device (such as screen mirroring lag), the user can report a lag trigger command. Upon receiving the lag trigger command, the cockpit device immediately switches the operating mode of the second Wi-Fi chip to Monitor mode to lock the wireless channel of the first Wi-Fi chip and capture the wireless frames at the moment of lag. The implementation methods for the user to report the lag trigger command include one or more of the following: The first method involves installing a physical button in the cockpit equipment for "lag feedback" or "lag report". Users can submit lag feedback by triggering this physical button.

[0037] The second type includes a client in the mobile device for interacting with the cockpit equipment. The client interface displays a "lag feedback" or "lag report" control. Users can submit lag feedback by clicking the "lag feedback" or "lag report" control.

[0038] The third method involves pre-setting keywords in the voice assistant of the cockpit device, such as "screen mirroring lag" or "the screen is frozen," which indicate lag. When the user speaks the lag keyword, they can submit feedback about the lag.

[0039] The three methods mentioned above for users to report lag are merely examples, and this application embodiment does not impose any limitations on them.

[0040] In this embodiment, the first WIFI chip and the mobile device transmit interactive data based on a designated wireless channel. The root cause of the lag in their wireless communication lies in transmission anomalies during wireless channel transmission. These anomalies include external radio frequency interference; other nearby WIFI devices occupying the same frequency channel; channel contention caused by concurrent access of multiple terminal devices, leading to RTS (Request To Send) frames, handshake failures, and data frame loss; the sending end repeatedly failing to receive ACK (Acknowledgment) frames, continuously triggering data retransmission and significantly increasing transmission latency; wireless signal propagation obstruction and excessive device distance causing signal strength attenuation; and increased modulation / demodulation error probability leading to wireless frame transmission and reception delays. Therefore, when lag occurs, monitoring the wireless channel to obtain monitoring data, followed by detailed analysis of this data, can determine the cause of the lag.

[0041] In this embodiment of the application, considering that during the process of the first WIFI chip communicating wirelessly with the mobile device through the wireless channel, the first WIFI chip cannot synchronously capture wireless frames for the following reasons.

[0042] Reason 1: Single-RF hardware can only lock onto a single working mode at any given time. When the first WIFI chip acts as an AP access point, the RF circuit focuses on data transmission and reception. The hardware does not support switching to a listening mode for the wireless channel at the same time. The two modes share the same antenna, RF front-end and baseband processing unit, and cannot work in parallel.

[0043] The second reason is that the channel scheduling logic of the underlying firmware of the first WIFI chip is an exclusive design. During normal business communication, all the computing power of the baseband processor is used for wireless frame encapsulation, modulation and demodulation, response and retransmission processing, without reserving independent computing power or buffer channels to continuously capture all wireless frames in the wireless channel.

[0044] Therefore, in this embodiment of the application, when the wireless communication between the first WIFI chip and the mobile device is interrupted, a second WIFI chip in the cockpit device, which is independent of the first WIFI chip in terms of hardware path, radio frequency front-end and baseband processing unit, is used to monitor the wireless channel through which the first WIFI chip and the mobile device communicate, so as to obtain at least one wireless frame in the wireless channel. Subsequent wireless frames are used to determine the cause of the interruption.

[0045] In this way, the first Wi-Fi chip is dedicated to interacting with mobile devices. When a lag is detected in the wireless communication, the second Wi-Fi chip is triggered to monitor the wireless channel. The computing power and radio frequency resources for packet capture and frame parsing are entirely carried out by the second Wi-Fi chip. This will not preempt the processing resources of the first Wi-Fi chip used for sending and receiving data for device interaction. This avoids the first Wi-Fi chip's monitoring and packet capture operations from exacerbating the screen projection lag and ensures that the user's basic interconnection experience is not affected by the lag detection function.

[0046] For example, if the first Wi-Fi chip in the cockpit equipment and the mobile device communicate wirelessly via the 5GHz 36 channel, then the second Wi-Fi chip in the cockpit equipment can be used to monitor the 5GHz 36 channel, entering a "listen-only" monitoring mode. Specifically, the radio frequency receiver of the second Wi-Fi chip is switched to the 5GHz 36 channel and enabled in monitoring mode, and it supports the corresponding 802.11 protocol standard, enabling it to capture most of the air interface wireless frames generated by the interaction between the first Wi-Fi chip and the mobile device within the 5GHz 36 channel.

[0047] It is important to emphasize that the second Wi-Fi chip in monitoring mode can bypass the MAC address filtering mechanism of the first Wi-Fi chip and completely capture all raw 802.11 air interface frames within the wireless channel, including Beacon frames, Probe frames, authentication / association request and response frames, service data frames, and ACK confirmation frames. In other words, the second Wi-Fi chip can monitor and capture any wireless frame appearing within this wireless channel. Only due to objective factors such as signal obstruction, channel interference, or chip buffer limitations, a small number of frames may be lost, preventing the second Wi-Fi chip from monitoring and capturing these lost frames.

[0048] The stuttering detection method provided in this application, when a stutter occurs in the wireless communication between the first WIFI chip in the cockpit device and the mobile device, controls the second WIFI chip in the cockpit device to listen to the corresponding wireless channel and collect wireless frames. Compared with the above-mentioned related technologies, firstly, since the second WIFI chip is integrated inside the cockpit device, there is no need for staff to manually build an external test environment or deploy a separate sniffing auxiliary device, saving manual operation steps such as on-site debugging, wiring, and configuring packet capture scripts, thus reducing the manpower cost and operational threshold of fault diagnosis. Secondly, this application uses event-triggered packet capture, only activating the second WIFI chip to listen to the wireless channel and collect wireless frames after a stuttering fault occurs. This eliminates the need for the device to run the packet capture program continuously for a long time, significantly reducing the total amount of wireless frame data collected, avoiding the problem of a large number of logs continuously occupying storage space and the problem of new and old logs being overwritten. The key interactive wireless frames corresponding to the moment the stutter occurs can be completely retained, preventing the loss of key data due to stuttering from the root cause.

[0049] Figure 3 A flowchart illustrating a stuttering detection method provided in an exemplary embodiment of this application is shown. The method is performed by a cockpit device having a first Wi-Fi chip and a second Wi-Fi chip, and includes the following steps.

[0050] Step 310: The first WIFI chip communicates wirelessly with the mobile device through the wireless channel.

[0051] In some embodiments, the cockpit device is equipped with two Wi-Fi chips. The first Wi-Fi chip is used for screen mirroring from mobile devices to the cockpit device for device interaction, and the second Wi-Fi chip is used to provide hotspot services to mobile devices.

[0052] In some embodiments, if wireless communication between the first Wi-Fi chip in the cockpit equipment and the mobile device is interrupted, the second Wi-Fi chip first saves the current hotspot service operation status, switches its working mode to pause the hotspot service, and enters the monitoring mode to perform wireless frame acquisition; or it adopts a hardware resource time-sharing scheduling method, with the hotspot service and monitoring mode running concurrently. After the wireless frame data acquisition task is completed and the preset acquisition end condition is met, the second Wi-Fi chip exits the monitoring mode and restores the hotspot function according to the pre-saved hotspot status.

[0053] In this embodiment, the existing second Wi-Fi chip in the cockpit equipment is directly reused to monitor the wireless channel. This chip is pre-installed at the factory and originally only performed hotspot distribution. No redesign or addition of RF, baseband, or antenna hardware is required, and the device's motherboard layout does not need to be modified, significantly reducing the overall hardware modification cost and product development cycle. Furthermore, the original second Wi-Fi chip only had a single hotspot service function, leaving its computing power and RF capabilities idle for a long time. This application reuses its RF path to monitor the wireless channel when lag occurs, without eliminating its basic hotspot function. A single chip simultaneously supports both hotspot distribution and wireless frame capture, maximizing the utilization of the dual Wi-Fi chips and improving hardware utilization.

[0054] Step 320: The first WIFI chip acquires connection quality data between the mobile device and the first WIFI chip.

[0055] In some embodiments, the parameters that the first WIFI chip acquires to reflect the connection quality between the mobile device and the first WIFI chip include at least one of the following: PLR (Packet Loss Rate), RTT (Round Trip Time), and RSSI (Received Signal Strength Indicator).

[0056] The packet loss rate is used to characterize the proportion of data packets lost during transmission out of the total number of data packets sent. A higher packet loss rate indicates more frequent data corruption and loss during transmission, potentially leading to issues such as dropped frames, stuttering, and audio-visual desynchronization in upper-layer services. Therefore, the packet loss rate provides a direct and quantitative reflection of the transmission stability and connection quality of the current wireless communication link.

[0057] End-to-end round-trip time (RTT) characterizes the total time it takes for a data packet to travel from the sender to the receiver, and then back to the sender via an acknowledgment packet. Higher RTT indicates more severe channel congestion and transmission bottlenecks, leading to stuttering issues in upper-layer screen mirroring services, such as delayed visuals, slow operation response, and audio-visual asynchrony. Therefore, RTT provides a direct and quantitative reflection of the transmission stability and connection quality of the current wireless communication link.

[0058] The received signal strength is used to characterize the strength of the analog wireless signal received by the Wi-Fi chip's antenna. A lower value indicates more severe signal attenuation, which can easily lead to frame loss and thus trigger stuttering during screen mirroring. Therefore, the received signal strength can intuitively and quantitatively reflect the transmission stability and connection quality of the current wireless communication link.

[0059] Step 330: The first WIFI chip identifies a lag in wireless communication between the first WIFI chip and the mobile device based on the connection quality data.

[0060] In some embodiments, the first WIFI chip determines whether the connection quality data is abnormal based on the connection quality data. If it is abnormal, it determines that the wireless communication between the first WIFI chip and the mobile device is interrupted.

[0061] In some embodiments, abnormal connection quality data includes at least one of the following: a data packet loss rate greater than a preset packet loss rate threshold, an end-to-end round-trip delay greater than a preset delay threshold, or a received signal strength less than a preset signal strength threshold. The presence of one or more of these conditions indicates abnormal connection quality data, meaning that the wireless communication link between the mobile device and the first Wi-Fi chip is abnormal.

[0062] For example, with a preset packet loss rate threshold of 10%, when the packet loss rate of Transmission Control Protocol (TCP) data packets between the mobile device and the cockpit device exceeds 10% within a 5-second window, the connection quality data is judged to be abnormal.

[0063] Among them, TCP packets are data units encapsulated in accordance with the Transmission Control Protocol. They carry business data such as screen projection audio and video, and interactive commands inside, and are covered by a TCP header, which contains transmission control information such as port, sequence number, RTT timer, and retransmission control.

[0064] For example, with a preset delay threshold of 200ms, when the end-to-end round-trip delay of TCP packets between the mobile device and the cockpit device is greater than 200ms, the connection quality data is determined to be abnormal.

[0065] For example, with a preset signal strength threshold of -70dBm, when the real-time RSSI of the cockpit equipment or mobile device is continuously lower than -70dBm, the connection quality data is determined to be abnormal.

[0066] In this embodiment, when the first Wi-Fi chip detects that any connection quality data such as RSSI, PLR, or RTT exceeds the corresponding threshold and becomes abnormal, it immediately determines that the wireless communication between the first Wi-Fi chip and the mobile device is experiencing a lag. This determination logic is simple and has a fast response speed, enabling it to detect the degradation of the wireless communication link connection quality in the first instance. This is suitable for sudden communication failures such as instantaneous strong interference and sudden signal drops. Once such a failure occurs, it will immediately cause the projected screen to lag without a buffer transition process. The real-time determination mechanism can accurately match sudden lag scenarios.

[0067] In some embodiments, the first Wi-Fi chip determines whether the connection quality data is abnormal based on the connection quality data. If the connection quality data is abnormal and the duration of the abnormality exceeds a preset duration threshold, it is determined that the wireless communication between the first Wi-Fi chip and the mobile device is interrupted.

[0068] In this embodiment, an abnormal duration verification logic is added. Wireless communication is only considered to have stuttered if the connection quality data is abnormal and the abnormal state persists for more than a preset duration threshold. This filters out false triggers caused by momentary channel disturbances and closely aligns with actual user experience. Brief fluctuations in connection quality data are imperceptible to the human eye; only when the wireless communication abnormality persists for a period of time will perceptible faults such as dropped frames, latency, and audio-visual asynchrony occur. Using persistent abnormality as the criterion ensures that subsequent packet capture and stuttering detection actions only target stuttering scenarios that are truly perceptible to the user, improving the effectiveness of stuttering data collection.

[0069] Step 340: In the event of a wireless communication interruption, the second WIFI chip listens to at least one wireless frame in the wireless channel, and the wireless frame is used to determine the cause of the interruption.

[0070] In some embodiments, if a lag occurs in the wireless communication between the first Wi-Fi chip and the mobile device, a lag diagnosis start command is triggered. When the second Wi-Fi chip receives the lag diagnosis start command, the second Wi-Fi chip begins to listen to the wireless channel through which the first Wi-Fi chip communicates with the mobile device to obtain at least one wireless frame in the wireless channel, and then determines the cause of the lag based on the obtained wireless frames.

[0071] Figure 4 A flowchart illustrating a stuttering detection method provided in an exemplary embodiment of this application is shown, the method being performed by a cockpit device having a first Wi-Fi chip and a second Wi-Fi chip. Based on Figure 2 The embodiment shown further includes steps 260-280 after step 240.

[0072] Step 220: The first WIFI chip communicates wirelessly with the mobile device through the wireless channel.

[0073] Step 240: In the event of a lag in the wireless communication between the first WIFI chip and the mobile device, the second WIFI chip listens for at least one wireless frame in the wireless channel.

[0074] Step 260: The second Wi-Fi chip sends the monitored wireless frame data to the server, allowing the server to determine the cause of the lag based on the monitored wireless frame data. And / or, Step 280: The second WIFI chip determines the cause of the lag based on the wireless frame monitoring data and sends the cause of the lag to the server.

[0075] Steps 260 and 280 will be explained below.

[0076] In some embodiments, the second Wi-Fi chip sends the monitored data of the wireless frames to a local or remote server, enabling the server to determine the cause of the lag based on the monitored data. For example, taking a vehicle cockpit device as an example, the second Wi-Fi chip sends the monitored data of the wireless frames to the vehicle manufacturer's backend server, allowing the backend server to determine the cause of the lag based on the monitored data. This eliminates the need for the cockpit device to occupy significant local storage to retain the monitored data, reducing the hardware burden on the cockpit device.

[0077] In some embodiments, after the second Wi-Fi chip captures the listening data of wireless frames, it determines the cause of the lag based on the captured data and sends the cause to the server. For example, taking a vehicle cockpit device as an example, the second Wi-Fi chip determines the cause of the lag based on the captured wireless frame listening data and sends the cause to the vehicle manufacturer's backend server. This allows data analysis to be completed locally on the cockpit device, eliminating the need to upload massive amounts of raw wireless frames, significantly saving upload bandwidth and reducing transmission time. Simultaneously, the server only needs to receive a brief lag conclusion, reducing the pressure on cloud storage and processing power.

[0078] It should be noted that the step of determining the cause of stuttering based on the monitored wireless frame data can be performed independently by the second Wi-Fi chip; it can also be performed independently by the server; or the second Wi-Fi chip can perform a simple preliminary stuttering cause analysis first, and then the server can perform a more detailed stuttering cause analysis later. Optionally, the server can use the preliminary stuttering cause analysis report produced by the second Wi-Fi chip as a reference when determining whether further detailed stuttering cause analysis is needed.

[0079] In some embodiments, the type of wireless frames detected by the second WIFI chip includes at least one of management frames, control frames, and data frames. Based on the detected wireless frame data, the cause of the stuttering is determined, including one or more of the following: Based on the monitoring data of the management frames, identify the stuttering caused by abnormal management frames.

[0080] Based on the monitoring data of the control frames, identify the stuttering caused by control frame abnormalities.

[0081] Based on the monitored data frames, identify the stuttering caused by abnormal data transmission.

[0082] In this embodiment, the second Wi-Fi chip detects at least one type of wireless frame, including management frames, control frames, and data frames. Management frames include at least one of beacon frames, authentication request frames, authentication response frames, association request frames, association response frames, deauthentication frames, and deassociation frames. Control frames include at least one of RTS (Request To Send) frames, CTS (Clear To Send) frames, and acknowledgment frames. Data frames include at least one of QoS data frames and retransmission flags. RTS / CTS are a set of classic handshake frames in Wi-Fi 802.11.

[0083] In some embodiments, if at least one of the following—a beacon frame, an authentication request frame, an authentication response frame, an association request frame, an association response frame, a deauthentication frame, and a deassociation frame—is abnormally retransmitted, the stuttering is identified as being caused by an abnormality in the management frame.

[0084] In some embodiments, when there are multiple request frames in the monitoring data of the control frame and no corresponding allow frame, or when no corresponding acknowledgment frame is received after a preset response time threshold is exceeded after a data frame is sent, it is identified that the stuttering is caused by an abnormal control frame.

[0085] In some embodiments, the data frame retransmission rate within a preset time period is determined based on the QoS data frame and the retransmission flag. If the data frame retransmission rate exceeds a preset retransmission rate threshold, the stuttering is identified as being caused by abnormal data transmission.

[0086] In some embodiments, if a corresponding acknowledgment frame is not received after a preset response time threshold is exceeded after a data frame is sent, the cause of the stutter is determined to be a physical layer transmission failure or conflict.

[0087] In some embodiments, when there are multiple request frames to send and no corresponding allow frame to send, the cause of the stutter is determined to be a busy channel or the presence of a hidden device.

[0088] In some embodiments, when all three of the following conditions are met simultaneously, the cause of the stuttering is determined to be channel congestion caused by co-channel interference: The first WIFI chip has a data frame retransmission rate greater than the preset retransmission rate threshold, missing acknowledgment frames, and multiple beacon frames sent from devices other than the aforementioned mobile devices.

[0089] In some embodiments, if it is detected that the MAC address of the aforementioned mobile device frequently sends disconnection requests to the first WIFI chip in the cockpit device within a short period of time, the cause of the lag is determined to be abnormal behavior on the mobile device side, such as forced disconnection at the mobile device application layer or unreasonable power management strategy. An unreasonable power management strategy could be, for example, the mobile device system quickly shuts down the RF receiver and RF transmitter in the WIFI and puts the wireless module to sleep after locking the screen to save power, forcibly disconnecting the wireless connection with the cockpit device.

[0090] like Figure 5 As shown, for management frames, the system checks whether the authentication and association processes are abnormally retransmitted. Frequent deassociation or deauthentication frames may indicate malicious attacks or AP / STA state machine errors. The state machine refers to the state machine of the cockpit or mobile device. For control frames, the system analyzes the interaction of RTS / CTS (Request to Send / Allow to Send) frames and the absence of ACK confirmation frames. Furthermore, capturing a large number of RTS frames without CTS responses may indicate a busy channel or a hidden node problem. Also, if a corresponding ACK confirmation frame is not captured after a long period (even exceeding the lifespan) following data frame transmission, it can generally be determined as a physical layer transmission failure or collision. For data frames, the system checks the QoS control field and retransmission flag, calculates the data frame retransmission rate within a specific time period, and identifies data transmission anomalies causing stuttering if the data frame retransmission rate exceeds a preset retransmission rate threshold.

[0091] The cause of the stuttering can be located individually or in combination based on management frame anomalies, control frame anomalies, and data transmission anomalies. For example... Figure 5 As shown, if a corresponding ACK confirmation frame is not received after a preset response time threshold is exceeded after a data frame is sent, the cause of the lag is determined to be a physical layer transmission failure or conflict. If multiple requests to send RTS frames exist but no corresponding allowed CTS frames are found, the cause of the lag is determined to be a busy channel or the presence of a hidden device. Furthermore, if all three of the following conditions are met simultaneously, the cause of the lag is determined to be channel congestion caused by co-channel interference: the data frame retransmission rate of the first Wi-Fi chip is greater than a preset retransmission rate threshold, ACK frames are missing, and multiple beacon frames are present from other terminal devices besides the aforementioned mobile devices.

[0092] In this embodiment, when determining the cause of a stutter, at least one of the following can be used: monitoring data from management frames, monitoring data from control frames, and monitoring data from data frames. Jointly judging multiple frame data can restore the true state of the wireless channel from multiple perspectives, as a single frame type can easily lead to incomplete information. Complementary frame data from multiple types can accurately distinguish different stuttering causes such as poor signal strength, channel contention, and message retransmission, improving the accuracy of stuttering location and avoiding misjudgments.

[0093] Figure 6A schematic diagram of the architecture of a stuttering detection system provided in an exemplary embodiment of this application is shown. Figure 6 As shown, the cockpit device 610 includes a first Wi-Fi chip 611 and a second Wi-Fi chip 612. The first Wi-Fi chip 611 includes an application monitoring module 6111, and the second Wi-Fi chip 612 includes a protocol analysis engine 6121 and a radio frequency receiver 6122. The application monitoring module 6111 runs on the first Wi-Fi chip 611, and the protocol analysis engine 6121 runs on the second Wi-Fi chip 612; both are software services belonging to the operating system framework layer.

[0094] The cockpit device 610 and the mobile device 620, such as a user's mobile phone, communicate wirelessly via a Wi-Fi wireless network to achieve screen projection. During the wireless communication between the first Wi-Fi chip 611 and the mobile device 620 via the Wi-Fi wireless channel, the application monitoring module 6111 in the first Wi-Fi chip 611 acquires the connection quality data between the mobile device and the first Wi-Fi chip 611, and identifies whether the wireless communication between the first Wi-Fi chip 611 and the mobile device is interrupted based on the connection quality data. If the wireless communication is interrupted, the application monitoring module 6111 in the first Wi-Fi chip 611 triggers an interruption detection command and sends the interruption detection command to the second Wi-Fi chip 612. After receiving the interruption detection command, the second Wi-Fi chip 612 controls the radio frequency receiver 6122 to switch to the aforementioned Wi-Fi wireless channel and start the listening mode to capture the listening data. Subsequently, the data monitored by the RF receiver 6122 is sent to the protocol analysis engine 6121 in the second Wi-Fi chip 612. The protocol analysis engine 6121 determines the cause of the lag based on at least one of the management frames, control frames, and data frames in the monitored data and sends the cause of the lag to the server 630. Alternatively, the RF receiver 6122 in the second Wi-Fi chip 612 can capture and monitor the data, sending it to the server 630 so that the server 630 can determine the cause of the lag based on the monitored data of the wireless frames.

[0095] It should be noted that the method steps in the above embodiments can be arbitrarily combined to obtain new embodiments, and this application does not impose any restrictions on them.

[0096] Figure 7 The diagram shows a structural block diagram of a cockpit device 610 provided in an exemplary embodiment of this application. The cockpit device 610 includes a first WIFI chip 611 and a second WIFI chip 612. The first WIFI chip 611 communicates wirelessly with mobile devices via a wireless channel; In the event of a lag in the wireless communication, the second WIFI chip 612 listens to at least one wireless frame in the wireless channel, and the wireless frame is used to determine the cause of the lag.

[0097] In some embodiments, the first WIFI chip 611 acquires connection quality data between the mobile device and the first WIFI chip 611. The first WIFI chip 611 identifies a lag in wireless communication between the first WIFI chip 611 and the mobile device based on the connection quality data.

[0098] In some embodiments, the first WIFI chip 611 identifies a lag in wireless communication between the first WIFI chip 611 and the mobile device based on the connection quality data, including: When the connection quality data is abnormal and the duration of the abnormality exceeds a preset duration threshold, it is determined that the wireless communication between the first WIFI chip 611 and the mobile device is interrupted.

[0099] In some embodiments, the abnormal connection quality data includes at least one of the following: The data packet loss rate is greater than a preset packet loss rate threshold; The end-to-end round-trip delay is greater than a preset delay threshold; The received signal strength is less than a preset signal strength threshold.

[0100] In some embodiments, the second WIFI chip 612 sends the listening data of the wireless frames to the server, so that the server can determine the cause of the lag based on the listening data of the wireless frames; and / or, The second WIFI chip 612 determines the cause of the lag based on the listening data of the wireless frame and sends the cause of the lag to the server.

[0101] In some embodiments, the type of wireless frames detected by the second WIFI chip 612 includes at least one of management frames, control frames, and data frames. Determining the cause of the stuttering based on the detected wireless frame data includes one or more of the following: Based on the monitoring data of the management frames, identify the stuttering caused by management frame anomalies; Based on the monitoring data of the control frames, identify the stuttering caused by control frame abnormalities; Based on the monitored data of the data frames, identify the stuttering caused by abnormal data transmission.

[0102] In some embodiments, identifying stuttering caused by management frame anomalies based on the monitoring data of the management frame includes: If at least one of the following types of frames—beacon frames, authentication request frames, authentication response frames, association request frames, association response frames, deauthentication frames, and deassociation frames—is abnormally retransmitted in the monitoring data of the management frames, the stuttering caused by the abnormality of the management frames is identified.

[0103] In some embodiments, identifying stuttering caused by control frame anomalies based on the monitoring data of the control frames includes: If there are multiple request frames in the monitoring data of the control frame and no corresponding allow frame, or if no corresponding acknowledgment frame is received after a preset response time threshold is exceeded after a data frame is sent, the lag caused by the abnormal control frame is identified.

[0104] In some embodiments, identifying the stuttering caused by abnormal data transmission based on the monitored data of the data frame includes: The retransmission rate of data frames within a preset time period is determined based on the QoS data frame and the retransmission flag. If the data frame retransmission rate is greater than a preset retransmission rate threshold, the system identifies lag caused by abnormal data transmission.

[0105] In some embodiments, determining the cause of the stuttering based on the monitored data of the wireless frames includes: If at least one of the deauthentication frame and the deassociation frame is abnormally retransmitted, the cause of the lag is determined to be a malicious attack or a state machine error, wherein the state machine is the state machine of the cockpit device or the mobile device.

[0106] In some embodiments, determining the cause of the stuttering based on the monitored data of the wireless frames includes: If a data frame is sent but no corresponding acknowledgment frame is received within a preset response time threshold, the cause of the lag is determined to be a physical layer transmission failure or conflict.

[0107] In some embodiments, determining the cause of the stuttering based on the monitored data of the wireless frames includes: If there are multiple request frames to be sent but no corresponding allowed frame to be sent, the cause of the lag is determined to be either a busy channel or the presence of a hidden device.

[0108] In some embodiments, determining the cause of the stuttering based on the monitored data of the wireless frames includes: When all three of the following conditions are met simultaneously, the cause of the stuttering is determined to be channel congestion caused by co-channel interference: The data frame retransmission rate of the first WIFI chip 611 is greater than the preset retransmission rate threshold, there are missing acknowledgment frames, and there are multiple beacon frames sent from devices other than the mobile device.

[0109] In some embodiments, the first WIFI chip 611 is used to enable the mobile device to project its screen onto the cockpit device, and the second WIFI chip 612 is used to provide hotspot services to the mobile device.

[0110] Figure 8 This illustration shows a structural block diagram of a computer device 700 provided in an exemplary embodiment of this application. The computer device 700 is a processor for a cockpit device. Typically, the computer device 700 includes a processor 701 and a memory 702.

[0111] Processor 701 may include one or more processing cores, such as one or more of a quad-core processor or an octa-core processor. Processor 701 may be implemented using at least one hardware form of DSP (Digital Signal Processing), FPGA (Field Programmable Gate Array), or PLA (Programmable Logic Array). Processor 701 may also include a main processor and a coprocessor. The main processor, also known as a CPU (Central Processing Unit), is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, processor 701 may integrate a GPU (Graphics Processing Unit), which is responsible for rendering and drawing the content required to be displayed on the screen.

[0112] The memory 702 may include one or more computer-readable storage media, which may be tangible and non-transitory. The memory 702 may also include high-speed random access memory and non-volatile memory, such as one or more disk storage devices or flash memory devices.

[0113] The memory 702 is used to store computer execution instructions, and the processor 701 is used to execute the computer execution instructions stored in the memory 702 to implement the various steps of the stuttering detection method in the above embodiments. For details, please refer to the relevant descriptions in the foregoing method embodiments.

[0114] In some embodiments, the non-transitory computer-readable storage medium in memory 702 stores at least one instruction, which is executed by processor 701 to implement the stuttering detection method provided in this embodiment. In some embodiments, computer device 700 may also optionally include: peripheral device interface 703 and at least one peripheral device. Processor 701, memory 702 and peripheral device interface 703 can be connected via a bus or signal line. Each peripheral device can be connected to peripheral device interface 703 via a bus, signal line or circuit board. Specifically, the peripheral device includes at least one of: radio frequency circuit 704, touch display screen 705, camera assembly 706, audio circuit 707 and power supply 708.

[0115] The radio frequency (RF) circuit 704 is used to receive and transmit RF (Radio Frequency) signals, also known as electromagnetic signals. The RF circuit 704 communicates with communication networks and other communication devices via electromagnetic signals.

[0116] The touch display screen 705 is used to display a user interface (UI). This UI may include graphics, text, icons, video, and any combination thereof. The touch display screen 705 also has the ability to acquire touch signals on or above its surface.

[0117] The camera assembly 706 is used to capture images or videos. Optionally, the camera assembly 706 includes a front-facing camera and a rear-facing camera.

[0118] Audio circuit 707 is used to provide an audio interface between the user and computer device 700.

[0119] Power supply 708 is used to supply power to the various components in computer device 700.

[0120] In some embodiments, the computer device 700 further includes one or more sensors 709. The one or more sensors 709 include, but are not limited to, an accelerometer 710, a gyroscope 711, a pressure sensor 712, an optical sensor 713, and a proximity sensor 714.

[0121] Those skilled in the art will understand that the above structure does not constitute a limitation on the computer device 700, and may include more or fewer components than shown in the figure, or combine certain components, or use different component arrangements.

[0122] This application also provides a computer-readable storage medium storing at least one computer program, which is loaded and executed by a processor to implement the stuttering detection method provided in the above-described method embodiments.

[0123] This application also provides a computer program product, which includes at least one computer program stored in a computer-readable storage medium; the at least one computer program is read from and executed by the processor of a computer device from the computer-readable storage medium, causing the computer device to perform the stuttering detection method provided in the above-described method embodiments.

[0124] It should be understood that "multiple" as used herein refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. Furthermore, the step numbers described herein are merely illustrative of one possible execution order. In some other embodiments, the steps may not be executed in numerical order, such as two steps with different numbers being executed simultaneously, or two steps with different numbers being executed in the reverse order of the illustration. This application does not limit this.

[0125] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware or by a program instructing related hardware. The program can be stored in a computer-readable storage medium, such as one or more read-only memories, disks, or optical discs.

[0126] The above description is merely an optional embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A method for detecting stuttering, characterized in that, The method is performed by a cockpit device having a first WIFI chip and a second WIFI chip, and the method includes: The first WIFI chip communicates wirelessly with the mobile device via a wireless channel; In the event of a lag in the wireless communication, the second WIFI chip listens to at least one wireless frame in the wireless channel, and the wireless frame is used to determine the cause of the lag.

2. The method according to claim 1, characterized in that, The method further includes: The first WIFI chip acquires connection quality data between the mobile device and the first WIFI chip; The first WIFI chip identifies a lag in wireless communication between itself and the mobile device based on the connection quality data.

3. The method according to claim 2, characterized in that, The first Wi-Fi chip identifies a lag in wireless communication between itself and the mobile device based on the connection quality data, including: When the connection quality data is abnormal and the duration of the abnormality exceeds a preset duration threshold, it is determined that the wireless communication between the first WIFI chip and the mobile device is experiencing a lag.

4. The method according to claim 2 or 3, characterized in that, The abnormal connection quality data includes at least one of the following: The data packet loss rate is greater than a preset packet loss rate threshold; The end-to-end round-trip delay is greater than a preset delay threshold; The received signal strength is less than a preset signal strength threshold.

5. The method according to claim 1, characterized in that, The method further includes: The second Wi-Fi chip sends the monitored data of the wireless frames to the server, so that the server can determine the cause of the lag based on the monitored data of the wireless frames; and / or, The second WIFI chip determines the cause of the lag based on the listening data of the wireless frames and sends the cause of the lag to the server.

6. The method according to claim 5, characterized in that, The second WIFI chip detects at least one type of wireless frame, including management frames, control frames, and data frames. Determining the cause of the stuttering based on the detected wireless frame data includes one or more of the following: Based on the monitoring data of the management frames, identify the stuttering caused by management frame anomalies; Based on the monitoring data of the control frames, identify the stuttering caused by control frame abnormalities; Based on the monitored data of the data frames, identify the stuttering caused by abnormal data transmission.

7. The method according to claim 6, characterized in that, The step of identifying stuttering caused by management frame anomalies based on the monitoring data of the management frame includes: If at least one of the following types of frames—beacon frames, authentication request frames, authentication response frames, association request frames, association response frames, deauthentication frames, and deassociation frames—is abnormally retransmitted in the monitoring data of the management frames, the stuttering caused by the abnormality of the management frames is identified.

8. The method according to claim 6, characterized in that, The step of identifying stuttering caused by control frame anomalies based on the monitoring data of the control frames includes: If there are multiple request frames in the monitoring data of the control frame and no corresponding allow frame, or if no corresponding acknowledgment frame is received after a preset response time threshold is exceeded after a data frame is sent, the lag caused by the abnormal control frame is identified.

9. The method according to claim 6, characterized in that, The step of identifying data transmission anomalies causing stuttering based on the monitored data frames includes: The retransmission rate of data frames within a preset time period is determined based on the QoS data frame and the retransmission flag. If the data frame retransmission rate is greater than a preset retransmission rate threshold, the system identifies lag caused by abnormal data transmission.

10. The method according to claim 5 or 6, characterized in that, The step of determining the cause of the stuttering based on the listening data of the wireless frames includes: If at least one of the deauthentication frame and the deassociation frame is abnormally retransmitted, the cause of the lag is determined to be a malicious attack or a state machine error, wherein the state machine is the state machine of the cockpit device or the mobile device.

11. The method according to claim 6, characterized in that, The step of determining the cause of the stuttering based on the listening data of the wireless frames includes: If a data frame is sent but no corresponding acknowledgment frame is received within a preset response time threshold, the cause of the lag is determined to be a physical layer transmission failure or conflict.

12. The method according to claim 6, characterized in that, The step of determining the cause of the stuttering based on the listening data of the wireless frames includes: If there are multiple request frames to be sent but no corresponding allowed frame to be sent, the cause of the lag is determined to be either a busy channel or the presence of a hidden device.

13. The method according to claim 6, characterized in that, The step of determining the cause of the stuttering based on the listening data of the wireless frames includes: When all three of the following conditions are met simultaneously, the cause of the stuttering is determined to be channel congestion caused by co-channel interference: The data frame retransmission rate of the first WIFI chip is greater than the preset retransmission rate threshold, there are missing acknowledgment frames, and there are multiple beacon frames sent from devices other than the mobile device.

14. The method according to any one of claims 1 to 13, characterized in that, The first WIFI chip is used to allow the mobile device to project its screen onto the cockpit device, and the second WIFI chip is used to provide hotspot service to the mobile device.

15. A cockpit device, characterized in that, The cockpit equipment includes a first WIFI chip and a second WIFI chip; The first WIFI chip communicates wirelessly with the mobile device via a wireless channel; In the event of a lag in the wireless communication, the second WIFI chip listens to at least one wireless frame in the wireless channel, and the wireless frame is used to determine the cause of the lag.

16. A computer device, characterized in that, The computer device includes a processor and a memory, the memory storing a computer program, the computer program being loaded and executed by the processor to implement the stuttering detection method as described in any one of claims 1 to 14.

17. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that is loaded and executed by a processor to implement the stuttering detection method as described in any one of claims 1 to 14.

18. A computer program product, characterized in that, The computer program product stores a computer program that is loaded and executed by a processor to implement the stuttering detection method as described in any one of claims 1 to 14.

Images