Method for processing sensor data, electronic device and readable storage medium

Abstract

The application provides a sensor data processing method, an electronic device and a readable storage medium, which can reduce the power consumption of the electronic device. The method comprises the following steps: obtaining first sensor data from a first sensor driver; predicting a first motion event of the electronic device according to the first sensor data; if the detection of the first motion event depends on second sensor data, obtaining the second sensor data from a second sensor driver; and determining whether a reporting condition of the first motion event is met according to the first sensor data and the second sensor data.

Description

Technical Field

[0001] This application relates to the field of electronic devices, and more particularly to a method for processing sensor data, an electronic device, and a readable storage medium. Background Technology

[0002] To provide users with more intelligent services, electronic devices can automatically execute operations corresponding to motion events. For example, for the pick-up and answer service, if the electronic device detects a pick-up event, it can answer the call.

[0003] Electronic devices can acquire sensor data from sensor drivers and determine whether a motion event has occurred based on the sensor data. If the reporting conditions for a motion event are met, the electronic device can report the motion event so that it can perform the operation corresponding to that motion event.

[0004] Currently, the way electronic devices process sensor data results in high power consumption. Summary of the Invention

[0005] This application provides a sensor data processing method, an electronic device, and a readable storage medium that can reduce the power consumption of the electronic device.

[0006] In a first aspect, a method for processing sensor data is provided, comprising: acquiring first sensor data from a first sensor driver; predicting a first motion event occurring in an electronic device based on the first sensor data; if the detection of the first motion event depends on second sensor data, acquiring the second sensor data from a second sensor driver; and determining whether the reporting conditions for the first motion event are met based on the first sensor data and the second sensor data.

[0007] This application embodiment reduces the power consumption of electronic devices by sending sensor data through a multi-level triggering method. After acquiring the first sensor data, the electronic device first predicts motion events based on the first sensor data. If the prediction indicates that a first motion event has occurred, it further acquires the dependent sensor data (i.e., the second sensor data) based on the sensor data that the first motion event depends on. The electronic device does not continuously acquire all sensor data, but acquires sensor data level by level as needed, achieving the purpose of on-demand acquisition, thereby reducing the transmission overhead of sensor data and reducing the power consumption of the electronic device.

[0008] In some possible implementations, acquiring the first sensor data from the first sensor driver includes: acquiring the first sensor data from the first sensor driver when the electronic device is in a non-stationary state.

[0009] In this embodiment, the first sensor data is acquired when the electronic device is in a non-stationary state, but not when the electronic device is in a stationary state. This reduces the transmission overhead of the first sensor data and thus reduces the power consumption of the electronic device.

[0010] In some possible implementations, the method further includes: determining the magnitude of the change in acceleration data; if the magnitude of the change in acceleration data is greater than or equal to a first threshold, then determining that the electronic device is in a non-stationary state.

[0011] This application embodiment determines whether an electronic device is stationary by basing the magnitude of the change in acceleration data on the relationship between the magnitude of the change and a first threshold, thereby reducing the complexity of determining whether an electronic device is stationary.

[0012] In some possible implementations, the method further includes: predicting a second motion event occurring in the electronic device based on the first sensor data and the second sensor data; if the detection of the second motion event depends on the third sensor data, obtaining the third sensor data from the third sensor driver; and determining whether the reporting conditions for the second motion event are met based on the first sensor data, the second sensor data, and the third sensor data.

[0013] The embodiments of this application can use a three-level triggering method to send sensor data. The first level corresponds to the first sensor data, the second level corresponds to the second sensor data, and the third level corresponds to the third sensor data. This can reduce the transmission time of the second and third sensors, especially the transmission time of the third sensor data, which can be greatly reduced, achieving the purpose of on-demand acquisition, thereby reducing the power consumption of electronic devices.

[0014] In some possible implementations, the method further includes: determining the magnitude of change in the first sensor data and / or the second sensor data; if the magnitude of change in the first sensor data and / or the second sensor data is greater than or equal to a second threshold, then determining that the first motion event has ended; if the first motion event has ended, then stopping the acquisition of the second sensor data from the second sensor driver.

[0015] The embodiments of this application can stop acquiring sensor data (i.e., second sensor data) that the first motion event depends on after the first motion event ends, thereby reducing the transmission time of the second sensor data and reducing the power consumption of the electronic device without affecting the detection of the first motion event.

[0016] In some possible implementations, the method further includes stopping power supply to the second sensor if the first motion event has ended.

[0017] Once the first motion event has ended, power can be cut off to the sensor (i.e., the second sensor) on which the first motion event depends, reducing the power-on time of the sensor device, extending the sensor life, improving the user's battery life experience, delaying public opinion and negative experiences caused by device aging, and thus reducing user returns.

[0018] In some possible implementations, the method further includes: determining a first function in the electronic device that is in an on state; the step of predicting a first motion event occurring in the electronic device based on the first sensor data includes: predicting the first motion event from motion events corresponding to the first function based on the first sensor data.

[0019] The first motion event can be determined from the motion events corresponding to the enabled functions. For functions that are disabled, the electronic device does not need to predict the motion events corresponding to those functions, thereby reducing some unnecessary calculations and lowering the power consumption of the electronic device.

[0020] In some possible implementations, the first sensor data is acceleration data and the second sensor data is angular velocity data.

[0021] In some possible implementations, the third sensor data includes proximity light data and / or ambient light data.

[0022] In some possible implementations, the first motion event includes one or more of the following: rotation event, pick-up and answer event, drop event, and pocket anti-accidental touch event.

[0023] In some possible implementations, if the first motion event includes a rotation event and a fall event, then the first sensor data includes acceleration data and the second sensor data includes angular velocity data.

[0024] In some possible implementations, if the first motion event includes a pick-up / answer event, then the first sensor data includes acceleration data, the second sensor data includes angular velocity data, and the second sensor data includes proximity light data.

[0025] In some possible implementations, if the first motion event includes a pocket anti-mistouch event, then the first sensor data includes acceleration data, the second sensor data includes angular velocity data, and the second sensor data includes ambient light data.

[0026] In a second aspect, an electronic device is provided, comprising a unit consisting of software and / or hardware, the unit being used to perform any one of the methods in the technical solution of the first aspect.

[0027] Thirdly, a chip is provided, including a processor; the processor is used to read and execute a computer program stored in a memory to perform any of the methods described in the first aspect.

[0028] Optionally, the chip also includes a memory, which is connected to the processor via a circuit or wire.

[0029] Alternatively, the chip may further include a communication interface.

[0030] Fourthly, an electronic device is provided, comprising: a processor, a memory, and an interface; the processor, memory, and interface cooperate with each other to enable the electronic device to execute any one of the methods described in the first aspect; or to include any one of the chips described in the third aspect.

[0031] Fifthly, a computer-readable storage medium is provided, wherein a computer program is stored therein, and when the computer program is executed by a processor, the processor performs any one of the methods described in the first aspect.

[0032] In a sixth aspect, a computer program product is provided, the computer program product comprising: computer program code, which, when executed on an electronic device, causes the electronic device to perform any one of the methods described in the first aspect. Attached Figure Description

[0033] Figure 1 This is a schematic diagram of the structure of an electronic device 100 provided in an embodiment of this application;

[0034] Figure 2 This is a software structure block diagram of the electronic device 100 provided in the embodiments of this application;

[0035] Figure 3 This is another software structure block diagram of the electronic device 100 provided in the embodiments of this application;

[0036] Figure 4 An interface for operating the automatic rotation function is shown;

[0037] Figure 5 An interface for switching multiple functions in an electronic device is shown.

[0038] Figure 6 This page displays an introduction to a pick-up and answer function;

[0039] Figure 7 This page displays an introduction to a raise-to-wake screen feature;

[0040] Figure 8 This illustrates a scenario where an electronic device is located in a user's pocket;

[0041] Figure 9 This is a schematic diagram of a drop detection method for electronic devices;

[0042] Figure 10 This is a flowchart illustrating the traditional method of detecting the motion state of electronic devices.

[0043] Figure 11 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application;

[0044] Figure 12 This is a schematic flowchart illustrating a sensor data processing method provided in an embodiment of this application;

[0045] Figure 13 This is a schematic flowchart illustrating motion state detection of an electronic device according to an embodiment of this application;

[0046] Figure 14 This is a schematic diagram illustrating the in-situ time of multiple sensor data provided in the embodiments of this application;

[0047] Figure 15 This is a schematic block diagram of an electronic device provided in an embodiment of this application;

[0048] Figure 16 This is a schematic diagram of the structure of a device provided in an embodiment of this application. Detailed Implementation

[0049] The technical solutions of the embodiments of this application will be described below with reference to the accompanying drawings. In the description of the embodiments of this application, unless otherwise stated, " / " means "or," for example, A / B can mean A or B; "and / or" in this text is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Furthermore, in the description of the embodiments of this application, "multiple" refers to two or more than two.

[0050] Hereinafter, the terms "first," "second," and "third" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first," "second," or "third" may explicitly or implicitly include one or more of that feature.

[0051] The solution in this application embodiment is applied to a scenario where the motion state of an electronic device is detected. The electronic device involved in this application embodiment will be described below.

[0052] The electronic devices in this application embodiment can be handheld terminal devices or wearable devices, etc. Handheld terminal devices may include, for example, mobile phones, tablets, augmented reality (AR) / virtual reality (VR) devices, etc. Wearable devices may include, for example, watches, bracelets, headphones, etc.

[0053] For example, Figure 1 This is a schematic diagram of the structure of an electronic device 100 provided in an embodiment of this application. The electronic device 100 may include a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, a headphone jack 170D, a sensor module 180, buttons 190, a motor 191, an indicator 192, a camera 193, a display screen 194, and a subscriber identification module (SIM) card interface 195, etc. The sensor module 180 may include a pressure sensor 180A, a gyroscope sensor 180B, a barometric pressure sensor 180C, a magnetic sensor 180D, an accelerometer sensor 180E, a distance sensor 180F, a proximity light sensor 180G, a fingerprint sensor 180H, a temperature sensor 180J, a touch sensor 180K, etc.

