Distributed time synchronization management method and system suitable for complex environment of hospital and intelligent wall clock

Abstract

This invention discloses a distributed time synchronization management method, system, and smart clock suitable for the complex environment of hospitals, belonging to the fields of Internet of Things and medical equipment management technology. The method includes: enabling multiple smart clock nodes deployed throughout the hospital to periodically communicate with a time server via a network to obtain network standard time; each node independently calculates and drives its pointer mechanism to perform time calibration actions based on the obtained standard time to eliminate accumulated timekeeping errors. This invention achieves a high degree of uniformity in the hospital's time reference through a distributed autonomous calibration mechanism; transforms fault management from passive inspection to proactive early warning through proactive status perception and remote alarms; and, combined with power outage recovery capabilities, constructs a reliable and intelligent hospital time service system, effectively solving the three major problems of time asynchrony, hidden faults, and power outage failure in existing technologies, thereby improving medical safety and management efficiency.

Description

Technical Field

[0001] This invention relates to the fields of Internet of Things (IoT) technology and medical device management technology, specifically to a distributed time synchronization management method suitable for complex hospital environments, a system for implementing the method, and a key device in the system—a smart wall clock. Background Technology

[0002] In modern healthcare systems, time is a crucial dimension. From monitoring patients' vital signs and medication records to surgical procedures and generating laboratory reports, almost all medical actions need to be accurately documented. These records are not only used for clinical decision-making but also serve as key evidence for medical quality assessment, legal proof, and liability tracing. Therefore, in the unique setting of a hospital, ensuring that public clocks scattered throughout various locations (such as operating rooms, wards, corridors, pharmacies, and laboratories) remain highly consistent and continuously usable is a fundamental and essential requirement. Currently, the vast majority of hospitals still use traditional quartz wall clocks. These clocks are essentially isolated timepieces, and their operating mechanism inherently presents them with insurmountable flaws:

[0003] 1. Inconsistent Time Standards and Uncontrollable Cumulative Errors: Each quartz clock relies on its internal quartz crystal oscillator for timekeeping. However, the frequency of the crystal oscillator can drift due to factors such as manufacturing processes, temperature, and aging, resulting in a daily error typically between ±0.5 seconds and ±2 seconds. This makes interdisciplinary medical collaboration and time-series data analysis extremely difficult, and could even lead to serious medical accidents due to relying on an incorrect "local time." Existing technologies attempt to solve this problem through periodic manual calibration, but this is not only labor-intensive, but the time inconsistency problem persists even within the calibration window.

[0004] 2. Latent malfunctions, relying on passive responses: Traditional wall clocks do not send any signals when they stop (battery depleted) or the needle jams. Their detection depends entirely on visual inspection by maintenance personnel. This passive, periodic inspection method has a significant time blind spot. A stopped wall clock may not be discovered for days or even weeks, during which time all operations relying on the clock's time may be based on erroneous information.

[0005] 3. Weak anti-interference capability and risk of service interruption: Mains power is the main or only energy source for traditional wall clocks. Once a planned power outage or sudden power failure occurs, the time information in that area will be completely interrupted.

[0006] In summary, existing technologies provide a static, isolated, and fragile time service system, which can no longer meet the high standards of time consistency, reliability, and intelligent management required by modern smart hospitals. Therefore, a completely new and systematic solution is urgently needed. Summary of the Invention

[0007] This invention aims to solve three core technical problems of existing hospital public clocks: inconsistent time base, difficulty in proactively detecting faults, and service interruption after power failure. It provides a time management method and system that can proactively maintain uniform time throughout the hospital, proactively expose its own faults, and maintain basic timing functions even when the main power supply fails.

[0008] The technical solution adopted by this invention to solve its technical problem is:

[0009] A distributed time synchronization management method suitable for the complex environment of a hospital is constructed, comprising the following steps:

[0010] S1: Multiple smart wall clock nodes deployed in different locations in the hospital establish connections with the time server through the network;

[0011] S2: Each of the smart wall clock nodes obtains the current network standard time from the time server according to a preset first cycle;

[0012] S3: Each smart clock node compares its current displayed time with the network standard time and calculates the time deviation.

[0013] S4: Each of the smart clock nodes generates and sends corresponding control commands to the pointer drive mechanism connected to it based on the calculated time deviation, so as to drive the pointer mechanism to perform at least one jump or continuous rotation, thereby eliminating the time deviation and completing the time calibration.

[0014] S5: Each of the smart wall clock nodes packages its own operating status parameters into status information and sends the status information to the remote management platform according to the preset second cycle;

[0015] S6: The remote management platform receives and parses the status information. When it determines that the operating status parameters of any node meet the preset abnormal conditions, it generates alarm information and notifies the management personnel.

[0016] In the method of the present invention, in step S4, when the time deviation exceeds a set first threshold, the pointer mechanism is executed to quickly return to zero; when the time deviation does not exceed the first threshold but is greater than zero, the pointer mechanism is executed to smoothly eliminate the deviation.

[0017] The method of the present invention, wherein the operating status parameters in step S5 include: whether the node is online, the pointer movement status, the heartbeat signal of the main control module, and the remaining power of the energy storage module; the abnormal conditions include at least one of the following: the node fails to report status information within three consecutive second cycles, the pointer movement status remains stationary for a first time length, the heartbeat signal of the main control module is interrupted, and the remaining power of the energy storage module is lower than a second threshold.

[0018] The method described in this invention further includes a power outage emergency step: when any smart clock node detects an external mains power interruption, it automatically switches to power supply from its built-in energy storage module to maintain the basic operation of the main control module, the pointer drive mechanism, and the network communication module. At the moment of switching the power supply mode and immediately thereafter, it controls a status indicator light to change its illumination state, and simultaneously reports the power outage event as a special abnormal status information to the remote management platform.

[0019] In the method described in this invention, in step S2, if the smart clock node fails to successfully obtain the network standard time at the requested time, it activates its internal backup timing unit to keep time, and immediately performs a time synchronization operation at the subsequent network recovery time, and performs frequency compensation calibration on the backup timing unit based on the synchronization result.

[0020] The present invention also provides a hospital time synchronization management system for implementing any of the foregoing methods, comprising:

[0021] A time server is used to provide standard time services on the network.

[0022] The remote management platform is used to manage multiple smart wall clock nodes, receive their reported status information, and determine anomalies and generate alarms according to preset rules;

[0023] Multiple smart wall clock nodes are distributed throughout the hospital and communicate with the time server and remote management platform; each smart wall clock node includes:

