A hybrid networking clock synchronization system based on master-slave architecture

Abstract

This invention discloses a hybrid network clock synchronization system based on a master-slave architecture, comprising a master unit and at least one slave unit. The master unit includes a first microprocessor, a Wi-Fi communication module, and a first BLE communication module. The slave unit includes a second microprocessor, a second BLE communication module, and a clock display module. The first microprocessor of the master unit accesses the network via the Wi-Fi communication module to obtain network clock data and environmental weather data. It extracts core fields from the data, encapsulates them into a synchronization data packet containing a feature identification code and payload data, and controls the first BLE communication module to send this synchronization data packet to the slave unit. The second microprocessor of the slave unit receives the synchronization data packet via the second BLE communication module, parses the payload data according to a preset decoding mapping table and the feature identification code, obtains the synchronization time value and weather parameters, thereby updating local data and controlling the clock display module to refresh the display. This effectively solves the technical problems of edge node computing power overload and excessive network energy consumption.

Description

Technical Field

[0001] This invention relates to the field of electronic clocks and Internet of Things (IoT) wireless communication technology, and more specifically, to a hybrid networking clock synchronization system based on a master-slave architecture. Background Technology

[0002] Currently, electronic clocks primarily rely on broadband networks such as Wi-Fi to obtain network time and environmental information. In multi-node deployment scenarios, to reduce terminal power consumption, a master-slave networking scheme is often adopted, where the master node acquires information via the internet and the slave nodes receive it via Bluetooth. However, existing technologies have the following significant shortcomings in the system's data processing algorithms and control logic: First, existing data distribution mechanisms typically transmit raw structured data (such as JSON or XML format) sent by the network server directly or after simple truncation to each slave node via Bluetooth. Because these data packets contain a large amount of redundant descriptive strings, they not only easily exceed the payload limit of Bluetooth Low Energy (BLE) single-packet transmission, causing a surge in packet transmission time, but also force the edge-side slave microprocessors to expend significant computing power and memory to perform complex string parsing and verification operations, creating a serious "computing power and energy consumption bottleneck" at the logical level.

[0003] Secondly, regarding communication timing control, to ensure the real-time display of terminal data, existing synchronization logic often employs a mechanism where the master and slave maintain a long-term connection or high-frequency polling. This crude control method, lacking dynamic timing management and sleep / wake-up scheduling, keeps the device's RF transceiver circuits active for extended periods, making it impossible to minimize the system's overall power consumption at the software scheduling level.

[0004] Furthermore, since low-power slave nodes often lack physical interaction buttons and complex display interfaces (i.e., dumb terminal devices), existing network configuration verification logic is extremely inadequate. In densely deployed environments such as apartments or office buildings, slave devices that use factory default fixed keys for Bluetooth communication are highly susceptible to signal crosstalk and misconnection with other similar networks in adjacent areas. Moreover, it is difficult for users to securely and asynchronously send personalized parameters such as sampling frequency and synchronization period to designated nodes.

[0005] In summary, how to thoroughly solve the problems of edge node computing power overload, excessive network energy consumption, and crosstalk prevention at the control logic level by optimizing data preprocessing and high compression ratio encapsulation algorithms, designing precise low-power timing scheduling logic, and building a secure asynchronous networking authentication mechanism is a technical problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0006] To address the technical problems of edge node computing power overload, excessive network energy consumption, and crosstalk prevention in existing technologies, this invention provides a hybrid networking clock synchronization system based on a master-slave architecture.

[0007] This invention provides a hybrid network clock synchronization system based on a master-slave architecture, comprising a master unit and at least one slave unit. The master unit includes a first microprocessor, a Wi-Fi communication module, and a first BLE communication module. The slave unit includes a second microprocessor, a second BLE communication module, and a clock display module. The first microprocessor of the master unit is configured to: access the network via the Wi-Fi communication module and acquire network clock data and environmental weather data; extract core fields from the data and encapsulate the extracted core fields into a synchronization data packet containing a feature identification code and payload data; and control the first BLE communication module to send the synchronization data packet to the slave unit. The second microprocessor of the slave unit is configured to: receive the synchronization data packet via the second BLE communication module; parse the payload data according to a preset decoding mapping table and the feature identification code to obtain a synchronization time value and weather parameters; update local data according to the synchronization time value and weather parameters; and control the clock display module to refresh the display.

