A cross-platform bluetooth identity recognition broadcast scanning optimization method and system

Abstract

This invention relates to the field of IoT near-field identification technology, specifically disclosing a cross-platform Bluetooth identity recognition broadcast scanning optimization method and system. The method includes the following steps: S1, constructing broadcast packets using AD Structure format, the broadcast packets including basic AD fields and manufacturer-defined data fields; S2, automatically loading corresponding scanning parameter sets, customizing scanning parameters for different mobile phone systems and manufacturers to dynamically optimize the scanning strategy; S3, processing invalid broadcast packets through a three-level filtering mechanism; S4, dynamically adjusting the broadcast interval based on the interaction status between the device and the mobile phone and the system platform, reducing power consumption while ensuring recognition sensitivity. This invention, employing the above-mentioned cross-platform Bluetooth identity recognition broadcast scanning optimization method and system, can improve cross-platform recognition rate, increase response time, and effectively adapt to the needs of multiple scenarios such as shared devices and smart homes, possessing high practicality and promotional value.

Description

Technical Field

[0001] This invention relates to the field of IoT near-field identity recognition technology, and in particular to a cross-platform Bluetooth identity recognition broadcast scanning optimization method and system. Background Technology

[0002] Bluetooth near-field identification (NFC) technology is a key supporting technology for IoT device interaction. However, in practical applications, this technology faces core challenges such as insufficient cross-platform compatibility, low scanning efficiency, and complex system adaptation, making it difficult to meet the actual needs of efficient device interaction in IoT scenarios. Most existing technical solutions adopt a general broadcast and scanning strategy, failing to fully consider and optimize the underlying protocols of the three major operating systems—HarmonyOS, Android, and iOS—leading to a series of application defects. Specifically, the device recognition success rate in background mode on iOS is only 35%, and the average response latency on Android reaches 1.2 seconds, while MCU resource consumption peaks at 80%, severely impacting device stability and user experience.

[0003] The prominent problems of current Bluetooth near-field identification technology are mainly reflected in three aspects: First, there is fragmentation in system protocols. HarmonyOS uses a distributed Bluetooth architecture, Android has implemented a dynamic MAC address policy since Android 10, and iOS has strengthened privacy protection mechanisms and limited background scanning frequency since iOS 14. These differences make it difficult for a unified Bluetooth near-field identification solution to achieve cross-system compatibility, with a device cross-identification failure rate as high as 42%. Second, the scanning strategy is crude. Traditional technology uses a fixed interval, such as 500ms, to scan without considering the customization limitations of different manufacturers' operating systems, which leads to a surge in MCU processing load and affects the overall operating efficiency of the device. Third, data processing is inefficient. Existing solutions perform full parsing of all received broadcast packets, which contains a large amount of redundant data from non-target devices. This processing method results in a 75% wastage rate of instruction cycles for 32-bit MCUs, reducing device battery life to less than 3 months.

[0004] Meanwhile, with the rapid development of IoT technology, the demand for seamless Bluetooth near-field cross-system interaction is becoming increasingly urgent in various fields such as shared devices, smart homes, industrial IoT, and wearable devices. In the shared device field, typical devices include shared bicycles and power banks, which require high-frequency background scanning support from iOS and Android systems for normal operation, but existing technologies are insufficient to meet this requirement. In the smart home field, typical devices such as smart door locks and environmental sensors rely on the distributed device collaboration capabilities of the HarmonyOS system, and the cross-device UUID conflict problem in existing technologies has become a major obstacle. In the industrial IoT field, devices such as AGV robots and warehouse tags require low-power long-connection support from the Android system, but the problem of interference from concurrent scanning of multiple devices urgently needs to be solved. In the wearable device field, child locators and health monitoring devices face the problem of dynamic switching of privacy addresses in the iOS system, and the insufficient efficiency of RPA address verification affects the normal identification function of the devices.

[0005] Therefore, a systematic technological breakthrough is urgently needed to solve the above-mentioned technical pain points and fill the gap in cross-platform adaptation technology in the field of IoT near-field identification. Summary of the Invention