[0024] Dial and hands;

[0025] A pointer drive mechanism, used to rotate the pointer;

[0026] The main control module is used for time comparison, deviation calculation, and control command generation.

[0027] The network module is used for data exchange with the time server and management platform;

[0028] The status sensing module is used to collect the operating status parameters of the smart wall clock nodes;

[0029] Energy storage modules are used to provide power when the main power supply is interrupted;

[0030] The alarm and indication module is used to perform local status indication and send alarm information to the management platform.

[0031] In the system described in this invention, the network module is one or more combinations of a Wi-Fi communication module, a LoRa communication module, or an NB-IoT communication module.

[0032] The present invention also provides a smart wall clock for hospitals, used as part of the aforementioned system, comprising: a housing, a dial and hands disposed in the housing, and components disposed within the housing:

[0033] A stepper motor is used as the pointer drive mechanism;

[0034] The main control module is connected to the stepper motor and contains or has an external real-time clock chip (RTC).

[0035] The wireless communication module, connected to the main control module, is used to access the IP network;

[0036] At least one sensor constitutes a state sensing module, which is connected to the main control module and is used to sense the physical or logical state of the wall clock.

[0037] A rechargeable battery pack forms an energy storage module, which is connected to the main control module and stepper motor through a power management unit.

[0038] The communication alarm module is connected to the main control module and is used to achieve two-way communication with the management platform;

[0039] Status indicator lights, connected to the main control module, are used to provide local visual status feedback.

[0040] The smart wall clock of the present invention includes a motion sensor for detecting whether the hands are moving, and / or a heartbeat detection circuit for monitoring the operation of the system program.

[0041] In the smart wall clock of the present invention, the power management unit is configured to monitor the remaining power of the battery pack and send a low power signal to the main control module when the power is lower than a preset value, thereby triggering an alarm process.

[0042] The beneficial effects of this invention are as follows:

[0043] 1. Achieves true hospital-wide time unification: By periodically and automatically synchronizing from an authoritative time source, this invention controls the time error of all wall clocks in the hospital to an extremely small range (depending on the synchronization period and network latency, it can reach sub-second level), providing a unified and reliable time benchmark for all medical activities, fundamentally solving the management and security risks caused by time inconsistency.

[0044] 2. Shifting the fault management paradigm from passive to proactive: Through built-in sensors and a periodic status reporting mechanism, this invention enables each clock node to have "self-diagnosis" and "self-reporting" capabilities. Fault detection changes from "accidentally seeing" to "certainly knowing," greatly shortening fault response and resolution time and significantly improving the reliability of hospital infrastructure.

[0045] 3. A highly flexible time service system has been built: The introduction of the energy storage module enables the wall clock to continue working as a reliable time source for several hours after the mains power is interrupted, ensuring the continuity of time information in emergency situations and enhancing the hospital's ability to respond to emergencies.

[0046] 4. Improved management efficiency and intelligence: The remote management platform enables centralized, unmanned monitoring and management of hundreds of wall clocks. Managers can gain a comprehensive overview on a single interface, quickly pinpoint fault locations, and optimize maintenance resource allocation. This represents a significant leap from traditional manual inspections to digital and intelligent operation and maintenance, saving labor costs and improving management precision. Attached Figure Description

[0047] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the present invention will be further described below in conjunction with the accompanying drawings and embodiments. 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.

[0048] Figure 1 This is one of the flowcharts of a distributed time synchronization management method suitable for complex hospital environments provided in the embodiments of the present invention;

[0049] Figure 2 This is the second flowchart of the distributed time synchronization management method suitable for complex hospital environments provided in the embodiments of the present invention;

[0050] Figure 3 This is a block diagram illustrating the principle of a distributed time synchronization management system suitable for complex hospital environments, as provided in this embodiment of the invention.

[0051] Figure 4 yes Figure 3 The diagram shows the internal structure of the smart wall clock node.

[0052] The diagram is labeled as follows: 10-Remote Management Platform, 20-Time Server, 30-Smart Clock Node, 31-Dial, 32-Pointer, 33-Main Control Module, 34-Stepper Motor, 35-Wireless Communication Module, 36-Sensor Module, 37-Energy Storage Module, 38-Communication Alarm Module, 39-Status Indicator Light, 40-Hospital Network. Detailed Implementation

[0053] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, a clear and complete description will be provided below in conjunction with the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are within the protection scope of the present invention.

[0054] This embodiment of the invention provides a time synchronization management method in a hospital environment, such as... Figure 1 As shown, it includes the following steps:

[0055] Step S1: Node Deployment and Network Connection Establishment

[0056] Multiple smart wall clock nodes deployed in different locations in the hospital establish connections with the time server through the network, allowing each smart wall clock node to access the hospital network and the time server.

[0057] Specific implementation method:

[0058] 1. Physical Deployment

[0059] Install smart wall clock nodes in key locations in the hospital (emergency room, operating room, ward, corridor, pharmacy, laboratory, etc.). Each node includes a dial, hands, drive mechanism, main control module, network communication module, energy storage module, etc. The node location selection needs to take into account network coverage and signal strength to avoid dead zones.

[0060] 2. Network connection initialization

[0061] After the node is powered on, the main control module starts the network module (Wi-Fi / LoRa / NB-IoT, etc.) and attempts to establish an IP network connection with the time server. It can obtain an IP address automatically via DHCP or connect to the time server (usually an NTP server or a hospital-built time service system) through pre-configured static IP / domain name resolution. Once the connection is successfully established, the node enters standby mode, ready to execute synchronization tasks periodically.

[0062] Step S2: Periodically acquire network standard time

[0063] Each smart clock node obtains the current network standard time from the time server according to the preset first cycle, ensuring that each node can obtain a unified and authoritative time reference on a regular basis;

[0064] Implementation details:

[0065] 1. First cycle setting