[0008] Furthermore, the structure of the synchronization data packet includes, in sequence: a feature identification code, payload data, and a check code; the feature identification code includes a time data identifier and a weather data identifier.

[0009] Furthermore, when the first microprocessor of the host encapsulates the synchronization data packet, its data compression logic includes: extracting the weather condition description, the highest temperature value, and the lowest temperature value from the environmental weather data; replacing the string-formatted weather condition description with a 1-byte hexadecimal mapped value; replacing the highest temperature value with a 1-byte signed value; and replacing the lowest temperature value with a 1-byte signed value.

[0010] Furthermore, the logic for the second microprocessor of the slave device to parse the payload data includes: identifying the feature identification code; if it is a weather data identifier, extracting the corresponding hexadecimal mapping value; calling the decoding mapping table in the local memory to restore the hexadecimal mapping value to the corresponding weather condition icon index and temperature value; verifying the data integrity of the verification code; and triggering the clock display module to refresh after the verification is successful.

[0011] Furthermore, the first microprocessor has a timing-based working state switching logic: during non-communication phases, the control host is in a sleep state; after a preset trigger time is reached, the WIFI communication module is woken up to acquire data; after acquisition is completed, the WIFI communication module is turned off and the server mode of the first BLE communication module is turned on; after data transmission is completed within the listening time or the listening time limit is reached, the first BLE communication module is turned off and re-enters the sleep state.

[0012] Furthermore, the second microprocessor controls the second BLE communication module to adopt a low-power scan response mode. When not connected to the host, it sends broadcast messages at a preset broadcast interval and responds to asynchronous connection requests from external mobile terminals to receive local function configuration parameters.

[0013] Furthermore, the automatic networking logic of the system is as follows: the host and the slave have a unified default key pre-stored in their respective memory; the slave receives a custom key sent by an external mobile terminal and overwrites the local default key with the custom key; the slave synchronizes the custom key to the host through the second BLE communication module, and the host and the slave subsequently match and connect based on the custom key.

[0014] Furthermore, the local function configuration parameters received by the slave device include at least: the period duration for the host to access WIFI and acquire data, the duration for the host to enable BLE server mode, and the sampling frequency for the slave device's local data acquisition.

[0015] Furthermore, the host also includes a host display module electrically connected to the first microprocessor. While encapsulating the synchronization data packet, the first microprocessor updates the content of the host display module based on the acquired network clock data and environmental weather data.

[0016] Furthermore, the slave device also includes a temperature and humidity acquisition module and a power monitoring module electrically connected to the second microprocessor. The second microprocessor is configured to periodically acquire local ambient temperature and humidity data and battery power data, and after establishing a connection with the host, upload the above data to the host through the second BLE communication module.

[0017] The beneficial effects of this invention are as follows: Ultimate data compression and parsing mechanism: By extracting core fields on the host side and generating hexadecimal mapping values ​​through table lookups, massive amounts of structured data such as network JSON are losslessly compressed into extremely small byte packets. This not only aligns with BLE's short packet transmission characteristics but also completely eliminates the complex string parsing process on the slave side, effectively solving the problems of edge node computing power overload and excessive network transmission energy consumption.

[0018] Global low-power timing control: The host adopts a timing-based state machine switching logic, which quickly enters a deep sleep state with extremely low power consumption after acquiring data and short-term communication. This breaks the extensive management of maintaining long-term connections or high-frequency polling in existing technologies and greatly extends the battery life of the system.

