False alarm suppression method and system for fall detection of smart watch with multi-sensor fusion

Abstract

The application relates to the technical field of health monitoring of intelligent wearable devices, and provides a fall detection false alarm suppression method and system of an intelligent watch integrating multiple sensors. Sensor data is collected through the intelligent watch worn by a user; the sensor data is divided into an inertial data window and an air pressure data window; the inertial data window is input into a lightweight neural network model pre-deployed on the intelligent watch for reasoning to obtain a preliminary determination result; if the preliminary determination result is a fall, a relative height change value corresponding to a suspected fall event is obtained; the activity intensity of the user is detected based on acceleration data and angular velocity data; if no motion signal meeting a preset activity intensity appears within a review monitoring window, a fall confirmation instruction is generated, and a fall alarm is triggered in response to the fall confirmation instruction. The application greatly reduces the operation power consumption of the device while ensuring the detection sensitivity, and adapts to the use requirement of low-power continuous monitoring of the intelligent watch.

Description

Technical Field

[0001] This application relates to the field of health monitoring technology for smart wearable devices, and in particular to a method and system for suppressing false alarms in fall detection of a smartwatch that integrates multiple sensors. Background Technology

[0002] As the population ages, smartwatches with fall detection capabilities are widely used in elderly health monitoring. Current fall detection technologies mostly rely on data from a single inertial measurement unit (IMU): schemes using fixed thresholds are prone to misinterpreting everyday movements like arm swings, rapid sitting, and violent vibrations as falls, resulting in a high false alarm rate; while schemes using deep learning for full computation have improved accuracy, continuous high-performance computing significantly drains the watch's battery, making long-term continuous monitoring impossible.

[0003] Meanwhile, existing solutions cannot verify changes in the user's vertical displacement at the physical level, making it difficult to distinguish between a real fall and a violent movement without any change in height. Furthermore, they lack a verification mechanism for the user's activity status after a fall, and scenarios where the user gets up immediately after slipping will still trigger invalid alarms, severely impacting the user experience. Summary of the Invention

[0004] This application provides a method and system for suppressing false alarms in fall detection of smartwatches that integrates multiple sensors, aiming to solve the problems of existing smartwatches consuming a lot of power during continuous high computing power operation and being unable to support long-term continuous monitoring.

[0005] In a first aspect, embodiments of this application provide a method for suppressing false alarms in fall detection of a smartwatch that integrates multiple sensors, the method comprising: Sensor data is collected by a smartwatch worn by the user. The sensor data includes at least acceleration data, angular velocity data, and air pressure data. The sensor data is preprocessed by setting the duration of the air pressure data window to be longer than that of the inertial data window, making the start time of the air pressure data window earlier than that of the inertial data window, and making the end time of the air pressure data window later than that of the inertial data window, thus completing the division between the inertial data window and the air pressure data window. The inertial data window is input into a lightweight neural network model pre-deployed on the smartwatch for inference to obtain a preliminary judgment result. If the preliminary judgment result is a fall, the air pressure data within a specified time period before the start of the inertial data window is extracted to calculate the first average air pressure. The air pressure data within a specified time period after the end of the inertial data window is extracted to calculate the second average air pressure. The relative height change value corresponding to the suspected fall event is obtained by combining the first average air pressure and the second average air pressure. If the relative height change value reaches the preset height descent threshold, a review monitoring window of preset duration will be opened after the suspected fall event ends, and the intensity of user activity will be detected based on acceleration data and angular velocity data; if no action signal that meets the preset activity intensity appears in the review monitoring window, a fall confirmation command will be generated, and a fall alarm will be triggered in response to the fall confirmation command.

[0006] In some embodiments, the sensor data is preprocessed, including: filtering and denoising the acceleration and angular velocity data; smoothing the air pressure data; and aligning the acceleration, angular velocity, and air pressure data according to a unified timestamp.

[0007] In some embodiments, the inertial data window is input into a lightweight neural network model pre-deployed on a smartwatch for inference to obtain a preliminary judgment result, including: running the lightweight neural network model to perform local calculations on the data in the inertial data window; if the output of the lightweight neural network model is a preliminary judgment result of not falling, the current detection process is terminated; if the output of the lightweight neural network model is a preliminary judgment result of falling, the subsequent steps of obtaining height change values ​​are continued.

[0008] In some embodiments, if the relative height change value reaches a preset height decrease threshold, a verification monitoring window of a preset duration is opened after the suspected fall event ends. The user's activity intensity is detected based on acceleration data and angular velocity data. This includes: starting a verification monitoring window of a fixed duration after all data in the inertial data window has been collected, continuously identifying the user's action signals based on acceleration data and angular velocity data during the operation of the monitoring window, and determining whether the action signals have reached a preset activity intensity.

[0009] In some embodiments, if no action signal meeting the preset activity intensity appears in the review monitoring window, a fall confirmation instruction is generated, including: if no action signal meeting the preset activity intensity is detected during the entire operation of the review monitoring window, a fall confirmation instruction is generated; if an action signal meeting the preset activity intensity is detected during the operation of the review monitoring window, the current fall detection process is terminated.

[0010] In some embodiments, before inputting the inertial data window into a lightweight neural network model pre-deployed on a smartwatch for inference, the method further includes: building a one-dimensional convolutional neural network as a basic recognition model; performing quantization compression optimization on the basic recognition model; and writing the optimized basic recognition model into the local storage area of ​​the smartwatch to complete the deployment.

[0011] In some embodiments, sensor data is collected via a smartwatch worn by the user, including: continuously collecting acceleration data and angular velocity data at a first fixed frequency; continuously collecting air pressure data at a second fixed frequency; marking the acceleration data, angular velocity data, and air pressure data with a unified timestamp and storing them in a temporary storage area.

[0012] Secondly, this application provides a fall detection false alarm suppression system for smartwatches that integrates multiple sensors, the system comprising: A data acquisition unit is used to acquire sensor data through a smartwatch worn by the user. The sensor data includes at least acceleration data, angular velocity data, and air pressure data. The sensor data is preprocessed by setting the duration of the air pressure data window to be longer than that of the inertial data window, setting the start time of the air pressure data window to be earlier than that of the inertial data window, and setting the end time of the air pressure data window to be later than that of the inertial data window, thereby completing the division between the inertial data window and the air pressure data window. The result acquisition unit is used to input the inertial data window into a lightweight neural network model pre-deployed on the smartwatch for inference and obtain a preliminary judgment result; if the preliminary judgment result is a fall, it extracts the air pressure data within a specified time period before the start of the inertial data window to calculate the first average air pressure; it extracts the air pressure data within a specified time period after the end of the inertial data window to calculate the second average air pressure; and it combines the first average air pressure and the second average air pressure to calculate the relative height change value corresponding to the suspected fall event. The fall alarm unit is used to open a verification monitoring window of a preset duration after the suspected fall event ends if the relative height change value reaches a preset height drop threshold. The window detects the user's activity intensity based on the acceleration data and angular velocity data. If no action signal meeting the preset activity intensity appears in the verification monitoring window, a fall confirmation command is generated, and a fall alarm is triggered in response to the fall confirmation command.

[0013] This application employs a cascaded detection architecture that combines a lightweight neural network for initial screening with multi-sensor physical rule verification. Routine activities can be directly excluded through initial screening, with only suspected fall events triggering subsequent verification. This significantly reduces device power consumption while ensuring detection sensitivity, making it suitable for the low-power continuous monitoring needs of smartwatches.

[0014] By combining air pressure data to calculate height changes for verification, false alarms for violent movements without any vertical drop are filtered out from the physical nature of vertical displacement. Combined with a post-fall activity intensity verification mechanism, non-fall scenarios such as getting up are excluded based on the user's activity state. This dual verification significantly improves fall detection accuracy and effectively suppresses false alarms. All detection logic can be executed locally on the smartwatch, without relying on cloud computing, resulting in fast detection response and high operational reliability.

[0015] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

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

[0017] Figure 1 This is a schematic flowchart illustrating the steps of a fall detection false alarm suppression method for a smartwatch that integrates multiple sensors, provided in an embodiment of this application. Figure 2 This is a schematic diagram illustrating the principle of a fall detection false alarm suppression method for a smartwatch that integrates multiple sensors, provided in an embodiment of this application. Figure 3 This is a schematic block diagram of a fall detection false alarm suppression system for a smartwatch that integrates multiple sensors, provided in one embodiment of this application. Figure 4 This is a schematic block diagram of the structure of a smartwatch provided in one embodiment of this application.

[0018] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Detailed Implementation

[0019] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0020] The flowchart shown in the attached diagram is for illustrative purposes only and does not necessarily include all content and operations / steps, nor does it necessarily have to be performed in the order described. For example, some operations / steps can be broken down, combined, or partially merged, so the actual execution order may change depending on the actual situation.

[0021] It should be understood that, in order to clearly describe the technical solutions of the embodiments of the present invention, the terms "first" and "second" are used in the embodiments of the present invention to distinguish identical or similar items with essentially the same function and effect. Those skilled in the art will understand that the terms "first" and "second" do not limit the quantity or execution order, and the terms "first" and "second" are not necessarily different.

[0022] It should be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the scope of the application. As used in this specification and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise.

[0023] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0024] As the population ages, smartwatches with fall detection capabilities are being widely used in the field of elderly health monitoring.

[0025] Existing fall detection technologies are mostly based on data from a single inertial measurement unit: schemes using fixed thresholds are prone to misjudging everyday actions such as arm swinging, quick sitting, and violent shaking as falls, resulting in a high false alarm rate; while schemes using deep learning for full-process computation have improved recognition accuracy, continuous high computing power will significantly consume the watch's battery, making it impossible to support long-term continuous monitoring.