[0006] The purpose of this invention is to provide a cross-platform Bluetooth identity recognition broadcast scanning optimization method and system to solve the problems of poor cross-platform compatibility, low scanning efficiency, high MCU load, and excessive power consumption in the prior art, and to achieve collaborative optimization of seamless interaction between multiple systems, efficient identification, and low power consumption operation.

[0007] To achieve the above objectives, this invention provides a cross-platform Bluetooth identity recognition broadcast scanning optimization method, comprising the following steps: S1. Broadcast packets are constructed using the AD Structure format. Broadcast packets include basic AD fields and vendor-defined data fields. S2. Automatically load the corresponding scan parameter set and customize scan parameters for different mobile phone systems and manufacturers to dynamically optimize the scan strategy; S3. Invalid broadcast packets are processed through a three-level filtering mechanism; S4. Based on the interaction status between the device and the mobile phone and the system platform, dynamically adjust the broadcast interval to reduce power consumption while ensuring recognition sensitivity.

[0008] Preferably, in S1, the basic AD field includes a Flags field and a service UUID field. The Flags field has a length of 0x02, which is 2 bytes; the data type Type=0x01 indicates that it is data of the Flags device capability flag type; the value is 0x06, indicating that the device is in limited discoverable mode and only supports BLE. The service UUID field uses 16-bit little-endian encoding and has a length of 0x03, or 3 bytes; the data type Type=0x06 indicates that it is a 16-bit service UUID type; the value 0xFE60 is a vendor-defined service UUID value.

[0009] Preferably, in S1, the data type of the manufacturer-defined data field is Type=0xFF. The manufacturer-defined data field includes a 2-byte manufacturer ID, a 1-byte device type identifier, a 1-byte status code, and a 1-byte CRC8 checksum. The manufacturer ID is fixed at 0xAA55 and is used for fast filtering of devices at the hardware layer. The device type identifier is set to 0x01 to indicate that the device is a shared device, 0x02 to indicate that the device is a smart home device, and 0x03 to indicate that the device is an industrial device. A status code of 0x00 indicates that the device is in standby mode, 0x01 indicates that the device is being authorized, and 0x02 indicates that the device has malfunctioned. The CRC8 checksum is calculated using the polynomial 0x07, with an initial value of 0x00. The checksum range covers the manufacturer ID to the status code, ensuring the integrity of data transmission.

[0010] Preferably, in S2, based on the manufacturer ID list pre-configured at the factory, the type of mobile phone system currently connected is identified, the corresponding scanning parameter set is automatically loaded, and the scanning parameters are customized for different mobile phone systems and manufacturers. The mobile operating systems include HarmonyOS, Android, and iOS; the scanning parameters include scanning interval, window, and channel priority; the dynamic optimization process of the scanning strategy is as follows: The HarmonyOS system is set with a scan interval of 1000ms and a scan window of 500ms, prioritizing the scan of channels 37 or 38; Android system settings: scan interval 200ms~500ms, scan window 100ms~200ms, full channel polling of channels 37, 38, and 39, or limit broadcast packet length to ≤28 bytes; The iOS system is set to a scan interval of 5000ms, a scan window of 100ms, and only responds to broadcast packets with the vendor ID.

[0011] Preferably, in S3, the three-level filtering mechanism for handling invalid broadcast packets includes hardware-level pre-filtering, communication-level extraction of vendor-defined data fields, and algorithm-level verification of CRC8 values. The hardware-layer pre-filtering process is as follows: the Bluetooth module configures the vendor ID through hardware registers and automatically discards broadcast packets with Type ≠ 0xFF or vendor ID ≠ 0xAA55; The process of extracting vendor-defined data fields at the communication layer is as follows: for packets that have passed the hardware layer pre-filtering, only the vendor-defined data fields are extracted, while other AD fields are ignored; The process of verifying the value of the CRC8 code at the algorithm layer is as follows: the value of the CRC8 check code is calculated using the polynomial 0x07, and compared with the check bit in the packet. If they do not match, the packet is discarded.