[0054] The mobile communication module 150 may include one or more of second-generation (2G), 3G, 4G, and 5G communication modules. The mobile communication module 150 may include one or more of a filter, a switch, a power amplifier, and a low-noise amplifier (LNA).

[0055] The wireless communication module 160 may include one or more of the following: Bluetooth (BT) module, Wireless Local Area Network (WLAN) module, Global Navigation Satellite System (GNSS) module, Near Field Communication (NFC) module, Infrared (IR) module, and Frequency Modulation (FM) module. The wireless communication module 160 may be one or more devices integrating at least one communication processing module. The wireless communication module 160 receives electromagnetic waves via antenna 2, performs frequency modulation and filtering on the electromagnetic wave signals, and sends the processed signal to processor 110. The wireless communication module 160 can also receive signals to be transmitted from processor 110, perform frequency modulation and amplification on them, and then convert them into electromagnetic waves for radiation via antenna 2.

[0056] It is understood that the structures illustrated in the embodiments of this application do not constitute a specific limitation on the electronic device 100. In other embodiments of this application, the electronic device 100 may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0057] It is understood that the interface connection relationships between the modules illustrated in the embodiments of this application are merely illustrative and do not constitute a structural limitation on the electronic device 100. In other embodiments of this application, the electronic device 100 may also employ different interface connection methods or combinations of multiple interface connection methods as described in the above embodiments.

[0058] The following is combined Figure 2 This application describes the software system architecture of the electronic device (such as a mobile phone) in the embodiments of this application. The software system of the device in the embodiments of this application can adopt a layered architecture, event-driven architecture, microkernel architecture, microservice architecture, or cloud architecture. This application embodiment takes the layered architecture Android system as an example to illustrate the software structure of the device.

[0059] Figure 2This is a software architecture block diagram of the device according to an embodiment of this application. The layered architecture divides the software into several layers, each with a clear role and function. Layers communicate with each other through software interfaces. In some embodiments, the Android system can be divided into four layers, from top to bottom: the application (APP) layer, the application framework layer, the system (libraries) layer, and the kernel layer. The system layer can also be called the native service layer.

[0060] like Figure 2 As shown, the application layer can include a series of application packages, which may include applications such as SMS, calendar, camera, video, navigation, gallery, calling, fitness and health, and wireless fidelity (WiFi).

[0061] The application framework layer provides application programming interfaces (APIs) and a programming framework for applications in the application layer. The application framework layer includes some predefined functions.

[0062] like Figure 2 As shown, the application framework layer may include a window manager, resource manager, notification manager, WiFi manager, camera manager, etc.

[0063] The window manager is used to manage window applications, including managing the window hierarchy and display order. The window manager can obtain the screen size, determine if a status bar is present, lock the screen, and capture the screen, among other things.

[0064] The file explorer provides applications with various resources, such as localized strings, icons, images, layout files, video files, etc.

[0065] The notification manager allows applications to display notifications in the status bar. These notifications can be used to deliver informational messages and can disappear automatically after a short pause, requiring no user interaction. For example, the notification manager can be used to notify users of download completion or message alerts. The notification manager can also display notifications as icons or scrolling text in the top status bar, such as notifications from background applications, or as dialog boxes on the screen. Examples include displaying text messages in the status bar, emitting sounds, vibrating electronic devices, and flashing indicator lights.

[0066] WiFi Manager is used to manage wireless network connections on your device. With WiFi Manager, you can obtain information about currently connected networks, search for available networks, connect to specified networks, and disable networks.

[0067] The camera manager is used to manage the cameras on the device, including getting a list of cameras and turning specific cameras on or off.

[0068] The application layer and application framework layer run in a virtual machine. The virtual machine executes the Java files of the application layer and application framework layer as binary files. The virtual machine is used to perform functions such as object lifecycle management, stack management, thread management, security and exception management, and garbage collection.

[0069] The system layer can include multiple functional modules. For example: sensor service module, physical state recognition module, 3D graphics processing library, WiFi module, camera module, etc.

[0070] The sensor service module is used to monitor sensor data uploaded by various sensors at the hardware layer to determine the physical status of the device.

[0071] The physical state recognition module is used to analyze and recognize user gestures, faces, etc.

[0072] The 3D graphics processing library is used to implement 3D graphics drawing, image rendering, compositing, and layer processing.

[0073] The kernel layer is the layer between hardware and software. The kernel layer includes at least the display driver, camera driver, sensor driver, and WiFi driver.

[0074] Figure 3 This illustrates another way of partitioning software architecture. Figure 3 The layers shown are Figure 2 The layers shown have a certain correspondence. Figure 3 The software architecture shown includes an application layer, framework layer, system layer, hardware abstraction layer (HAL), sensor hub layer, and hardware layer. The application layer, framework layer, and system layer are already defined. Figure 2 The above has already been introduced, so I won't repeat it here.

[0075] Both the HAL layer and the sensorhub layer belong to the kernel layer. The HAL layer encapsulates kernel drivers, providing interfaces to higher layers and shielding them from the implementation details of the underlying hardware. The HAL layer can include motion HAL, WiFi HAL, audio HAL, and camera HAL, among others. Additionally, the HAL layer can include the HAL interface definition language (HIDL). The sensorhub includes virtual sensors, which contain motion algorithm modules. These modules are used to determine the motion state of electronic devices based on sensor data.

[0076] SensorHub is a hardware and software solution based on a low-power microcontroller unit (MCU) and a lightweight real-time operating system (RTOS). SensorHub is a sensor management component that enables hardware abstraction, device management, and data distribution for sensor devices.

[0077] For example, SensorHub can call algorithm initialization functions when an electronic device is powered on. Furthermore, SensorHub can access and process data from various sensors; for instance, it can access accelerometers to collect acceleration values, receive and parse these values, determine whether a fall event has occurred based on the acceleration values, calculate the fall height, and report the fall event to the caller or subscriber.

[0078] After collecting sensor data, SensorHub can input the sensor data into the corresponding algorithm model for recognition and upload it to the HAL layer.

[0079] Using sensorhub technology can ensure that while keeping electronic devices in low-power, screen-off standby mode, the relevant hardware modules can still be turned on, and the various information detected by the relevant hardware modules can be received and processed.

[0080] The motion algorithm module is responsible for issuing enable commands and reporting events for various services (or functions) in electronic devices. This is a crucial service that is readily perceived by users and directly impacts their experience. Based on users' requirements for the timeliness and accuracy of the motion algorithm module's services, this embodiment of the application can place the motion algorithm module in the sensorhub subsystem, allowing it to remain in place 24 / 7 in a low-power manner. This reduces power consumption while ensuring a good user experience.

[0081] With technological advancements, users have increasingly higher demands for electronic devices, expecting them to possess more intelligent functions such as pick-to-answer, flip-to-mute, raise-to-wake, accidental touch prevention, drop detection, automatic screen rotation, and pedometers. Users can freely choose whether to enable or disable these functions. The motion algorithm module is responsible for issuing enable commands and reporting events for these services, representing a crucial service that is most noticeable to users and directly impacts their experience.

[0082] Figure 4 The user interface for the automatic screen rotation function is shown. Users can access the following by pulling down on the screen: Figure 4 The display interface is shown below. Users can click the "Auto Rotate" icon to enable or disable this function. If the user enables the screen auto rotate function, the electronic device will automatically adjust the display to portrait mode when rotated to portrait mode and to landscape mode when rotated to landscape mode. If the user disables the screen auto rotate function, the display will remain unchanged regardless of whether the electronic device is in portrait or landscape mode.

[0083] Figure 5 The interface for features such as accidental touch prevention, pick-to-answer, drop detection, and raise-to-wake functionality is shown. Users can access these features by clicking the "Settings" icon on their electronic device. Figure 5 The user interface shown allows users to toggle a function on or off by clicking the switch button on the right side of the function bar. Figure 5 The user interface shown has enabled the anti-accidental touch function, the pick-to-answer function, and the raise-to-wake function, while disabling the drop detection function.

[0084] In some implementations, users can access options such as "pick up and answer" by clicking the "pick up and answer" option. Figure 6 The details page shows an introduction to the pick-up answering function, such as "When a call comes in, bring the phone to your ear to answer; when answering with a hands-free or Bluetooth headset, bringing it to your ear switches to earpiece mode." Users can determine whether to enable this function based on the feature descriptions on the details page.

[0085] In some implementations, users can access features such as raising to wake the screen by clicking the "raise to wake" option. Figure 7 The details page shown displays an introduction to the raise-to-wake feature, such as "When the device screen is off, pick it up to wake the screen." Users can determine whether to enable this feature based on the information on the details page.

[0086] The anti-mistouch function mainly refers to preventing the electronic device from responding to functions such as screen unlocking, raising to wake, and picking up to answer calls after the screen is off. This function is primarily used in scenarios where the electronic device is placed in the user's pocket or bag to prevent accidental operation without the user's consent.

[0087] Figure 8 This illustrates an application scenario for an anti-mistouch feature. When a user places an electronic device in their pocket, if the screen is not off, the contact between the pocket and the device's display might be mistaken by the device as user interaction. If the anti-mistouch feature is not enabled, the device will respond to this erroneous action, impacting the user experience. If the anti-mistouch feature is enabled, the device will not respond to this erroneous action once it recognizes the device as being in the pocket, thus improving the user experience.

[0088] Figure 9 This illustrates a drop process of an electronic device. If the user has enabled drop detection, the electronic device will record the drop event. For example, the device can record the start of the drop (T1) and the impact time (T2). Furthermore, the device can calculate the drop height and time, and simulate the drop trajectory, based on the drop time T1 and impact time T2. The device can also determine whether it has actually hit the ground based on multiple frames (e.g., twenty frames) of sensor data prior to impact.

[0089] The functions of the electronic devices mentioned above can be executed based on their motion state. The electronic device can determine which function to perform based on its motion state. In some implementations, the motion state of the electronic device can reflect the user's actions on the device. Therefore, based on the motion state of the electronic device, it is possible to recognize the user's gestures, the user's state, the device's state, and the user's traffic behavior.

