A bluetooth earphone terminal fault detection and remote maintenance method

Abstract

The application discloses a kind of Bluetooth headset terminal fault detection and remote maintenance method, it is related to Internet of Things technical field, including using depth self-checking procedure to the core hardware of Bluetooth headset is layered monitoring, obtains operating state data, and is substituted into fault tree model and is logically traversed, and the fault path in the traversal process is mapped as fault diagnosis code, fault diagnosis code is divided into regular error and fatal error according to fault type, is respectively stored to fault log storage area, fault diagnosis code is converted into readable text prompt, the application is by constructing fault logic analysis model, by establishing fault severity dynamic evaluation system, fault data is realized hierarchical storage and priority transmission, ensure that key error information can be saved completely and timely report, convert raw data into readable, clear guidance maintenance information, effectively improve the experience of user when facing equipment failure, improve the overall efficiency and reliability of product service.

Description

[0001] This invention relates to the field of Internet of Things (IoT) technology, and in particular to a method for fault detection and remote maintenance of Bluetooth headset terminals. Background Technology

[0002] In recent years, with the rapid development of mobile internet and wearable devices, Bluetooth headsets, as the core terminal for audio interaction, have become increasingly complex in terms of functional integration and application scenarios, covering a variety of functions such as high-fidelity audio transmission, voice calls, and intelligent noise reduction. This places extremely high demands on the hardware reliability and stability of the devices. In order to ensure the normal operation of Bluetooth headsets, the industry usually sets up basic error detection mechanisms in embedded firmware to identify anomalies by monitoring the status of key nodes, so as to prevent functional failure or performance degradation. These technologies play a fundamental role in product factory testing and daily maintenance.

[0003] Currently, Chinese invention patent CN119996920B discloses a Bluetooth headset fault feedback method and a Bluetooth headset, comprising: when a collision is detected in the Bluetooth headset, determining first damage data of a first type of function and second damage data of a second type of function in the Bluetooth headset based on at least one of hardware parameters and preset function detection data; subsequently, determining first interaction content based on the first damage data, and determining second interaction content and control commands based on the second damage data; sending the first interaction content and second interaction content to the user terminal; and maintaining or adjusting the second type of function according to the control commands. This allows for timely feedback to users regarding the health impact of functional impairment, and prevents users from overusing functions that could negatively affect their health through corresponding control commands, effectively protecting users' auditory health when using Bluetooth headsets. However, existing self-testing programs rely on simple threshold comparisons or single hardware status polling, making it difficult to handle complex coupled faults and lacking logical analysis models. This results in inaccurate fault location and an inability to deeply trace specific failure paths. Existing technologies often cannot effectively differentiate the severity of faults in terms of data storage and transmission, leading to limited storage resources being occupied by routine logs. Critical fatal error data may be lost or not transmitted in a timely manner, making it difficult for users to obtain intuitive fault descriptions and repair suggestions. Ultimately, this results in difficulties in remote maintenance, high after-sales costs, and a poor user experience. Summary of the Invention

[0004] The technical problem solved by this invention is that self-testing programs rely on simple threshold comparisons or single hardware status polling, which are difficult to cope with complex coupled faults and lack logical analysis models, resulting in inaccurate fault location and inability to deeply trace specific failure paths. Existing technologies often cannot effectively distinguish the severity level of faults in terms of data storage and transmission, resulting in limited storage resources being occupied by routine logs. Critical fatal error data may be lost or not transmitted in a timely manner, making it difficult for users to obtain intuitive fault descriptions and maintenance suggestions. Ultimately, this leads to difficulties in remote maintenance, high after-sales costs, and a poor user experience.

[0005] To solve the above-mentioned technical problems, the present invention provides the following technical solution: a method for fault detection and remote maintenance of a Bluetooth headset terminal, comprising the following steps: Step S1: Integrate a deep self-test program into the embedded firmware of the Bluetooth headset and pre-configure a fault tree model including top events, intermediate events, bottom events and logic gate relationships. Step S2: Use a deep self-test program to perform layered monitoring of the core hardware of the Bluetooth headset, obtain the operating status data of each monitoring level, use the operating status data as input variables into the fault tree model, traverse the trigger condition set of all bottom events in the fault tree model, when the input variable of one of the bottom events meets the corresponding trigger condition, determine that the current bottom event is activated, backtrack upward according to the logic gate relationship in the fault tree model, obtain the current state of the intermediate event and the top event corresponding to the current bottom event, and map the logic path from the activated bottom event to the top event in the fault tree model into fault diagnosis code; Step S3: Divide the fault log storage area in the non-volatile storage medium of the Bluetooth headset, divide the fault diagnosis code into regular errors and fatal errors according to the fault type, and store them in the fault log storage area according to different storage strategies. Step S4: Transmit the fault diagnosis code to the user terminal and convert it into a readable text prompt.

[0006] In a preferred embodiment of the Bluetooth headset terminal fault detection and remote maintenance method of the present invention, step S1 includes the following sub-steps: Step S101: Construct the topology of the fault tree model, wherein the fault tree model includes top event, intermediate event and bottom event; Step S102: In the embedded firmware initialization stage, start the deep self-test program, establish corresponding monitoring levels for core hardware, and establish self-test sub-tasks corresponding to each monitoring level. The core hardware includes a Bluetooth main control chip, a radio frequency link, a baseband processor, an audio codec, and power management hardware. The monitoring hierarchy includes a radio frequency front-end layer, a baseband processing layer, an audio codec layer, and a power management layer; Step S103: Execute the self-test sub-tasks corresponding to each monitoring level, obtain the operating status data of each monitoring level of the core hardware, and use the operating status data as the input variable of the bottom event in the fault tree model.

[0007] As a preferred embodiment of the Bluetooth headset terminal fault detection and remote maintenance method of the present invention, the top event includes Bluetooth headset terminal function failure; The Bluetooth headset terminal malfunctions include: inability to establish a connection, inability to play audio, and inability to capture audio. The intermediate events include RF link anomalies, baseband processor anomalies, audio codec anomalies, and power management hardware anomalies. The aforementioned events include excessive RF bit error rate, inconsistent baseband read / write data, power parameters exceeding safe range, and excessive audio noise floor.