[0066] The first cycle is a preset time interval (e.g., every 5 minutes, 15 minutes, or 1 hour, which can be adjusted according to the hospital's accuracy requirements). Each node has an internal timer or scheduling task that triggers the time acquisition process when the cycle arrives.

[0067] 2. Time acquisition process

[0068] The node sends a time request to the time server (such as a UDP packet using the NTP protocol or a custom time query protocol). The time server returns the current network standard time (accurate to milliseconds or higher). The node stores the received standard time in a local cache (such as the RTC register of the master module or a memory variable) for the next comparison.

[0069] Step S3: Deviation Calculation

[0070] Each smart clock node compares its current displayed time with the network standard time, calculates the time deviation, quantifies the difference between the local displayed time and the standard time, and provides a basis for calibration.

[0071] Implementation details:

[0072] 1. Read the local display time

[0073] The node identifies the current time value (hour, minute, second) by the pointer position or reads it from the internal RTC. If it is a purely analog wall clock, it may be necessary to use a motion sensor or stepper motor encoder to deduce the time corresponding to the pointer position.

[0074] 2. Comparison and Calculation

[0075] Convert local time and network standard time to a unified time format (such as Unix timestamp), and calculate the difference: Deviation = Standard Time - Local Time (unit: seconds or less). The deviation can be positive (local time is slower) or negative (local time is faster).

[0076] Step S4: Deviation Correction (Pointer Driven)

[0077] Each smart clock node generates and sends corresponding control commands to the connected pointer drive mechanism based on the calculated time deviation, thereby driving the pointer mechanism to perform at least one jump or continuous rotation, thus eliminating the time deviation, completing time calibration, and making the time displayed by the clock consistent with the standard time through mechanical action.

[0078] Implementation details:

[0079] 1. Control command generation

[0080] The main control module generates drive commands (including rotation direction, number of steps, or speed curve) based on the magnitude and direction of the deviation. If the deviation is large, the command will drive the pointer to make a larger adjustment; if the deviation is small, a fine adjustment is sufficient.

[0081] 2. Pointer-driven execution

[0082] After receiving a command, the pointer driving mechanism (such as a stepper motor) drives the hour, minute, and second hands to rotate. Jump-type rotation: When the deviation exceeds a certain threshold, it directly rotates to the target position, reducing adjustment time. Continuous rotation: When the deviation is small and within the threshold, it rotates slowly and smoothly, avoiding sudden pointer jumps that cause visual discomfort (the specific grading strategy is detailed in claim 2). After rotation, the node updates the local RTC display time to match the standard time.

[0083] Step S5: Report Operating Status

[0084] Each smart clock node packages its own operating status parameters into status information and sends the status information to the remote management platform according to the preset second cycle, so that the management center can keep track of the health status of each node in real time.

[0085] Implementation details:

[0086] 1. Parameter acquisition: The node status sensing module acquires the following parameters: whether the node is online (network connectivity), pointer movement status (whether it is rotating), main control module heartbeat signal (software running normally), and energy storage module remaining power (battery voltage / percentage). These parameters are packaged into structured status information (such as JSON, binary frames) within the main control module.

[0087] 2. Second cycle reporting: The data is sent to the remote management platform according to the preset second cycle (which may be different from the first cycle, such as every 1 minute or every 5 minutes). The data is uploaded using the network communication module (TCP / UDP / HTTP / MQTT and other protocols).

[0088] Step S6: Anomaly Detection and Alarm

[0089] The remote management platform receives and parses status information. When it determines that the operating status parameters of any node meet the preset abnormal conditions, it generates alarm information and notifies the management personnel, thus detecting node failures or abnormal states in advance and reducing the risk of service interruption.

[0090] Implementation details:

[0091] 1. Platform Analysis and Judgment: The remote management platform receives status information and parses out the values ​​of various parameters. It then judges based on preset abnormal conditions, such as: no information received from a node for three consecutive second cycles → offline abnormal pointer movement remains stationary for a certain time duration → possible needle jamming or stopping, heartbeat signal interruption → main control program malfunction, battery level below the second threshold → impending power outage risk. Alarm generation and notification: Once any abnormal condition is met, the platform generates alarm information (including node ID, abnormality type, and timestamp). It notifies administrators via SMS, email, platform pop-ups, mobile app push notifications, etc., for timely repair or replacement of the node.

[0092] 2. Alarm Generation and Notification: Once any abnormal condition is met, the platform generates an alarm message (including node ID, abnormality type, and timestamp). Administrators are notified via SMS, email, platform pop-ups, mobile app push notifications, etc., to facilitate timely repair or replacement of the node.

[0093] Overall process sequence example:

[0094] Assume the first cycle = 15 minutes, the second cycle = 5 minutes:

[0095] 1. 0 min: Node powers on and connects to the network successfully;

[0096] 2. Every 15 minutes: The node requests the standard time from the time server → calculates the deviation → drives the pointer calibration;

[0097] 3. Every 5 minutes: Node collects status parameters → packages them → reports them to the platform;

[0098] 4. Platform continuous monitoring: If a node fails to report three times consecutively (within 15 minutes) → alarm will be triggered;

[0099] Calibration and reporting in parallel: Even during calibration, nodes continue to report their status in the second cycle.

[0100] The method implementation process of the above embodiments embodies the closed-loop management concept of distributed node autonomous synchronization + centralized platform monitoring, which can ensure the uniformity of time reference, that is, network time synchronization (steps S2-S3), and intelligent pointer driving (step S4) to achieve calibration without sensory interference or with minimal interference; periodic status reporting and anomaly judgment (steps S5-S6) can also enable early detection and early handling of faults, ensuring high consistency, high reliability and high maintainability of time in the hospital environment.

[0101] In a further embodiment of the method, step S1, based on the hospital floor plan, the areas where wall clocks need to be installed are determined (operating rooms, ICUs, ward corridors, pharmacies, laboratories, emergency rooms, administrative offices, etc.). The wall clocks should be installed in locations easily visible to medical staff and patients, while also being easily accessible to maintenance personnel. Considering the distribution of the hospital's Wi-Fi, LoRa gateways, or NB-IoT base stations, locations with good signal coverage are prioritized to avoid communication dead zones. It is confirmed that there is a stable mains power outlet near the location, or that a PoE / LoRa / NB-IoT wireless power supply route is reserved for locations without outlets.

[0102] Each smart wall clock node must have the following components upon leaving the factory: dial and hands: mechanical structure; hand drive mechanism: stepper motor and transmission device; main control module: embedded MCU, built-in or external RTC chip; network module: Wi-Fi / LoRa / NB-IoT (combinable to adapt to different regional signal conditions); status sensing module: motion sensor, heartbeat detection circuit, etc.; energy storage module: rechargeable battery pack + power management unit; alarm and indication module: status indicator light, communication alarm module.

[0103] Software and Configuration: Firmware flashing: Nodes need to be pre-installed with time synchronization management firmware, including network protocol stack, time synchronization algorithm, status acquisition and reporting logic; Identification: Each node is assigned a unique device ID (MAC address, UUID, or hospital asset number) for platform identification; Network parameter configuration: Wi-Fi nodes: SSID, password, encryption method (WPA2 / WPA3); LoRa / NB-IoT nodes: device address, application key, server port; Time server address configuration: pointing to the hospital's NTP server or dedicated time service's IP / domain name and port.

[0104] When plugged into AC power or connected to a PoE switch, the node power management unit starts, charging / powering the main control module, network module, and energy storage module. The main control module performs a self-check of the hardware status (sensors, motors, battery, network module). If a fatal fault is found, a fault indicator light illuminates and a log entry is logged (but not reported). The main control module calls the network module driver to initialize the communication interface (Wi-Fi chip, LoRa RF module, NB-IoT baseband). It attempts to scan for available networks (in Wi-Fi mode) or register with an operator's network (in LoRa / NB-IoT mode).

[0105] Establish a network connection. If successful, record the server response time and latency for subsequent synchronization cycle optimization. If it fails, initiate a reconnection mechanism (exponential backoff retries to prevent network congestion). Local indication: The status indicator light changes from flashing (connecting) to solid (connected), or displays green to indicate normal operation. Log recording: The node internally stores connection success timestamps, server IP addresses, signal strength, and other information. Ready: The node enters a standby loop, waiting for the first synchronization task of the first cycle to be triggered (proceeding to step S2).

[0106] In a further embodiment of the method, before executing step S2, the following must be satisfied: (1) Step S1 has been completed: The node has successfully connected to the network where the time server is located and has communication capabilities. (2) The time server is available: The NTP server or dedicated time service process deployed in the hospital is running and the network is reachable. (3) The node's internal timer has been initialized: It is used to accurately trigger the synchronization task of the first cycle. (4) The node's system time base: Before the first successful synchronization, the node relies on the built-in RTC or backup timing unit to maintain a coarse time (which may have a large error).

[0107] In step S2, the first cycle is defined as follows: The first cycle is the interval between two requests for standard time from a node to the time server (e.g., 5 minutes, 15 minutes, 1 hour). The setting is based on: Medical precision requirements: Shorter cycles (e.g., 5 minutes) can be set for high-precision scenarios such as operating rooms and ICUs; longer cycles (e.g., 30 minutes) can be set for ordinary corridors. Network load: To avoid server pressure caused by hundreds of nodes making concurrent requests within the same second, random offsets or segmented cycles can be used to distribute requests. Energy consumption considerations: For battery-powered or LoRa / NB-IoT nodes, the cycle should not be too short to extend battery life. Storage method: The cycle value is written to the node configuration file or can be distributed by a remote management platform (supporting dynamic adjustment).

[0108] Periodic Scheduling and Triggering Mechanism: Hardware Timer: An RTC within the main control module or an independent hardware timer, accurate to the second or millisecond level, is used for periodic counting. Software Task Scheduling: The operating system (such as FreeRTOS, Linux embedded systems) creates a periodic task thread, which triggers the time acquisition function when the period arrives. Debouncing: Periodic triggering adopts "on-demand" instead of polling, reducing CPU usage; debouncing logic is added to prevent repeated triggering in a short period of time. Random Offset: To avoid "synchronization storms," ​​nodes can add a random offset (±10% of the period) to the period, allowing requests to be evenly distributed on the timeline.

[0109] Network standard time acquisition process:

[0110] 1. Request Initiation

[0111] Protocol Selection: NTP (Network Time Protocol, UDP port 123) is commonly used, suitable for high-precision internet / internal network time synchronization. For hospital internal networks, a lightweight TCP / UDP time query protocol can be customized (reducing the overhead of complex NTP handshakes). Packet Construction: NTP request packet: Includes fields such as version number, mode (client), and transmission timestamp. Custom protocol: Can include node ID, request sequence number, checksum, etc., facilitating server log tracking. Sending Target: Uses the time server IP or domain name configured in the S1 phase (supports a primary / backup server list to improve availability).

[0112] 2. Network transmission

[0113] Routing and QoS: If the hospital network has VLAN isolation or QoS policies, it must ensure that time synchronization data packets have a priority no lower than ordinary service traffic to avoid excessive latency. Transmission delay measurement: Nodes record the sending timestamp T1 and receiving timestamp T4 to calculate network round-trip delay and clock skew (NTP principle). Retry mechanism: If no response is received within the predetermined timeout period, automatic retransmission is performed (maximum number of retries can be set, such as 3 times), with the retry interval increasing each time (exponential backoff).

[0114] 3. Response Analysis

[0115] The server returns the following content: An NTP response includes the server's sending timestamp T2 and the response timestamp T3, which the node uses to calculate the deviation between its local clock and the standard time. Custom protocols return the standard time (accurate to milliseconds or higher) plus the server's time source identifier (such as GPS or an atomic clock). Time format conversion: The server time is converted to a unified Unix timestamp or ISO8601 format and stored in the node's memory or RTC register as input to S3.

[0116] Subsequent processing of the acquired results: Successful acquisition: Update the local time base cache, reset the periodic timer, and prepare for the next period trigger; the "last successful synchronization time" and "synchronization delay" can be attached as health indicators in the status information (S5). Acquisition failure: Start the internal backup timing unit (RTC or high-precision crystal oscillator) for timekeeping, mark "time synchronization failed" in the status information, trigger an additional synchronization immediately after the network recovers (without waiting for the next period), and perform frequency compensation calibration on the backup timing unit to correct crystal oscillator drift.

[0117] For the specific scenarios of hospitals, time synchronization requests should be restricted to internal IP ranges or use VPN tunnels to prevent external time spoofing. Packet verification (such as NTP Authenticator or custom signatures) should be enabled to prevent tampering. The time server can function as a primary / backup (dual-machine hot standby or cluster). Nodes should be configured with multiple server addresses, automatically switching when the primary server becomes unavailable. Given the varying network latency between different buildings in large hospitals, nodes can record the Round Trip Time (RTT) of each synchronization to determine whether period adjustment is needed or to select the nearest time server mirror. For LoRa / NB-IoT nodes, reporting and synchronization requests should be merged as much as possible to reduce air interface usage time. Wi-Fi nodes can utilize idle periods for synchronization to avoid peak traffic.

[0118] In a further embodiment, step S3 is the core calculation step of the time synchronization link. Its function is to compare the time displayed on the local clock (which may have errors) with the network standard time (authoritative benchmark) obtained from the time server to obtain a time offset. This offset is the direct basis for subsequent pointer driving (step S4), and the accuracy of the offset directly affects the calibration effect and time consistency in medical scenarios. In a hospital environment, the offset may originate from crystal oscillator drift, pointer mechanical errors, residual data from the previous calibration, etc., requiring precise quantification and differentiation of positive and negative directions.

[0119] Before executing step S3, the following conditions must be met: a) S2 completed successfully: the node has obtained the latest network standard time (denoted as T_std) from the time server; b) local time is readable: the node can obtain its own currently displayed time (denoted as T_local); c) time format unification capability: the node firmware has the function of converting times from different sources into a unified time base (such as UTC timestamp or Unix time) and performing arithmetic operations; d) necessary sensor data is available: if the wall clock is analog, the displayed time needs to be deduced from the pointer position or motion sensor.