[0090] Gesture recognition mainly refers to sensing the user's gestures, such as flipping an electronic device, tapping an electronic device, shaking an electronic device, and picking up an electronic device.

[0091] Electronic devices can perform corresponding operations based on recognized user gestures. For example, for the flip-to-mute operation, if the electronic device detects that the user has flipped it, it can mute the device. Similarly, for the flip-to-reject-call operation, if the electronic device detects that the user has flipped it and there is an incoming call, it can hang up the call. Another example is the shake-to-change-background-image operation, if the electronic device detects that the user is shaking it, it can change the background image. Finally, for the pick-up-to-answer-call operation, if the electronic device detects that the user has picked it up and there is an incoming call, it can answer the call.

[0092] The state of a device can include one or more of the following: the electronic device is facing up or down, the electronic device is on a table, in a pocket, or in the user's hand, the electronic device is in a state of being dropped, the electronic device is in a state of rotation, etc.

[0093] Electronic devices can perform corresponding operations based on their state. For example, if the device is detected face down, the screen can be turned off; if it's face up, the screen can be turned on. If the device is in a user's pocket, a pocket-protection mode can be activated. If the device is in landscape mode, the display will be adjusted to landscape mode; if it's in portrait mode, the display will be adjusted to portrait mode. If the device has been dropped, the drop will be recorded.

[0094] User state recognition primarily refers to sensing the user's state. A user's state can include one or more of the following: walking, running, standing, and sitting. Electronic devices can perform corresponding operations based on the user's state. For example, the step counting function can be automatically activated when the user is walking or running; the step counting function can be paused after the user stands or sits down.

[0095] User traffic behavior assessment primarily refers to sensing a user's state while using public transportation. A user's traffic behavior can include one or more of the following: cycling, driving, taking a train, subway, high-speed rail, or elevator. Electronic devices can then perform corresponding operations based on this behavior. For example, when a user is driving, the electronic device can automatically connect to the vehicle via Bluetooth. Another example is activating noise cancellation when a user is making a phone call on a train.

[0096] Electronic devices can determine their motion state based on data collected by sensors. The sensors in this embodiment can also be called motion sensors. The sensors in this embodiment may include one or more of the following: accelerometers, angular velocity sensors, proximity sensors, ambient light sensors, etc.

[0097] Accelerometers can include, for example, accelerometers (ACC). Accelerometers can measure the acceleration of electronic devices in a certain direction.

[0098] An angular velocity sensor may include, for example, a gyroscope. An angular velocity sensor can detect the rotational angular velocity of an electronic device when it deflects or tilts, thereby detecting whether the electronic device has deflected and the angle of deflection.

[0099] Proximity sensors are used to detect whether an electronic device is near a user or an object. They determine proximity based on changes in the intensity of light detected. For example, if the sensor detects a decrease in light intensity, it indicates the electronic device is approaching the user; conversely, if it detects an increase in intensity, it indicates the device is moving away from the user.

[0100] An ambient light sensor can detect the intensity of ambient light around an electronic device. Based on this, it can be determined whether the electronic device is in a user's bag or pocket. For example, if the light intensity sensed by the ambient light sensor is less than or equal to a preset threshold, it indicates that the electronic device is in the user's bag or pocket.

[0101] The motion state recognition of electronic devices described above can be achieved by... Figure 3 The motion algorithm module shown is used to execute this. It should be noted that recognizing the motion state of an electronic device can also be understood as recognizing motion events. In some scenarios, motion state and motion event can be interchanged. The following section uses motion events as an example to describe the solution of this application embodiment.

[0102] The motion algorithm module can determine the occurrence of motion events based on data collected by sensors. See also Figure 10 The motion algorithm module is connected to the sensor driver and is used to acquire sensor data from the sensor driver.

[0103] The sensor driver includes drivers for one or more sensors, such as an angular velocity sensor driver, a proximity sensor driver, and an ambient light sensor driver. After the electronic device is powered on, the motion algorithm module can send a request message to the sensor driver to request sensor data. Upon receiving the request message, the sensor driver can send the sensor data to the motion algorithm module. The sensor driver can send the sensor data, for example, through periodic transmission.

[0104] Sensor drivers can send all sensor data to the motion algorithm module. For example, an accelerometer driver can send acceleration data to the motion algorithm module, an angular velocity sensor driver can send angular velocity data to the motion algorithm module, a proximity sensor driver can send proximity light data to the motion algorithm module, and an ambient light sensor driver can send ambient light data to the motion algorithm module.

[0105] After receiving sensor data, the motion algorithm module can detect currently occurring motion events based on this data. A currently occurring motion event can refer to the current motion state of the electronic device. For example, the motion algorithm module can determine a motion event based on acceleration data, angular velocity data, proximity light data, and ambient light data. Furthermore, the motion algorithm module can determine whether the event reporting conditions are met based on the occurring motion event. If the reporting conditions are met, the motion event is reported. After the motion event is reported, the electronic device can execute the operation corresponding to that motion event.

[0106] In some implementations, the motion algorithm module can detect motion events occurring in the electronic device for multiple functions. Different functions correspond to different algorithm modules, and different algorithms are used to identify different motion events. The motion algorithm module can input sensor data into different algorithm modules to identify different motion events. The algorithm modules involved in the embodiments of this application can be obtained by training a neural network model.

[0107] For example, the algorithm module corresponding to the automatic rotation function is algorithm module 1. The input of algorithm module 1 is sensor data, and the output can be whether a rotation event has occurred.

[0108] For example, the algorithm module corresponding to the pick-up and answer function is algorithm module 2. The input of algorithm module 2 is sensor data, and the output can be whether a pick-up event has occurred.

[0109] For example, the algorithm module corresponding to the drop detection function is algorithm module 3. The input of algorithm module 3 is sensor data, and the output can be whether a drop event has occurred.

[0110] For example, the algorithm module corresponding to the pocket anti-accidental touch function is algorithm module 4. The input of algorithm module 4 is sensor data, and the output can be whether the electronic device is in the user's pocket.

[0111] Currently, sensor drivers transmit sensor data periodically. This means that after the electronic device is powered on, the sensor driver continuously sends sensor data to the motion algorithm module. Because sensor data is constantly being sent to the motion algorithm module, the motion algorithm module also needs to continuously determine the motion state.

[0112] However, in some scenarios, motion event detection does not necessarily require all sensor data. If the sensor driver continuously sends sensor data and the motion algorithm module constantly determines the motion state of the electronic device, it will inevitably lead to excessive overhead for the electronic device.

[0113] For example, taking the detection of rotational events as an example, the detection of rotational events does not require proximity light data and ambient light data. However, currently, the sensor driver sends all sensor data (including proximity light data and ambient light data) to the motion algorithm module, which increases the data transmission overhead.

[0114] For example, even if the fall event has ended, meaning the electronic device has hit the ground, the sensor driver will still continuously send sensor data to the motion algorithm module after the electronic device hits the ground. The algorithm module will still continuously determine whether the electronic device has experienced a fall event based on the sensor data, which will increase the data transmission overhead and computational overhead.

[0115] Electronic devices can determine whether they have touched the ground based on acceleration data. For example, an electronic device can determine whether it has touched the ground based on changes in acceleration data. If the change in acceleration (or resultant acceleration) is greater than or equal to a second threshold, the electronic device can determine that it has touched the ground. The change in acceleration can be the change in acceleration over several frames (e.g., twenty frames) before the electronic device touches the ground.

[0116] For example, if an electronic device is stationary, but the various sensor drivers are still continuously sending data to the motion algorithm module, and the algorithm module within the motion algorithm module is still continuously detecting motion events, this will lead to high power consumption of the electronic device. Furthermore, even when the electronic device is stationary, the various sensors still need to be powered on, meaning that all sensors and other devices need to be constantly on, which will also affect the lifespan of the devices.

[0117] To address the aforementioned issues, this application provides a sensor data processing method and an electronic device that transmits sensor data through a multi-level triggering mechanism to reduce the power consumption of the electronic device. After acquiring first sensor data, the electronic device first predicts motion events based on the first sensor data. If a first motion event is predicted to have occurred, it further acquires the dependent sensor data (i.e., second sensor data) based on the sensor data that the first motion event depends on. The electronic device does not continuously acquire all sensor data, but rather acquires sensor data level by level as needed, achieving on-demand acquisition and thus reducing the transmission overhead of sensor data and the power consumption of the electronic device.

[0118] The first sensor in this embodiment can be any of the sensors described above. For example, the first sensor may include one or more of the following: an accelerometer, an angular velocity sensor, an ambient light sensor, and a proximity sensor. The accelerometer may be, for example, an accelerometer, and the angular velocity sensor may be, for example, a gyroscope.

[0119] The electronic device in this application embodiment may include a detection module, a motion algorithm module, and a data stream management module, such as... Figure 11 As shown. The solution in this embodiment can be implemented through a detection module, a motion algorithm module, and a data stream management module. It should be noted that the motion algorithm module in this embodiment can also be replaced by a motion module. In some implementations, the motion module may include a motion algorithm module and a subscription state management module.

[0120] The detection module, located between the sensor driver and the motion algorithm module, can be used to detect whether the electronic device is stationary. The detection module can be a built-in function of the system framework. The system framework itself provides motion detection functionality, which can identify whether the electronic device is stationary. This embodiment can combine the data stream's free pause or resume mechanism provided by the system framework to realize the transmission or interruption of the data stream.

[0121] The data flow management module is located between the sensor driver and the motion algorithm module, or it can be located within the motion algorithm module. The data flow management module controls the connection and disconnection of the data flow between the sensor driver and the motion algorithm module. When the data flow management module closes the data flow between the sensor driver and the motion algorithm module, the sensor driver cannot send sensor data to the motion algorithm module. When the data flow management module opens the data flow between the sensor driver and the motion algorithm module, the sensor driver can send sensor data to the motion algorithm module.

[0122] As described above, the motion algorithm module can acquire sensor data from the sensor driver and use the algorithm module to identify the motion state of the electronic device.

[0123] The following is combined with Figure 12 The present application provides a detailed description of the sensor data processing method provided in the embodiments.