[0008] In a preferred embodiment of the Bluetooth headset terminal fault detection and remote maintenance method of the present invention, step S2 includes the following sub-steps: Step S201, the self-test subtask of the RF front-end layer is RF loopback test, and the bit error rate is obtained as the input variable of the bottom event; The self-test subtask of the baseband processing layer is a memory integrity scan, which obtains the read-write comparison results as the input variables for the base event. The self-test subtask of the audio codec layer is audio path squelch detection, which obtains the energy value as the input variable for the bottom event; The self-test subtask of the power management layer is to sample and monitor power parameters and obtain power monitoring data as input variables for bottom events. Step S202: Substitute the input variables of each bottom event into the fault tree model, and traverse the trigger condition set of all bottom events in the fault tree model; When the input variable of one of the bottom events meets the corresponding triggering condition, it is determined that the current bottom event is activated. The logic gate relationship in the fault tree model is traced back upward to obtain the current state of the intermediate event and the top event corresponding to the current bottom event. Step S203: Obtain the logical path from the activated bottom event to the top event in the fault tree model, and map the logical path to fault diagnosis code.

[0009] As a preferred embodiment of the Bluetooth headset terminal fault detection and remote maintenance method of the present invention, the radio frequency loopback test includes: The loop between the transmit and receive paths is closed within the Bluetooth master control chip to generate a preset test signal; The preset test signal is transmitted through the transmission path and demodulated through the receiving path; Use the demodulated preset test signal as the demodulated signal; Calculate the bit error rate of the demodulated signal and the preset test signal, and use the bit error rate as an input variable to evaluate whether the radio frequency link bottom event is triggered; The memory integrity scan includes: The memory hardware of the Bluetooth headset was tested using a checkerboard algorithm for read and write operations. The comparison results of the read and write tests were used as input variables to evaluate whether the baseband processor's bottom event was triggered. The audio path noise detection includes: Switch the input of the audio codec to a preset mute signal source and control the audio codec to perform signal acquisition and encoding; The encoded audio data stream is acquired, and the energy value of the audio data stream is calculated. The energy value is used as an input variable to evaluate whether the audio codec bottom event is triggered. The self-test subtask of the power management layer is power parameter sampling and monitoring; The power parameter sampling and monitoring includes: The power management chip of the Bluetooth headset collects the battery voltage, battery temperature and operating current in real time through its sampling interface to obtain power monitoring data. This power monitoring data is then used as an input variable to evaluate whether a power management hardware event has been triggered.

[0010] As a preferred embodiment of the Bluetooth headset terminal fault detection and remote maintenance method of the present invention, the trigger condition set includes a first trigger condition, a second trigger condition, a third trigger condition and a fourth trigger condition. The first triggering condition includes: if the bit error rate is greater than a first threshold, then triggering a radio frequency bit error rate exceeding the limit event; The second triggering condition includes: if the result of the read / write test is that the data read by the Bluetooth headset is inconsistent with the data written, then a baseband read / write data inconsistency event is triggered; The third triggering condition includes: if one of the power monitoring data exceeds a preset safety threshold range, then trigger a power parameter exceeding safety range event. The fourth triggering condition includes: if the energy value is greater than the second threshold, then trigger the audio noise floor excessive event.

[0011] As a preferred embodiment of the Bluetooth headset terminal fault detection and remote maintenance method of the present invention, mapping the logical path to fault diagnosis code specifically includes: The logical path includes a bottom event, intermediate events, a top event, and logic gates connecting the various events; Extract the preset number and logic gate type of each event in the logical path; The logic gate types include OR gates and AND gates; Arrange the preset numbers of each event in hierarchical order from bottom event to top event, and insert the corresponding logic gate type identifier between adjacent preset numbers to obtain the arrangement sequence; The permuted sequence is converted into fault diagnosis codes using preset character conversion rules; The fault diagnosis code includes a fault type field, a fault source field, and a logical path verification field.

[0012] As a preferred embodiment of the Bluetooth headset terminal fault detection and remote maintenance method of the present invention, step S3 specifically includes: A pre-defined circular buffer of a specific size is used as the fault log storage area within the non-volatile storage medium of the Bluetooth headset. The fault diagnosis codes are classified into general errors and fatal errors based on the fault type. The common errors include connection packet loss, transient signal-to-noise ratio degradation, and minor frame errors in audio decoding; The fatal errors include watchdog timeout, system deadlock, hardware bus anomaly, and battery overvoltage / undervoltage protection triggering. For common errors, a hash feature code is generated based on the current fault type and timestamp. The hash feature code is stored in the fault log storage area using a first-in-first-out strategy. When the fault log storage area is full, the oldest stored hash feature code is automatically overwritten. For fatal errors, extract key data at the moment of failure; The key data includes memory stack data, register status, and memory snapshots; The critical data is compressed and packaged using a lossless compression algorithm to obtain a compressed error package, which is then stored in the reserved sector of the fault log storage area.

[0013] In a preferred embodiment of the Bluetooth headset terminal fault detection and remote maintenance method of the present invention, step S4 includes the following sub-steps: Step S401: Establish a Bluetooth connection between the Bluetooth headset terminal and the user terminal, encapsulate the fault diagnosis code into a data packet with a custom protocol format, and transmit it to the user terminal. The custom protocol format includes a start header, data length, fault diagnosis code, checksum, and end character; Step S402: Add a fault identifier to the data packet according to the fault type. Data packets with fatal error identifiers take priority over data packets with regular errors during transmission. In step S403, the user terminal receives the Bluetooth data packet with the added fault identifier, determines the transmission order according to the fault identifier, and converts the data packet into a readable text prompt according to the transmission order.

[0014] As a preferred embodiment of the Bluetooth headset terminal fault detection and remote maintenance method of the present invention, the step of converting data packets into readable text prompts specifically includes: Call the local preset fault code parsing library to query the readable text prompts corresponding to the data packet; The readable text prompts include the name of the faulty component, a description of the cause of the fault, and user-executable repair suggestions; The readable text prompts are rendered into a graphical user interface page and displayed on the user terminal's screen.

[0015] The beneficial effects of this invention are as follows: By constructing a fault logic analysis model, this invention can accurately identify complex coupled faults and trace specific failure paths, achieving in-depth location of the root cause of the fault. By establishing a dynamic fault severity assessment system, fault data is stored hierarchically and transmitted with priority, ensuring that key error information is completely preserved and reported in a timely manner. This avoids the problem of losing fatal fault data due to the resource consumption of regular logs. The invention transforms raw data into highly readable and clearly guiding maintenance information, making remote fault diagnosis and maintenance possible. This significantly reduces the demand for on-site service and after-sales costs, while effectively improving the user experience when facing equipment failures and enhancing the overall efficiency and reliability of product services. Attached Figure Description