[0012] Preferably, in S4, the broadcast interval is dynamically adjusted through state machine control switching logic. The specific strategy includes the following steps: S41. Initialization mode uses a 200ms interval for rapid device connection establishment; S42, Normal Mode adapts to 500ms or 200ms intervals depending on the system type to balance response speed and power consumption; S43, in sleep mode, uses a 2000ms interval to achieve the lowest power consumption operation.

[0013] Preferably, in S4, the trigger conditions for each mode switching are as follows: If the target device is not detected for 3 consecutive times, switch from initialization mode to daily mode; If there are no scan requests within 10 seconds, switch from normal mode to sleep mode; If a scan request with the target vendor ID is detected, wake up from hibernation mode to normal mode.

[0014] This invention also provides a cross-platform Bluetooth identity recognition broadcast scanning optimization system, comprising: The Hardware Abstraction Layer (HAL) is used to encapsulate Bluetooth module control, UART communication, and Flash storage, and provides a unified API interface including ble_init() and uart_send(). The communication layer is used to parse BLE protocol stack data, extract broadcast packet AD structure, RSSI value and device address, and quickly locate and extract vendor-defined data fields. The algorithm layer includes a broadcast packet generation module for AD structure assembly and CRC verification; a scanning filtering module for vendor ID verification and CRC verification; and a cross-platform adaptation module for system identification and parameter adjustment. The application layer executes authorization logic based on the output of the algorithm layer and manages the system state through an event-driven mechanism.

[0015] Therefore, the present invention employs the above-mentioned cross-platform Bluetooth identity recognition broadcast scanning optimization method and system, and the beneficial effects are as follows: (1) This invention achieves seamless compatibility with HarmonyOS, Android, iOS and mainstream mobile phone manufacturers through customized broadcast packet structure and scanning parameter set, with a recognition success rate of ≥98% and iOS background mode response time ≤780ms, which is 64% shorter than the prior art and solves the recognition failure problem caused by system protocol fragmentation.

[0016] (2) The three-level filtering mechanism of this invention increases the invalid broadcast packet drop rate to over 90%, the non-target packet filtering speed is 240 times faster than the traditional solution, the average load of the 32-bit MCU is reduced from 80.3% to 7.8%, and the peak load is ≤15%, ensuring stable operation of the equipment.

[0017] (3) This invention supports multiple application scenarios such as shared devices, smart homes, and industrial IoT. It can customize device parameters according to different scenarios. At the same time, it adopts a modular architecture design, which has strong code portability, low hardware cost, and facilitates large-scale promotion and application.

[0018] The technical solution of the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. Attached Figure Description

[0019] Figure 1 This is an overall flowchart of an embodiment of a cross-platform Bluetooth identity recognition broadcast scanning optimization method of the present invention; Figure 2 This is a schematic diagram of the broadcast packet structure of an embodiment of the broadcast scanning optimization method for cross-platform Bluetooth identity recognition according to the present invention; Figure 3 This is a flowchart illustrating the dynamic optimization of the scanning strategy in an embodiment of a cross-platform Bluetooth identity recognition broadcast scanning optimization method of the present invention. Detailed Implementation

[0020] The technical solution of the present invention will be further described below with reference to the accompanying drawings and embodiments.

[0021] Unless otherwise defined, the technical or scientific terms used in this invention shall have the ordinary meaning as understood by one of ordinary skill in the art to which this invention pertains.

[0022] This invention achieves precise control of cross-platform Bluetooth near-field identification through a layered, decoupled architecture. Its core comprises four major technical modules: dynamic adaptation of broadcast packet structure, intelligent adjustment of scanning strategy, optimization of data filtering algorithm, and adaptive broadcast interval. These modules work collaboratively through standardized interfaces, forming a complete technical chain from hardware layer signal transmission and reception to communication layer protocol parsing, algorithm layer intelligent decision-making, and application layer authorization response. This solution maintains a hardware cost of less than 8 yuan while increasing the cross-platform identification success rate to 98% and optimizing MCU processing efficiency by 90%, providing underlying technical support for seamless interaction of IoT devices.