[0026] Meanwhile, existing solutions cannot verify changes in the user's vertical displacement at the physical level, making it difficult to distinguish between a real fall and a violent movement without any change in height. Furthermore, they lack a verification mechanism for the user's activity status after a fall, and scenarios where the user gets up immediately after slipping will still trigger invalid alarms, severely impacting the user experience.

[0027] Please refer to Figure 1 and Figure 2 This application provides a method for suppressing false alarms in fall detection for smartwatches that integrates multiple sensors, applicable to smartwatches. This method is specifically designed for smartwatches with multi-sensor data acquisition, local processing, and wireless communication capabilities, and is intended for use in scenarios such as elderly monitoring and sports safety. It is important to note that all data acquisition and processing in this method is initiated only after explicit user authorization, and all calculations are performed locally on the watch. Data is not uploaded unless absolutely necessary, strictly adhering to relevant regulations on personal information protection to fully safeguard user data security and privacy.

[0028] Combination Figure 1 Method steps illustration Figure 2As shown in the schematic diagram, this method is divided into three core steps executed sequentially: multimodal data acquisition and window segmentation, lightweight model initial screening and height parameter extraction, and multi-level confirmation and alarm triggering. The provided method for suppressing false alarms in fall detection for smartwatches that integrates multiple sensors includes steps S101 to S103. Details are as follows: Step S101. Collect sensor data through the smartwatch worn by the user. The sensor data includes at least acceleration data, angular velocity data, and air pressure data. Preprocess the sensor data by setting the duration of the air pressure data window to be longer than the duration of the inertial data window, setting the start time of the air pressure data window to be earlier than the start time of the inertial data window, and setting the end time of the air pressure data window to be later than the end time of the inertial data window, thus completing the division between the inertial data window and the air pressure data window.

[0029] Specifically, this step is the data input end of the entire detection process, responsible for acquiring raw sensor data, optimizing data noise reduction, unifying timing, and segmenting and caching, which is the data foundation for subsequent judgment steps.

[0030] Sensor data is collected by a smartwatch worn by the user. The sensor data includes at least acceleration data, angular velocity data, and air pressure data. The sensor data is preprocessed by setting the duration of the air pressure data window to be longer than that of the inertial data window, making the start time of the air pressure data window earlier than that of the inertial data window, and making the end time of the air pressure data window later than that of the inertial data window, thus completing the division between the inertial data window and the air pressure data window.

[0031] Specifically, this step is the data input end of the entire detection process, responsible for acquiring raw sensor data, optimizing data noise reduction, unifying timing, and segmenting and caching, which is the data foundation for subsequent judgment steps.

[0032] Data acquisition from multiple sensors is achieved through the smartwatch's built-in inertial measurement unit, which includes an acceleration sensing module and an angular velocity sensing module. Both modules start acquiring data simultaneously, collecting acceleration and angular velocity data in three orthogonal directions in three-dimensional space at a frequency of 100 times per second. The built-in barometric pressure sensor continuously collects ambient atmospheric pressure data at a frequency of 25 times per second.

[0033] Each time data sampling is completed, the current sampled data is immediately marked with a millisecond-level high-precision timestamp generated by the smartwatch system, ensuring that each data point has a unique time sequence identifier. All timestamped raw data is stored in real time in the device's built-in circular temporary buffer. The buffer adopts a first-in-first-out overwrite mechanism and can store 30 seconds of full sensor data by default, which ensures that the data is continuous and not lost, while avoiding excessive storage space occupation over a long period of time.

[0034] Sensor data preprocessing involves applying a fourth-order Butterworth low-pass filter algorithm to denoise both acceleration and angular velocity data. The filter cutoff frequency is set to correspond to a motion frequency of twenty times per second, filtering out minor vibrations from watch wear and high-frequency noise from electromagnetic interference, while retaining the effective mid-to-low frequency signals corresponding to human limb movements. A forward-backward bidirectional filtering method is used to avoid phase shifts during filtering, ensuring that the timing phase of the filtered data is consistent with the original data.

[0035] The continuously collected air pressure data is smoothed using a five-point moving average algorithm. This involves calculating the average of five consecutive sampling points to obtain the smoothed air pressure value for the current moment. This eliminates pressure jumps caused by instantaneous atmospheric disturbances and sensor noise, improving the stability of the air pressure data. For the sampling points at the beginning and end of the data sequence, missing sampling points are supplemented using edge copying to ensure that the length of the smoothed data is consistent with the original data.

[0036] Using the time axis of the inertial data as a reference, a linear interpolation algorithm is employed to resample the barometric pressure data. Barometric pressure data with lower sampling frequencies are interpolated to the same sampling density as the inertial data, ensuring that corresponding acceleration, angular velocity, and barometric pressure data exist simultaneously at the same time point, achieving a one-to-one temporal correspondence among the three types of data. After alignment, the acceleration, angular velocity, and barometric pressure data at the same moment are combined into a data frame and stored in chronological order, providing a standardized temporal dataset for subsequent window segmentation.

[0037] A sliding window mechanism is used to segment continuous time-series data, generating inertial data windows and barometric pressure data windows respectively. The duration of the inertial data window is set to 1.5 seconds, corresponding to 150 sampling points. The window slides forward by 0.1 seconds each time, that is, a new set of inertial data windows is generated every 0.1 seconds, which is used to monitor the motion status in real time.

[0038] For each set of inertial data windows, a set of barometric pressure data windows is generated simultaneously. The total duration of the barometric pressure data window is set to 3.5 seconds, and it extends forward by one second and backward by one second, centered on the midpoint of the corresponding inertial data window. This ensures that the start time of the barometric pressure data window is one second earlier than the start time of the inertial data window, and the end time is one second later than the end time of the inertial data window. This forward and backward extension design can fully cover the three stages: the steady state before a suspected fall event, the event itself, and the steady state after the event, providing sufficient reference data for subsequent height change calculations.

[0039] After window segmentation, a unique integer index number is assigned to each paired inertial data window and barometric pressure data window, with each index number corresponding one-to-one with the window's start timestamp. The data from the two windows are stored in different cache blocks, with a mapping relationship established through the index numbers. When retrieving data, only the index number needs to be entered to simultaneously retrieve the corresponding inertial and barometric pressure data, ensuring accurate data matching. A window cache queue is also set up, capable of caching up to twenty paired window data sets, using a first-in, first-out (FIFO) mechanism for updates to ensure the latest window data is always retained while keeping memory usage within a reasonable range.

[0040] The time-series dataset is segmented using a sliding window mechanism, with the two types of windows paired using a center-aligned pairing rule: Inertial data window: duration 1.5s, corresponding to 150 sampling points (100Hz sampling rate), window sliding step size is 0.1s, that is, a new inertial window is generated every 10 sampling points forward, realizing real-time monitoring with high temporal resolution.

[0041] Barometric pressure data window: Total duration 3.5s, corresponding to 350 resampled barometric pressure sampling points; centered on the midpoint of the corresponding inertial window, extending forward 1.75s and backward 1.75s. Let the start time of the inertial window be timu_start and the end time be timu_end = timu_start + 1.5s, then the start time of the barometric pressure window is tbaro_start = timu_start - 1.0s, and the end time is tbaro_end = timu_end + 1.0s.

[0042] This design ensures that the air pressure window fully covers the three stages of "the stable phase before the fall, the fall process, and the stable phase after the fall," reserving sufficient benchmark data for height difference calculation and avoiding the impact of air pressure fluctuations at the moment of the event on the accuracy of the benchmark value.

[0043] Each set of inertial data windows is generated and synchronously assigned a unique integer index number, which corresponds one-to-one with the start timestamp of the inertial window; paired barometric pressure data windows share the same index number. The data for the two types of windows are stored in separate memory blocks: the inertial window stores a 6×150 floating-point matrix, and the barometric pressure window stores a 1×350 floating-point vector, with a mapping relationship established through the index numbers. When calling the data, only the index number needs to be passed in to simultaneously retrieve the paired inertial and barometric pressure data, ensuring zero data matching errors.

[0044] Window cache queue management utilizes a first-in, first-out (FIFO) cache queue capable of holding 20 paired windows. The queue employs a circular buffer; new windows are written from the tail of the queue, while the oldest window is removed from the head and its memory is released. Under normal detection conditions, the queue always retains the 20 most recent window sets, ensuring that the corresponding window can be retrieved in case of a suspected fall event, while keeping memory usage within a reasonable range for the smartwatch embedded system. When a window set is marked as a suspected fall event, the system locks the memory corresponding to that window, preventing queue overwriting until the current detection cycle ends.

[0045] Step S102. Input the inertial data window into the lightweight neural network model pre-deployed on the smartwatch for inference to obtain a preliminary judgment result; if the preliminary judgment result is a fall, extract the air pressure data within a specified time period before the start of the inertial data window to calculate the first average air pressure; extract the air pressure data within a specified time period after the end of the inertial data window to calculate the second average air pressure; combine the first average air pressure and the second average air pressure to calculate the relative height change value corresponding to the suspected fall event.

[0046] Specifically, this step completes the initial fall determination and physical feature extraction, and relies on the local computing power of the smartwatch to realize model inference.

[0047] First, the input inertial data window is preprocessed by normalization. This involves linearly mapping the raw acceleration and angular velocity values ​​to a range of -1 to 1, based on the sensor's measurement range, thus eliminating the impact of differences in sensor ranges on model inference. After normalization, the data is organized into the input format required by the model according to channel order and fed into a lightweight one-dimensional convolutional neural network model pre-deployed on the smartwatch for forward propagation inference.