[0016] Figure 1 This is a basic flowchart illustrating a method for fault detection and remote maintenance of a Bluetooth headset terminal, as provided in one embodiment of the present invention. Detailed Implementation

[0017] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments.

[0018] Reference Figure 1 As an embodiment of the present invention, a method for fault detection and remote maintenance of a Bluetooth headset terminal is provided, comprising the following steps: Step S1: Integrate a deep self-test program into the embedded firmware of the Bluetooth headset and pre-configure a fault tree model including top events, intermediate events, bottom events and logic gate relationships. Step S2: Use a deep self-test program to perform layered monitoring of the core hardware of the Bluetooth headset, obtain the operating status data of each monitoring level, use the operating status data as input variables to input the fault tree model, traverse the trigger condition set of all bottom events in the fault tree model, when the input variable of one of the bottom events meets the corresponding trigger condition, determine that the current bottom event is activated, backtrack upward according to the logic gate relationship in the fault tree model, obtain the current state of the intermediate event and the top event corresponding to the current bottom event, and map the logic path from the activated bottom event to the top event in the fault tree model into fault diagnosis code; Step S3: Divide the fault log storage area in the non-volatile storage medium of the Bluetooth headset, divide the fault diagnosis code into regular errors and fatal errors according to the fault type, and store them in the fault log storage area according to different storage strategies. Step S4: Transmit the fault diagnosis code to the user terminal and convert it into a readable text prompt.

[0019] By deeply integrating a self-test program into the embedded firmware of the Bluetooth headset and combining it with a pre-built fault tree model, a data-driven automated fault diagnosis and remote maintenance system was constructed. The deep self-test program can perform real-time and hierarchical status monitoring of the core hardware of the Bluetooth headset. The acquired operating status data is substituted into the fault tree model for rigorous logical traversal, which can deduce the fault phenomenon from the bottom hardware status to the top fault phenomenon. This realizes the leap from qualitative analysis to quantitative analysis in fault diagnosis. The fault path in the traversal process is mapped into standardized fault diagnosis codes and classified and stored in non-volatile storage media to ensure the persistent preservation and anti-loss capability of fault information. The fault diagnosis codes are transmitted to the user terminal and converted into readable text prompts, which greatly improves the transparency of fault perception, provides accurate data support for remote maintenance, significantly reduces after-sales service costs, and improves problem-solving efficiency.

[0020] Step S1 includes the following sub-steps: Step S101: Construct the topology of the fault tree model, which includes top event, intermediate events, and bottom event; Step S102: In the embedded firmware initialization stage, start the deep self-test program, establish corresponding monitoring levels for core hardware, and establish self-test sub-tasks corresponding to each monitoring level. The core hardware includes the Bluetooth main control chip, RF link, baseband processor, audio codec, and power management hardware; The monitoring layers include the RF front-end layer, baseband processing layer, audio codec layer, and power management layer; Step S103: Execute the self-test sub-tasks corresponding to each monitoring level, obtain the operating status data of each monitoring level of the core hardware, and use the operating status data as the input variable of the bottom event in the fault tree model.

[0021] The fault tree model is constructed as a three-layer directed acyclic graph containing top events, intermediate events, and bottom events. The top event represents the macroscopic functional failure of the Bluetooth headset, the intermediate events correspond to the abnormal state of each hardware subsystem, and the bottom event is directly related to the over-limit of specific physical parameters.

[0022] The deep self-test program is burned into the read-only memory of the Bluetooth master controller chip and configured to start immediately after the embedded firmware completes stack initialization.

[0023] The monitoring layers established for the core hardware are specifically divided as follows: the radio frequency front-end layer is responsible for signal transmission and reception quality, the baseband processing layer is responsible for data processing and storage, the audio codec layer is responsible for analog-to-digital conversion of audio signals, and the power management layer is responsible for power distribution and voltage regulation.

[0024] Each monitoring level's corresponding self-test subtask is designed as an independent function module, which calls the underlying driver interface to obtain operating status data. After normalization, the operating status data is injected into the fault tree model as input variables for the bottom event, thereby establishing a real-time mapping relationship between the physical hardware status and the logical fault model.

[0025] By constructing a fault tree model topology, a deep self-test program is initiated during the embedded firmware initialization phase. Corresponding monitoring levels are established for core hardware, achieving full-coverage monitoring of key components. This layered monitoring mechanism decouples the massive hardware system into independent detection units such as the RF front-end layer, baseband processing layer, audio codec layer, and power management layer. By executing the self-test sub-tasks corresponding to each layer, the operating status data of each layer of hardware can be accurately obtained. These underlying operating status data are directly used as input variables for the underlying events in the fault tree model, establishing a direct mapping relationship between physical hardware status and logical fault model. This ensures the comprehensiveness and depth of fault detection, avoids blind spots that may be caused by single-level detection, and can quickly locate specific hardware layers, improving the resolution and accuracy of fault diagnosis.

[0026] Top issues include Bluetooth headset terminal malfunction; Bluetooth headset terminal malfunctions include: inability to establish a connection, inability to play audio, and inability to capture audio. Intermediate events include RF link anomalies, baseband processor anomalies, audio codec anomalies, and power management hardware anomalies; Baseline events include excessive RF bit error rate, inconsistent baseband read / write data, power supply parameters exceeding safe range, and excessive audio noise floor.

[0027] The top event is specifically broken down into three observable user scenarios: failure to establish a connection represents communication failure, failure to play audio represents downlink interruption, and failure to collect audio represents uplink interruption. The intermediate events, as the direct causes of the top event, correspond to the following: radio frequency link abnormalities affecting connection establishment, baseband processor abnormalities affecting data processing, audio codec abnormalities affecting signal conversion, and power management hardware abnormalities affecting overall power supply. The bottom event, as the smallest diagnostic unit of the fault, specifically includes: radio frequency bit error rate exceeding the standard, assessing wireless signal quality; baseband read / write data inconsistency, assessing memory health; power parameters exceeding the safe range, assessing battery and charging circuit status; and excessive audio noise floor, assessing analog circuit noise level.