[0023] like Figure 1 As shown, a cross-platform Bluetooth identity recognition broadcast scanning optimization method includes the following steps: S1. Use AD Structure format to construct broadcast packets. Broadcast packets include basic AD fields and vendor-defined data fields.

[0024] The broadcast packets use the AD Structure (LTV) format defined by the Bluetooth core specification, with a strict total length limit of ≤31 bytes to adapt to iOS system restrictions. Device identification is achieved quickly through manufacturer-defined data fields. For example... Figure 2 As shown, the total length of the broadcast packet in this invention is 10 bytes ≤ 31 bytes, which meets the requirements of iOS.

[0025] The basic AD field has a total length of 5 bytes, including the Flags field and the service UUID field. The Flags field has a length of 0x02, which is 2 bytes. The data type Type=0x01 indicates that it is data of the Flags device capability flag type. The value is 0x06, indicating that the device is in limited discoverable mode and only supports BLE.

[0026] The service UUID field uses 16-bit little-endian encoding, with a length of 0x03 (3 bytes); data type Type=0x06 indicates it is a 16-bit service UUID; a value of 0xFE60 represents a vendor-defined service UUID value. Differences in cross-system basic AD field settings are shown in Table 1. Table 1. Cross-system field differences

[0027] The vendor-defined data field is 5 bytes long, with data type Type=0xFF. This field includes a 2-byte vendor ID, a 1-byte device type identifier, a 1-byte status code, and a 1-byte CRC8 checksum. The vendor ID is a fixed value of 0xAA55, used for rapid device filtering at the hardware layer. The device type identifier is set to 0x01 for shared devices, 0x02 for smart home devices, and 0x03 for industrial devices.

[0028] Status codes 0x00 indicate the device is in standby mode, 0x01 indicates the device is being authorized, and 0x02 indicates a device malfunction. The CRC8 checksum is calculated using a polynomial of 0x07, with an initial value of 0x00. The checksum covers the vendor ID to the status code, ensuring data transmission integrity.

[0029] S2, such as Figure 3 As shown, based on the list of manufacturer IDs pre-configured at the factory, the system identifies the type of mobile phone system currently connected during the startup phase, realizing closed-loop control of "system identification - parameter matching - dynamic adjustment". Among them, the mobile phone system includes HarmonyOS, Android and iOS.

[0030] The system automatically loads the corresponding scan parameter set, customizing scan parameters for different mobile phone systems and manufacturers. These parameters include scan interval, scan window, and channel priority. The dynamic optimization process of the scan strategy is as follows: The HarmonyOS system is set with a scanning interval of 1000ms and a scanning window of 500ms, prioritizing the scanning of channels 37 or 38 to improve the discovery priority of distributed devices.

[0031] Android system settings: scan interval 200ms~500ms, scan window 100ms~200ms, full channel polling of channels 37, 38, and 39, or limit broadcast packet length to ≤28 bytes.

[0032] For Xiaomi phones of brand B, set the scan interval to 200ms, the scan window to 100ms, and poll all channels (37, 38, or 39) to adapt to MIUI's background scanning restrictions. For phones of brand C, set the scan interval to 500ms, the scan window to 200ms, and limit the broadcast packet length to ≤28 bytes to avoid ColorOS filtering long packets.

[0033] The iOS system is set to scan at a 5000ms interval and scan window at 100ms, and only responds to broadcast packets with the vendor ID to compensate for the low background scanning frequency of iOS.

[0034] HarmonyOS Enhancement Strategy: By adding a service UUID (0000FE60-0000-1000-8000-00805F9B34FB) to the broadcast packet, HarmonyOS devices will mark the device of this invention as a "high-priority service", improving the scanning response speed by 40%.

[0035] S3. To address the resource waste caused by the MCU's full parsing of broadcast packets in traditional scanning schemes, an invalid broadcast packet processing mechanism is implemented.