[0048] The lightweight model's structure consists of: an input layer, two sets of convolutional and pooling modules, a global average pooling layer, two fully connected layers, and an output layer. The first set of convolutional modules uses a one-dimensional convolutional kernel of size 5, outputting 16 feature channels, followed by a max-pooling layer of size 2. The second set of convolutional modules uses a one-dimensional convolutional kernel of size 3, outputting 32 feature channels, followed by a max-pooling layer of size 2. The global average pooling layer compresses the two-dimensional feature map into a one-dimensional feature vector. The two fully connected layers sequentially perform feature mapping and classification calculations. The output layer outputs a probability value between zero and one, representing the likelihood of a fall event corresponding to the current window of data.

[0049] The model has been optimized through eight-bit integer quantization compression, with the number of model parameters controlled to within 100,000. The time taken for a single inference operation is no more than 20 milliseconds, and it only consumes very low computing power resources, making it suitable for the low-power operation requirements of smartwatches.

[0050] The probability threshold is set to 0.7. If the probability value output by the model is less than or equal to 0.7, the preliminary judgment result is that it is not a fall. At this time, the system immediately clears the cached data of the current window, switches the processor to low-power operation mode, and terminates the current detection process. If the probability value output by the model is greater than 0.7, the preliminary judgment result is that it is a fall. The current event is marked as a suspected fall event. The system retrieves the bound air pressure data window through the index and enters the subsequent calculation of the relative height change value.

[0051] After retrieving the corresponding air pressure data window, benchmark values ​​were calculated by extracting stable air pressure data before and after the event: the period from 0.3 seconds to 0.6 seconds before the start time of the inertial data window was selected as the pre-benchmark segment, and the period from 0.3 seconds to 0.6 seconds after the end time was selected as the post-benchmark segment. The selection of the two benchmark segments avoided the moment immediately adjacent to the event to prevent airflow disturbances and arm movements during the event from affecting the accuracy of the benchmark values.

[0052] All air pressure sampling points within the two reference segments were extracted. Outliers were removed from both sets of data using the Grubbs criterion, specifically sampling points deviating from the average value by more than three standard deviations, thus eliminating abnormal data caused by sudden sensor noise or abrupt changes in external air pressure. The arithmetic mean of the remaining sampling points after outlier removal was calculated to obtain the initial and subsequent reference air pressures.

[0053] Based on the physical law that atmospheric pressure decreases with increasing altitude, and according to the correspondence between air pressure and altitude under standard atmospheric conditions, the altitude corresponding to the previous reference air pressure and the altitude corresponding to the subsequent reference air pressure are calculated separately. The difference between the two altitudes is the change in relative vertical altitude before and after the event. The altitude conversion formula is: h = 44330 × [1 - (P / P0)] 0.1903 ]; Where h is the altitude, P is the measured air pressure, and P0 is the standard atmospheric pressure at sea level; the relative altitude change value Δh is the difference between the corresponding altitude of the previous reference segment and the corresponding altitude of the subsequent reference segment. During the calculation, temperature compensation can be performed using data from the watch's built-in temperature sensor to correct the impact of temperature changes on the accuracy of the barometric pressure sensor measurement, thereby improving the accuracy of altitude calculation.

[0054] Meanwhile, when a person wearing a smartwatch falls while standing, the vertical height difference of the wrist from the standing position to the falling position is typically around 0.6m, corresponding to a change in atmospheric pressure of approximately 7Pa. Since this solution uses the relative difference in air pressure before and after the event to calculate the relative height difference, rather than relying on absolute altitude, it can stably capture the instantaneous vertical displacement caused by the fall, providing a sufficiently reliable physical basis for judgment. Furthermore, this solution uses a pressure sensor with a waterproof and sealed structure, ensuring excellent self-sealing. In rainy weather, ambient moisture will not penetrate the sensor and affect the accuracy of air pressure measurement. Moreover, the core algorithm is based on the relative difference in air pressure over a short period; the overall slow change in ambient air pressure is offset by the difference calculation. Therefore, the interference of rainy weather on the algorithm's detection accuracy is minimal and negligible.

[0055] The selection of baseline segments and outlier removal are achieved by selecting two stable periods far removed from the event process from the paired barometric pressure data windows as baselines: Pre-reference period: The time period from 0.3s to 0.6s before the start of the inertial window, corresponding to 30 resampled air pressure points, represents the stable air pressure state before the fall; Post-baseline segment: The period from 0.3s to 0.6s after the end of the inertial window, corresponding to 30 resampled air pressure points, represents the stable air pressure state after the fall.

[0056] Both benchmarks avoid the moment immediately following the event to prevent airflow disturbances and instantaneous pressure fluctuations caused by rapid arm movements during a fall.

[0057] For the sampling points within the two baseline segments, outliers were removed using the Grubbs criterion: First, the arithmetic mean μ and sample standard deviation of the data for that segment were calculated. For each sampling point x_i, the statistic G_i = |x_i - μ| / σ was calculated. If G_i was greater than the corresponding confidence level's Grubbs critical value, the point was determined to be an outlier and removed. This process was repeated until no outliers were found within the segment. After removal, the arithmetic mean of the remaining sampling points was calculated to obtain the preceding baseline pressure P1 and the following baseline pressure P2.

[0058] Based on the international standard atmospheric model, the conversion formula between air pressure and altitude is: h = 44330 × [1 - (P / P0)] 0.1903 ]; where h is the altitude (unit: meters), P is the measured air pressure value, and P0 is the standard sea level atmospheric pressure (1013.25hPa).

[0059] Substituting the front reference pressure P1 and the rear reference pressure P2 into the formula, we obtain the front reference height h1 and the rear reference height h2. The difference between the two is the relative height change value h1-h2. Temperature compensation correction is introduced in the calculation process: the current ambient temperature T is read by the temperature sensor built into the watch, and combined with the temperature drift coefficient k of the barometer sensor, the measured barometer pressure is corrected by P_corr=P+k×(T-T0), where T0 is the sensor calibration reference temperature, eliminating the influence of temperature changes on the accuracy of barometer measurement.

[0060] This method uses the relative difference in air pressure over a short period of time to calculate the altitude difference, rather than relying on absolute altitude. Therefore, slow overall changes in ambient air pressure (such as air pressure drift caused by weather changes and diurnal temperature differences) will cancel each other out in the difference calculation and will not affect the test results.

[0061] Meanwhile, the product uses a barometric pressure sensor with an IP68 waterproof sealing structure. The sensor cavity is connected to the outside world through a waterproof and breathable membrane, preventing water vapor from penetrating the inside of the sensing element. Rainy weather will only cause a slow overall change in ambient air pressure and will not cause a short-term local pressure jump. Therefore, it has minimal interference with the fall detection algorithm based on relative difference and can be ignored.

[0062] This air pressure-assisted detection solution has been tested in mass-produced smartwatches. When a person falls from a standing position, the vertical drop of the wrist is usually about 0.6m, which corresponds to an air pressure change of about 7Pa. This can be stably identified by the sensor, and the physical judgment basis is sufficient and reliable.

[0063] Step S103. If the relative height change value reaches the preset height drop threshold, a review monitoring window of preset duration is opened after the suspected fall event ends, and the user's activity intensity is detected based on acceleration data and angular velocity data; if no action signal that meets the preset activity intensity appears in the review monitoring window, a fall confirmation command is generated, and a fall alarm is triggered in response to the fall confirmation command.

[0064] Specifically, this step is the final confirmation and alarm stage, which sequentially completes the height threshold comparison, post-fall activity status verification, command generation, and alarm output.

[0065] The calculated relative height change value is compared with a preset height drop threshold within the device. This threshold is set to 0.4 meters by default and can be fine-tuned according to user scenarios. If the relative height change value is less than the preset height drop threshold, it indicates that the user has not experienced significant vertical displacement, which does not conform to the physical characteristics of a real fall. The event is determined to be a false alarm, and the system clears all relevant cached data, resets the detection status, and terminates this round of detection. If the relative height change value is greater than or equal to the preset height drop threshold, it confirms that the user has experienced significant vertical displacement, which conforms to the physical characteristics of a fall, and the system proceeds to the subsequent activity intensity verification stage.

[0066] Since the air pressure data for the later reference segment is located 0.3 to 0.6 seconds after the end of the inertial data window, the calculation of the relative height change value can only be completed after the air pressure data for this period is collected. After the model initially screens the data as a suspected fall, it will continuously cache all subsequent sensor data. Once the height calculation is completed and the height change is determined to meet the standard, the validity statistics of the verification monitoring window will be started from the end of the inertial data window. Because the data from the end of the inertial window to the completion of the height determination has been pre-stored in the cache, the verification window can directly retrieve the cached data for the monitoring duration without waiting for real-time acquisition. This ensures both the integrity of the height calculation data and the accurate start of the verification duration from the end of the event, without any timing conflicts or data interference.

[0067] After the height determination is passed, the system starts a ten-second verification monitoring window, with the last sampling point of the inertial data window as the starting point. The cached data before the window starts is directly included in the monitoring scope, and data continues to be collected in real time during the window operation, so as to achieve a seamless connection between the monitoring period and the end of the event and avoid missing key action data after the fall.