[0019] Secure and anti-crosstalk asynchronous networking: To address the difficulty of configuring dumb terminal devices for networking, this invention introduces an external mobile terminal to asynchronously distribute custom keys, and the slave device leads the synchronization of underlying parameters to overwrite the default key, achieving seamless and secure physical isolation and completely solving the problems of device misconnection and signal crosstalk in densely deployed environments. Attached Figure Description

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

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

[0022] Figure 1 This is a system overall architecture diagram provided in the embodiments of the present invention; Figure 2 This is a hardware functional block diagram of the host and slave provided in an embodiment of the present invention; Figure 3 This is a host workflow control diagram provided in an embodiment of the present invention; Figure 4 This is a schematic diagram of the synchronization data packet structure and compression mapping provided in an embodiment of the present invention; Figure 5 This is a host low-power timing state transition diagram provided in an embodiment of the present invention; Figure 6 This is a timing diagram for automatic networking and custom key synchronization provided in an embodiment of the present invention. Detailed Implementation

[0023] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0024] In the description of this invention, unless otherwise stated, "a plurality of" means two or more; the terms "center," "longitudinal," "lateral," "upper," "lower," "left," "right," "inner," "outer," "front end," "rear end," "head," "tail," "vertical," "horizontal," "top," "bottom," "inner," and "outer," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings, and are only for the convenience of describing the invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of the invention. Furthermore, the terms "first," "second," "third," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance.

[0025] Example 1: Hybrid Networked Clock Synchronization System and Hardware Topology Based on Master-Slave Architecture; Combination Figure 1 (System Overall Architecture Diagram) and Figure 2 (Hardware functional block diagram of master and slave devices) As shown, this embodiment provides a hybrid network clock synchronization system based on a master-slave architecture. The system mainly consists of a master and at least one slave device (multiple slave devices are used as an example in this embodiment, such as slave 1, slave 2 to slave N). The master acts as the data hub and gateway of the system, responsible for high-power, large-volume data interaction with the external network (NTP network time server, weather forecast server); the slave devices act as distributed terminal nodes, responsible for accurate time display and collection of local environmental data.

[0026] 1. To address the limitation of existing technologies due to the black-box nature of algorithms, this embodiment provides detailed specifications for the underlying hardware structure of the host. For example... Figure 2As shown, the host hardware structure includes a first microprocessor, a WIFI communication module, a first BLE communication module, and a host display module. In a preferred embodiment, the first microprocessor, the WIFI communication module, and the first BLE communication module can be integrated into the same SoC (System-on-Chip), such as Espressif Systems' ESP32-C3 or ESP32-S3 series chips. These chips integrate a 32-bit RISC-V single-core or dual-core processor with a clock speed of up to 160MHz, and simultaneously integrate 2.4 GHz Wi-Fi and Bluetooth 5 (LE) radio frequency circuitry. This highly integrated design not only reduces the size of the PCBA (Printed Circuit Board Assembly) but also avoids the additional power consumption and latency associated with communication between different chips via UART / SPI. In another preferred embodiment, if the host needs to drive a large-size or high-resolution host display module (such as a large-size TFT-LCD color screen or a multi-segment e-ink screen), the first microprocessor can be an independent microcontroller (such as STMicroelectronics' STM32L4 series ultra-low-power MCU), with an independent WIFI / BLE transparent transmission module externally connected via SDIO or SPI bus. The host display module is electrically connected to the first microprocessor via I2C or 8080 parallel port to display the global synchronization time and weather conditions acquired by the host in real time. The host's power management section (not shown in the figure) preferably uses a low-dropout linear regulator (LDO, such as RT9013) or a high-efficiency step-down DC-DC converter to convert the 5V power input from the external adapter or the internal dry battery power to 3.3V to provide stable power to the above modules.