[0124] See Figure 12 In step S1210, first sensor data is acquired from the first sensor driver.

[0125] The first sensor data refers to the data collected by the first sensor. The first sensor can be any one or more sensors in an electronic device. In some implementations, the first sensor can be an accelerometer. In some implementations, the first sensor can be an angular velocity sensor.

[0126] In some embodiments, first sensor data is acquired from the first sensor driver when the electronic device is in a non-stationary state. If the electronic device is in a stationary state, the first sensor data may not be acquired from the first sensor driver to reduce power consumption due to data transmission.

[0127] This application does not specifically limit the method for determining whether an electronic device is stationary. For example, an electronic device can determine whether it is stationary based on acceleration data. If the acceleration data changes, the electronic device can determine that it is not stationary; if the acceleration data remains essentially unchanged, the electronic device can determine that it is stationary.

[0128] In some implementations, the electronic device can determine whether it is stationary by measuring the magnitude of the acceleration data change. If the magnitude of the acceleration data change is greater than or equal to a first threshold, the electronic device is determined to be non-stationary. If the magnitude of the acceleration data change is less than the first threshold, the electronic device is determined to be stationary.

[0129] The magnitude of change in the aforementioned acceleration data can refer to the magnitude of change in acceleration data over several consecutive frames. For example, the magnitude of change in acceleration data can be the magnitude of change in acceleration data over two consecutive frames.

[0130] The first threshold can be a preset value or a pre-configured value. The first threshold can be flexibly adjusted according to actual needs. For example, to improve user experience and increase the sensitivity of motion recognition, the first threshold can be set smaller. To reduce the power consumption of electronic devices, the first threshold can be set larger.

[0131] This application embodiment determines whether an electronic device is stationary by basing the magnitude of the change in acceleration data on the relationship between the magnitude of the change and a first threshold, thereby reducing the complexity of determining whether an electronic device is stationary.

[0132] In some implementations, the detection process of whether an electronic device is stationary can be performed by a detection module. In some embodiments, the detection module can be a built-in function of the accelerometer. For example, on the sensorhub side, the sensorhub itself provides motion detection capabilities to adapt to the accelerometer. Embodiments of this application can utilize this capability of the sensorhub to detect whether the electronic device is stationary. By utilizing the built-in function of the sensorhub, embodiments of this application can determine whether the electronic device is stationary without sending sensor data to the motion algorithm module, which helps reduce the power consumption of the electronic device. The above-mentioned operating mode of the accelerometer in this embodiment can be called sentinel mode.

[0133] See also Figure 12 In step S1220, a first motion event occurring in the electronic device is predicted based on the first sensor data.

[0134] After acquiring data from the first sensor, the electronic device can predict motion events based on the changing patterns of the first sensor data; that is, it can predict possible motion events, which are then designated as the first motion event. The electronic device can input the first sensor data into an algorithm module, which can then output the first motion event.

[0135] For example, if an electronic device determines, based on data from a first sensor, that it is in a state of weightlessness (or sustained weightlessness) or has experienced free fall, then the electronic device can determine that a fall event may have occurred, i.e., the first motion event is a fall event.

[0136] In step S1230, if the first motion event depends on the second sensor data, then the second sensor data is obtained from the second sensor driver.

[0137] Once the electronic device predicts the occurrence of the first motion event, it can obtain sensor data from the corresponding sensor driver based on the sensor data upon which the first motion event depends.

[0138] For example, if the first motion event is a fall event, since the sensor data on which the fall event depends includes angular velocity sensor data, the electronic device can acquire angular velocity data from the angular velocity sensor drive.

[0139] For example, if the first motion event is a pick-up event, since the sensor data on which the pick-up event depends includes angular velocity sensor data, the electronic device can obtain angular velocity data from the angular velocity sensor drive.

[0140] For example, if the first motion event is located in the user's pocket, since the sensor data on which this event depends includes angular velocity sensor data, the electronic device can obtain angular velocity data from the angular velocity sensor drive.

[0141] The second sensor data may include all sensor data (in addition to the first sensor data) upon which the first motion event depends, or it may include only a portion of the sensor data upon which the first motion event depends. For example, the picking-up event depends not only on angular velocity data but also on proximity light data; in this case, the second sensor data may include only angular velocity data and exclude proximity light data. Similarly, the event of the object being in the user's pocket depends not only on angular velocity data but also on ambient light data; in this case, the second sensor data may include only angular velocity data and exclude ambient light data.

[0142] In step S1240, based on the data from the first sensor and the data from the second sensor, it is determined whether the reporting conditions for the first motion event are met.

[0143] The electronic device can determine whether a first motion event has actually occurred based on data from the first sensor and data from the second sensor. If a first motion event has occurred, it reports the first motion event and executes the operation corresponding to the first motion event.

[0144] In some implementations, the electronic device can input first sensor data and second sensor data into a motion algorithm, which can then determine whether the reporting conditions for a first motion event are met based on the first sensor data and second sensor data.

[0145] As described above, the electronic device in this embodiment can acquire sensor data using a multi-level triggering method. Multi-level triggering can also be called hierarchical triggering. Acquiring sensor data through multi-level triggering can reduce the power consumption of the electronic device.

[0146] This application does not specifically limit the number of levels in the multi-level embodiments. For example, there can be two levels, with the first level corresponding to the data from the first sensor and the second level corresponding to the data from the second sensor. Alternatively, there can be three levels, with the first level corresponding to the data from the first sensor, the second level corresponding to the data from the second sensor, and the third level corresponding to the data from the third sensor. Of course, the multi-level can also be other levels, and this application does not specifically limit this.

[0147] Taking a two-level multi-level system as an example, the sensor data can be transmitted as follows: when the triggering condition of the first level is met, the electronic device obtains the first sensor data from the first sensor driver; when the triggering condition of the second level is met, the electronic device obtains the second sensor data from the second sensor driver; if the triggering condition of the second level is not met, the sensor driver does not obtain the second sensor data.

[0148] Taking a two-level multi-sensor system as an example, the first sensor data includes acceleration data, and the second sensor data includes one or more of angular velocity data, proximity light data, and ambient light data. Alternatively, the first sensor data includes one or more of acceleration data and angular velocity data, and the second sensor data includes one or more of proximity light data and ambient light data.

[0149] For example, taking rotation events and fall events as examples, the first sensor may include acceleration events, and the second sensor may include angular velocity events.

[0150] Taking a three-level system as an example, when the trigger condition of the first level is met, the electronic device acquires data from the first sensor driver. When the trigger condition of the second level is met, the electronic device acquires data from the second sensor driver. If the trigger condition of the second level is not met, the sensor driver does not acquire data from the second sensor. When the trigger condition of the third level is met, the electronic device acquires data from the third sensor driver. If the trigger condition of the third level is not met, the electronic device does not acquire data from the third sensor.

[0151] Taking a three-level multi-sensor system as an example, the first sensor data includes acceleration data, the second sensor data includes angular velocity data, and the third sensor data includes proximity light data and ambient light data.

[0152] For example, in the case of picking up a phone to answer, the first sensor data includes acceleration data, the second sensor data includes angular velocity data, and the third sensor data includes proximity light data. In the case of the pocket-based accidental touch prevention event, the first sensor data includes acceleration data, the second sensor data includes angular velocity data, and the third sensor data includes ambient light data.

[0153] The first-level trigger condition can be that the electronic device described above is in a non-stationary state. The second-level trigger condition can include the first motion event described above depending on the second sensor data.

[0154] In some implementations, if the multi-level system is three-level, the electronic device can predict a second motion event that occurs in the electronic device based on the data from the first sensor and the data from the second sensor.

[0155] After acquiring data from the first sensor and data from the second sensor, the electronic device can predict motion events based on the changing patterns of the first sensor data and data from the second sensor data. That is, it can predict possible motion events, and the predicted motion events are the second motion events.

[0156] The second motion event can be the same as or different from the first motion event. For example, the second motion event can be a subset of the first motion event. Predicting motion events based solely on the first sensor data may result in a large number of events and low accuracy. However, predicting motion events based on both the first and second sensor data can eliminate some obviously unreasonable motion events, thus improving the accuracy of the predicted motion events.

[0157] For example, taking acceleration data from the first sensor and angular velocity data from the second sensor, if the electronic device detects a large acceleration in a certain direction, it may have experienced a drop, or the user may be riding a high-speed train or airplane. That is, the first motion event could include a drop, riding a high-speed train, or riding an airplane. All of these events rely on angular velocity data. The electronic device can further determine a second motion event based on the angular velocity data. If the electronic device determines a change in its angular velocity based on the angular velocity data, it can rule out riding a high-speed train or airplane, and the electronic device is more likely to have experienced a drop. Therefore, the second motion event includes a drop.

[0158] The sensor data upon which a motion event (such as the first motion event or the second motion event) depends can be understood as the sensor data required to determine the motion event.

[0159] For example, in a drop event, the sensor data relied upon includes acceleration and angular velocity data. Similarly, in a pick-up-to-answer event, the sensor data relied upon includes acceleration, angular velocity, and proximity light data. Finally, in a pocket-based accidental touch prevention event, the sensor data relied upon includes acceleration, angular velocity, and ambient light data.

[0160] In some implementations, if the second motion event depends on third sensor data, then the third sensor data is obtained from the third sensor driver. After predicting the second motion event, the electronic device can obtain sensor data from the corresponding sensor driver based on the sensor data that the second motion event depends on.

[0161] In some implementations, the third sensor data may include: the remaining sensor data on which the second motion event depends, in addition to the first and second sensor data.

[0162] For example, taking the second motion event as a pick-up and answer event, the electronic device determines the second motion event as a pick-up and answer event based on acceleration data and angular velocity data. Since the pick-up and answer event also depends on proximity light data, the electronic device can obtain proximity light data from the proximity light sensor, that is, the third sensor data includes proximity light data.

[0163] For example, taking the second motion event as a pocket anti-mistouch event, the electronic device determines the second motion event as a pocket anti-mistouch event based on acceleration data and angular velocity data. Since the pocket anti-mistouch event also depends on ambient light data, the electronic device can obtain ambient light data from the ambient light sensor, that is, the third sensor data includes ambient light data.