[0036] The three-level filtering mechanism of this invention for handling invalid broadcast packets includes hardware-level pre-filtering, communication-level extraction of vendor-defined data fields, and algorithm-level verification of CRC8 values. This reduces the processing time for invalid broadcast packets from 12ms to 1.2ms, and reduces the MCU load by 90%.

[0037] The hardware-layer pre-filtering process is as follows: The Bluetooth module configures the vendor ID (0xAA55) through the hardware register and automatically discards broadcast packets with Type ≠ 0xFF or the first 2 bytes of Value, i.e., vendor ID ≠ 0xAA55.

[0038] The process of extracting vendor-defined data fields at the communication layer is as follows: for packets that have passed the hardware layer pre-filtering, only the vendor-defined data fields (0xFF type) are extracted, while other AD fields are ignored.

[0039] The process of verifying the CRC8 checksum value at the algorithm layer is as follows: the CRC8 checksum value is calculated using the polynomial 0x07, and compared with the check bits in the packet; if they do not match, the packet is discarded. The efficiency is greatly improved through a three-level filtering mechanism, as shown in Table 2. Table 2 Efficiency Comparison

[0040] S4. Based on the interaction status between the device and the mobile phone and the system platform, dynamically adjust the broadcast interval to reduce power consumption while ensuring recognition sensitivity.

[0041] The broadcast interval of this invention is set to a range of 200ms-2s. The broadcast interval is dynamically adjusted through state machine control switching logic. The specific strategy includes the following steps: S41. In initialization mode, HarmonyOS / Android foreground, iOS foreground or iOS background all use a 200ms interval to quickly establish device connection.

[0042] S42. In daily mode, the interval is adapted to 500ms or 200ms depending on the system type to balance response speed and power consumption. Specifically, the interval is 500ms for HarmonyOS / Android foreground and iOS foreground, and 200ms for iOS background.

[0043] S43. In sleep mode, HarmonyOS / Android foreground, iOS foreground or iOS background all use a 2000ms interval to achieve the lowest power consumption operation.

[0044] The trigger conditions for switching between modes in this invention are as follows: If the target device is not detected for 3 consecutive times, switch from initialization mode to daily mode.

[0045] If there are no scan requests within 10 seconds, switch from normal mode to sleep mode.

[0046] If a scan request with the target vendor ID is detected, wake up from hibernation mode to normal mode.

[0047] In iOS background compensation, when an iOS device is detected in background mode through a specific AD field, a 200ms interval is forced to offset the reduced iOS background scanning frequency, increasing the frequency from 1Hz to 5Hz.

[0048] This invention implements cross-platform Bluetooth near-field identification functionality based on a general-purpose embedded hardware platform and modular software architecture. The core functionality is implemented in C language, with key algorithms including broadcast packet generation, scanning filtering, and platform adaptation. The system employs a three-level decoupled design—hardware abstraction layer, communication layer, and algorithm layer—ensuring code portability and hardware independence. Furthermore, algorithm optimization keeps single-identification power consumption below 0.5mJ, meeting the battery life requirement of over 6 months for the CR2032 battery.

[0049] This invention provides a cross-platform Bluetooth identity recognition broadcast scanning optimization system for implementing the above-mentioned method. The system adopts a bottom-up layered architecture, with each layer enabling unidirectional data flow through standardized interfaces. The specific architecture includes: The Hardware Abstraction Layer (HAL) encapsulates low-level operations such as Bluetooth module control (initialization, broadcast / scan parameter configuration), UART communication (115200bps baud rate, 8N1 format, hardware flow control RTS / CTS), and Flash storage (encrypted partition storage device key), providing unified API interfaces including ble_init() and uart_send().

[0050] The communication layer is used to parse BLE protocol stack data (LTV format), extract broadcast packet AD structure, RSSI value and device address, and quickly locate and extract vendor-defined data fields.

[0051] The algorithm layer is the processing unit of this system, including a broadcast packet generation module for AD structure assembly and CRC verification; a scanning and filtering module for vendor ID verification and CRC verification; and a cross-platform adaptation module for system identification and parameter adjustment.