[0027] 2. Physical configuration of slave-side hardware, such as Figure 2As shown, the slave device, being a terminal device extremely sensitive to power consumption (typically powered by 1 to 2 AA / AAA dry batteries, requiring a battery life of over one year), has a hardware structure including a second microprocessor, a second BLE communication module, a clock display module, a temperature and humidity acquisition module, and a power monitoring module. In this specific embodiment, the second microprocessor and the second BLE communication module preferably employ highly integrated low-power Bluetooth SoC chips, such as Nordic Semiconductor's nRF52832 or the domestically produced PH6222 chip. These chips consume only microamps (µA) of power on average when BLE broadcasting is enabled. The clock display module preferably uses a segmented LCD (liquid crystal display) or EPD (electronic paper display), driven and refreshed through the dedicated driver pin (SEG / COM) or SPI interface of the second microprocessor. The temperature and humidity acquisition module is used to collect real-time temperature and humidity data of the local environment where the slave device is located (such as a bedroom or study), and preferably uses a digital temperature and humidity sensor (such as Sensirion's SHT30 or DHT11), which is electrically connected to the second microprocessor via an I2C bus. The power monitoring module is used to monitor the voltage status of the slave dry cell battery in real time to prevent time loss due to sudden power failure. Its specific hardware implementation can be a voltage divider network composed of precision resistors. One end of the voltage divider network is connected to the positive terminal of the battery, and the other end is grounded. The voltage divider node is connected to the ADC (analog-to-digital converter) pin of the second microprocessor. To further reduce power consumption, an N-channel MOSFET can be connected in series between the voltage divider network and ground. The second microprocessor only needs to pull the gate of the MOSFET high via GPIO to turn on the voltage divider network, and immediately turns it off after the data acquisition is complete, avoiding continuous static leakage current from the voltage divider resistors.

[0028] Example 2: Data simplification, compression, and protocol encapsulation mechanisms to circumvent the black box of transmission; Addressing the technical pain points of existing clock networks when transmitting complex weather data using Bluetooth Low Energy (BLE), such as "excessively large data packets, high packet loss rate due to packet fragmentation, and reduced battery life due to long connections," this embodiment combines... Figure 3 (Host workflow control chart) and Figure 4 (Synchronous data packet structure and compression mapping diagram) discloses in detail a data compression algorithm and underlying communication message structure for use inside a microprocessor.

[0029] 1. Data acquisition and core field extraction, such as... Figure 3As shown in the intermediate steps, after the host wakes up at the preset trigger time, its first microprocessor controls the WIFI communication module to connect to the router and sends a time synchronization request to the NTP network time server via the UDP protocol to obtain a 64-bit NTP timestamp and convert it into the local standard time (UNIX timestamp format, accurate to the second). Simultaneously, the first microprocessor accesses the RESTful API interface of the weather forecast server via an HTTP GET request to obtain a JSON (JavaScript Object Notation) format message containing detailed weather information. The original JSON weather message is typically large (up to several KB) and contains a lot of redundant string descriptions (such as "Today, some areas will experience showers turning cloudy, with winds of 3-4 levels"). The first microprocessor internally hosts a lightweight JSON parsing algorithm (such as the cJSON library) that forcibly removes redundant characters by searching for specific keys, extracting only three core fields: weather condition description (String format), highest temperature value (Float or Int format), and lowest temperature value (Float or Int format).

[0030] 2. Extreme Data Compression Based on Encoding Mapping Table In order to pack the extracted weather data into a single extremely short BLE data packet (usually the maximum payload of a single packet is 20 bytes), the first microprocessor executes strict data compression logic: (1) Weather Condition Mapping: The first microprocessor's flash memory contains a "weather condition hexadecimal mapping dictionary (decoding mapping table)". The first microprocessor performs a hash comparison between the extracted Chinese string format weather condition description and the dictionary. For example, if "sunny" is extracted, it is replaced with a 1-byte hexadecimal value 0x01; if "cloudy" is extracted, it is replaced with 0x02; if "thunderstorm" is extracted, it is replaced with 0x08. Through this mapping logic, the UTF-8 Chinese string that originally occupied several or even more than ten bytes is losslessly compressed to only 1 byte. (2) Temperature Value Quantization: The extracted highest / lowest temperature values ​​are rounded and replaced with a 1-byte signed integer value (int8_t). A 1-byte signed number ranges from -128 to +127, which completely covers the range of all normal natural ambient temperatures on Earth. Therefore, temperature data is compressed to 2 bytes.