[0164] To reduce unnecessary calculations in electronic devices, the device can predict a first motion event based on a first function that is enabled. For functions that are disabled, the electronic device may not need to predict the motion event corresponding to that function.

[0165] In some implementations, the electronic device can determine a first function that is in the active state and predict a first motion event from the motion events corresponding to the first function based on the first sensor data.

[0166] The first function can be any of the functions described above, such as one or more of the following: automatic rotation function, pick-up to answer function, drop detection function, and pocket anti-mistouch function. Each function corresponds to a motion event; the automatic rotation function corresponds to a rotation event, the pick-up to answer function corresponds to a pick-up to answer event, the drop detection function corresponds to a drop event, and the pocket anti-mistouch function corresponds to a pocket anti-mistouch event.

[0167] To reduce the power-on time of sensor devices and extend their lifespan, embodiments of this application can de-energize a sensor when its data is not needed. For example, if the first motion event has ended, power can be stopped for the second sensor. Similarly, if the second motion event has ended, power can be stopped for both the second and third sensors.

[0168] For example, in the case of a drop event, if the electronic device detects that it has hit the ground, it means that the drop event has ended, and the electronic device can stop acquiring data from the second sensor and stop supplying power to the angular velocity sensor.

[0169] In some implementations, electronic devices can stop acquiring data from a sensor and stop supplying power to that sensor when no motion events require it, thus ensuring the normal operation of the electronic device.

[0170] The embodiments of this application can also reuse sensor data to detect other types of motion events. For example, if the electronic device acquires the second sensor data because it predicts a first motion event, it can still detect other types of motion events based on the acquired second sensor data. For instance, if the electronic device acquires angular velocity data because it predicts a fall event, it can detect rotational events based on the angular velocity data.

[0171] If an electronic device returns from a non-stationary state to a stationary state, the electronic device does not acquire any sensor data from the sensor driver in order to reduce the power consumption of the electronic device.

[0172] The solutions in this application embodiment can be executed by a motion algorithm module and a data flow management module. The solutions in this application embodiment will be described in detail below in conjunction with the motion algorithm module and the data flow management module.

[0173] If the electronic device is not in a stationary state, the data flow management module opens the data flow between the first sensor driver and the motion algorithm module so that the first sensor driver can send the first sensor data to the motion algorithm module.

[0174] If the electronic device is stationary, the data flow management module shuts down the data flow between the first sensor driver and the motion algorithm module to prevent the first sensor driver from sending the first sensor data to the motion algorithm module.

[0175] If the data flow management module opens the data flow between the first sensor driver and the motion algorithm module, the first sensor driver can send the first sensor data to the motion algorithm module. If the data flow management module closes the data flow between the first sensor driver and the motion algorithm module, the first sensor driver will not send the first sensor data to the motion algorithm module.

[0176] This application embodiment adds a data stream management module to enable the opening and closing of the data stream, allowing the sensor driver to send sensor data to the motion algorithm module as needed, instead of continuously sending sensor data to the motion algorithm module, thereby reducing the power consumption of the electronic device.

[0177] When the electronic device is stationary, the first sensor driver does not send first sensor data to the motion algorithm module, thereby reducing the overhead of data transmission. Furthermore, since the motion algorithm module does not receive sensor data, it does not perform subsequent algorithm logic calculations, further reducing the computational overhead of the electronic device. Therefore, the solution in this embodiment can reduce the power consumption of the electronic device.

[0178] In some implementations, if the electronic device is stationary, the sensor driver may not send any sensor data to the motion algorithm module, and the data flow module may shut down all data flow between the sensor driver and the motion algorithm module to minimize the overhead of the electronic device.

[0179] It should be noted that the sensor driver sending sensor data to the motion algorithm module in this embodiment can also be understood as the sensor sending sensor data to the motion algorithm module.

[0180] The first sensor data can be used to determine the first motion event, where the first sensor data refers to the data collected by the first sensor. In other words, the motion algorithm module can predict the first motion event based on the first sensor data.

[0181] If the first sensor is an accelerometer, then when the electronic device is not stationary, the accelerometer driver sends acceleration data to the motion algorithm module, while the drivers of other sensors (angular velocity sensor, ambient light sensor, and proximity sensor) can temporarily withhold sensor data from the motion algorithm module. If the first sensor includes both an accelerometer and an angular velocity sensor, then when the electronic device is not stationary, the accelerometer driver sends acceleration data to the motion algorithm module, the angular velocity sensor driver sends angular velocity data to the motion algorithm module, while the drivers of other sensors (ambient light sensor and proximity sensor) can temporarily withhold sensor data from the motion algorithm module.

[0182] In some implementations, if the electronic device is not stationary, the first sensor driver sends first sensor data to the motion algorithm module.

[0183] In some implementations, after receiving the first sensor data, the motion algorithm module can predict motion events based on the first sensor data. If a first motion event is predicted to have occurred in the electronic device, and the first motion event depends on the second sensor data, then the second sensor driver can send the second sensor data to the motion algorithm module. If the first motion event does not depend on the second sensor data, then the second sensor driver may not send the second sensor data to the motion algorithm module.

[0184] In some implementations, if the first motion event depends on the second sensor data, the data flow management module can open the data flow between the second sensor driver and the motion algorithm module, allowing the second sensor driver to send the second sensor data to the motion algorithm module. If the first motion event does not depend on the second sensor data, the data flow management module can close the data flow between the second sensor driver and the motion algorithm module, preventing the second sensor driver from sending the second sensor data to the motion algorithm module. In this way, the motion algorithm module can first determine the sensor data that the first motion event depends on, and then acquire that data. In other words, the sensor driver can transmit useful sensor data according to actual needs, avoiding invalid transmission of sensor data and thus reducing data transmission overhead.

[0185] In some implementations, the data flow management module can open or close the data flow between the second sensor driver and the motion algorithm module based on a request from the motion algorithm module. If the motion algorithm module determines that it needs second sensor data, it can send a request message to the data flow management module to request the acquisition of the second sensor data. Based on this request message, the data flow management module can open the data flow between the second sensor driver and the motion algorithm module.

[0186] The embodiments of this application adopt a hierarchical approach to send sensor data. First, it is determined whether the first sensor data needs to be acquired. If the first sensor data needs to be acquired, it is then determined whether the second sensor data needs to be acquired based on the first sensor data. If the second sensor data needs to be acquired, then the second sensor data is sent. This can reduce the transmission time of the second sensor data and help reduce the power consumption of electronic devices.

[0187] For example, if the motion algorithm module determines that the electronic device is in a state of weightlessness (or continuous weightlessness) based on the data from the first sensor, then the motion algorithm module can predict that the first motion event is a fall event. Further, the motion algorithm module determines whether the fall event requires data from the second sensor based on the sensor data on which the fall event is determined. Since the fall event depends on angular velocity data, the motion algorithm module can determine that the fall event requires angular velocity data. As another example, if the second sensor data is proximity light data, since the fall event does not depend on proximity light data, the motion algorithm module can determine that the fall event does not require proximity light data. Similarly, if the second sensor data is ambient light data, since the fall event does not depend on ambient light data, the motion algorithm module can determine that the first function does not require ambient light data.

[0188] If the motion algorithm module determines, based on the first sensor data, that the electronic device may be in a state where it has been picked up by the user (i.e., the first motion event is a pick-up and answer event), then the motion algorithm module can determine whether the pick-up and answer event requires second sensor data based on the sensor data upon which it was determined. For example, if the second sensor data is angular velocity data, the motion algorithm module can determine that the pick-up and answer event requires angular velocity data. Similarly, if the second sensor data is proximity light data, the motion algorithm module can determine that the pick-up and answer event requires proximity light data. And if the second sensor data is ambient light data, the motion algorithm module can determine that the pick-up and answer event does not require ambient light data.

[0189] If the motion algorithm module determines, based on the first sensor data, that the electronic device may be in the user's pocket (i.e., the first motion event is a pocket-protection event), then the motion algorithm module can determine whether second sensor data is needed based on the sensor data upon which the pocket-protection event is determined. For example, if the second sensor data is acceleration data, the motion algorithm module can determine that the pocket-protection event requires acceleration data. Similarly, if the second sensor data is proximity light data, the motion algorithm module can determine that the pocket-protection event does not require proximity light data. Likewise, if the second sensor data is ambient light data, the motion algorithm module can determine that the pocket-protection event requires ambient light data.

[0190] In some embodiments, if the second sensor data includes angular velocity data, the motion algorithm module determines that angular velocity data is needed when the first motion event includes one or more of the following states: a fall event, a pick-up and answer event, or a pocket accidental touch event. Since angular velocity data is required in determining the above motion events, the motion algorithm module needs to acquire angular velocity data in order to accurately determine whether the electronic device is truly in the aforementioned motion state.

[0191] Taking the second sensor data, which includes angular velocity data, as an example, if the motion algorithm module determines that angular velocity data is needed, the data flow management module can open the data flow between the angular velocity sensor driver and the motion algorithm module, so that the angular velocity sensor driver can send the angular velocity data to the motion algorithm module.

[0192] In some implementations, after the second sensor driver sends the second sensor data to the motion algorithm module, the motion algorithm module can predict the second motion event based on the first sensor data and the second sensor data.

[0193] In some embodiments, the first sensor is an acceleration sensor, the second sensor is an angular velocity sensor, and the third sensor is an ambient light sensor and / or a proximity light sensor.

[0194] In some implementations, if the second motion event depends on the third sensor data, the data flow management module opens the data flow between the third sensor driver and the motion algorithm module, allowing the third sensor driver to send the third sensor data to the motion algorithm module. If the second motion event does not depend on the third sensor data, the data flow management module may not open the data flow between the third sensor driver and the motion algorithm module, thus preventing the third sensor driver from sending the third sensor data to the motion algorithm module.

[0195] In some implementations, the data flow management module can open or close the data flow between the third sensor driver and the motion algorithm module based on a request from the motion algorithm module. If the motion algorithm module determines that a second motion event depends on the third sensor data, it can send a request message to the data flow management module to request the acquisition of the third sensor data. Based on this request message, the data flow management module can open the data flow between the third sensor driver and the motion algorithm module.