[0028] The top, intermediate, and bottom events in the fault tree model are defined with specific business scenarios, covering various functional failures that Bluetooth headsets may encounter in actual use. The top event is defined as a functional failure of the Bluetooth headset terminal, so that the diagnostic results can directly reflect the user's actual experience. The intermediate events cover hardware module-level failures, and the bottom events are defined as specific technical indicators. This multi-level definition method, from macro-functional failures to micro-parameter out-of-bounds errors, constructs a complete fault semantic network. This enables the fault diagnosis logic to accurately capture subtle changes in hardware performance, ensuring that the diagnostic results not only match the user's description of the fault phenomenon, but also include the hardware parameter details required by technicians, thus improving the effectiveness and usability of fault information flow between different roles.

[0029] Step S2 includes the following sub-steps: Step S201, the self-test subtask of the RF front-end layer is the RF loopback test, and the bit error rate is obtained as the input variable of the bottom event; The self-test subtask of the baseband processing layer is a memory integrity scan, which obtains the read-write comparison results as the input variables for the base event. The self-test subtask of the audio codec layer is to detect noise in the audio path and obtain the energy value as the input variable for the bottom event. The self-test subtask of the power management layer is to sample and monitor power parameters and obtain power monitoring data as input variables for bottom events. Step S202: Substitute the input variables of each bottom event into the fault tree model, and traverse the set of triggering conditions for all bottom events in the fault tree model. When the input variable of one of the bottom events meets the corresponding triggering condition, it is determined that the current bottom event is activated. Based on the logic gate relationship in the fault tree model, the current state of the intermediate event and the top event corresponding to the current bottom event is obtained by tracing back upwards. Step S203: Obtain the logical path from the activated bottom event to the top event in the fault tree model, and map the logical path to the fault diagnosis code.

[0030] In this embodiment, the self-test subtask of the RF front-end layer is executed by constructing a digital loop inside the chip, and the obtained bit error rate is used as the base event input variable. The subtask of the baseband processing layer performs a full address scan of the memory and uses the read-write comparison result as the input variable. The subtask of the audio codec layer detects the noise floor energy value in the silent state as the input variable. The subtask of the power management layer obtains voltage and current data through ADC sampling as the input variable.

[0031] The process of traversing the trigger condition set of all bottom events in the fault tree model is as follows: Substitute the above input variables into the fault tree model and monitor in real time whether they meet the preset trigger condition set. When the input variable of a certain bottom event exceeds the threshold, the bottom event is determined to be activated. According to the preset logic gate relationship in the fault tree model, backtrack upward. If the bottom event is activated and its parent is an OR gate, the parent intermediate event is directly determined to be abnormal.

[0032] Obtaining the current state of the intermediate and top events corresponding to the current bottom event includes: recording the complete node sequence from the activated bottom event through all intermediate logical nodes to the top event, defining the sequence as a logical path, and converting it into a unique fault diagnosis code according to a preset character mapping table.

[0033] A multi-dimensional hardware health assessment system was constructed. By substituting the input variables of each bottom event into the fault tree model and traversing the trigger condition set of all bottom events, it is possible to monitor in real time whether the hardware status has reached the fault threshold. When the input variable meets the trigger condition, the bottom event is determined to be activated. Based on the logical gate relationship in the fault tree model, it is backtracked upwards to quickly clarify the propagation path of the fault between levels, accurately obtain the current status of the intermediate and top events corresponding to the current bottom event, and finally obtain the complete logical path from the activated bottom event to the top event. This path is then mapped into fault diagnosis code. This diagnostic code, which preserves the complete logical evolution process, records the result of the fault occurrence and the cause and development process of the fault. This helps to quickly formulate targeted repair solutions and avoids the time waste and secondary damage risk caused by blind disassembly and testing.

[0034] RF loopback testing includes: The loop between the transmit and receive paths is closed inside the Bluetooth master control chip to generate a preset test signal; The preset test signal is transmitted through the transmission path and demodulated through the receiving path; Use the demodulated preset test signal as the demodulated signal; Calculate the bit error rate of the demodulated signal and the preset test signal, and use the bit error rate as an input variable to evaluate whether the RF link bottom event is triggered; Memory integrity scan includes: The memory hardware of the Bluetooth headset was tested using a checkerboard algorithm for read and write operations. The comparison results of the read and write tests were used as input variables to evaluate whether the baseband processor's bottom event was triggered. Audio path noise detection includes: Switch the input of the audio codec to the preset mute signal source and control the audio codec to perform signal acquisition and encoding; The encoded audio data stream is acquired, and the energy value of the audio data stream is calculated. The energy value is used as an input variable to evaluate whether the audio codec's underlying event is triggered. The self-test subtask of the power management layer is power parameter sampling and monitoring; Power parameter sampling and monitoring includes: The power management chip of the Bluetooth headset collects the battery voltage, battery temperature and operating current in real time through its sampling interface to obtain power monitoring data. This power monitoring data is then used as an input variable to evaluate whether a power management hardware event has been triggered.

[0035] The preset test signal is set as a digital signal with a known bit stream. The setting is based on comparing it bit by bit with the received demodulated signal to calculate the specific bit error rate value. It can simulate the data characteristics of real Bluetooth communication to accurately reflect the performance of the RF link when processing actual signals.

[0036] The preset mute signal source is set to: internal ground signal or zero potential reference signal. The setting is based on eliminating external environmental noise interference by inputting a zero signal to create a pure noise floor test environment. The noise floor level of the audio circuit is directly quantified based on the energy value measured at the output terminal at this time to determine whether there is abnormal interference.

[0037] In this embodiment, the specific implementation of the radio frequency loopback test is as follows: control the radio frequency switch inside the Bluetooth master control chip to directly connect the output of the transmit path to the input of the receive path, generate a known bit stream preset test signal and transmit it, and demodulate it after loop transmission. The bit error rate is calculated by comparing the original bit stream and the demodulated bit stream.

[0038] The memory integrity scan uses a checkerboard algorithm, which alternately writes binary patterns 01010101 and 10101010 to the memory address, and then reads the data and compares them bit by bit. Any inconsistency will be recorded.

[0039] Audio path squelch detection involves switching the multiplexing switch at the input of the audio codec to the internal signal source, acquiring and encoding a segment of silence data, and quantifying the noise floor by calculating the root mean square energy value of this segment of data.

[0040] Power parameter sampling and monitoring utilizes the analog-to-digital converter built into the power management chip to read the register values ​​of the battery voltage pin, battery thermistor pin, and current sensing amplifier at a frequency of 10 times per second via the I2C bus interface, thereby obtaining real-time voltage, temperature, and current data.