[0068] During the verification monitoring window, the device continuously collects acceleration and angular velocity data at a frequency of 100 times per second. All verification data is stored separately in a temporary buffer, not mixed with the normal detection window buffer, to avoid data confusion. Upon acquiring a new sampling point, the current user activity intensity is immediately calculated. The preset activity intensity is set with two parallel quantization judgment conditions; satisfying either one is considered as the existence of autonomous activity meeting the preset activity intensity. The acceleration determination condition is first calculated by measuring the triaxial composite acceleration value at the current sampling point. The calculation formula is as follows: a_total = (ax) 2 +ay 2 +az 2 ) 0.5 ; Where ax, ay, and az are the acceleration values ​​along the x, y, and z axes, respectively. The arithmetic mean of the composite acceleration values ​​from five consecutive sampling points is then taken to obtain the current effective acceleration value. If the effective acceleration value for five consecutive sampling periods exceeds a preset gravity disturbance threshold, it is determined that there is significant limb movement. The gravity disturbance threshold ranges from 1.5g to 3.0g, with a default preferred value of 2.0g.

[0069] The angular velocity determination criterion is to take the maximum value among the absolute values ​​of the three axial angular velocities as the current peak angular velocity; if the peak angular velocity at any sampling point exceeds a preset rotation rate threshold, it is determined that there is a limb flipping or waving motion. The rotation rate threshold ranges from 100° / s to 300° / s, with a default preferred value of 200° / s.

[0070] During the review process, an activity intensity determination is performed immediately after the calculation of each sampling point is completed, without waiting for the window to close, thus improving response efficiency.

[0071] If, at any point during the verification monitoring window's operation, an action signal meeting the preset activity intensity is detected, it indicates that the user still possesses the ability to move independently after the event, most likely a routine action such as immediately getting up after slipping and quickly sitting down, and is thus determined to be a false alarm. At this point, the system immediately terminates the verification monitoring, clears the data in the verification temporary cache, unlocks the data in the window corresponding to the current event, allowing the cache queue to be overwritten, switches the processor from high-power mode back to low-power normal detection mode, and continues to generate the next set of detection windows by sliding steps, resuming the normal detection cycle.

[0072] If the monitoring window fails to detect any action signal meeting the preset activity intensity throughout the entire monitoring period from startup to shutdown, it indicates that the user lost the ability to move independently after the event, consistent with the characteristics of a real fall, and is therefore determined to be a real fall event. At this point, the system generates a standardized fall confirmation command. The command uses a structured format and includes key data such as a unique event number, event timestamp, location information at the time of the event, and event detection confidence level, which is used to trigger subsequent alarm procedures. The command is immediately sent to the alarm module after generation, and all related sensor data is simultaneously stored in the local event log for later review.

[0073] Upon receiving a fall confirmation command, the smartwatch's alarm module simultaneously triggers both local and remote alarms. Local alarms include: controlling the vibration motor to provide intermittent strong vibrations, controlling the buzzer to emit a high-frequency alert sound, and illuminating the watch screen to display a prominent alarm message to alert those nearby, while also allowing the user to manually cancel the alarm. Remote alarms include: sending an alarm message containing the user's current location and the time of the fall to pre-set emergency contacts via the watch's built-in wireless communication unit; if the user has set up an emergency call function, it can also automatically dial the emergency contact's number for remote assistance.

[0074] During the alarm process, if the user manually triggers the cancellation command via buttons, touch screen, or other means, all alarm actions will be immediately terminated, the detection status will be reset, and normal detection will resume.

[0075] In some embodiments, the sensor data is preprocessed, including: filtering and denoising the acceleration and angular velocity data; smoothing the air pressure data; and aligning the acceleration, angular velocity, and air pressure data according to a unified timestamp.

[0076] For the raw data of six channels including acceleration and angular velocity, a fourth-order Butterworth low-pass filter is used for noise reduction for each channel. The filter cutoff frequency is set to 20Hz to match the main effective frequency band of human limb movement. This can filter out high-frequency noise above 20Hz caused by watch micro-vibration and electromagnetic interference, while fully preserving the mid-to-low frequency characteristics of movements such as falling and arm swinging.

[0077] The filtering employs a forward-backward bidirectional filtering (zero-phase filtering): first, the data sequence is filtered once in the forward time direction, and then the filtered result is filtered a second time in the reverse time direction. The final output signal has no phase shift, and its timing phase is completely consistent with the original data. The filtering calculation formula is based on the difference equation of the Butterworth filter. The output value at each moment is calculated by weighting the current input value, the previous input value, and the previous output value. The weighting coefficients are determined by the cutoff frequency and sampling rate of the fourth-order filter.

[0078] The raw air pressure data were smoothed using a five-point moving average algorithm. The calculation formula is as follows: Psmooth[i]=(Pi-2+Pi-1+Pi+Pi+1+Pi+2) / 5; Where Pi is the i-th original air pressure sampling point, and Psmoothi ​​is the air pressure value at the corresponding time after smoothing. For the sampling points at the beginning and end of the data sequence (i<2 or i>N-3, where N is the total number of sampling points), missing points are supplemented by edge copying, that is, the first sampling point is copied at the beginning of the sequence to complete it, and the last sampling point is copied at the end of the sequence to complete it, ensuring that the length of the smoothed data is completely consistent with the original data.

[0079] This smoothing method can effectively suppress sensor random noise and pressure jumps caused by instantaneous airflow disturbances, while preserving the overall trend of air pressure changes, providing a stable input for subsequent altitude difference calculations.

[0080] Multi-source data time-series alignment uses the sampling time of inertial data as a reference and employs a linear interpolation algorithm to resample the air pressure data, ensuring a one-to-one correspondence between the two types of data on the time axis. Specifically, for any inertial sampling time t, the two sampling points (t1, P1) and (t2, P2) closest in time and located before and after t in the air pressure data sequence are found. The air pressure value corresponding to time t is then calculated using linear interpolation. P(t) = P1 + (P2 - P1) × (t - t1) / (t2 - t1); After iterating through all inertial sampling times and completing the resampling of all air pressure data, the triaxial acceleration, triaxial angular velocity, and air pressure data at the same time are combined into a standard data frame and stored in chronological order as a time-series dataset. Each data frame contains 7 numerical dimensions, and the sampling rate is uniformly 100Hz to provide standardized input for subsequent window segmentation.

[0081] In some embodiments, the inertial data window is input into a lightweight neural network model pre-deployed on a smartwatch for inference to obtain a preliminary judgment result, including: running the lightweight neural network model to perform local calculations on the data in the inertial data window; if the output of the lightweight neural network model is a preliminary judgment result of not falling, the current detection process is terminated; if the output of the lightweight neural network model is a preliminary judgment result of falling, the subsequent steps of obtaining height change values ​​are continued.

[0082] This embodiment refines the data processing before and after model inference, the decision threshold, and the resource scheduling after branching.

[0083] Before model inference, range normalization is performed channel-by-channel on the 6-channel data within the inertial window, linearly mapping the original sensor values ​​to the [-1, 1] interval to eliminate the influence of range differences between different sensors on model inference. The normalization formula is: x_norm=2×(x-x_min) / (x_max-x_min)-1; Where x is the original sampled value, and x_max and x_min are the upper and lower limits of the corresponding sensor range: the accelerometer range is ±16g, so x_max=16g and x_min=-16g; the gyroscope range is ±2000° / s, so x_max=2000° / s and x_min=-2000° / s.

[0084] After normalization, the data is organized into a 150×6 two-dimensional matrix format, which is used as the input tensor of the model input layer.

[0085] Model inference and threshold determination are performed by feeding the normalized input tensor into a locally deployed lightweight one-dimensional convolutional neural network, performing forward propagation inference, and outputting a probability value p between 0 and 1, representing the confidence level of the fall event corresponding to the current window.

[0086] Set the judgment threshold to 0.7: If p≤0.7, the preliminary judgment is that it was not a fall, and this round of testing is terminated; If p > 0.7, the preliminary judgment result is a fall, the current window is marked as a suspected fall event, the window data of the corresponding index is locked, and the subsequent physical verification process begins.

[0087] Differentiated computing power scheduling strategies are adopted for the two judgment results to achieve low-power operation: Non-fall branch: Immediately release the cache memory of the current window, reduce the processor core clock frequency to a low-power level, maintain 100Hz sampling for the inertial sensor and 25Hz sampling for the barometer sensor, and continue generating the next set of windows by the sliding step size, maintaining the normal detection cycle. This branch covers most everyday scenarios and is the main control link for average power consumption.

[0088] Suspected fall branch: Upgrade the processor to full computing power, keep the sensor sampling frequency unchanged, retrieve the paired air pressure data window through index, and start the subsequent altitude change calculation and multi-level verification process.

[0089] In some embodiments, if the relative height change value reaches a preset height decrease threshold, a verification monitoring window of a preset duration is opened after the suspected fall event ends. The user's activity intensity is detected based on acceleration data and angular velocity data. This includes: starting a verification monitoring window of a fixed duration after all data in the inertial data window has been collected, continuously identifying the user's action signals based on acceleration data and angular velocity data during the operation of the monitoring window, and determining whether the action signals have reached a preset activity intensity.

[0090] After the altitude change judgment is passed, the system takes the last sampling point time t_imu_end of the inertial window as the official starting point of the review monitoring. The total duration of the review window is 10s, and the monitoring end time is t_imu_end+10s.

[0091] Since altitude calculation requires air pressure data from 0.3 to 0.6 seconds after the end of the inertial window, the altitude determination is completed later than t_imu_end. The inertial data collected during this period has been pre-stored in a temporary buffer. When the review starts, this buffered data is directly backtracked into the review window without waiting for real-time collection. This ensures the data integrity of altitude calculation and ensures that the review duration is accurately calculated from the end of the event without any timing conflicts.

[0092] All data during the review period is stored separately in a dedicated temporary cache area, which is physically isolated from the window cache of normal testing to avoid data confusion.