[0196] This application embodiment achieves dynamic acquisition of sensor data through a multi-level data transmission method, so that data can be acquired only when needed without shutting down the system, thereby greatly reducing the overhead caused by data transmission.

[0197] In some implementations, the embodiments of this application can reuse sensor data. If the motion algorithm module determines that the first motion event requires the second sensor data, the second sensor driver will send the second sensor data to the motion algorithm module, which can then perform subsequent logical judgments based on the second sensor data. If the third motion event does not require the second sensor data, or if the motion algorithm module has not yet predicted the third motion event, the motion algorithm module can still detect the third motion event based on the second sensor data.

[0198] In some implementations, the electronic device may also include a subscription state management module, such as Figure 11 As shown. The subscription state management module is located within the motion module; that is, the motion module can include the subscription state management module.

[0199] The subscription status management module can be used to manage various functions in electronic devices. For example, the subscription status management module can query the on / off status of each function and record the queried on / off states. The status of the functions recorded by the subscription status management module can be called the subscription status management result. In other words, the subscription status management result can include the on / off status of each function.

[0200] Taking answering a call as an example, if the user turns off the answer-by-call function, the subscription status management module can record the corresponding status as "off". Similarly, for the pocket accidental touch prevention function, if the user turns it on, the subscription status management module can record the corresponding status as "on". Other function statuses are similar and will not be illustrated further for simplicity.

[0201] Table 1

[0202] Automatic screen rotation closure Pick up and answer the phone closure Drop detection Open Pocket anti-accidental touch Open

[0203] Table 1 shows the states corresponding to several functions. In the scheme shown in Table 1, the user has turned off the automatic screen rotation function and the pick-to-answer function, and turned on the drop detection function and the pocket anti-accidental touch function.

[0204] In some embodiments, before determining whether a first motion event depends on second sensor data, the motion algorithm module can determine the first function that is enabled based on the subscription state management result in the subscription state management module. For functions that are disabled, the motion algorithm module does not need to perform subsequent logical judgments for those functions, i.e., it does not need to predict the motion event corresponding to those functions.

[0205] Taking Table 1 as an example, since the user has turned off the automatic screen rotation function, the motion algorithm module does not need to predict rotation events. Since the user has turned off the pick-up to answer function, the motion algorithm module does not need to predict pick-up to answer events. Since the user has enabled the drop detection function, the motion algorithm module needs to predict drop events. Since the user has enabled the pocket accidental touch prevention function, the motion algorithm module needs to predict pocket accidental touch events.

[0206] It should be noted that Table 1 is only an example and should not be construed as limiting the embodiments of this application. The states of various functions of the electronic device can also be other states, and the embodiments of this application do not limit this.

[0207] Taking Table 1 as an example, the first function includes drop detection and pocket accidental touch prevention. The motion algorithm module determines the first motion event from the motion corresponding to the first function based on the first sensor data. In some implementations, the motion algorithm module can first determine the motion event corresponding to the first function based on the first function. Then, the motion algorithm module can determine the first motion event from the motion events corresponding to the first function based on the first sensor data. In other words, the first motion event belongs to the motion events corresponding to the first function.

[0208] For example, still using Table 1, the first function includes drop detection and pocket accidental touch prevention. The motion events corresponding to the first function include drop events and pocket accidental touch prevention events. The motion algorithm module determines the possible motion events of the electronic device based on the first sensor data. The first motion event is the intersection of the motion event corresponding to the first function and the possible motion events. For example, if the motion algorithm module determines that the possible motion events based on the first sensor data include drop events and rotation events, since the user has turned off the screen auto-rotation function, the first motion event includes drop events but not rotation events.

[0209] By subscribing to the state management module and recording the activation status of various functions in the electronic device, the motion algorithm module can more accurately determine the actual sensor data required, thereby improving the accuracy of motion state judgment. In predicting the first motion event, this embodiment can exclude motion events corresponding to functions that have been disabled by the user. This avoids unnecessary calculations, reduces the overhead of the electronic device, and also helps improve the accuracy of the predicted first motion event.

[0210] In some implementations, the subscription state management module is also used to record and manage the sensor data requirements of various motion events in the electronic device. In some embodiments, the subscription state management module can record the sensor data requirements of all functions. In other embodiments, the subscription state management module can only record the sensor data requirements of enabled functions. For disabled functions, the subscription state management module may not record the sensor data required by that function to reduce overhead.

[0211] In some embodiments, the subscription status management module can modify the sensor data requirements of each function based on its on / off status and the execution status of each motion event. For example, if a user disables a function, that function does not require any sensor data, and the subscription status management module can modify the sensor data requirement of that function to "not required." Similarly, if a motion event has been completed, the function corresponding to that motion event does not currently require any sensor data, and the subscription status management module can modify the sensor data requirement of that function to "not required."

[0212] Taking the drop detection function as an example, if the motion algorithm module detects a significant change in the acceleration (or resultant acceleration) of the electronic device, and this change exceeds a preset value, it indicates that the electronic device has hit the ground and the drop process has ended. At this time, the subscription status management module can modify the drop detection function's requirement for sensor data to "not required".

[0213] Table 2 shows the requirements of various functions in an electronic device for sensor data.

[0214] Table 2

[0215]

[0216] Referring to Table 2, if the user has turned off the automatic screen rotation function, or the automatic screen rotation process has ended, the automatic screen rotation function does not require the sensor data listed in Table 2. If the user has enabled the pick-up answer function, and the electronic device is being picked up by the user, acceleration data, angular velocity data, and proximity light data are required for the pick-up answer function, but ambient light data is not required. If the user has enabled the drop detection function, and the electronic device is being dropped, acceleration data and angular velocity data are required for the drop detection function, but proximity light data and ambient light data are not required. If the user has disabled the pocket accidental touch prevention function, or the electronic device has been removed from the user's pocket, the pocket accidental touch prevention function does not require the sensor data listed in Table 2.

[0217] In some embodiments, the subscription state management module can determine whether to shut down the data flow between the sensor driver and the motion algorithm module based on the sensor data requirements of each function (or motion event).

[0218] In some embodiments, if the motion algorithm module determines that the first motion event of the electronic device has ended, the motion algorithm module may request to shut down the sensor data stream corresponding to the first motion event. Taking a drop event as an example, if the motion algorithm module detects that the electronic device has touched the ground, the motion algorithm module may request to shut down the angular velocity data stream. The motion algorithm module can determine whether the electronic device has touched the ground based on multiple frames of data (e.g., twenty frames of data) before the electronic device touched the ground.

[0219] Taking the fourth sensor data as an example, the subscription status management module can determine whether to shut down the data flow between the fourth sensor driver and the motion algorithm module based on the dependence of the second function on the fourth sensor data.

[0220] In some implementations, the second function refers to all functions that are enabled in the electronic device. For example, the second function includes one or more of the following: automatic screen rotation, pick-up answering, drop detection, and pocket anti-mistouch.

[0221] If the second function does not require fourth sensor data, the subscription state management module determines to shut down the data flow between the fourth sensor data and the motion algorithm module. The fact that the second function does not require fourth sensor data means that none of the currently enabled functions in the electronic device require it. In this case, the subscription state management module can determine to shut down the data flow between the fourth sensor data and the motion algorithm module to reduce the power consumption of the electronic device.

[0222] If any function requires fourth sensor data, the subscription state management module determines that the data flow between the fourth sensor driver and the motion algorithm module cannot be closed, and the fourth sensor driver needs to continue sending fourth sensor data to the motion algorithm module.

[0223] This embodiment of the application can, based on the subscription status results in the subscription status management module, shut down the data flow between the fourth sensor driver and the motion algorithm module only when all functions no longer require fourth sensor data. This ensures the normal processing flow of the electronic device and the user experience. Furthermore, shutting down the data flow between the fourth sensor driver and the motion algorithm module when none of the functions require fourth sensor data reduces data transmission overhead.

[0224] The fourth sensor can be any one or more of the sensors mentioned above. For example, the fourth sensor can be any one or more of an accelerometer, an angular velocity sensor, a proximity sensor, and an ambient light sensor.

[0225] Taking Table 2 as an example, for acceleration data, although the automatic screen rotation function and the pocket anti-mistouch function do not require acceleration data, the pick-up answering function and the drop detection function do. Therefore, the subscription state management module determines not to close the data flow between the accelerometer driver and the motion algorithm module. For angular velocity data, although the automatic screen rotation function and the pocket anti-mistouch function do not require angular velocity data, the pick-up answering function and the drop detection function do. Therefore, the subscription state management module determines not to close the data flow between the angular velocity sensor driver and the motion algorithm module. For proximity light data, although the automatic screen rotation function, the drop detection function, and the pocket anti-mistouch function do not require proximity light data, the pick-up answering function does. Therefore, the subscription state management module determines not to close the data flow between the proximity light sensor driver and the motion algorithm module. For ambient light data, since the automatic screen rotation function, the pick-up answering function, the drop detection function, and the pocket anti-mistouch function do not require ambient light data, the subscription state management module determines that the data flow between the ambient light sensor driver and the motion algorithm module can be closed.

[0226] If the subscription state management module determines that the data flow between the fourth sensor driver and the motion algorithm module can be shut down, the data flow management module can shut down the data flow between the fourth sensor driver and the motion algorithm module based on the decision of the subscription state management module, and the fourth sensor driver will no longer send fourth sensor data to the motion algorithm module.

[0227] The following describes how the second function determines its need for fourth sensor data. In some embodiments, the subscription status management module can determine whether the second function requires fourth sensor data based on first information. The first information includes one or more of the following: the on / off state of the second function, whether the second function has finished detecting, and the sensor data on which the motion state corresponding to the second function depends.

[0228] If the second function is turned off, it does not require data from the fourth sensor. If the second function is turned off, it means the user does not need to detect it, and therefore the second function does not require any sensor data.