[0041] RF loopback testing closes the loop between the transmit and receive paths within the Bluetooth main control chip, calculates the bit error rate of the demodulated signal and the preset test signal, and can accurately assess the signal transmission quality and anti-interference capability of the RF link. Memory integrity scanning uses a checkerboard algorithm to perform read and write tests on memory hardware. By comparing the read and write results, it can keenly detect physical damage or poor contact of memory cells. Audio path squelch detection switches to a preset mute signal source and calculates the energy value of the encoded audio data stream, objectively quantifying the background noise level of the audio codec. Power parameter sampling and monitoring collects battery voltage, temperature, and operating current values ​​in real time through a sampling interface, comprehensively monitoring the power supply stability of the power system. These dedicated detection algorithms designed for specific hardware physical characteristics have higher sensitivity and accuracy than general detection methods. They can identify minor degradation of hardware performance in the early stages of a fault, effectively preventing minor hidden dangers from evolving into fatal failures.

[0042] The trigger condition set includes a first trigger condition, a second trigger condition, a third trigger condition, and a fourth trigger condition; The first triggering condition includes: if the bit error rate is greater than the first threshold, then the radio frequency bit error rate exceeds the limit event is triggered; The second triggering condition includes: if the result of the read / write test is that the data read by the Bluetooth headset is inconsistent with the data written, then the baseband read / write data inconsistency event is triggered; The third triggering condition includes: if one of the data in the power monitoring data exceeds the preset safety threshold range, then the power parameter exceeding the safety range event is triggered; The fourth triggering condition includes: if the energy value is greater than the second threshold, then the audio noise floor event is triggered.

[0043] The first threshold is set at 0.1%. The basis for this setting is that the first threshold is a critical point for radio frequency link quality set based on Bluetooth industry standards and hardware specifications. It is used to determine whether the bit error rate exceeds the standard, thereby accurately identifying whether there is a degradation in the signal transmission and reception performance of the radio frequency hardware.

[0044] The second threshold is set to -65dBm. The basis for this setting is that the second threshold is the audio energy boundary line that distinguishes between normal background noise and abnormal interference. It is used to measure the circuit's background noise level in a silent state. If it exceeds this value, it is determined that there is abnormal interference in the audio codec circuit.

[0045] The preset safety threshold range is set as follows: voltage between 3.3V and 4.35V, temperature between 0℃ and 45℃, and peak operating current not exceeding 2.5A. The preset safety threshold range is determined strictly according to the battery specifications and the safety margin of the power management chip. It is used to prevent battery overvoltage, undervoltage, abnormal temperature or overcurrent, and to ensure the electrical safety and stable operation of the Bluetooth headset.

[0046] By setting quantitative judgment criteria, the following events are triggered: a bit error rate exceeding a first threshold is used to trigger an event indicating excessive RF bit error rate; inconsistency between Bluetooth headset read and write data is used to trigger an event indicating inconsistent baseband read and write data; power monitoring data exceeding a preset safety threshold is used to trigger an event indicating power parameters exceeding a safety range; and energy values ​​exceeding a second threshold are used to trigger an event indicating excessive audio noise floor. This judgment mechanism based on specific thresholds and comparison results eliminates the subjectivity and uncertainty of human experience-based judgments, ensuring the consistency and fairness of fault judgment criteria across different usage environments and individual devices. Differentiated trigger conditions are set for the physical characteristics of different monitoring levels, enabling the system to adapt to the sensitivity of different hardware modules to environmental factors. This ensures both the sensitivity of fault detection and the effective filtering of false alarms caused by instantaneous fluctuations in the external environment, greatly improving the robustness and reliability of the entire fault detection system.

[0047] Mapping logical paths to fault diagnosis codes specifically includes: The logical path includes bottom events, intermediate events, top events, and logic gates connecting each event; Extract the preset number and logic gate type of each event in the logic path; Logic gate types include OR gates and AND gates; An OR gate indicates that a single fault can trigger a higher-level event, while an AND gate indicates that multiple faults must exist simultaneously to trigger a higher-level event. Arrange the preset numbers of each event in hierarchical order from bottom event to top event, and insert the corresponding logic gate type identifier between adjacent preset numbers to obtain the arrangement sequence; The permuted sequence is converted into fault diagnosis codes using preset character conversion rules; The fault diagnosis code includes a fault type field, a fault source field, and a logical path verification field.

[0048] The default numbering is set as follows: bottom event ID is E01, middle event ID is M05, and top event ID is T02.

[0049] The default character conversion rule is set as follows: the event ID and logic gate identifier are arranged in order, and the sequence is converted into hexadecimal code by looking up a table.

[0050] First, extract the preset numbers of all nodes on the path from the activated bottom event to the top event in the fault tree. At the same time, extract the logic gate types that connect these nodes. OR gates are identified as 1, and AND gates are identified as 0. Arrange these elements in order from bottom to top, and insert the corresponding logic gate type identifier between every two event numbers to form a permutation sequence. Convert this sequence into hexadecimal fault diagnosis codes by using a lookup table method.

[0051] The fault diagnosis code contains three fields: the high 8 bits are the fault type field, used to distinguish between regular errors and fatal errors; the middle 16 bits are the fault source field, used to accurately locate the underlying hardware; and the low 8 bits are the logical path verification field, used to verify the integrity of the logical path and ensure that the data has not been tampered with during transmission.

[0052] A specific coding rule for mapping logical paths to fault diagnosis codes is proposed. By extracting the preset numbers and logic gate types of each event in the logical path and arranging this information in a hierarchical order from bottom event to top event, and inserting the corresponding logic gate type identifier between adjacent preset numbers, structured code is finally generated. This coding method has extremely high information density and logical reconstruction. It compresses complex fault propagation paths into standardized code sequences, which not only saves storage space and transmission bandwidth, but also completely preserves the logical hierarchy at the time of the fault. The maintenance terminal can parse these codes to completely reconstruct which bottom event the fault started from, which logic gates made the judgments, and which top event it ultimately led to. This deep information preservation mechanism makes fault diagnosis no longer limited to result display, but goes deep into logical cause analysis, providing accurate data guidance for subsequent fault repair and product optimization.