[0120] How to obtain the local display time T_local:

[0121] There are two main types of smart wall clock nodes, and the acquisition methods are slightly different:

[0122] 1. Digital display type (if LCD / OLED screen is available)

[0123] Time values ​​(hours, minutes, seconds, milliseconds) are read directly from the display driver or internal RTC registers. The RTC is typically maintained by an independent crystal oscillator, independent of the pointer, and offers fast reading speed and high accuracy.

[0124] 2. Pointer display type (mechanical pointer)

[0125] This is an upgraded version of the traditional wall clock in hospitals, and it is also the main application area for this solution. Obtaining T_local is more complex:

[0126] Option A: RTC mapping method

[0127] The node's internal RTC maintains ideal timing, and the pointer-driven mechanism is theoretically synchronized with it; the actual RTC value read is used as T_local. However, if the pointer deviates from the RTC, the read RTC value needs to be corrected by adjusting the pointer position.

[0128] Option B: Pointer Position Recognition Method

[0129] Motion sensor detection: The current pointer position is determined by feedback from Hall effect sensors, photoelectric encoders, or stepper motors. Image recognition (less commonly used): A camera captures the dial and identifies the pointer angle (high cost, generally not used). Stepper motor step count calculation: The cumulative number of steps driven by the motor since the last calibration is recorded, and the time corresponding to the pointer position is calculated. Fusion method: Combining the initial RTC value with the pointer position calculation improves reading accuracy under mechanical slippage or external interference.