[0229] If the second function detection is complete, then the second function does not require data from the fourth sensor. For example, for the drop detection function, if the motion algorithm module detects that the electronic device has touched the ground, it means the drop detection is complete, and there is no need to continue detecting the drop state. Therefore, the drop detection function does not require any sensor data. Similarly, for the pocket anti-mistouch function, if the electronic device has been taken out of the user's pocket and is being held in their hand, the pocket anti-mistouch detection is complete, and there is no need to continue detecting the pocket state. Therefore, the pocket anti-mistouch function does not require any sensor data. Likewise, for the pick-up answering function, if the user has hung up the call or removed the phone from their ear, the pick-up answering function detection is complete, and there is no need to continue detecting the picked-up state. Therefore, the pick-up answering function does not require any sensor data.

[0230] In some embodiments, to avoid the sensor being in a constantly on state, or to reduce the sensor's power-on time, the sensor can be powered off when the data flow management module closes the data flow between the sensor driver and the motion algorithm module, and then the sensor (or sensor chip) can be powered on when the data flow management module opens the data flow between the sensor driver and the motion algorithm module. This can extend the sensor's lifespan, improve the user's battery life experience, delay negative feedback and poor user experience caused by device aging, and thus reduce user returns.

[0231] In this embodiment, the motion algorithm module can determine the motion state of the electronic device based on the acquired sensor data. This motion state can be understood as the final determined motion state. The acquired sensor data may include only the first sensor data, or only the first sensor data and the second sensor data, or simultaneously include the first sensor data, the second sensor data, and the third sensor data.

[0232] In some implementations, if the motion algorithm module determines that the predicted motion event depends on the first sensor data but not on the second and third sensor data, then the motion algorithm module determines the motion event of the electronic device based on the first sensor data. If the motion algorithm module determines that the predicted motion event depends on the first and second sensor data but not on the third sensor data, then the motion algorithm module can determine the motion event of the electronic device based on the first and second sensor data. If the motion algorithm module determines that the predicted motion event depends on the first, second, and third sensor data, then the motion algorithm module can determine the motion event of the electronic device based on the first, second, and third sensor data.

[0233] In some implementations, if the electronic device changes from a non-stationary state to a stationary state, the data flow management module can shut down all data flow between the sensor data and the motion algorithm module. This prevents all sensor drivers from sending sensor data to the motion algorithm module, thereby reducing the power consumption of the electronic device. In this case, the accelerometer returns to sentinel mode, and the subsequent logic algorithm no longer responds or runs until the next significant change in acceleration data occurs, triggering the accelerometer's sentinel mode to detect the change and resume subsequent logic judgment and algorithm execution.

[0234] The following is combined with Figure 13 The solutions of the embodiments of this application will be described in more detail. It should be noted that... Figure 13 The solutions shown are merely for the purpose of illustrative purposes and are intended to illustrate the embodiments of this application. They should not be construed as limiting the scope of the embodiments of this application.

[0235] Figure 13 The illustrated electronic device includes a sensor driver, a detection module, a data stream management module, and a motion algorithm module. The motion algorithm module includes a subscription state management module.

[0236] After the electronic device is powered on, the motion algorithm module can send a request message to the sensor driver, which requests the sensor driver to send sensor data according to a first mode. The first mode is a threshold-based sensor data sending mode, or in other words, the first mode only sends sensor data when the electronic device is not stationary.

[0237] If the motion algorithm module requests to send sensor data according to the first mode, the accelerometer sensor can activate sentry mode. The detection module determines whether the acceleration data of two consecutive frames are approximately the same. If the acceleration data of two consecutive frames are approximately the same, it indicates that the electronic device is in a stationary state. The data stream management module can choose not to open the data stream between the accelerometer sensor driver and the motion algorithm module, and the accelerometer sensor driver will not send acceleration data to the motion algorithm module. If the acceleration data of two consecutive frames are different, it indicates that the electronic device is in a non-stationary state. The data stream management module can open the data stream between the accelerometer sensor driver and the motion algorithm module, and the accelerometer sensor driver will send acceleration data to the motion algorithm module. In other words, this embodiment of the application can prevent the acquisition of acceleration data in a stationary state, and only enable the acquisition of acceleration data when a change in acceleration data is detected.

[0238] The motion algorithm module determines the functions that are enabled in the electronic device based on the subscription status management results in the subscription status management module, and determines whether each function depends on angular velocity sensor data.

[0239] For the automatic screen rotation function, the motion algorithm module can determine the current state of the electronic device based on acceleration data.

[0240] For the pick-up and answer function, the motion algorithm module can predict whether the electronic device has engaged in a pick-up and answer event based on acceleration data. If the motion algorithm module determines that the electronic device may have engaged in a pick-up and answer event based on the acceleration data, then the motion algorithm module can determine that the pick-up and answer function requires angular velocity data.

[0241] For drop detection, the motion algorithm module can predict whether an electronic device has experienced a drop based on acceleration data. If the motion algorithm module determines that the electronic device may have experienced a drop based on the acceleration data, such as when the electronic device is in a state of continuous weightlessness, then the motion algorithm module can determine that the drop detection function requires angular velocity data.

[0242] For the pocket-protection feature, the motion algorithm module can predict whether a pocket-protection event has occurred based on acceleration data. If the motion algorithm module determines that a pocket-protection event may have occurred based on the acceleration data, then the motion algorithm module can determine that the pocket-protection feature requires angular velocity data.

[0243] The subscription status management module can record the angular velocity data requirements of various functions.

[0244] If a function requires angular velocity data, the data flow management module can open a data flow between the angular velocity sensor driver and the motion algorithm module, allowing the angular velocity sensor driver to send the angular velocity data to the motion algorithm module. The motion algorithm module can then input the angular velocity data into the algorithm corresponding to the function that requires the data for subsequent calculations.

[0245] The subscription status management module can also record the ambient light data and proximity light data requirements of various functions.

[0246] If the pick-up and answer function requires proximity light data, the data stream management module can open a data stream between the proximity light sensor driver and the motion algorithm module, allowing the proximity light sensor driver to send proximity light data to the motion algorithm module. The motion algorithm module can then input the proximity light data into the algorithm corresponding to the pick-up and answer function for subsequent calculations.

[0247] For example, the motion algorithm module can determine whether an electronic device has engaged in a pick-up and answer event, and whether the reporting conditions for such events are met, based on angular velocity data, proximity light data, and other relevant data. If the reporting conditions are met, the motion algorithm module reports the pick-up and answer event.

[0248] If the pocket anti-mistouch function requires ambient light data, the data stream management module can open a data stream between the ambient light sensor driver and the motion algorithm module, allowing the ambient light sensor driver to send ambient light data to the motion algorithm module. The motion algorithm module can then input the ambient light data into the algorithm corresponding to the pocket anti-mistouch function for subsequent calculations.

[0249] For example, the motion algorithm module can determine whether an electronic device has experienced a pocket-protection accidental touch event, and whether the reporting conditions for such events are met, based on angular velocity data, ambient light data, and other relevant data. If the reporting conditions are met, the motion algorithm module will report the pocket-protection accidental touch event.

[0250] If the motion event corresponding to a certain function has ended or the user has turned off a function, then that function will not require any sensor data. The subscription status management module can modify the sensor data requirement status corresponding to that function, changing the sensor data requirement status of that function to "not required".

[0251] If none of the functions require data from a particular sensor, the data flow management module can shut down the data flow between that sensor driver and the component module. Taking an ambient light sensor as an example, if none of the functions require ambient light data, the subscription status management module can instruct the data flow management module to shut down the data flow between the ambient light sensor driver and the motion algorithm module, so that the ambient light sensor driver does not send ambient light data to the motion algorithm module.

[0252] If a function meets the event reporting conditions, the motion algorithm module will report the event.

[0253] Taking drop detection as an example, the electronic device initially operates at rest. Once it begins to move, two frames of acceleration data determine if a non-stationary state is met. Then, combining this with the subscription state management results from the subscription state management module, the acceleration data is input to the required algorithm module. This algorithm module, based on the continuous changes in acceleration data across multiple frames, determines if the conditions for a stable free fall state are met, and then performs logical judgments based on the dependence of other event types on angular velocity data. If angular velocity data is needed, it is requested. This angular velocity data can also be used to determine other motion state types.

[0254] Figure 14 Taking the drop detection function as an example, this illustrates the time required for the motion algorithm module to obtain acceleration and angular velocity data.

[0255] from Figure 14As can be seen, the accelerometer is only online when the electronic device is no longer stationary, while the angular velocity sensor only requests data during a sustained free fall. The angular velocity sensor remains online throughout the free fall. When the electronic device hits the ground, a significant change in acceleration indicates the end of the fall, and the angular velocity data is then deactivated. After the fall is complete, the electronic device returns to a stationary state. Accelerometer data is no longer sent to the motion algorithm module, and the accelerometer enters sentinel mode.

[0256] from Figure 14 It can be seen that during the drop detection process, the time in which angular velocity data is stored is greatly reduced, and the time in which acceleration data is stored is also reduced to a certain extent, which can greatly reduce the power consumption of electronic devices.

[0257] The foregoing has detailed examples of the methods provided in this application. It is understood that the corresponding apparatus, in order to achieve the above functions, includes hardware structures and / or software modules corresponding to the execution of each function. Those skilled in the art should readily recognize that, based on the units and algorithm steps of the examples described in conjunction with the embodiments disclosed herein, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed in hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0258] This application can divide electronic devices into functional modules based on the above method examples. For example, each function can be divided into its own functional module, or two or more functions can be integrated into one module. The integrated module can be implemented in hardware or as a software functional module. It should be noted that the module division in this application is illustrative and only represents one logical functional division; other division methods may be used in actual implementation.

[0259] The following is combined Figures 15-16 The following describes the device embodiments of this application. It should be noted that the device embodiments correspond to the method embodiments, and any content not described in detail can be found in the method embodiments.

[0260] Figure 15 This is a schematic block diagram of the electronic device provided in the embodiments of this application. Figure 15 The electronic device 1500 shown can be any of the electronic devices mentioned above. The electronic device 1500 includes a motion algorithm module 1510 and a data flow management module 1520.

[0261] The data stream management module 1520 is used to: open the data stream between the first sensor driver and the motion algorithm module.