[0053] Step S3 specifically includes: A pre-defined circular buffer of a specific size is used as the fault log storage area within the non-volatile storage medium of the Bluetooth headset. The fault diagnosis codes are classified into general errors and fatal errors based on the fault type. Common errors include connection packet loss, transient signal-to-noise ratio degradation, and minor frame errors in audio decoding; Fatal errors include watchdog timeout, system deadlock, hardware bus anomaly, and battery overvoltage / undervoltage protection triggering; For common errors, a hash signature is generated based on the current fault type and timestamp. The hash signature is stored in the fault log storage area using a first-in-first-out strategy. When the fault log storage area is full, the oldest stored hash signature is automatically overwritten. For fatal errors, extract key data at the moment of failure; Key data includes memory stack data, register status, and memory snapshots; Memory stack data refers to the function call chain, return address, and local variable values ​​stored in the memory area pointed to by the CPU stack pointer at the moment of program crash or exception.

[0054] Register status refers to all real-time values ​​temporarily stored in the CPU's general-purpose registers, program counter, and status register at the instant a fault occurs.

[0055] A memory snapshot refers to a data image that is fully read and saved from a critical memory region. Critical regions include the global variable area, heap memory, or specific hardware-mapped segments.

[0056] The critical data is compressed and packaged using a lossless compression algorithm to obtain a compressed error package, which is then stored in the reserved sector of the fault log storage area.

[0057] Reserved sectors cannot be overwritten by hash signatures of regular errors.

[0058] When a fatal error is detected in step S2, the system may crash completely at any time. In this case, if conventional full memory snapshot storage is used, it will be time-consuming and easily interrupted. This embodiment evaluates the remaining available time before the system crash based on the context features and dynamic weights carried in the fault diagnosis code. For example, if the dynamic weights of the power management layer show a sharp drop in battery voltage, the remaining available time is extremely short. The firmware prioritizes extracting register states and core stack data and packing them with a high compression ratio. If the remaining time is relatively sufficient, it further extracts some memory snapshots. Through this adaptive critical scene extraction mechanism, it ensures that the most critical system crash scene data is preserved in non-volatile storage media.

[0059] The non-volatile storage medium uses NOR Flash chips, and the storage address space is divided into a circular buffer and a reserved sector.

[0060] The default size is set to 16KB. This setting is based on meeting the needs of storing regular error logs within a certain time period, while avoiding the occupation of too many non-volatile storage resources. Combined with the cyclic movement strategy of read and write pointers, it ensures the controllability of log management space and efficient coverage.

[0061] A storage management strategy combining a circular buffer and reserved sectors is adopted. Faults are categorized into regular errors and fatal errors for differentiated processing. For regular errors, a hash signature is generated based on the fault type and timestamp, and the data is stored in the circular buffer using a first-in, first-out (FIFO) strategy. When the buffer is full, the oldest data is automatically overwritten. This circular reuse mechanism ensures that storage space is not exhausted due to log accumulation during long-term operation, maintaining the efficient operation of the storage system. For fatal errors, critical data at the time of the fault is extracted, compressed and packaged using a lossless compression algorithm, and then stored in the reserved sectors. This strict data protection measure ensures that critical on-site information can be completely preserved in the event of a severe system crash. This hierarchical storage and compression design balances the resource efficiency of daily system operation with the traceability under extreme fault conditions, resolving the contradiction between limited embedded storage resources and massive amounts of fault log data.

[0062] Step S4 includes the following sub-steps: Step S401: Establish a Bluetooth connection between the Bluetooth headset terminal and the user terminal, encapsulate the fault diagnosis code into a data packet with a custom protocol format, and transmit it to the user terminal. The custom protocol format includes a start header, data length, fault diagnosis code, checksum, and end character; Step S402: Add a fault identifier to the data packet according to the fault type. Data packets with fatal error identifiers take priority over data packets with regular errors during transmission. In step S403, the user terminal receives the Bluetooth data packet with the added fault identifier, determines the transmission order based on the fault identifier, and converts the data packet into a readable text prompt according to the transmission order.

[0063] Since Bluetooth connections may be unstable when a fault occurs, and conventional single or fixed-number transmissions are prone to packet loss, in this embodiment, the transmission of data packets is not only prioritized according to the fault type, but also dynamically assigned retransmission count identifiers according to the weight of the underlying event that triggers the fault. For example, for conventional errors caused by exceeding the RF bit error rate, the corresponding data packets are assigned a higher retransmission count identifier. When the user terminal receives the data, it initiates the corresponding fault tolerance verification and waiting mechanism according to the identifier, so as to ensure the final delivery of the fault diagnosis code even under poor RF quality.

[0064] The custom protocol format is specifically defined as follows: the start header is a fixed 1-byte 0xAA, the data length is a 1-byte indicator of the payload length, the fault diagnosis code is a 4-byte payload, the checksum uses CRC8 check, and the end character is a 1-byte 0x55.

[0065] Before transmission, a fault flag bit is added to a specific position in the header of the data packet according to the fault type. Setting the highest bit to 1 indicates a fatal error, and setting it to 0 indicates a normal error. When scheduling the transmission task, the protocol stack of the Bluetooth master control chip scans the transmission buffer. Once a data packet with a fatal error flag is detected, the current normal data stream is immediately interrupted, and the data packet is inserted at the front of the transmission queue for priority over air interface transmission.

[0066] After receiving the Bluetooth data packet, the user terminal parses the packet header to obtain the fault identifier, and reorders the data in the buffer queue according to the identifier to ensure that the text prompts of fatal errors are rendered and displayed with priority over regular errors.

[0067] A custom protocol format was designed, and a fault-based intelligent transmission priority mechanism was introduced. Fault identifiers were added to data packets according to the fault type, which can identify the urgency of the data and ensure that data packets marked as fatal errors have higher priority than regular error data packets during transmission. This priority scheduling strategy can ensure that critical fault information can overcome the transmission bottleneck and be accurately delivered to the user terminal in the shortest possible time when Bluetooth bandwidth is limited. This prevents the complete loss of device connectivity or maintenance delays due to failure to report serious faults in a timely manner. After receiving the Bluetooth data packets with added fault identifiers, the user terminal determines the transmission order according to the fault identifiers and converts the data packets into readable text prompts in sequence. This standardized encapsulation and orderly transmission processing significantly improves the real-time performance and reliability of fault reporting, ensuring that maintenance personnel can obtain the most critical information as soon as possible, and providing a solid communication foundation for rapid response and handling.

[0068] Converting data packets into readable text prompts specifically includes: Call the local preset fault code parsing library to query the readable text prompts corresponding to the data packets; The readable text prompts include the name of the faulty component, a description of the cause of the fault, and user-executable repair suggestions; The readable text prompts are rendered into a graphical user interface page and displayed on the user's terminal screen.