[0130] Regarding the format and precision of the network standard time T_st, the following are important considerations: 1) Source: The time obtained from S2, usually UTC time or local standard time with time zone; 2) Format: Unix timestamp (number of seconds since 1970-01-01 00:00:00 UTC, including decimal seconds); ISO 8601 string (e.g., 2026-04-08T10:20:30.123Z); 3) Precision: It is recommended to be ≥ milliseconds to meet the time recording requirements of medical scenarios; 4) Time zone handling: Hospitals generally use local time zones (e.g., Beijing time UTC+8). Nodes need to be unified to the same time zone before comparison, otherwise a fixed deviation will occur.

[0131] Regarding time format unification and conversion, to achieve accurate comparison, T_local and T_std need to be converted to the same unit and base: 1. Unify to UTC timestamp (recommended): T_std_utc = UTC timestamp returned by the server. T_local_utc = T_local (local timezone time) → converted to UTC (minus timezone offset). 2. Unify to Unix timestamp (seconds + milliseconds): This facilitates direct subtraction to obtain the deviation. 3. Unify resolution: If T_std is accurate to milliseconds, T_local should also be improved to the millisecond level (this can be estimated through RTC interpolation or pointer position subdivision).

[0132] Regarding the formula for calculating the deviation, the deviation (offset) is defined as follows:

[0133] offset = Tstd − Tlocal

[0134] Unit: seconds (decimals may be retained, such as 0.25 seconds)

[0135] Symbol meaning:

[0136] offset > 0: Local time is slower than standard time, and the hands need to be moved forward.

[0137] offset < 0: Local time is ahead of standard time, and the hands need to be moved backward.

[0138] offset ≈ 0: The time is basically consistent, no calibration is required or only fine-tuning is needed.

[0139] For example:

[0140] T_std_utc = 1712568030.500 (corresponds to 2026-04-08 10:20:30.500 UTC)

[0141] T_local_utc = 1712568028.000 (corresponds to 2026-04-08 10:20:28.000 UTC)

[0142] offset=2.5 seconds → local time is 2.5 seconds slow, the pointer needs to be adjusted forward by the corresponding angle / steps by 2.5 seconds.

[0143] Regarding the filtering and stability assessment of deviation, since there may be instantaneous jitter when reading T_local (such as pointer inertia or sensor noise), direct calculation may introduce errors. The following methods can be used to handle errors: Averaging through multiple sampling: Read T_local 3-5 times consecutively, remove outliers, and then average; Dead zone filtering: If |offset| is less than a certain minimum value (e.g., 0.1 seconds), it is considered zero deviation to avoid frequent and meaningless fine-tuning; Rate of change limitation: If the deviation suddenly exceeds a reasonable range within a short period (e.g., >10 seconds), it may be a reading error or interference, and should be marked as abnormal and trigger an S5 / S6 alarm.

[0144] Regarding the impact of pointer mechanical characteristics on deviation calculation, the following are included: 1) Minimum adjustment unit: Mechanical pointers are limited by the step angle of the stepper motor and may not be accurate to the decimal place of the second. Discretization processing is required during calculation (e.g., using 0.5 seconds or 1 second as the minimum calibration unit); 2) Backlash and idle: Gear backlash may cause the actual display time to be different when rotating in the forward and reverse directions with the same deviation. Compensation is required in the drive strategy (S4); 3) Multi-pointer coupling: The linkage relationship between the hour, minute, and second hands must be kept correct. Otherwise, simply calibrating the second hand will lead to incorrect hour / minute hand positions. The carry relationship of the hour must be considered when calculating the deviation.

[0145] Special considerations for hospital settings: 1) To avoid interference with medical staff observation during the calibration process, after deviation calculation, the S4 tiered strategy can be used to schedule large-deviation jump calibrations during low-traffic periods (such as nighttime), while small-deviation continuous calibrations can be performed at any time. 2) Multi-node deviation trend analysis: The management platform can collect historical offsets for each node, analyze crystal oscillator drift characteristics in different areas, optimize the first cycle, or replace nodes in advance. 3) Prioritize time-sensitive areas: After deviation calculation, nodes in areas such as operating rooms and ICUs can be given higher calibration priority to ensure absolute time accuracy in critical locations. 4) Prevent malicious tampering: The deviation calculation process and results can be enhanced with verification codes or signatures to prevent local time display from being maliciously modified to evade supervision.