[0093] The preset activity intensity is set with two parallel quantization criteria. Meeting either criterion indicates autonomous activity: Acceleration criterion: For each sampling point, the triaxial composite acceleration is first calculated. a_total = (ax) 2 +ay 2 +az 2 ) 0.5 ; The arithmetic mean of the combined acceleration from five consecutive sampling points is then calculated to obtain the effective acceleration value. If the effective acceleration value for five consecutive sampling periods exceeds the gravity disturbance threshold, it is determined that there is a large-amplitude limb movement. The gravity disturbance threshold ranges from 1.5g to 3.0g, with a default preferred value of 2.0g.

[0094] Angular velocity determination criteria: For each sampling point, the maximum absolute value of the three-axis angular velocities, ωmax = max(|ωx|,|ωy|,|ωz|), is taken as the peak angular velocity. If the peak angular velocity of any sampling point exceeds the rotation rate threshold, it is determined that there is a limb flipping or waving motion. The rotation rate threshold ranges from 100° / s to 300° / s, with a default preferred value of 200° / s.

[0095] The verification process employs a point-by-point real-time judgment mechanism. Upon completion of each new sampling point, the aforementioned two indicators are immediately calculated and a judgment is executed, without waiting for the entire window to close. Once a target activity signal is detected, the verification process immediately terminates, triggering a false alarm branch; if no target activity is detected throughout the 10-second window, a real fall branch is triggered. This mechanism effectively shortens the high-power runtime of false alarm scenarios and reduces the system's average power consumption.

[0096] In some embodiments, if no action signal meeting the preset activity intensity appears in the review monitoring window, a fall confirmation instruction is generated, including: if no action signal meeting the preset activity intensity is detected during the entire operation of the review monitoring window, a fall confirmation instruction is generated; if an action signal meeting the preset activity intensity is detected during the operation of the review monitoring window, the current fall detection process is terminated.

[0097] If a target activity signal is detected during the review process and is determined to be a false alarm, the system will perform a reset in the following order: immediately stop review monitoring and clear all data in the review-dedicated temporary buffer area; Unlock the window data corresponding to the current suspected fall event, allowing the window cache queue to overwrite it; Switch the processor from full computing power mode back to low power normal detection mode; Reset the detection state machine to idle state, continue to generate a new detection window by sliding step of 0.1s, and resume normal detection cycle.

[0098] The entire reset process is completed within 10ms, ensuring that the continuity of detection is not affected.

[0099] If no activity is detected reaching the target during the entire review window, it is determined to be a real fall. The system generates a structured fall confirmation instruction, which includes the following fields: Event Unique ID: a 32-bit unsigned integer that globally and uniquely identifies this fall event; Event Occurrence Timestamp: millisecond-level UTC time, corresponding to the end time of the inertial window; Event Location Information: if the positioning function is enabled, it includes the current latitude and longitude coordinates; Detection Confidence: a confidence score of 0 to 1 calculated by combining the model probability, height difference amplitude, and review static duration; Severity Level: corresponding to the mild / moderate / severe classification result.

[0100] Once the command is generated, it is immediately sent to the alarm module to trigger an alarm; at the same time, all data of this event (original sensor window data, judgment results of each stage, alarm execution records) is written to the local non-volatile storage event log. The size of a single log is about 2KB, and it can store 100 historical events by default, which can be viewed by users and their families.

[0101] After an alarm is triggered, the user can actively terminate the alarm by pressing a physical button or clicking the cancel button on the screen. Upon receiving the cancellation command, the system immediately stops all local and remote alarm actions, resets the detection status, and resumes normal detection; at the same time, it marks this event as "user cancellation" and saves it in the local log, which can be used as sample data for subsequent adaptive threshold calibration.

[0102] In some embodiments, before inputting the inertial data window into a lightweight neural network model pre-deployed on a smartwatch for inference, the method further includes: building a one-dimensional convolutional neural network as a basic recognition model; performing quantization compression optimization on the basic recognition model; and writing the optimized basic recognition model into the local storage area of ​​the smartwatch to complete the deployment.

[0103] The basic recognition model is a one-dimensional convolutional neural network adapted to time-series signals. The parameters of each layer and the input and output dimensions are defined as follows: Input layer: dimension (150, 6), corresponding to 150 time steps and 6 sensing channels; The first convolutional module contains one 1D convolutional layer and one max pooling layer. The convolutional kernel size is 5, the number of output channels is 16, and same padding is used to ensure that the size remains unchanged. The activation function is ReLU. The pooling kernel size is 2, the stride is 2, and the output dimension is (75, 16). The second convolutional module contains one 1D convolutional layer and one max pooling layer. The convolutional kernel size is 3, the number of output channels is 32, with same padding and ReLU activation; the pooling kernel size is 2, the stride is 2, and the output dimension is (37, 32). Global average pooling layer: performs global averaging over the time dimension and outputs a 32-dimensional one-dimensional feature vector; First fully connected layer: Output dimension 16, ReLU activation; The second fully connected layer has an output dimension of 1, is activated by Sigmoid, and outputs a fall probability value of 0 to 1.

[0104] The model has approximately 12,000 parameters, a lightweight structure, and is suitable for embedded edge operation.

[0105] The model was trained using a multi-source dataset: including multi-pose fall data (forward, backward, lateral, tripping, etc.) collected from real people and daily action data (walking, running, waving, sitting down, rolling over, pounding on the table, etc.), supplemented by publicly available fall datasets for augmentation, with a total sample size exceeding 100,000. Training employed a binary cross-entropy loss function and the Adam optimizer, with the training and validation sets split in an 8:2 ratio. After training, the validation set accuracy reached over 96%.

[0106] After training, INT8 integer quantization is used for compression: the activation values ​​of the model are statistically analyzed using a calibration dataset, and the 32-bit floating-point weights and activation values ​​are converted into 8-bit integer representations. After quantization, the model size is compressed to 1 / 4 of its original size, the inference speed is increased by more than 3 times, the accuracy loss is controlled within 1%, the time for a single inference is less than 20ms, and the computational power consumption is extremely low.

[0107] The quantized model file is written to the smartwatch's read-only storage partition. The model is automatically preloaded into memory upon system startup, eliminating the need for repeated storage reads. Model inference is executed using the watch's local neural network inference engine, completed entirely on the device side without internet access, ensuring user privacy by preventing data from leaving the device. The model supports OTA updates, and future firmware iterations can further optimize recognition accuracy and adapt to new scenarios.

[0108] In some embodiments, sensor data is collected via a smartwatch worn by the user, including: continuously collecting acceleration data and angular velocity data at a first fixed frequency; continuously collecting air pressure data at a second fixed frequency; marking the acceleration data, angular velocity data, and air pressure data with a unified timestamp and storing them in a temporary storage area.

[0109] Sensor hardware parameters and synchronous acquisition The smartwatch has three built-in sensors, and its hardware specifications are as follows: Accelerometer: Measurement range ±16g, resolution not less than 0.001g, sampling frequency 100Hz; Gyroscope: Measurement range ±2000° / s, resolution not less than 0.06° / s, sampling frequency 100Hz; Barometric pressure sensor: Measurement range 300~1100hPa, resolution not less than 0.01hPa, sampling frequency 25Hz.

[0110] The accelerometer and gyroscope are sampled synchronously in hardware, sharing the same sampling clock to ensure that the acceleration and angular velocity data at the same moment are strictly aligned; the barometer is sampled independently and timestamped by the global system clock.

[0111] The system uses a global millisecond-level real-time clock (RTC) as a unified time reference. When each sensor completes a sampling, the hardware automatically reads the current system timestamp with an accuracy of 1 millisecond and stores it in conjunction with the sampling data.

[0112] The raw data is stored separately by channel: acceleration data includes three components (ax, ay, z) and a timestamp; gyroscope data includes three components (ωx, ωy, ωz) and a timestamp; and barometric pressure data includes barometric pressure values ​​and a timestamp. All data is written to its respective raw buffer in the order of sampling time, providing a data source for subsequent preprocessing and alignment.

[0113] All three types of sensor data are stored using a first-in, first-out (FIFO) circular buffer (circular queue). The default buffer capacity is 30 seconds of full data: 3000 sampling points can be stored for inertial data, and 750 sampling points can be stored for barometric pressure data. The buffer write pointer moves forward continuously with sampling, and when the buffer is full, new data automatically overwrites the oldest data, ensuring that the most recent 30 seconds of sensor data are always retained.

[0114] Before writing data to the buffer, over-range anomaly filtering is performed: if the sampled value exceeds the sensor's nominal range, it is determined to be invalid data and replaced with the value of the previous valid sampled point to avoid anomalies interfering with subsequent algorithm judgments.

[0115] In some embodiments, to address the shortcomings of fixed judgment thresholds being unable to adapt to differences in user height, wearing habits, and physical activity levels, resulting in high false alarm and false negative rates for specific groups, an adaptive threshold mechanism of initial calibration + dynamic iteration is designed to continuously optimize detection parameters to match individual user characteristics.

[0116] In the initialization phase of the detection process and the feedback phase after the S103 judgment, when a user first activates the fall detection function, the system guides the user to complete five standard actions in sequence: standing for 30 seconds, slowly sitting down, quickly sitting down, raising an arm to check the time, and jumping in place, with each action repeated three times. The system collects full inertial and air pressure data during the actions and calculates individual baseline parameters: the average height change of all sitting actions is extracted and multiplied by a safety factor of 0.8 to generate a user-specific initial height descent threshold; the average wearing axis angle of all arm-raising actions is extracted to generate a user-specific posture verification angle threshold range; and the average activity intensity of daily slow walking and arm swinging is extracted to generate a user-specific physiological verification activity intensity threshold.