[0052] The application layer executes authorization logic (such as relay control and indicator light feedback) based on the output of the algorithm layer, and manages the system status through an event-driven mechanism, which is either in standby, identification, or authorization mode.

[0053] The core functions of the system of this invention are as follows: Low power management: The system supports MCU Stop2 mode, in which the current is ≤10μA and the Bluetooth module is in deep sleep mode, with the current ≤5μA during sleep. It is triggered to wake up by events such as UART interrupt and timer interrupt.

[0054] Encrypted storage: The system uses AES-128 hardware encryption to encrypt the IRK key and vendor ID of the partitioned storage device to prevent data leakage after physical disassembly.

[0055] System diagnostics: The system monitors the RSSI fluctuation of Bluetooth signal quality and battery voltage in real time. When the battery voltage is ≤2.8V, a low battery alarm is triggered, and debugging information is output via UART.

[0056] Example 1: To verify the practical effectiveness of the cross-platform Bluetooth near-field identification technology of this invention, the testing team conducted multi-dimensional tests in a standardized electromagnetic compatibility laboratory and real-world application scenarios, covering three core indicators: cross-platform compatibility, scanning efficiency, and power consumption characteristics. The tests employed the controlled variable method, comparing key data from traditional general solutions with the optimized solution of this invention to quantitatively verify the performance improvements brought about by the dynamic broadcast strategy, vendor data filtering, and system adaptation algorithm. The testing environment strictly followed GB / T30257-2013 "Technical Requirements for Data Interaction in the IoT Sensing Layer," and key equipment included a Bluetooth protocol analyzer (Ellisys BEX400), a high-precision current logger (Keithley 2450), and mainstream brand smartphone terminals.

[0057] I. Cross-platform compatibility testing: Six mainstream mobile devices operating systems (HarmonyOS, Android, and iOS) were selected for testing of recognition success rate and response time within a distance range of 0.5-5 meters. A total of 500 valid samples were tested on each device (including indoor multi-partition and semi-open corridor scenarios). The results are shown in Table 3 below. Table 3 Comparison of Recognition Success Rate and Response Time

[0058] As shown in Table 3, the probability of broadcast packets being scanned by the system increased from 42% to 95% for Brand A models by prioritizing the service UUID (0000FE60); Brand B / C models solved the MIUI background scanning suppression problem by dynamically adjusting the scanning interval (200ms / 500ms) and packet length limit (28-byte adaptation).

[0059] The iOS model uses a 200ms broadcast interval to compensate for the background scanning frequency loss, increasing it from 1Hz to 5Hz. Combined with the SCAN_RSP ignore mechanism, the response time is reduced by 64%. No cases of three consecutive recognition failures occurred during the test, and abnormal situations such as signal obstruction can be recovered within 3 scan cycles.

[0060] II. Scanning Efficiency and MCU Load Testing: In an indoor multi-device interference scenario (with 20 non-target Bluetooth devices broadcasting simultaneously), the MCU resource usage of the traditional full-data parsing solution and the data filtering solution of this invention were compared. The test tool used was the code coverage analysis function of IAR EmbeddedWorkbench, and the results are as follows: MCU load comparison, based on a 32-bit MCU, 32MHz main frequency environment, test duration is 10 minutes: The traditional solution has an average instruction cycle utilization rate of 80.3%, with a peak of 92%, because it performs full parsing of non-target packets and invalid data processing accounts for 75%.

[0061] The average instruction cycle utilization rate of the solution of this invention is 7.8%, with a peak of 15%, because the vendor ID pre-filtering mechanism reduces the proportion of invalid data processing to 9%.

[0062] Broadcast packet processing efficiency: Non-target packet filtering speed: The hardware layer pre-filtering time of the present invention is ≤50μs / packet, which is 240 times faster than the 12ms / packet of software full parsing.

[0063] Target packet extraction time: The average parsing time of a single packet in this invention is 1.2ms, which includes the complete process of AD structure traversal, vendor ID verification, and CRC verification.

[0064] Concurrent processing capability: The solution of this invention supports identification requests of ≥20 target devices / second, which can meet the needs of multi-user scenarios with shared devices.