[0146] In a further embodiment of the method, step S4, based on the time offset calculated in S3, the clock's displayed time is actually changed via a pointer drive mechanism (usually a stepper motor and gear set) to align with the network standard time. When the time offset exceeds a set first threshold, the pointer mechanism performs a jump rotation to quickly return to zero; when the time offset does not exceed the first threshold but is greater than zero, the pointer mechanism performs a micro-step continuous rotation to smoothly eliminate the offset. This approach aims to quickly eliminate the offset (ensuring time consistency) while avoiding sudden pointer jumps that could confuse medical staff or patients (improving usability), ensuring that the clock in key areas always displays accurate time, supporting medical records, collaboration, and emergency management.

[0147] Before executing step S4, the following conditions must be met: 1) S3 is successfully completed: a valid offset (including sign and magnitude) has been obtained; 2) The pointer drive mechanism is ready: the stepper motor, transmission gears, and limit detection are normal, and there are no stuck pins or mechanical faults (status is monitored by S5 / S6); 3) The main control module is operating normally: it can execute motion control algorithms and send pulse signals to the drive circuit; 4) Safety conditions: the calibration process will not generate electromagnetic interference with patient safety equipment or critical medical equipment (must comply with hospital EMC specifications).

[0148] In step S4, the classification and threshold setting methods for deviation are as follows:

[0149] Introduce a first threshold (Threshold1) as the critical point for mode selection:

[0150] Jump rotation: |offset| ≥ Threshold1

[0151] In scenarios with large deviations, simply rotate the pointer to the target position to reduce calibration time.

[0152] Microstep continuous rotation: 0 < |offset| < Threshold1

[0153] In scenarios with small deviations, rotate slowly and smoothly to avoid sudden jumps. When offset=0 or close to zero (dead zone): do not perform rotation and directly enter standby mode.

[0154] Threshold selection principles: For general hospital areas: Threshold1 can be set to 5-30 seconds (balancing speed and visual comfort); For high-sensitivity areas (operating rooms, ICUs): Threshold1 can be set to a smaller value (e.g., 2 seconds), favoring continuous rotation to maintain visual stability. Thresholds can be remotely configured and issued by the management platform to adapt to different scenario requirements.

[0155] In step S4, the control command includes the following elements:

[0156] Rotation direction:

[0157] offset > 0 → Local time is slow → The pointer needs to move forward (clockwise).

[0158] offset < 0 → local time is fast → the pointer needs to rotate backward (counter-clockwise).

[0159] Rotation range:

[0160] Convert the time deviation into pointer angles or stepper motor steps:

[0161] Steps = offset × steps / second

[0162] The "steps / second" depends on the motor drive microstepping and gear reduction ratio (e.g., 1.8° per step for a stepper motor, and 0.5 seconds per step for the second hand after deceleration).

[0163] Rotation Modes: Jump Mode: Sends the total number of steps at once, causing the motor to rotate at high speed to the desired position. Continuous Mode: Sends commands in small segments, causing the motor to rotate smoothly at low speed. Speed ​​Curve: Jump Mode: A three-segment curve of acceleration—constant speed—deceleration to avoid start / stop shock. Continuous Mode: Constant speed or gradual acceleration / deceleration to ensure smooth operation. Multi-Hand Linkage: Adjusting the second hand may trigger the minute / hour hand; the total number of linkage steps needs to be calculated to prevent incorrect hour / minute hand positions caused by adjusting only the second hand.

[0164] The pointer-driven execution process includes:

[0165] 1) Skip-type rotation execution, command issuance: The main control module calculates the target number of steps at once and sends it to the motor driver (such as ULN2003, DRV8825, etc.). High-speed rotation: The motor operates at a high speed, and the gear set drives the pointer to the target position quickly. Position detection: The limit switch or encoder confirms that the pointer has reached the target position. If there is no position feedback, the step count is matched with the theoretical position. Stop and reset: The motor stops at the current position, and the control command ends. Visual prompt (optional): The status indicator light can flash once to indicate that calibration is in progress (to avoid medical staff mistaking it for a malfunction).

[0166] 2) Micro-step continuous rotation execution, segmented commands: The total number of steps is divided into several small segments (e.g., the number of steps corresponding to each segment of 0.5 seconds), and sent cyclically. Low-speed smooth rotation: The motor runs at a low speed to ensure continuous pointer movement without abrupt jumps. Real-time fine-tuning: After each segment is executed, the pointer position can be reread (via sensor or step count) to correct subsequent commands and prevent cumulative errors. Smooth throughout: Suitable for scenarios with small deviations; the pointer movement is almost imperceptible visually, or only a very slow movement is felt.

[0167] In a further embodiment, step S5 of the method is the status monitoring and observability step of the time synchronization management method. Its function is to provide real-time or near-real-time feedback on the operating status of each smart clock node to the remote management platform, enabling administrators to: understand whether the node is online and functioning normally; predict potential faults (such as insufficient power, stuck hands, or communication interruptions); provide a data basis for subsequent anomaly alarms (S6); and support operational and maintenance decisions (such as replacing batteries, repairing nodes, or adjusting deployment). In a hospital environment, this proactive monitoring can greatly reduce the risk of time information errors caused by clock malfunctions and compensate for the lag in traditional passive inspections.

[0168] The operating status parameters in step S5 include: whether the node is online, the pointer movement status, the main control module's heartbeat signal, and the remaining power of the energy storage module; abnormal conditions include at least one of the following: the node fails to report status information for three consecutive second cycles, the pointer movement remains stationary for a first time length, the main control module's heartbeat signal is interrupted, or the remaining power of the energy storage module is lower than the second threshold. Extended parameters (optional) include: ambient temperature (affecting crystal oscillator drift and battery performance), the success / failure status and delay of the most recent time synchronization, the operating current of the pointer drive mechanism (to determine mechanical resistance), communication signal strength (RSSI, used for network optimization), etc.

[0169] Parameter Acquisition and Preprocessing: 1) Acquisition Timing: Real-time acquisition; motion sensors and heartbeat signals are continuously monitored during operation, and the memory cache is updated immediately when the status changes; periodic sampling; battery level, signal strength, etc., are sampled at fixed intervals (e.g., every 30 seconds) to avoid frequent readings that increase power consumption; snapshot before reporting: when reporting is triggered in the second cycle, the latest values ​​of all current parameters are packaged to ensure data timeliness. 2) Data Validity Verification: Sensor data is checked for range (e.g., battery level 0-100%, signal strength within a reasonable range), and obvious outliers are removed (e.g., high-frequency jittering of the pointer movement between stillness and motion, which may be noise, is addressed using a de-jittering algorithm).