[0031] 3. Memory alignment and structure encapsulation of synchronization data packets, such as... Figure 4As shown, the compressed data will be packaged in the RAM of the first microprocessor according to a specific protocol structure to form a "synchronization data packet". In order to prevent the C language compiler from automatically performing byte alignment and generating invalid memory holes (padding), the structure corresponding to this data packet is forced to use single-byte alignment instructions (such as #pragma pack(1)) at the code level. The strict structure of this synchronization data packet in memory is as follows: Feature Identifier (1 Byte): Serves as a header and indicates the type of subsequent payload data. For example, 0xAA is defined as the time synchronization packet identifier, 0xBB as the weather synchronization packet identifier, and 0xCC as the identifier for a mixed clock and weather data packet.

[0032] Payload data (7 bytes): Synchronization time value (4 Bytes): UNIX timestamp stored in unsigned 32-bit integer (uint32_t), supporting time calculations up to 2106.

[0033] Weather condition mapping value (1 Byte): The value of 0x01 ~ 0xFF obtained from the previous table lookup.

[0034] Maximum temperature value (1 Byte): The signed value of the aforementioned int8_t.

[0035] Minimum temperature value (1 Byte): The signed value of the aforementioned int8_t.

[0036] Checksum (2 bytes): CRC16 (Cyclic Redundancy Check) algorithm is preferred. Before transmission, the first microprocessor calculates a 2-byte checksum by inputting the feature identification code and payload data into the CRC16 polynomial and appends it to the end of the packet.

[0037] In summary, the originally massive network time and weather JSON data was extremely compressed and encapsulated by the first microprocessor into a synchronization data packet with a length of only 10 bytes (1+7+2=10). This "miniaturized" data packet structure perfectly matches the short packet broadcasting and fast connection and transmission characteristics of the BLE underlying link layer, ensuring that data exchange between the master and slave devices can be completed in just milliseconds, thereby compressing the start-up time of the communication radio frequency circuit to the limit.

[0038] 4. Reverse Parsing and Display Refresh Mechanism on the Slave Side: After the first microprocessor on the slave receives the aforementioned 10-byte synchronization data packet via the second BLE communication module, its parsing logic is mirror-symmetric to the compression logic of the host: First, the entire data packet is recalculated using CRC16. If the calculation result is inconsistent with the checksum at the end of the packet, it is determined that the data was flipped due to electromagnetic interference during air transmission, and the packet is directly discarded without further processing. If the checksum passes, the second microprocessor extracts the "feature identification code" of the first byte. When a weather data identifier (such as 0xBB) is identified, the second microprocessor extracts a 1-byte "weather condition mapping value" (such as 0x01) from the subsequent payload. Subsequently, the second microprocessor calls the same "decoding mapping table" stored in its local ROM to find the local UI resource library index corresponding to 0x01 (i.e., Figure 4 (See the address pointer of the "sunny day icon" shown). Simultaneously, the signed temperature value is restored to a decimal display number. Finally, the second microprocessor controls the clock display module (pulling high the corresponding segment code pin of the LCD) to light up the "sunny day" icon and update the corresponding temperature number. The entire process eliminates the need for complex string processing on the slave side, greatly freeing up the computing power of the slave's low-end MCU and further controlling slave power consumption.

[0039] Example 3: Host-based ultra-low power scheduling logic based on a time-series state machine; As is well known, the peak current of a Wi-Fi module during continuous operation can reach 300mA to 500mA. If kept on continuously, even a high-capacity dry cell battery will be depleted within a few days. To balance the advantages of active Wi-Fi acquisition with the need for long-term battery power, a solution was developed... Figure 5 As shown in the host low-power timing state transition diagram, in this embodiment, the first microprocessor is configured to execute a "multi-level state machine switching logic" based on strict timing. The lifecycle of the first microprocessor is divided into the following four states: 1. Deep Sleep State: During non-communication phases, the first microprocessor controls the host in a deep sleep state. In this state, the first microprocessor disconnects the power supply to the radio frequency (RF) oscillator of the WIFI communication module and the first BLE communication module, shuts down the internal high-frequency master clock (e.g., a 160MHz PLL), and only retains the extremely low-frequency RTC (real-time clock, such as a 32.768kHz crystal oscillator) and necessary GPIO interrupt wake-up circuits. At this time, the static power consumption of the entire host is forcibly reduced to an extremely low level of 10uA~20uA. The host remains in this state for over 99% of its lifespan.

[0040] 2. WIFI Active State: When the RTC timer inside the first microprocessor reaches the preset trigger time (e.g., 2:00 AM, 8:00 AM, 2:00 PM, and 8:00 PM daily), the RTC generates an internal hardware interrupt, waking the first microprocessor from deep sleep. Upon waking, the first microprocessor immediately executes the following pipelined operations: ① Pulls up the power enable pin to start the WIFI communication module; ② Initiates a connection request to the home wireless LAN / router based on the SSID and password stored in local Flash; ③ Obtains NTP time and JSON weather information, and completes data extraction, hexadecimal mapping, and 10-byte encapsulation as described in Example 2; ④ Key leakage protection mechanism: To prevent prolonged network searching and power consumption due to power outages of the home router or external network failures, the first microprocessor has a "WIFI watchdog timer." If data is not successfully acquired within the preset timeout period (e.g., 15 seconds), the WIFI task will be forcibly interrupted, directly abandoning the network connection to protect battery life. Regardless of whether the acquisition is successful or not, after the operation is completed, the first microprocessor immediately sends a power-off command to the WIFI communication module and enters the next state. This state consumes the most power, but the duration of each instance is extremely short (usually within 3-5 seconds).

[0041] 3. BLE Server State: After Wi-Fi is turned off, the first microprocessor activates the first BLE communication module and initializes it to BLE Peripheral and GATT Server modes. In this mode, the first BLE communication module begins sending directed broadcast messages containing the system identifier at a specific frequency (e.g., once every 200 milliseconds), announcing that the host is ready to send data. At this time, the host's power consumption drops back to the milliampere (mA) level.

[0042] 4. Data Interaction State: When a slave device that has been continuously active within the monitoring range (with a high duty cycle during the second BLE communication module scan) captures the master's broadcast, the slave device actively initiates a connection request. After the connection is established, the state machine transitions to the data interaction state. The first microprocessor sends a pre-packaged 10-byte "synchronization data packet" to the slave device via the Notify or Write attribute of the GATT Characteristic. A single slave device typically only needs tens of milliseconds to receive and return an ACK (acknowledgment packet). After sending, the master actively disconnects from the slave device, and the state machine reverts to the "BLE server state," continuing to wait for the next slave device to connect.

[0043] State machine reset conditions: When the first microprocessor enters "BLE server mode," it will simultaneously start a "listening duration timer." When any of the following conditions are met, the first microprocessor will completely shut down the first BLE communication module and control the system to reset to "deep sleep mode": Condition A: All slave devices in the internally maintained pairing list have completed data synchronization (e.g., all three slave devices in the local area network have completed handshakes). Condition B: The preset listening time limit (e.g., 60 seconds) has been reached. This means that some slave devices may not have responded due to power failure or excessive distance; in this case, forced sleep is initiated to prevent power consumption from indefinite waiting.

[0044] Example 4: Anti-interference automatic networking and parameter configuration mechanism based on dynamic key overlay; In densely populated environments such as apartments and office buildings, if two adjacent households use the same brand and model of clock synchronization system, "crosstalk" interference can easily occur (for example, weather data from household A's main unit might be synchronized to household B's slave unit, causing household B's slave unit to display the temperature of the wrong city). To address this issue, [the following is a separate, unrelated sentence:] Combining... Figure 6 (As shown in the timing diagram of automatic network formation and custom key synchronization), this embodiment designs a seamless secure pairing logic based on a mobile APP: 1. Factory-Initiated Matching Phase: At the factory, a unified "Default Key (e.g., 0x00000000)" is pre-programmed into designated sectors of the non-volatile memory (Flash / EEPROM) of both the master and all slave devices. Since the slave devices are used to implement functions such as alarms and countdowns that require periodic settings, their second microprocessor controls the second BLE communication module to always remain in low-power scan response mode. At this time, unconfigured slave devices can establish a basic communication handshake with the master device using the default key.

[0045] 2. External Terminal (APP) Custom Intervention Phase: Upon first use, users do not need to perform complex pairing operations on clock devices lacking input buttons. The user opens the external mobile terminal (phone APP), and the APP uses the phone's Bluetooth function to search for and discover the slave device. After establishing a connection, the APP generates a "Custom Key (e.g., 0x1A2B3C4D)" based on a timestamp or a random algorithm. The APP then sends this Custom Key, along with local function configuration parameters (including but not limited to: the duration of the host's Wi-Fi data acquisition cycle, such as 6 / 12 / 24 hours; the duration of the host's BLE server mode; and the sampling frequency of the slave device's local data acquisition), to the slave device.

[0046] 3. Slave-driven Low-level Shuffling and Synchronization Phase: After receiving the above configuration data, the slave's second microprocessor executes the following core logic: ① Directly overwrites and erases the original default key in the local Flash memory with the received custom key; ② Caches the received function configuration parameters in RAM; ③ When the master reaches its next wake-up period, switches to "BLE server mode," and broadcasts, the slave immediately connects to the master. The slave uses a special handshake message (the header identifies itself as a new network configuration device in plaintext) to synchronize the cached "custom key" and "function configuration parameters" to the master's first microprocessor.

[0047] 4. Continuous Secure Communication Phase: After receiving and verifying the parameter packet, the host's first microprocessor also updates its local key to a "custom key" and resets its RTC wake-up cycle according to the new parameters. Thereafter, all broadcast packet payloads and connection requests between the host and slave devices within this group must be encrypted using AES-128 or XOR encryption with this custom key. If a new device from a neighboring device initiates a connection using the factory default key, it will be directly rejected by the host / slave device at the link layer, thus achieving seamless, unobtrusive secure physical isolation and anti-interference grouping.

[0048] Example 5: Application Expansion of Two-Way Data Backhaul and Local Ecosystem Closed Loop Furthermore, to maximize the application value of this system in the Internet of Things, this embodiment not only supports one-way synchronization from the host to the slave, but also constructs a closed loop for data backhaul: On the one hand, if the host itself is a wall clock device with a display panel, the first microprocessor, while encapsulating synchronization data packets and sending them to the slave, will also extract timestamps and weather parsing data to drive the host's own display module to refresh the screen, achieving self-sufficiency. On the other hand, the temperature and humidity acquisition module and power monitoring module on the slave acquire indoor temperature and humidity values ​​and the current battery percentage at a set sampling frequency (e.g., once every 30 minutes). During the millisecond "data interaction state" window period during which the host periodically activates the first BLE communication module to establish a connection, the slave's second microprocessor, in addition to receiving downlink weather and time packets, will simultaneously send local temperature, humidity, and power data uplink to the host. The host can temporarily store the micro-environment data of these multiple nodes in the local storage. When the WIFI communication module is woken up again, the data will be aggregated and uploaded to the home smart gateway or APP cloud, reminding the user to replace the battery of the slave device in time, or to control the home air conditioner / humidifier in a coordinated manner, forming a complete smart home micro-ecosystem closed loop.

[0049] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention in any way. Although the present invention has been disclosed above with reference to preferred embodiments, it is not intended to limit the present invention. Any person skilled in the art can make some modifications or alterations to the above-disclosed technical content to create equivalent embodiments without departing from the scope of the present invention. Any simple modifications, equivalent changes, and alterations made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention shall still fall within the scope of the present invention.

Claims

1. A hybrid network clock synchronization system based on a master-slave architecture, comprising a master and at least one slave, wherein the master includes a first microprocessor, a WIFI communication module, and a first BLE communication module, and the slave includes a second microprocessor, a second BLE communication module, and a clock display module; characterized in that: The first microprocessor of the host is configured to: access the network and acquire network clock data and environmental weather data through the WIFI communication module; extract core fields from the data and encapsulate the extracted core fields into a synchronization data packet containing a feature identification code and payload data; control the first BLE communication module to send the synchronization data packet to the slave device; the second microprocessor of the slave device is configured to: receive the synchronization data packet through the second BLE communication module; parse the payload data according to a preset decoding mapping table and the feature identification code to obtain a synchronization time value and weather parameters; update local data according to the synchronization time value and weather parameters, and control the clock display module to refresh the display.

2. The clock synchronization system according to claim 1, characterized in that, The structure of the synchronization data packet includes, in sequence: a feature identification code, payload data, and a check code; the feature identification code includes a time data identifier and a weather data identifier.

3. The clock synchronization system according to claim 2, characterized in that, When the first microprocessor of the host encapsulates the synchronization data packet, its data compression logic includes: extracting the weather condition description, the highest temperature value, and the lowest temperature value from the environmental weather data; replacing the string-formatted weather condition description with a 1-byte hexadecimal mapped value; replacing the highest temperature value with a 1-byte signed value, and replacing the lowest temperature value with a 1-byte signed value.

4. The clock synchronization system according to claim 2, characterized in that, The logic for the slave device's second microprocessor to parse the payload data includes: identifying the feature identification code; if it is a weather data identifier, extracting the corresponding hexadecimal mapping value; calling the decoding mapping table in the local memory to restore the hexadecimal mapping value to the corresponding weather condition icon index and temperature value; verifying the data integrity of the check code; and triggering the clock display module to refresh after successful verification.

5. The clock synchronization system according to claim 1, characterized in that, The first microprocessor has a timing-based working state switching logic: during non-communication phases, the control host is in a sleep state; after a preset trigger time is reached, the WIFI communication module is woken up to acquire data; After acquisition, the WIFI communication module is turned off and the server mode of the first BLE communication module is turned on; after the data transmission is completed within the listening time or the listening time limit is reached, the first BLE communication module is turned off and re-enters sleep state.

6. The clock synchronization system according to claim 1, characterized in that, The second microprocessor controls the second BLE communication module to adopt a low-power scan response mode. When not connected to the host, it sends broadcast messages at a preset broadcast interval and responds to the asynchronous connection request of the external mobile terminal to receive local function configuration parameters.

7. The clock synchronization system according to claim 6, characterized in that, The automatic networking logic of the system is as follows: The host and slave devices have a unified default key pre-stored in their respective memory; The slave device receives a custom key sent by an external mobile terminal and overwrites the local default key with the custom key; The slave device synchronizes the custom key to the host device through the second BLE communication module, and the host device and the slave device subsequently connect based on the custom key.

8. The clock synchronization system according to claim 6, characterized in that, The local function configuration parameters received by the slave device include at least: the period for the host to access WIFI and acquire data, the duration for the host to enable BLE server mode, and the sampling frequency for the slave device's local data acquisition.

9. The clock synchronization system according to claim 1, characterized in that, The host also includes a host display module electrically connected to the first microprocessor. While encapsulating the synchronization data packet, the first microprocessor updates the content of the host display module based on the acquired network clock data and environmental weather data.

10. The clock synchronization system according to claim 1, characterized in that, The slave device also includes a temperature and humidity acquisition module and a power monitoring module electrically connected to the second microprocessor. The second microprocessor is configured to periodically acquire local ambient temperature and humidity data and battery power data, and after establishing a connection with the host, upload the above data to the host through the second BLE communication module.

Images