[0069] Rendering readable text prompts into a graphical user interface page involves the user terminal application querying and retrieving text information such as the name of the faulty component, description of the cause of the fault, and maintenance suggestions based on the fault diagnosis code. The application then matches the corresponding interface color scheme with the severity of the fault, calls the operating system's UI rendering engine to dynamically populate this information into the interface template card, and finally displays the complete page, including the "view details" interactive button, on the terminal display screen in the form of a pop-up, full-screen prompt, or notification message.

[0070] The local default fault code parsing library is set to an SQLite database built into the user terminal APP. This setting is based on establishing a fast mapping relationship between fault diagnosis codes and readable text descriptions, so that the user terminal can query and display intuitive fault prompts in real time without an internet connection, thereby improving the user experience.

[0071] By calling the locally preset fault code parsing library to query the readable text prompts corresponding to the data packets, an intelligent conversion from underlying fault diagnosis codes to user natural language is achieved. This conversion mechanism not only includes the accurate location of the faulty component name, but also provides a detailed description of the fault cause and gives users actionable maintenance suggestions. It directly transforms technical parameters into operational guidance feedback, greatly empowering end users. When encountering a fault, end users can perform initial self-rescue or avoid improper operation based on clear text prompts, effectively preventing secondary damage to equipment caused by user misoperation. The readable text prompts are rendered into a graphical user interface page and displayed on the screen. The intuitive visual presentation reduces the cognitive threshold of information, allowing users of different ages and technical backgrounds to easily understand the fault status. The visual interactive interface significantly improves the user experience, enhances users' trust and satisfaction with the product's technical services, and also reduces after-sales communication costs caused by unclear fault descriptions.

[0072] This invention has the following significant advantages over the prior art: Dynamically adaptive low-overhead self-test: This invention does not statically attach conventional test items to the fault tree, but dynamically allocates self-test resources based on the current power consumption and service operation status of the headset, and performs logical judgments in combination with the dynamic weights of each level. This mechanism effectively avoids full and high-frequency fault tree traversal on the headset with limited computing power, and greatly reduces the computing power squeeze on normal audio playback or Bluetooth communication during the self-test process.

[0073] Adaptive Preservation of Real-Time Data in Extreme Collapse Scenarios: In the face of fatal errors, conventional circular buffers or direct snapshot mechanisms in the field often fail before the system is completely powered off due to excessive writing time. When a fatal error is identified, this invention innovatively evaluates the remaining available time before the system crashes based on dynamic weights, and adaptively extracts and compresses the most critical real-time data into the reserved sector within the extreme time window, which greatly improves the success rate of capturing the final real-time data.

[0074] Fault-tolerant and collaborative hierarchical reporting: This invention extends the dynamic weight of fault diagnosis codes to the transmission link, dynamically allocating transmission priority and retransmission count identifiers. This not only realizes hierarchical reporting of faults, but also effectively overcomes the data packet loss problem caused by unstable connection in Bluetooth headsets under fault conditions, especially radio frequency abnormalities, through a dynamic retransmission mechanism, ensuring that high-priority fault codes can reliably reach the user terminal.

[0075] The self-checking scheduling, hierarchical storage, and fault-tolerant transmission mechanism of this invention is not an isolated collection of technical means, but an organic collaborative system formed to address the resource constraints and uncontrollable fault states of Bluetooth headsets.

[0076] This invention, by constructing a fault logic analysis model, can accurately identify complex coupled faults and trace specific failure paths, achieving in-depth fault root cause localization. By establishing a dynamic fault severity assessment system, fault data is stored hierarchically and transmitted with priority, ensuring that critical error information is completely preserved and reported in a timely manner. This avoids the problem of losing fatal fault data due to the resource consumption of regular logs. The invention transforms raw data into highly readable and clearly guiding maintenance information, making remote fault diagnosis and maintenance possible. This significantly reduces on-site service requirements and after-sales costs, while effectively improving the user experience when facing equipment failures and enhancing the overall efficiency and reliability of product services.

[0077] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product implemented on one or more computer-usable storage media containing computer-usable program code. The storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random Access Memory (SRAM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Erasable Programmable Read Only Memory (EPROM), Programmable Red-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0078] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention, and all such modifications or substitutions should be covered within the protection scope of the present invention.

Claims

1. A method for fault detection and remote maintenance of a Bluetooth headset terminal, characterized in that, Includes the following steps: Step S1: Integrate a deep self-test program into the embedded firmware of the Bluetooth headset and pre-configure a fault tree model including top events, intermediate events, bottom events and logic gate relationships. Step S2: Use a deep self-test program to perform layered monitoring of the core hardware of the Bluetooth headset, obtain the operating status data of each monitoring level, use the operating status data as input variables into the fault tree model, traverse the trigger condition set of all bottom events in the fault tree model, when the input variable of one of the bottom events meets the corresponding trigger condition, determine that the current bottom event is activated, backtrack upward according to the logic gate relationship in the fault tree model, obtain the current state of the intermediate event and the top event corresponding to the current bottom event, and map the logic path from the activated bottom event to the top event in the fault tree model into fault diagnosis code; Step S3: Divide the fault log storage area in the non-volatile storage medium of the Bluetooth headset, divide the fault diagnosis code into regular errors and fatal errors according to the fault type, and store them in the fault log storage area according to different storage strategies. Step S4: Transmit the fault diagnosis code to the user terminal and convert it into a readable text prompt.

2. The Bluetooth headset terminal fault detection and remote maintenance method as described in claim 1, characterized in that, Step S1 includes the following sub-steps: Step S101: Construct the topology of the fault tree model, wherein the fault tree model includes top event, intermediate event and bottom event; Step S102: In the embedded firmware initialization stage, start the deep self-test program, establish corresponding monitoring levels for core hardware, and establish self-test sub-tasks corresponding to each monitoring level. The core hardware includes a Bluetooth main control chip, a radio frequency link, a baseband processor, an audio codec, and power management hardware. The monitoring hierarchy includes a radio frequency front-end layer, a baseband processing layer, an audio codec layer, and a power management layer; Step S103: Execute the self-test sub-tasks corresponding to each monitoring level, obtain the operating status data of each monitoring level of the core hardware, and use the operating status data as the input variable of the bottom event in the fault tree model.