[0170] In a further embodiment, the method also includes a power outage emergency step: when any smart clock node detects an external mains power outage, it automatically switches to power supply by its built-in energy storage module to maintain the basic operation of the main control module, the pointer drive mechanism and the network communication module. At the moment of switching the power supply mode and afterward, it controls a status indicator light to change its illumination state, and reports the power outage event as a special abnormal status information to the remote management platform.

[0171] In a further embodiment, in method step S2, if the smart clock node fails to successfully acquire the network standard time at the requested time, its internal backup timing unit is activated to keep time. Upon subsequent network recovery, a time synchronization operation is immediately performed, and the backup timing unit is calibrated with frequency compensation based on the synchronization result. By introducing a mechanism of backup timing unit + keeping time + immediate synchronization and frequency compensation after network recovery, it is ensured that during network interruption: the clock can still maintain a usable time display (keeping time); the drift error of the backup timing unit can be quickly corrected after network recovery; and a high degree of consistency with the standard time is maintained over a long period, avoiding the accumulation of time deviations caused by intermittent network outages.

[0172] The hardware and software modules required to implement the above mechanism include: a backup timing unit: typically an independent real-time clock (RTC) chip inside the node (such as DS3231, PCF8563, etc.), driven by a dedicated crystal oscillator (usually 32.768kHz), which can continue timing when the main control module or main power supply is abnormal; a main time synchronization source: a network time server (NTP or hospital-built time service); a main control module: responsible for detecting network request results, switching timing modes, and executing frequency compensation algorithms; and a power management unit: ensuring that the backup timing unit can still be powered by the energy storage module or an independent battery when the main power supply or network module is powered off.

[0173] like Figure 2 As shown, the implementation details of the above mechanism include:

[0174] 1) Detection of network request failures

[0175] During S2 execution: The node sends a time request (NTP / UDP or custom protocol) to the time server according to the first cycle; starts the request timeout count (e.g., 2-5 seconds, depending on the network protocol and hospital environment); if no valid response is received after the timeout, or if an error code / verification failure is received, it is determined that the network time acquisition has failed; the failure count is incremented by 1 (which can be used for subsequent statistical analysis), and the backup timing unit startup process is triggered.

[0176] 2) Activate the backup timing unit to keep time.

[0177] Switching Timing Mode: Upon detecting consecutive failures (or immediately after the first failure), the main control module switches to local timekeeping mode, with the time reference provided by the backup RTC. Timekeeping Initiation: The current time of the backup RTC is read as a temporary local time reference. Automatic calibration tasks dependent on network time are paused (steps S3-S4 temporarily suspend network-based deviation correction). The pointer display remains synchronized with the backup RTC (if the pointer drive mechanism is bound to the RTC). Timekeeping Maintenance: The backup RTC is driven by an independent crystal oscillator, typically with a daily error of ±2ppm-±5ppm (approximately ±5-10 seconds / day), depending on the crystal oscillator quality and ambient temperature. The node continues to periodically attempt network connections (retrying at the start of each cycle, without waiting for the next complete cycle).

[0178] 3) Network recovery detection

[0179] Retry mechanism: During the timekeeping period, the node will still attempt to reconnect to the time server at a certain frequency (which can be a subset of the first period, such as every 1 minute).

[0180] Recovery determination: Once the request is successful and a valid standard time is received, the network is determined to have recovered.

[0181] Perform a time synchronization operation immediately:

[0182] Stop the timekeeping mode and switch the local time base back to the network standard time.

[0183] Perform S3 (compare local RTC time with standard time) and S4 (pointer calibration) once to make the wall clock display perfectly match the standard time.

[0184] Record the deviation between the actual network time and the backup RTC time during this synchronization (i.e., the cumulative drift).

[0185] 4) Frequency compensation calibration

[0186] The goal is to correct the long-term drift of the backup timing unit's crystal oscillator, thereby improving timekeeping accuracy during the next network interruption. The implementation method is as follows:

[0187] a. Calculate the drift rate:

[0188] Drift rate = Timekeeping duration deviation

[0189] Example: After an 8-hour network outage, the backup RTC is 16 seconds behind the standard time → Drift rate = 16 seconds / 8 hours = 2 seconds / hour = approximately 555.6 ppm (this is just an example; the actual crystal oscillator ppm will be much lower). b. Frequency compensation adjustment:

[0190] Some high-precision RTC chips (such as DS3231) have built-in temperature compensation, which can be fine-tuned at the software level by adjusting the timer interrupt frequency or calibration register.

[0191] For a regular RTC, a software compensation counter can be introduced into the main control firmware: during the timekeeping period, the time accumulation is finely adjusted in the opposite direction of the drift rate (e.g., adding / subtracting a few milliseconds per second), which is equivalent to changing the perceived value of the crystal oscillator timing frequency.

[0192] c. Compensation parameter storage: The compensation coefficient is written into the non-volatile memory (EEPROM / Flash), and the corrected timing logic is used directly for the next time timekeeping.

[0193] d. Verify the effect: Calculate the deviation again when the network is restored next time. If the drift is significantly reduced, it means that the compensation is effective.

[0194] 5) Linkage with steps S5 / S6

[0195] Status reporting: When the timekeeping mode is started, the node marks "network time synchronization failed, entering timekeeping mode" in the status information, which is convenient for the management platform to monitor.

[0196] Anomaly detection: If the timeout period is too long (e.g., more than 24 hours) or the drift exceeds the preset warning value, the platform can dispatch an order in advance to check the node crystal oscillator or power supply status.

[0197] Alarm: Failure to restore network synchronization for an extended period may trigger an offline or synchronization failure alarm on S6.

[0198] In another embodiment of the present invention, a hospital time synchronization management system for implementing any of the foregoing method embodiments is also provided, referring to... Figure 3 The hospital time synchronization management system of the present invention mainly consists of three parts: a remote management platform 10, a time server 20, and multiple smart clock nodes 30. They are interconnected through a hospital network 40 (which may include a wired local area network and wireless Wi-Fi). The time server 20 can be a hospital-built NTP server or an NTP service provider with internet access.