[0117] All initial thresholds have upper and lower limits (height threshold is limited to 0.3m-0.6m, attitude angle threshold is limited to 15°-30°, and activity intensity threshold is limited to 1.5g-3.0g) to prevent calibration deviations from causing the thresholds to exceed reasonable ranges.

[0118] During routine testing, the system automatically selects two types of events as calibration samples and stores them in the local sample library, including: Category 1: Events initially identified as suspected falls by the model, but subsequently determined to be false alarms by any level of physical verification (e.g., events where the height meets the standard but physiological verification detects spontaneous slipping and getting up). The second category: events where users manually cancel alarms via buttons or touchscreens.

[0119] A threshold fine-tuning is triggered every 30 valid calibration samples collected while the watch is in an idle charging state. A weighted average algorithm is used to update the threshold, with the weight of the new sample set to 0.7 and the weight of the historical threshold set to 0.3. This ensures that the threshold iterates according to user habits while avoiding sudden changes in the threshold due to a single abnormal sample.

[0120] By extracting the gravitational acceleration component in a static state once per hour, the long-term average angle between the watch's wearing axis and the direction of gravity is calculated. The angle judgment range for posture verification is dynamically adjusted, automatically adapting to changes in posture reference caused by the user's left / right hand wearing the watch, different wearing tightness, and different wearing positions, without requiring manual settings by the user.

[0121] The calculation method for the included axial angle θ is as follows: In a stationary state, the acceleration signal is primarily composed of the gravitational component, and the triaxial acceleration vector is taken as a = [ax, ay, az]. T Calculate the acceleration modulus ||a|| = (ax) 2 +ay 2 +az 2 ) 0.5 Then the axial included angle θ = arccos(az / ||a||) is converted into an angle value of θdeg = θ × 180 / π; the average included angle θmean of the window is obtained by averaging all sampling points within the window.

[0122] In some embodiments, to address the shortcomings of fixed detection strategies in balancing accuracy and power consumption across different activity scenarios, the sampling frequency, verification level, and detection sensitivity are dynamically adjusted by identifying user activity scenarios in real time. This minimizes average power consumption and extends the battery life of smartwatches while ensuring detection reliability.

[0123] This mechanism is embedded as a front-end module in the S101 data acquisition process. It extracts statistical features of inertial data every 5 seconds, including the average value of triaxial composite acceleration, acceleration variance, and peak value of average angular velocity. It uses a lightweight decision tree classifier to identify the current user activity scenario, which is divided into five categories: static scenario (sitting, lying down), light activity scenario (walking slowly, raising arms daily), moderate activity scenario (walking briskly, going up and down stairs), vigorous activity scenario (running, jumping), and sleep scenario.

[0124] Configure differentiated detection parameters and verification levels for different scenarios, including: Sleep scenario: Inertial sampling frequency is reduced to 25Hz, barometric pressure sampling frequency is reduced to 5Hz, window sliding step size is increased to 0.5s, only the "model initial screening + height verification" two-level detection is retained, attitude verification and rotation verification are turned off, and the overall computing power consumption is reduced to 20% of the default mode; For static / mild activity scenarios: the default detection parameters are used, namely 100Hz inertial sampling, 25Hz barometric pressure sampling, and 0.1s window sliding step size, to perform three levels of detection: initial model screening, height confirmation, and physiological verification. For moderate / intense activity scenarios: the inertial sampling frequency is increased to 200Hz, the barometric pressure sampling frequency is increased to 50Hz, the window sliding step size is kept at 0.1s, and the five-level verification of "model initial screening + attitude verification + rotation verification + height verification + physiological verification" is fully opened. At the same time, the probability threshold of model initial screening is increased from 0.7 to 0.8, and the sensitivity of initial screening is appropriately reduced to filter out a large number of false triggers caused by intense exercise.

[0125] The posture verification, specifically wrist axis determination, is performed by calculating the average included angle θmean within the window. If θmean ≤ 20° (range 15°~30°), the wrist is considered vertical, ruling out the possibility of a fall. The rotation verification, specifically the cumulative angle determination using the gyroscope, is performed by calculating the cumulative rotation angle ∑|ω|△t within the window. If the cumulative angle is less than 200° (range 150°~250°), there is no significant rollover, ruling out the possibility of a fall. Both verifications have clearly defined calculation formulas and threshold ranges, and can be stably reproduced.

[0126] The scene recognition results employ an anti-shake mechanism that switches strategies only after three consecutive consistent recognitions. This prevents scene jumps caused by brief movements and avoids excessive power consumption due to frequent switching of detection strategies. During strategy switching, the sampling frequency transitions gradually in a gradient manner to avoid abrupt data changes affecting detection accuracy.

[0127] In some embodiments, to address the shortcomings of existing solutions that can only determine whether a fall has occurred but cannot distinguish the severity of the fall, and that all events trigger alarms of the same level, which can easily cause unnecessary disturbances and cannot provide effective reference for rescue, the severity of the fall is quantitatively assessed through multi-dimensional features to achieve graded differentiated alarms.

[0128] This mechanism is embedded in the fall confirmation instruction generation process of S103. After determining that a fall is real but before triggering an alarm, a severity assessment step is added. This is achieved by extracting four types of features strongly correlated with injury risk from existing detection data, including: Impact force characteristics: The peak value of the triaxial composite acceleration is extracted from the inertial data window. The higher the peak value, the greater the impact force of the fall and the higher the risk of injury. Fall height characteristics: The relative height change value calculated using step S102. The larger the height difference, the greater the fall height and the higher the risk of injury. Body rollover characteristics: The three-dimensional cumulative rotation angle is calculated using a rotation verification process. The larger the rollover angle, the more complex the fall posture and the higher the risk of injury. Stasis duration characteristic: The time from the start of the monitoring window to the first detection of minute limb movements within the statistical review monitoring window; if no activity is detected throughout the entire review window, the entire duration of the review window is taken. The longer the stasis duration, the higher the probability of loss of mobility.

[0129] By applying linear normalization to the four types of features, they are mapped to a score range of 0-1. Then, weights are assigned to different features: impact force feature weight 0.35, fall height feature weight 0.25, body roll feature weight 0.2, and static duration feature weight 0.2. The total severity score is obtained by weighted summation, with a score range of 0-1.

[0130] Falls are categorized into three levels based on the total score, each corresponding to a different alarm logic: Minor fall (0-0.4 points): Triggers local slight vibration and alert sound, displays "Fall detected, do you need help?", with a 10-second cancellation time. If the user manually cancels, no report is generated, only a local log is recorded; if not canceled within the time limit, a slight alert message is sent to emergency contacts.

[0131] Moderate fall (0.4-0.7 points): Immediately triggers strong local vibration and high-frequency alert, with a 5-second cancellation time; if not cancelled within the time limit, an alarm message containing the user's real-time location will be sent to the emergency contact, and the emergency contact will be automatically dialed.

[0132] Severe fall (0.7-1 point): Immediately triggers a full local alarm and sends an emergency alarm message directly to the emergency contact without delay, automatically dialing the emergency contact's phone number; if the user has pre-configured an emergency medical contact method, the call will be initiated simultaneously.

[0133] By storing the fall occurrence time, severity score, four types of characteristic values, and alarm execution records in the local event log, users and their families can review the data later, providing data reference for health management.

[0134] In some embodiments, to address the limitations of single smartwatch sensors and the potential for misjudgments in specific scenarios such as the watch being dropped or the arm being violently swung, a multi-terminal collaborative verification mechanism with the same account is designed. This mechanism improves the accuracy of fall detection through cross-verification of data from multiple devices, while ensuring user privacy through end-to-end processing.

[0135] This mechanism, as an optional verification step, is embedded after the S102 altitude change confirmation is passed and before the physiological resting state verification. Users can choose to enable or disable it. The smartwatch periodically scans online smart devices under the same user account via Bluetooth and local area network to maintain a list of collaborative devices. Supported devices include: the user's smartphone, other smart bracelets / wearable devices, millimeter-wave human presence sensors in the home environment, and smart cameras that support on-device computing. The device list only records the online status and device type of the devices and does not store device privacy data; all collaborative data interactions are completed within the local area network and are not uploaded to the cloud.

[0136] Once the watch completes the initial model screening and height change confirmation, and still determines it as a suspected fall, it immediately broadcasts a confirmation request to online collaborative devices. The request only carries the timestamp and event number of the event, without transmitting raw sensor data or user identity information, thus maximizing privacy protection.

[0137] Upon receiving the request, each collaborative device extracts its own sensor data before and after the corresponding timestamp, performs fall feature determination locally, and only returns the binary classification results of "suspected fall / non-fall / invalid data" to the watch. Smartphones: Extract data from their own acceleration sensor to determine if there are synchronous, severe impact characteristics; if the phone is stationary and charging, invalid data is returned.

[0138] Other wearable devices: Similarly, they detect acceleration impacts and subsequent static states to help verify the overall motion state of the human body.

[0139] Home-use millimeter-wave sensor: detects whether a human body has a rapid falling trajectory within a corresponding time period, and whether it remains stationary after falling.

[0140] On-device smart camera: Only when explicitly authorized by the user, it calls the local on-device human posture recognition algorithm to determine whether there is a falling posture; it does not record or upload video footage throughout the process, and only returns the judgment result.

[0141] The watch collects the results returned by all collaborating devices and uses a weighted voting mechanism for comprehensive judgment: the watch's own detection results have a weight of 0.5, the smartphone has a weight of 0.2, the millimeter-wave sensor has a weight of 0.2, and the smart camera has a weight of 0.1.