[0262] The motion algorithm module 1510 is used to: acquire first sensor data from the first sensor driver; and predict a first motion event occurring in the electronic device based on the first sensor data.

[0263] The data stream management module 1520 is further configured to: if the detection of the first motion event depends on the second sensor data, then open the data stream between the second sensor driver and the motion algorithm module.

[0264] The motion algorithm module 1510 is further configured to: acquire the second sensor data from the second sensor driver; and determine whether the reporting conditions of the first motion event are met based on the first sensor data and the second sensor data.

[0265] In some possible implementations, the motion algorithm module 1510 is used to: acquire first sensor data from the first sensor drive when the electronic device is in a non-stationary state.

[0266] In some possible implementations, the data flow management module 1520 is configured to: open the data flow between the first sensor driver and the motion algorithm module when the electronic device is in a non-stationary state.

[0267] In some possible implementations, the motion algorithm module 1510 is used to: determine the magnitude of change in acceleration data; if the magnitude of change in acceleration data is greater than or equal to a first threshold, then determine that the electronic device is in a non-stationary state.

[0268] In some possible implementations, the motion algorithm module 1510 is further configured to: predict a second motion event occurring in the electronic device based on the first sensor data and the second sensor data.

[0269] The data flow management module 1520 is further configured to: if the detection of the second motion event depends on the data from the third sensor, then open the data flow between the third sensor driver and the motion algorithm module.

[0270] The motion algorithm module 1510 is further configured to: acquire the third sensor data from the third sensor driver; and determine whether the reporting conditions for the second motion event are met based on the first sensor data, the second sensor data, and the third sensor data.

[0271] In some possible implementations, the motion algorithm module 1510 is configured to: determine the magnitude of change in the first sensor data and / or the second sensor data; if the magnitude of change in the first sensor data and / or the second sensor data is greater than or equal to a second threshold, determine that the first motion event has ended; and if the first motion event has ended, stop acquiring the second sensor data from the second sensor driver.

[0272] In some possible implementations, the data flow management module 1520 is further configured to: shut down the data flow between the second sensor driver and the motion algorithm module if the first motion event has ended.

[0273] In some possible implementations, the electronic device further includes a control module for stopping power supply to the second sensor if the first motion event has ended.

[0274] In some possible implementations, the motion algorithm module 1510 is used to: determine a first function in the electronic device that is in an active state; and predict the first motion event from the motion events corresponding to the first function based on the first sensor data.

[0275] In some possible implementations, the motion algorithm module 1510 is used to: determine a first function in the electronic device that is in an on state from the subscription state management result of the subscription state management module.

[0276] In some possible implementations, the first sensor data is acceleration data and the second sensor data is angular velocity data.

[0277] In some possible implementations, the third sensor data includes proximity light data and / or ambient light data.

[0278] In some possible implementations, the first motion event includes one or more of the following: rotation event, pick-up and answer event, drop event, and pocket anti-accidental touch event.

[0279] In some possible implementations, if the first motion event includes a rotation event and a fall event, then the first sensor data includes acceleration data and the second sensor data includes angular velocity data.

[0280] In some possible implementations, if the first motion event includes a pick-up / answer event, then the first sensor data includes acceleration data, the second sensor data includes angular velocity data, and the second sensor data includes proximity light data.

[0281] In some possible implementations, if the first motion event includes a pocket anti-mistouch event, then the first sensor data includes acceleration data, the second sensor data includes angular velocity data, and the second sensor data includes ambient light data.

[0282] Figure 16 This is a schematic structural diagram of the device according to an embodiment of this application. Figure 16 The dashed lines indicate that the unit or module is optional. The device 1600 can be used to implement the methods described in the above method embodiments. The device 1600 can be a chip or an electronic device.

[0283] Apparatus 1600 may include one or more processors 1610. The processor 1610 may support apparatus 1600 in implementing the methods described in the preceding method embodiments. The processor 1610 may be a general-purpose processor or a special-purpose processor. For example, the processor may be a central processing unit (CPU). Alternatively, the processor may 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. The general-purpose processor may be a microprocessor or any conventional processor.

[0284] The apparatus 1600 may further include one or more memories 1620. The memories 1620 store a program that can be executed by the processor 1610, causing the processor 1610 to perform the methods described in the preceding method embodiments. The memories 1620 may be independent of the processor 1610 or integrated within the processor 1610.

[0285] The device 1600 may also include a transceiver 1630. The processor 1610 can communicate with other devices or chips via the transceiver 1630. For example, the processor 1610 can send and receive data with other devices or chips via the transceiver 1630.

[0286] This application also provides a chip, which includes a processor for reading and executing a computer program stored in a memory to perform the sensor data processing method described in any of the above embodiments.

[0287] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, causes the processor to perform the sensor data processing method described in any of the above embodiments.

[0288] This application also provides a computer program product that, when run on a computer, causes the computer to perform the aforementioned steps to implement the sensor data processing method described in the above embodiments.

[0289] In this embodiment, the electronic device, computer-readable storage medium, computer program product or chip are all used to execute the corresponding methods provided above. Therefore, the beneficial effects that can be achieved can be referred to the beneficial effects of the corresponding methods provided above, and will not be repeated here.

[0290] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, indirect coupling or communication connection between devices or units. The replaced units may or may not be physically separate. The component shown as a unit may be one physical unit or multiple physical units, that is, it may be located in one place or distributed in multiple different places. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0291] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0292] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, in essence, or the parts that contribute to the prior art, or all or part of the technical solutions, can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0293] It should be understood that in the various embodiments of this application, the order of the above-mentioned processes does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0294] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included 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 processing sensor data, characterized in that, include: The first sensor, which is an accelerometer, is used to detect whether the electronic device is in a non-stationary state by using a first sensor in sentry mode. When the electronic device is in a non-stationary state, first sensor data is acquired from the first sensor drive. Based on the first sensor data, a first motion event occurring in the electronic device is predicted, the motion event including one or more of the following: rotation event, picking up event, falling event, and accidental pocket touch event; If the detection of the first motion event depends on the second sensor data, then the second sensor data is obtained from the second sensor driver, the second sensor including an angular velocity sensor; Based on the data from the first sensor and the data from the second sensor, determine whether the reporting conditions for the first motion event are met; Based on the first sensor data and the second sensor data, predict the second motion event that occurs in the electronic device; If the detection of the second motion event depends on third sensor data, the third sensor data is obtained from the third sensor driver, the third sensor including the remaining sensors that the second motion event depends on, in addition to the first sensor and the second sensor; Based on the data from the first sensor, the second sensor, and the third sensor, determine whether the reporting conditions for the second motion event are met. If the first motion event is detected to have ended, then power supply to the second sensor is stopped; If the second motion event is detected to have ended, then power supply to the second sensor and the third sensor is stopped; If the electronic device is detected to have returned to a stationary state from a non-stationary state, then the acquisition of data from the first sensor is stopped.

2. The method according to claim 1, characterized in that, Before acquiring the first sensor data from the first sensor driver, the method further includes: Determine the magnitude of change in the acceleration data; If the change in the acceleration data is greater than or equal to the first threshold, then the electronic device is determined to be in a non-stationary state.

3. The method according to claim 1 or 2, characterized in that, The method further includes: Determine the magnitude of change in the first sensor data and / or the second sensor data; If the change in the first sensor data and / or the second sensor data is greater than or equal to the second threshold, then it is determined that the first motion event has ended. If the first motion event has ended, then stop acquiring the second sensor data from the second sensor driver.

4. The method according to claim 1 or 2, characterized in that, The method further includes: Determine the first function in the electronic device that is in the enabled state; The step of predicting a first motion event occurring in the electronic device based on the first sensor data includes: Based on the first sensor data, predict the first motion event from the motion events corresponding to the first function.

5. The method according to claim 1, characterized in that, The third sensor data includes proximity light data and / or ambient light data.

6. An electronic device, characterized in that, include: Motion algorithm module and data flow management module, The data stream management module is used to: when the electronic device is detected to be in a non-stationary state by the first sensor in sentry mode, open the data stream between the first sensor driver and the motion algorithm module, wherein the first sensor is an accelerometer sensor; The motion algorithm module is used to: acquire first sensor data from the first sensor driver; and predict a first motion event occurring in the electronic device based on the first sensor data, wherein the motion event includes one or more of the following: rotation event, picking up event, falling event, and pocket accidental touch event; The data stream management module is further configured to: if the detection of the first motion event depends on the data from the second sensor, then open the data stream between the second sensor driver and the motion algorithm module, wherein the second sensor includes an angular velocity sensor; The motion algorithm module is further configured to: acquire the second sensor data from the second sensor driver; and determine whether the reporting conditions for the first motion event are met based on the first sensor data and the second sensor data. Based on the first sensor data and the second sensor data, a second motion event occurring in the electronic device is predicted. If the detection of the second motion event depends on the third sensor data, the third sensor data is obtained from the third sensor driver. Based on the first sensor data, the second sensor data, and the third sensor data, it is determined whether the reporting conditions for the second motion event are met. The third sensor includes the remaining sensors that the second motion event depends on, in addition to the first sensor and the second sensor. The data flow management module is further configured to: if the motion algorithm module detects that the first motion event has ended, then close the data flow between the second sensor driver and the motion algorithm module; if the second motion event is detected to have ended, then close the data flow between the second sensor driver and the third sensor driver and the motion algorithm module. And if the motion algorithm module detects that the electronic device has returned from a non-stationary state to a stationary state, it shuts down the data flow between the first sensor driver and the motion algorithm module.

7. The electronic device according to claim 6, characterized in that, The motion algorithm module is used for: Determine the magnitude of change in the acceleration data; If the change in the acceleration data is greater than or equal to the first threshold, then the electronic device is determined to be in a non-stationary state. If the electronic device is in a non-stationary state, it acquires first sensor data from the first sensor driver.

8. An electronic device, characterized in that, The electronic device includes a memory and a processor, the memory storing a computer program executable on the processor, the processor executing the computer program to implement the method as described in any one of claims 1 to 5.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, causes the processor to perform the method as described in any one of claims 1 to 5.

Images