[0199] Reference Figure 4The single smart clock node 30 (or "smart clock") is the specific embodiment of this invention. Its appearance is no different from a traditional wall clock, including a housing, a dial 31 housed within the housing, and hands 32. Internally, it integrates a complex electronic system: The main control module 33, typically an embedded microcontroller (MCU), is the control center of the entire node, responsible for executing time synchronization algorithms, processing sensor data, and coordinating the work of various modules. It may integrate a high-precision real-time clock chip (RTC) internally or externally as a backup timing unit, maintaining basic timing when the main control MCU is in sleep mode or the network is interrupted. The stepper motor 34, acting as the hand driving mechanism, receives pulse signals from the main control module 33 and precisely controls the rotation angle and speed of the hands 32. The wireless communication module 35 is the interface for implementing network functions; it can be a Wi-Fi module or a LoRa or NB-IoT module suitable for wide-area low-power scenarios. The sensor module 36 may consist of one or more motion sensors. For example, a triaxial accelerometer can be used to detect whether the clock body vibrates slightly due to the movement of the hands or external factors. If there is no vibration for a long time, it can be preliminarily determined that the clock has stopped. A specially designed photoelectric interruptor can accurately detect whether the second hand is jumping.

[0200] In addition, a heartbeat signal detection circuit can be implemented in software to prove that the program of the main control module 33 is running normally in a loop. Energy storage module 37: Consists of a rechargeable lithium battery pack and a power management unit (PMIC). The PMIC is responsible for seamless switching between mains power and battery power, battery charging management, and accurate monitoring of remaining power. Communication alarm module 38: Its hardware can be reused with the wireless communication module 35, but its software functions are abstracted to specifically construct and send status information and alarm messages in a specific format. Status indicator 39: Such as a multi-color LED light, used for local physical indication. For example, a green light indicates normal operation, a yellow light indicates that battery power is being used (power outage recovery), and a flashing red light indicates a fault.

[0201] It should be understood that those skilled in the art can make improvements or modifications based on the above description, and all such improvements and modifications should fall within the protection scope of the appended claims.

Claims

1. A distributed time synchronization management method suitable for complex hospital environments, characterized in that, Includes the following steps: S1: Multiple smart wall clock nodes deployed in different locations in the hospital establish connections with the time server through the network; S2: Each of the smart wall clock nodes obtains the current network standard time from the time server according to a preset first cycle; S3: Each smart clock node compares its current displayed time with the network standard time and calculates the time deviation. S4: Each of the smart clock nodes generates and sends corresponding control commands to the pointer drive mechanism connected to it based on the calculated time deviation, so as to drive the pointer mechanism to perform at least one jump or continuous rotation, thereby eliminating the time deviation and completing the time calibration. S5: Each of the smart wall clock nodes packages its own operating status parameters into status information and sends the status information to the remote management platform according to the preset second cycle; S6: The remote management platform receives and parses the status information. When it determines that the operating status parameters of any node meet the preset abnormal conditions, it generates alarm information and notifies the management personnel.

2. The method according to claim 1, characterized in that, In step S4, when the time deviation exceeds a set first threshold, the pointer mechanism performs a jump rotation to quickly return to zero; when the time deviation does not exceed the first threshold but is greater than zero, the pointer mechanism performs a micro-step continuous rotation to smoothly eliminate the deviation.

3. The method according to claim 1, characterized in that, The operating status parameters in step S5 include: whether the node is online, the pointer movement status, the heartbeat signal of the main control module, and the remaining power of the energy storage module; The abnormal conditions include at least one of the following: the node fails to report status information for three consecutive second cycles, the pointer movement remains stationary for a first time length, the main control module's heartbeat signal is interrupted, or the remaining power of the energy storage module is lower than the second threshold.

4. The method according to claim 1, characterized in that, It also includes a power outage emergency procedure: when any smart clock node detects an external mains power outage, it automatically switches to power supply from its built-in energy storage module to maintain the basic operation of the main control module, pointer drive mechanism and network communication module. At the moment of switching the power supply mode and immediately thereafter, it controls a status indicator light to change its illumination state, and reports the power outage event as a special abnormal status information to the remote management platform.

5. The method according to claim 1, characterized in that, In step S2, if the smart clock node fails to obtain the network standard time at the requested time, it starts its internal backup timing unit to keep time, and immediately performs a time synchronization operation when the network is restored, and performs frequency compensation calibration on the backup timing unit based on the synchronization result.

6. A hospital time synchronization management system for implementing the method of any one of claims 1-5, characterized in that, include: A time server is used to provide standard time services on the network. The remote management platform is used to manage multiple smart wall clock nodes, receive their reported status information, and determine anomalies and generate alarms according to preset rules; Multiple smart wall clock nodes are distributed throughout the hospital and communicate with the time server and remote management platform; each smart wall clock node includes: Dial and hands; The pointer drive mechanism is used to drive the pointer to rotate; The main control module is used for time comparison, deviation calculation, and control command generation. The network module is used for data exchange with the time server and management platform; The status sensing module is used to collect the operating status parameters of the smart wall clock nodes; Energy storage modules are used to provide power when the main power supply is interrupted; The alarm and indication module is used to perform local status indication and send alarm information to the management platform.

7. The system according to claim 6, characterized in that, The network module is one or more of the following: a Wi-Fi communication module, a LoRa communication module, or an NB-IoT communication module.

8. A smart wall clock for use in a hospital, as part of the system described in claim 6 or 7, characterized in that, include: The housing, the dial and hands located within the housing, and the components within the housing: A stepper motor is used as the pointer drive mechanism; The main control module is connected to the stepper motor and contains or has an external real-time clock chip (RTC). The wireless communication module, connected to the main control module, is used to access the IP network; At least one sensor constitutes a state sensing module, which is connected to the main control module and is used to sense the physical or logical state of the wall clock. A rechargeable battery pack forms an energy storage module, which is connected to the main control module and stepper motor through a power management unit. The communication alarm module is connected to the main control module and is used to achieve two-way communication with the management platform; Status indicator lights, connected to the main control module, are used to provide local visual status feedback.

9. The smart wall clock according to claim 8, characterized in that, The sensor includes a motion sensor for detecting whether the pointer is moving, and / or a heartbeat detection circuit for monitoring the operation of the system program.

10. The smart wall clock according to claim 8, characterized in that, The power management unit is configured to monitor the remaining power of the battery pack and send a low power signal to the main control module when the power is lower than a preset value, triggering an alarm process.

Images