[0142] If the total weighted score is ≥0.6, the fall event is confirmed to be real, and the subsequent physiological stillness verification stage begins; if the score is <0.6, it is determined to be a false alarm, and the testing process is terminated immediately.

[0143] If there are no available collaborative devices, or if the device times out and does not return a result, the collaborative verification step will be automatically skipped, and the original manual form device detection logic will be used to ensure that the function is normal and available in scenarios without network or supporting devices.

[0144] In some embodiments, to address the industry pain point that users experience continuous height changes when riding elevators, going up and down stairs, or sitting in chairlifts, which can easily trigger false alarms due to height thresholds, the system extracts temporal features of height changes to distinguish between instantaneous falls and regular vertical movements. This enables targeted filtering of false alarms in such scenarios while ensuring that genuine falls are not overlooked.

[0145] This mechanism is embedded after the calculation of the relative altitude change value of S102 is completed and before the altitude threshold comparison, as a scenario-based pre-filtering step. It extracts three core features of the altitude change curve from the barometric pressure data window while calculating the relative altitude change value of the event: Duration of height change: Calculates the length of time it takes for the height to decrease from the initial reference value to the final reference value. The height change in a real fall is an instantaneous descent, typically lasting ≤0.5s; while the height change in elevators or going up and down stairs is a slow change lasting several seconds.

[0146] Rate of change of height: Calculates the average and peak rates during descent. The rate of descent in a real fall is much greater than the rate of ascent / descent during normal stair climbing or elevator riding.

[0147] Acceleration waveform characteristics: The acceleration waveform of a real fall shows a typical pulse pattern of "first a negative peak due to weightlessness, then a positive peak due to impact"; while the acceleration of going up and down stairs or moving in an elevator is a periodic step-like fluctuation without strong impact peaks.

[0148] Based on the above three types of characteristics, a rule-based judgment method is used to identify the current scene: if the duration of height change is >2s, the average height change rate is <0.5m / s, and the acceleration shows periodic fluctuation characteristics, then it is judged as a stair-climbing scene; if the duration of height change is >5s, the height change rate is uniform, and the acceleration has no obvious impact peak, then it is judged as an elevator-riding scene.

[0149] After identifying a vertical motion scenario, the detection rules are dynamically adjusted to filter out common false triggers: the height descent threshold is temporarily increased to twice the default threshold to filter out false judgments caused by small height changes; an additional impact acceleration verification condition is added, requiring the peak value of the synthetic acceleration within the inertial data window to be ≥6g before it is judged as a suspected fall, further filtering out false triggers from smooth vertical motion. If a severe impact peak is detected simultaneously in a vertical motion scenario, followed by continuous stillness, it is still judged as a suspected fall and proceeds normally to the subsequent physiological verification stage, ensuring that real fall events such as falls in elevators and staircases are not missed.

[0150] When no continuous height change is detected in three consecutive detection windows and the acceleration returns to normal activity characteristics, the system automatically exits the vertical motion scene and restores the default detection threshold and verification rules.

[0151] Please see Figure 3 As shown, Figure 3 This is a schematic diagram of the structure of a multi-sensor smartwatch fall detection false alarm suppression system 200 provided in this application embodiment. The multi-sensor smartwatch fall detection false alarm suppression system 200 is used to execute the steps of the multi-sensor smartwatch fall detection false alarm suppression method shown in the above embodiments. The multi-sensor smartwatch fall detection false alarm suppression system 200 can be a single server or a server cluster, or it can be a terminal, such as a handheld terminal, laptop computer, wearable device, or robot.

[0152] like Figure 3 As shown, the smartwatch fall detection false alarm suppression system 200 integrating multiple sensors includes: The data acquisition unit 201 is used to acquire sensor data through a smartwatch worn by the user. The sensor data includes at least acceleration data, angular velocity data, and air pressure data. The sensor data is preprocessed by setting the duration of the air pressure data window to be longer than the duration of the inertial data window, setting the start time of the air pressure data window to be earlier than the start time of the inertial data window, and setting the end time of the air pressure data window to be later than the end time of the inertial data window, thereby completing the division between the inertial data window and the air pressure data window. The result acquisition unit 202 is used to input the inertial data window into a lightweight neural network model pre-deployed on the smartwatch for inference and obtain a preliminary judgment result; if the preliminary judgment result is a fall, it extracts the air pressure data within a specified time period before the start of the inertial data window to calculate the first average air pressure; it extracts the air pressure data within a specified time period after the end of the inertial data window to calculate the second average air pressure; and it combines the first average air pressure and the second average air pressure to calculate the relative height change value corresponding to the suspected fall event. The fall alarm unit 203 is used to open a verification monitoring window of a preset duration after the suspected fall event ends if the relative height change value reaches a preset height drop threshold, and detect the user's activity intensity based on the acceleration data and angular velocity data; if no action signal that meets the preset activity intensity appears in the verification monitoring window, a fall confirmation command is generated, and a fall alarm is triggered in response to the fall confirmation command.

[0153] In some embodiments, the sensor data is preprocessed, including: filtering and denoising the acceleration and angular velocity data; smoothing the air pressure data; and aligning the acceleration, angular velocity, and air pressure data according to a unified timestamp.

[0154] In some embodiments, the preprocessed sensor data is divided into an inertial data window and a barometric pressure data window, including: setting the duration of the barometric pressure data window to be longer than the duration of the inertial data window, setting the start time of the barometric pressure data window to be earlier than the start time of the inertial data window, setting the end time of the barometric pressure data window to be later than the end time of the inertial data window, and completing the division of the two types of data windows according to the above time rules.

[0155] In some embodiments, the inertial data window is input into a lightweight neural network model pre-deployed on a smartwatch for inference to obtain a preliminary judgment result, including: running the lightweight neural network model to perform local calculations on the data in the inertial data window; if the output of the lightweight neural network model is a preliminary judgment result of not falling, the current detection process is terminated; if the output of the lightweight neural network model is a preliminary judgment result of falling, the subsequent steps of obtaining height change values ​​are continued.

[0156] In some embodiments, if the preliminary determination result is a fall, the relative height change value before and after the suspected fall event is obtained based on the air pressure data window, including: extracting air pressure data within a specified time period before the start of the inertial data window to calculate a first average air pressure; extracting air pressure data within a specified time period after the end of the inertial data window to calculate a second average air pressure; and combining the first average air pressure and the second average air pressure to convert the relative height change value corresponding to the suspected fall event.

[0157] In some embodiments, if the relative height change value reaches a preset height decrease threshold, a verification monitoring window of a preset duration is opened after the suspected fall event ends. The user's activity intensity is detected based on acceleration data and angular velocity data. This includes: starting a verification monitoring window of a fixed duration after all data in the inertial data window has been collected, continuously identifying the user's action signals based on acceleration data and angular velocity data during the operation of the monitoring window, and determining whether the action signals have reached a preset activity intensity.

[0158] In some embodiments, if no action signal meeting the preset activity intensity appears in the review monitoring window, a fall confirmation instruction is generated, including: if no action signal meeting the preset activity intensity is detected during the entire operation of the review monitoring window, a fall confirmation instruction is generated; if an action signal meeting the preset activity intensity is detected during the operation of the review monitoring window, the current fall detection process is terminated.

[0159] In some embodiments, before inputting the inertial data window into a lightweight neural network model pre-deployed on a smartwatch for inference, the method further includes: building a one-dimensional convolutional neural network as a basic recognition model; performing quantization compression optimization on the basic recognition model; and writing the optimized basic recognition model into the local storage area of ​​the smartwatch to complete the deployment.

[0160] In some embodiments, sensor data is collected via a smartwatch worn by the user, including: continuously collecting acceleration data and angular velocity data at a first fixed frequency; continuously collecting air pressure data at a second fixed frequency; marking the acceleration data, angular velocity data, and air pressure data with a unified timestamp and storing them in a temporary storage area.

[0161] It should be noted that those skilled in the art will understand that, for the sake of convenience and brevity, the specific working process of the multi-sensor smartwatch fall detection false alarm suppression system and its modules described above can be found in the corresponding embodiments of the multi-sensor smartwatch fall detection false alarm suppression method, and will not be repeated here.

[0162] The aforementioned method for suppressing false alarms in fall detection for smartwatches that integrates multiple sensors can be implemented as a computer program, which can be used in various ways, such as... Figure 3 It runs on the system shown.

[0163] Please see Figure 4 , Figure 4 This is a schematic block diagram of the structure of a smartwatch provided in an embodiment of this application. The smartwatch includes a processor, a memory, and a network interface connected via a device bus, wherein the memory may include a storage medium and internal memory.

[0164] The storage medium may store operating devices and computer programs. The computer program includes program instructions that, when executed, cause the processor to perform any of the fall detection false alarm suppression methods for smartwatches that integrate multiple sensors.

[0165] The processor provides computing and control capabilities, supporting the operation of the entire smartwatch.

[0166] The internal memory provides an environment for the execution of computer programs in non-volatile storage media. When the computer program is executed by the processor, it enables the processor to execute any method for suppressing false alarms in fall detection of smartwatches that integrates multiple sensors.

[0167] This network interface is used for network communication, such as sending assigned tasks. Those skilled in the art will understand that... Figure 4 The structure shown is merely a block diagram of a portion of the structure related to the solution of this application and does not constitute a limitation on the terminal to which the solution of this application is applied. A specific smartwatch may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0168] It should be understood that the processor can be a Central Processing Unit (CPU), but it can also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. Among these, a general-purpose processor can be a microprocessor or any conventional processor.