[0065] Typical Case: In the C brand Find X5 model test, the traditional solution was not adapted to the 28-byte broadcast packet length limit of ColorOS, resulting in 41% of the target packets being dropped by the system. After optimization, by dynamically adjusting the length of the manufacturer's data field, compressing it from 6 bytes to 5 bytes, and with the compact arrangement of the AD structure, the packet length was controlled at 26 bytes, and the filtering pass rate was improved to 99.2%.

[0066] III. Power Consumption and Battery Life Tests: Powered by a 220mAh CR2032 button cell battery, the average power consumption and theoretical battery life of the system were tested under different operating modes. A dynamic broadcast interval strategy was adopted, with a broadcast interval of 500ms in daily mode and 2000ms in sleep mode. The test results are shown in Table 4 below: Table 4 Comparison of average power consumption and theoretical battery life of the test system under different operating modes

[0067] As can be seen from Table 4, the details of the power consumption optimization in this invention are as follows: The dynamic broadcast interval allows the system to automatically switch to a 2000ms interval when there is no interaction, reducing broadcast power consumption by 60% compared to a fixed 500ms interval. The manufacturer's data filtering algorithm reduces the number of MCU wake-ups from 10 times per second to 1 time per second, increasing the duty cycle of sleep mode to 95%.

[0068] The Bluetooth module's deep sleep mechanism (current ≤ 5μA) works in conjunction with the MCU's Stop2 mode (current ≤ 10μA) to ultimately control the idle power consumption to 8.7μA.

[0069] Extreme scenario verification: In the background mode of E-brand 13 Pro, with a broadcast interval of 200ms, the CR2032 battery achieved a test battery life of 31.2 days, meeting the commercial requirement of "battery replacement every six months" for shared devices; in daily mode, the battery life exceeded 60 days, which is 220% better than traditional solutions.

[0070] Therefore, the present invention adopts the above-mentioned cross-platform Bluetooth identity recognition broadcast scanning optimization method and system, which can effectively solve the pain points of the prior art, realize the synergistic optimization of cross-platform compatibility, efficient identification and low power consumption operation, and has high practicality and promotion value.

[0071] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and not to limit them. 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 still be made to the technical solutions of the present invention, and these modifications or equivalent substitutions cannot cause the modified technical solutions to deviate from the spirit and scope of the technical solutions of the present invention.

Claims

1. A cross-platform Bluetooth identity recognition broadcast scanning optimization method, characterized in that, Includes the following steps: S1. Broadcast packets are constructed using the AD Structure format. Broadcast packets include basic AD fields and vendor-defined data fields. S2. Automatically load the corresponding scan parameter set and customize scan parameters for different mobile phone systems and manufacturers to dynamically optimize the scan strategy; S3. Invalid broadcast packets are processed through a three-level filtering mechanism; S4. Based on the interaction status between the device and the mobile phone and the system platform, dynamically adjust the broadcast interval to reduce power consumption while ensuring recognition sensitivity.

2. The cross-platform Bluetooth identity recognition broadcast scanning optimization method according to claim 1, characterized in that, In S1, the basic AD field includes the Flags field and the service UUID field. The Flags field has a length of 0x02, which is 2 bytes; the data type Type=0x01 indicates that it is data of the Flags device capability flag type; the value is 0x06, indicating that the device is in limited discoverable mode and only supports BLE. The service UUID field uses 16-bit little-endian encoding and has a length of 0x03, or 3 bytes; the data type Type=0x06 indicates that it is a 16-bit service UUID type; the value 0xFE60 is a vendor-defined service UUID value.