3. The Bluetooth headset terminal fault detection and remote maintenance method as described in claim 2, characterized in that, The top event includes the Bluetooth headset terminal function malfunction; The Bluetooth headset terminal malfunctions include: inability to establish a connection, inability to play audio, and inability to capture audio. The intermediate events include RF link anomalies, baseband processor anomalies, audio codec anomalies, and power management hardware anomalies. The aforementioned events include excessive RF bit error rate, inconsistent baseband read / write data, power parameters exceeding safe range, and excessive audio noise floor.

4. The Bluetooth headset terminal fault detection and remote maintenance method as described in claim 3, characterized in that, Step S2 includes the following sub-steps: Step S201, the self-test subtask of the RF front-end layer is RF loopback test, and the bit error rate is obtained as the input variable of the bottom event; The self-test subtask of the baseband processing layer is a memory integrity scan, which obtains the read-write comparison results as the input variables for the base event. The self-test subtask of the audio codec layer is audio path squelch detection, which obtains the energy value as the input variable for the bottom event; The self-test subtask of the power management layer is to sample and monitor power parameters and obtain power monitoring data as input variables for bottom events. Step S202: Substitute the input variables of each bottom event into the fault tree model, and traverse the trigger condition set of all bottom events in the fault tree model; When the input variable of one of the bottom events meets the corresponding triggering condition, it is determined that the current bottom event is activated. The logic gate relationship in the fault tree model is traced back upward to obtain the current state of the intermediate event and the top event corresponding to the current bottom event. Step S203: Obtain the logical path from the activated bottom event to the top event in the fault tree model, and map the logical path to fault diagnosis code.

5. The Bluetooth headset terminal fault detection and remote maintenance method as described in claim 4, characterized in that, The radio frequency loopback test includes: The loop between the transmit and receive paths is closed within the Bluetooth master control chip to generate a preset test signal; The preset test signal is transmitted through the transmission path and demodulated through the receiving path; Use the demodulated preset test signal as the demodulated signal; Calculate the bit error rate of the demodulated signal and the preset test signal, and use the bit error rate as an input variable to evaluate whether the radio frequency link bottom event is triggered; The memory integrity scan includes: The memory hardware of the Bluetooth headset was tested using a checkerboard algorithm for read and write operations. The comparison results of the read and write tests were used as input variables to evaluate whether the baseband processor's bottom event was triggered. The audio path noise detection includes: Switch the input of the audio codec to a preset mute signal source and control the audio codec to perform signal acquisition and encoding; The encoded audio data stream is acquired, and the energy value of the audio data stream is calculated. The energy value is used as an input variable to evaluate whether the audio codec bottom event is triggered. The self-test subtask of the power management layer is power parameter sampling and monitoring; The power parameter sampling and monitoring includes: The power management chip of the Bluetooth headset collects the battery voltage, battery temperature and operating current in real time through its sampling interface to obtain power monitoring data. This power monitoring data is then used as an input variable to evaluate whether a power management hardware event has been triggered.

6. The Bluetooth headset terminal fault detection and remote maintenance method as described in claim 5, characterized in that, The set of triggering conditions includes a first triggering condition, a second triggering condition, a third triggering condition, and a fourth triggering condition; The first triggering condition includes: if the bit error rate is greater than a first threshold, then triggering a radio frequency bit error rate exceeding the limit event; The second triggering condition includes: if the result of the read / write test is that the data read by the Bluetooth headset is inconsistent with the data written, then a baseband read / write data inconsistency event is triggered; The third triggering condition includes: if one of the power monitoring data exceeds a preset safety threshold range, then trigger a power parameter exceeding safety range event. The fourth triggering condition includes: if the energy value is greater than the second threshold, then trigger the audio noise floor excessive event.

7. The Bluetooth headset terminal fault detection and remote maintenance method as described in claim 6, characterized in that, Mapping the logical path to fault diagnosis code specifically includes: The logical path includes a bottom event, intermediate events, a top event, and logic gates connecting the various events; Extract the preset number and logic gate type of each event in the logical path; The logic gate types include OR gates and AND gates; Arrange the preset numbers of each event in hierarchical order from bottom event to top event, and insert the corresponding logic gate type identifier between adjacent preset numbers to obtain the arrangement sequence; The permuted sequence is converted into fault diagnosis codes using preset character conversion rules; The fault diagnosis code includes a fault type field, a fault source field, and a logical path verification field.

8. The Bluetooth headset terminal fault detection and remote maintenance method as described in claim 7, characterized in that, Step S3 specifically includes: A pre-defined circular buffer of a specific size is used as the fault log storage area within the non-volatile storage medium of the Bluetooth headset. The fault diagnosis codes are classified into general errors and fatal errors based on the fault type. The common errors include connection packet loss, transient signal-to-noise ratio degradation, and minor frame errors in audio decoding; The fatal errors include watchdog timeout, system deadlock, hardware bus anomaly, and battery overvoltage / undervoltage protection triggering. For common errors, a hash feature code is generated based on the current fault type and timestamp. The hash feature code is stored in the fault log storage area using a first-in-first-out strategy. When the fault log storage area is full, the oldest stored hash feature code is automatically overwritten. For fatal errors, extract key data at the moment of failure; The key data includes memory stack data, register status, and memory snapshots; The critical data is compressed and packaged using a lossless compression algorithm to obtain a compressed error package, which is then stored in the reserved sector of the fault log storage area.

9. The Bluetooth headset terminal fault detection and remote maintenance method as described in claim 8, characterized in that, Step S4 includes the following sub-steps: Step S401: Establish a Bluetooth connection between the Bluetooth headset terminal and the user terminal, encapsulate the fault diagnosis code into a data packet with a custom protocol format, and transmit it to the user terminal. The custom protocol format includes a start header, data length, fault diagnosis code, checksum, and end character; Step S402: Add a fault identifier to the data packet according to the fault type. Data packets with fatal error identifiers take priority over data packets with regular errors during transmission. In step S403, the user terminal receives the Bluetooth data packet with the added fault identifier, determines the transmission order according to the fault identifier, and converts the data packet into a readable text prompt according to the transmission order.

10. The Bluetooth headset terminal fault detection and remote maintenance method as described in claim 9, characterized in that, The process of converting data packets into readable text prompts specifically includes: Call the local preset fault code parsing library to query the readable text prompts corresponding to the data packet; The readable text prompts include the name of the faulty component, a description of the cause of the fault, and user-executable repair suggestions; The readable text prompts are rendered into a graphical user interface page and displayed on the user terminal's screen.

Images