[0169] In one embodiment, the processor is configured to run a computer program stored in memory to perform the following steps: Sensor data is collected by a smartwatch worn by the user. The sensor data includes at least acceleration data, angular velocity data, and air pressure data. The sensor data is preprocessed by setting the duration of the air pressure data window to be longer than that of the inertial data window, making the start time of the air pressure data window earlier than that of the inertial data window, and making the end time of the air pressure data window later than that of the inertial data window, thus completing the division between the inertial data window and the air pressure data window. The inertial data window is input into a lightweight neural network model pre-deployed on the smartwatch for inference to obtain a preliminary judgment result. If the preliminary judgment result is a fall, the air pressure data within a specified time period before the start of the inertial data window is extracted to calculate the first average air pressure. The air pressure data within a specified time period after the end of the inertial data window is extracted to calculate the second average air pressure. The relative height change value corresponding to the suspected fall event is obtained by combining the first average air pressure and the second average air pressure. If the relative height change value reaches the preset height descent threshold, a review monitoring window of preset duration will be opened after the suspected fall event ends, and the intensity of user activity will be detected based on acceleration data and angular velocity data; if no action signal that meets the preset activity intensity appears in the review monitoring window, a fall confirmation command will be generated, and a fall alarm will be triggered in response to the fall confirmation command.

[0170] In some embodiments, the sensor data is preprocessed, including: filtering and denoising the acceleration and angular velocity data; smoothing the air pressure data; and aligning the acceleration, angular velocity, and air pressure data according to a unified timestamp.

[0171] In some embodiments, the preprocessed sensor data is divided into an inertial data window and a barometric pressure data window, including: setting the duration of the barometric pressure data window to be longer than the duration of the inertial data window, setting the start time of the barometric pressure data window to be earlier than the start time of the inertial data window, setting the end time of the barometric pressure data window to be later than the end time of the inertial data window, and completing the division of the two types of data windows according to the above time rules.

[0172] In some embodiments, the inertial data window is input into a lightweight neural network model pre-deployed on a smartwatch for inference to obtain a preliminary judgment result, including: running the lightweight neural network model to perform local calculations on the data in the inertial data window; if the output of the lightweight neural network model is a preliminary judgment result of not falling, the current detection process is terminated; if the output of the lightweight neural network model is a preliminary judgment result of falling, the subsequent steps of obtaining height change values ​​are continued.

[0173] In some embodiments, if the preliminary determination result is a fall, the relative height change value before and after the suspected fall event is obtained based on the air pressure data window, including: extracting air pressure data within a specified time period before the start of the inertial data window to calculate a first average air pressure; extracting air pressure data within a specified time period after the end of the inertial data window to calculate a second average air pressure; and combining the first average air pressure and the second average air pressure to convert the relative height change value corresponding to the suspected fall event.

[0174] In some embodiments, if the relative height change value reaches a preset height decrease threshold, a verification monitoring window of a preset duration is opened after the suspected fall event ends. The user's activity intensity is detected based on acceleration data and angular velocity data. This includes: starting a verification monitoring window of a fixed duration after all data in the inertial data window has been collected, continuously identifying the user's action signals based on acceleration data and angular velocity data during the operation of the monitoring window, and determining whether the action signals have reached a preset activity intensity.

[0175] In some embodiments, if no action signal meeting the preset activity intensity appears in the review monitoring window, a fall confirmation instruction is generated, including: if no action signal meeting the preset activity intensity is detected during the entire operation of the review monitoring window, a fall confirmation instruction is generated; if an action signal meeting the preset activity intensity is detected during the operation of the review monitoring window, the current fall detection process is terminated.

[0176] In some embodiments, before inputting the inertial data window into a lightweight neural network model pre-deployed on a smartwatch for inference, the method further includes: building a one-dimensional convolutional neural network as a basic recognition model; performing quantization compression optimization on the basic recognition model; and writing the optimized basic recognition model into the local storage area of ​​the smartwatch to complete the deployment.

[0177] In some embodiments, sensor data is collected via a smartwatch worn by the user, including: continuously collecting acceleration data and angular velocity data at a first fixed frequency; continuously collecting air pressure data at a second fixed frequency; marking the acceleration data, angular velocity data, and air pressure data with a unified timestamp and storing them in a temporary storage area.

[0178] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, causes the processor to implement the steps of the fall detection false alarm suppression method for a smartwatch with fused multi-sensor technology as provided in any embodiment of this application.

[0179] The computer-readable storage medium can be the internal storage unit of the smartwatch described in the foregoing embodiments, such as the hard drive or memory of the smartwatch. Alternatively, the computer-readable storage medium can be an external storage device of the smartwatch, such as a plug-in hard drive, Smart Media Card (SMC), Secure Digital (SD) card, or Flash Card.

[0180] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for suppressing false alarms in fall detection of a smartwatch that integrates multiple sensors, characterized in that, include: Sensor data is collected by a smartwatch worn by the user, and the sensor data includes at least acceleration data, angular velocity data and air pressure data; The sensor data is preprocessed, and the duration of the barometric pressure data window is set to be longer than that of the inertial data window. The start time of the barometric pressure data window is earlier than that of the inertial data window, and the end time of the barometric pressure data window is later than that of the inertial data window, thus completing the division between the inertial data window and the barometric pressure data window. The inertial data window is input into a lightweight neural network model pre-deployed on the smartwatch for inference to obtain a preliminary judgment result; if the preliminary judgment result is a fall, the air pressure data within a specified time period before the start of the inertial data window is extracted to calculate the first average air pressure; After the inertial data window ends, calculate the second average air pressure based on the air pressure data within a specified time period; combine the first average air pressure and the second average air pressure to obtain the relative height change value corresponding to the suspected fall event; If the relative height change value reaches the preset height drop threshold, a review monitoring window of preset duration will be opened after the suspected fall event ends, and the intensity of user activity will be detected based on the acceleration data and angular velocity data. If no action signal meeting the preset activity intensity appears in the verification monitoring window, a fall confirmation command is generated, and a fall alarm is triggered in response to the fall confirmation command.

2. The method according to claim 1, characterized in that, The preprocessing of the sensor data includes: The acceleration data and the angular velocity data are filtered and denoised. The air pressure data is smoothed. The acceleration data, angular velocity data, and air pressure data are aligned using a unified timestamp.

3. The method according to claim 1, characterized in that, The step of inputting the inertial data window into a lightweight neural network model pre-deployed on the smartwatch for inference to obtain preliminary judgment results includes: The lightweight neural network model is run to perform local calculations on the data within the inertial data window. If the output of the lightweight neural network model is a preliminary judgment result of not falling, the current detection process is terminated. If the output of the lightweight neural network model is a preliminary judgment result of falling, the subsequent steps of obtaining height change values ​​are continued.

4. The method according to claim 1, characterized in that, If the relative height change value reaches a preset height decrease threshold, a review monitoring window of a preset duration is opened after the suspected fall event ends. Based on the acceleration and angular velocity data, the intensity of user activity is detected, including: After all data in the inertial data window has been collected, a fixed-duration verification and monitoring window is started. During the operation of the monitoring window, the user's motion signals are continuously identified based on acceleration and angular velocity data to determine whether the motion signals have reached the preset activity intensity.

5. The method according to claim 1, characterized in that, If no action signal meeting the preset activity intensity appears within the verification monitoring window, a fall confirmation instruction is generated, including: If the monitoring window fails to detect any action signal that reaches the preset activity intensity throughout the entire process, a fall confirmation command will be generated. If a motion signal reaching the preset activity intensity is detected during the operation of the review monitoring window, the current fall detection process will be terminated.

6. The method according to claim 1, characterized in that, Before inputting the inertial data window into the lightweight neural network model pre-deployed on the smartwatch for inference, the method further includes: A one-dimensional convolutional neural network is constructed as the basic recognition model; The basic recognition model is subjected to quantization and compression optimization processing, and the optimized basic recognition model is written to the local storage area of ​​the smartwatch to complete the deployment.

7. The method according to claim 1, characterized in that, The collection of sensor data via a user-worn smartwatch includes: Acceleration and angular velocity data are continuously collected at a first fixed frequency. Air pressure data is continuously collected at a second fixed frequency; Acceleration data, angular velocity data, and air pressure data are marked with a unified timestamp and stored in a temporary storage area.

8. A fall detection false alarm suppression system for smartwatches integrating multiple sensors, used to implement the method as described in any one of claims 1-7, characterized in that, include: The data acquisition unit is used to collect sensor data through a smartwatch worn by the user. The sensor data includes at least acceleration data, angular velocity data, and air pressure data. The sensor data is preprocessed, and the duration of the barometric pressure data window is set to be longer than that of the inertial data window. The start time of the barometric pressure data window is earlier than that of the inertial data window, and the end time of the barometric pressure data window is later than that of the inertial data window, thus completing the division between the inertial data window and the barometric pressure data window. The result acquisition unit is used to input the inertial data window into a lightweight neural network model pre-deployed on the smartwatch for inference and obtain a preliminary judgment result; if the preliminary judgment result is a fall, the air pressure data within a specified time period before the start of the inertial data window is extracted to calculate the first average air pressure; After the inertial data window ends, calculate the second average air pressure using air pressure data within a specified time period. The relative height change value corresponding to the suspected fall incident was obtained by combining the first and second average air pressures. A fall alarm unit is used to open a pre-set review and monitoring window for a preset duration after a suspected fall event ends if the relative height change value reaches a preset height drop threshold, and to detect the intensity of user activity based on the acceleration data and angular velocity data. If no action signal meeting the preset activity intensity appears in the verification monitoring window, a fall confirmation command is generated, and a fall alarm is triggered in response to the fall confirmation command.

Images