3. The cross-platform Bluetooth identity recognition broadcast scanning optimization method according to claim 2, characterized in that, In S1, the vendor-defined data field has a data type type of Type=0xFF. The vendor-defined data field includes a 2-byte vendor ID, a 1-byte device type identifier, a 1-byte status code, and a 1-byte CRC8 checksum. The vendor ID is fixed at 0xAA55 and is used for fast device filtering at the hardware layer. The device type identifier is set to 0x01 to indicate that the device is a shared device, 0x02 to indicate that the device is a smart home device, and 0x03 to indicate that the device is an industrial device. A status code of 0x00 indicates that the device is in standby mode, 0x01 indicates that the device is being authorized, and 0x02 indicates that the device has malfunctioned. The CRC8 checksum is calculated using the polynomial 0x07, with an initial value of 0x00. The checksum range covers the manufacturer ID to the status code, ensuring the integrity of data transmission.

4. The cross-platform Bluetooth identity recognition broadcast scanning optimization method according to claim 3, characterized in that, In S2, based on the list of manufacturer IDs pre-configured when the device leaves the factory, the type of mobile phone system currently connected is identified, and the corresponding scanning parameter set is automatically loaded, and scanning parameters are customized for different mobile phone systems and mobile phone manufacturers. The mobile operating systems include HarmonyOS, Android, and iOS; the scanning parameters include scanning interval, window, and channel priority; the dynamic optimization process of the scanning strategy is as follows: The HarmonyOS system is set with a scan interval of 1000ms and a scan window of 500ms, prioritizing the scan of channels 37 or 38; Android system settings: scan interval 200ms~500ms, scan window 100ms~200ms, full channel polling of channels 37, 38, and 39, or limit broadcast packet length to ≤28 bytes; The iOS system is set to a scan interval of 5000ms, a scan window of 100ms, and only responds to broadcast packets with the vendor ID.

5. The cross-platform Bluetooth identity recognition broadcast scanning optimization method according to claim 4, characterized in that, In S3, the three-level filtering mechanism handles invalid broadcast packets by including hardware-level pre-filtering, communication-level extraction of vendor-defined data fields, and algorithm-level verification of CRC8 values. The hardware-layer pre-filtering process is as follows: the Bluetooth module configures the vendor ID through hardware registers and automatically discards broadcast packets with Type ≠ 0xFF or vendor ID ≠ 0xAA55; The process of extracting vendor-defined data fields at the communication layer is as follows: for packets that have passed the hardware layer pre-filtering, only the vendor-defined data fields are extracted, while other AD fields are ignored; The process of verifying the value of the CRC8 code at the algorithm layer is as follows: the value of the CRC8 check code is calculated using the polynomial 0x07, and compared with the check bit in the packet. If they do not match, the packet is discarded.

6. The cross-platform Bluetooth identity recognition broadcast scanning optimization method according to claim 5, characterized in that, In S4, the broadcast interval is dynamically adjusted through state machine control switching logic. The specific strategy includes the following steps: S41. Initialization mode uses a 200ms interval for rapid device connection establishment; S42, Normal Mode adapts to 500ms or 200ms intervals depending on the system type to balance response speed and power consumption; S43, in sleep mode, uses a 2000ms interval to achieve the lowest power consumption operation.

7. The cross-platform Bluetooth identity recognition broadcast scanning optimization method according to claim 6, characterized in that, In S4, the trigger conditions for switching between modes are as follows: If the target device is not detected for 3 consecutive times, switch from initialization mode to daily mode; If there are no scan requests within 10 seconds, switch from normal mode to sleep mode; If a scan request with the target vendor ID is detected, wake up from hibernation mode to normal mode.

8. A cross-platform Bluetooth identity recognition broadcast scanning optimization system, used to implement the method according to any one of claims 1-7, characterized in that, include: The Hardware Abstraction Layer (HAL) is used to encapsulate Bluetooth module control, UART communication, and Flash storage, and provides a unified API interface including ble_init() and uart_send(). The communication layer is used to parse BLE protocol stack data, extract broadcast packet AD structure, RSSI value and device address, and quickly locate and extract vendor-defined data fields. The algorithm layer includes a broadcast packet generation module for AD structure assembly and CRC verification; a scanning filtering module for vendor ID verification and CRC verification; and a cross-platform adaptation module for system identification and parameter adjustment. The application layer executes authorization logic based on the output of the algorithm layer and manages the system state through an event-driven mechanism.

Images