Methods and systems for reducing power consumption in IoT wireless sensor systems

Abstract

This invention discloses a method and system for reducing power consumption in IoT wireless sensor systems. The method includes: a system initialization phase, a daily inspection phase, an intelligent decision-making phase, an instantaneous response phase, a main control processing phase, and a task completion phase. The coprocessor used employs subthreshold design technology, with a standby current of less than 100nA. It runs continuously during the wireless SoC's sleep period, autonomously managing sensor polling, threshold comparison, and wake-up decisions. The coprocessor only wakes up the wireless SoC via a built-in power switch to perform data processing and wireless transmission when sensor data exceeds a preset threshold, reaches a scheduled reporting time, or receives an external interrupt. This invention achieves an architectural shift from "timed polling" to "event response," reducing overall power consumption by up to 90% and extending battery life by 5-10 times. It is suitable for IoT applications such as smart agriculture, industrial monitoring, cold chain logistics, and smart buildings.

Description

Technical Field

[0001] This invention relates to the field of Internet of Things (IoT) technology, and in particular to a method and system for reducing power consumption in IoT wireless sensor systems. Background Technology

[0002] With the rapid development of IoT technology, IoT wireless sensors have been widely used in many fields such as smart agriculture, industrial monitoring, cold chain logistics, smart buildings, and environmental monitoring. These sensor nodes are usually deployed in remote or difficult-to-maintain environments, are battery powered, and need to operate continuously for months or even years.

[0003] However, existing IoT wireless sensor systems generally adopt a single SoC (System on Chip) architecture, where the wireless SoC (such as nRF54L15) simultaneously handles all tasks including sensor data acquisition, processing, and wireless communication. In this traditional architecture, even when no valid event occurs, the main SoC needs to frequently wake up from deep sleep to poll and listen to the connected sensors to detect any data changes that need to be reported.

[0004] This "periodic polling" working mode has the following significant drawbacks: (1) Excessive power consumption: Even in low-power sleep mode, the standby current of the main control SoC is usually still in the microamp (μA) level (e.g., about 1.8μA in System ON Sleep mode and about 0.3μA in System OFF mode for nRF54L15). When frequently waking up to poll the sensors, the current consumption will rise sharply to the milliamp (mA) level. A large number of invalid sensor data acquisition and monitoring operations cause serious energy waste.

[0005] (2) Limited battery life: Due to limitations such as product size and cost, battery capacity cannot be increased indefinitely. If wireless sensors already deployed in the field need to be replaced to achieve long battery life, it will bring huge labor and resource costs, as well as maintenance risks and operational safety hazards.

[0006] (3) Low system efficiency: The traditional architecture adopts the "time-driven" mode, that is, the sensor polling task is executed according to a fixed schedule. Regardless of whether an actual event occurs, the SoC needs to perform invalid data acquisition and processing according to the preset cycle, resulting in extremely low overall system energy efficiency.

[0007] (4) High maintenance costs: For large-scale IoT sensor networks, frequent battery replacements not only increase direct material costs, but also generate a large number of indirect costs such as manual inspections and on-site maintenance, which seriously restricts the large-scale promotion of IoT applications.

[0008] While some SoC chips in the current technology provide deep sleep and timed wake-up functions, they still essentially require the main control MCU to handle sensor monitoring tasks, thus failing to achieve a true "event-driven" architecture. Furthermore, some solutions attempt to reduce power consumption by optimizing software algorithms or lowering the operating frequency, but with limited success and failing to fundamentally solve the system-level power consumption problem.

[0009] Therefore, there is an urgent need for an innovative system architecture and methodology that can significantly reduce overall system power consumption, extend battery life, and reduce maintenance costs while ensuring the normal monitoring functions of IoT wireless sensors, thereby achieving a truly low-power, long-lasting, event-driven IoT sensor system. (WeChat) Summary of the Invention The main objective of this invention is to provide a method and system for reducing the power consumption of IoT wireless sensor systems, aiming to solve the technical problem of excessive power consumption in existing IoT wireless sensor systems.

[0010] To achieve the above objectives, the first aspect of the present invention provides a method for reducing the power consumption of an IoT wireless sensor system, wherein the IoT wireless sensor system includes a sensor array, a low-power coprocessor, a wireless SoC, and a battery module. The method includes the following steps: Step S1: System initialization phase, used to configure and initialize the connected sensors using a low-power coprocessor via I2C or SPI interface, and set the sensor's operating parameters, sampling period, threshold conditions, and configure the wake-up conditions and power management strategy of the wireless SoC using the low-power coprocessor. Step S2: During the routine inspection phase, a low-power coprocessor is used to take over system control, so as to completely power down the wireless SoC or put it into the deepest sleep state through the built-in power switch; and the low-power coprocessor uses the low-power coprocessor to poll the sensors autonomously according to a preset cycle, obtain sensor data, and temporarily store the data in the built-in SRAM. Step S3: Intelligent decision-making stage, used to keep the low-power coprocessor running continuously during the wireless SoC sleep period, autonomously manage sensor monitoring tasks, and power the wireless SoC through the power switch and wake up the wireless SoC when the wake-up conditions are met; Step S4: Instantaneous response phase, used to power the wireless SoC with a low-power coprocessor via a power switch and wake up the wireless SoC via an interrupt signal; and use the low-power coprocessor to transmit critical event data temporarily stored in SRAM to the wireless SoC via I2C or SPI interface. Step S5: Main control processing stage, used to quickly read sensor data provided by low power coprocessor after the wireless SoC is woken up, perform data processing and analysis, and send the data to the gateway or cloud server through the wireless communication module; Step S6: Task completion stage, used to send a sleep command to the low-power coprocessor after the wireless SoC completes data processing and wireless transmission; the low-power coprocessor cuts off the power supply to the wireless SoC through the power switch, and the system returns to the managed mode of step S2, where the low-power coprocessor continues to perform daily monitoring.

[0011] Furthermore, the step of powering the wireless SoC and waking it up via a power switch when the wake-up condition is met includes: having the low-power coprocessor compare the real-time collected sensor data with a preset threshold rule; if the sensor data does not trigger the threshold rule, then monitoring continues and the wireless SoC remains in sleep mode; if the sensor data triggers the threshold rule, then proceed to step S4.

[0012] Furthermore, the low-power coprocessor has a built-in programmable threshold comparator and state machine, supporting up to four sensor inputs to independently set different preset rules for each sensor, wherein the preset rules include a wake-up threshold and / or trigger conditions.

[0013] Furthermore, the preset rules include: an event-triggered mode, used to wake up the wireless SoC when the sensor data exceeds a preset threshold; or / and a timed-triggered mode, used to wake up the wireless SoC when a preset timed reporting point is reached; or / and an external-triggered mode, used to wake up the wireless SoC when an external interrupt signal is received.

[0014] Furthermore, the low-power coprocessor has a built-in 128-byte SRAM for temporarily storing sensor initialization commands and key event data, ensuring that the main SoC can quickly obtain complete context information after waking up, reducing processing latency after waking up.

[0015] Furthermore, the power switch is integrated inside the low-power coprocessor or implemented through a separate MOSFET, and is controlled by the coprocessor to turn on and off according to the wake-up condition, so as to realize on-demand power supply for the wireless SoC.

[0016] This application also provides an IoT wireless sensor system, including: A sensor array, including at least one sensor, for acquiring environmental parameters or physical quantity data; A low-power coprocessor connects to the sensor array via an I2C or SPI interface. It is used to autonomously manage the configuration, polling, and data acquisition of the sensors, perform threshold comparison and wake-up decisions, and has built-in power switch and SRAM data storage functions. The low-power coprocessor adopts subthreshold design technology, with a standby current of less than 100 nanoamps and an operating current in the microamp level. The wireless SoC connects to the low-power coprocessor via an I2C interface and is used to perform data processing and wireless communication tasks in the wake-up state. It supports multiple wireless protocols such as Bluetooth Low Energy, Zigbee, LoRa, and proprietary 2.4GHz. A battery module is used to power the low-power coprocessor, wireless SoC, and sensor array. The low-power coprocessor runs continuously during the wireless SoC's sleep period, autonomously manages sensor monitoring tasks, and only powers the wireless SoC and wakes it up via a power switch when the wake-up conditions are met.

[0017] Furthermore, the sensor array includes one or more of the following: temperature and humidity sensor, accelerometer, gyroscope, light sensor, pressure sensor, CO2 sensor, and PM2.5 sensor, and is connected to a low-power coprocessor via an I2C or SPI interface.

[0018] Furthermore, the system uses a graphical configuration tool of a low-power coprocessor to set parameters, including sensor parameter configuration, threshold rule setting, wake-up strategy configuration, and wireless protocol configuration. After configuration, the corresponding firmware code and configuration file are automatically generated.

[0019] Furthermore, the standby power consumption of the IoT wireless sensor system is less than 1 microamp.

[0020] This invention provides a method and system for reducing power consumption in IoT wireless sensor systems, with the following advantages: Significantly reduced system power consumption: By introducing a low-power coprocessor to offload the daily monitoring tasks of the main control SoC, the main control SoC is in a completely powered-off or deep sleep state most of the time. The overall standby power consumption of the system is reduced from 100-500μA in traditional solutions to below 1μA, with a power reduction of up to 90%. Taking the CR2032 button battery as an example, the traditional solution provides a battery life of about 6 months, while this solution can extend it to more than 5 years.

[0021] Extended battery life: Due to the significant reduction in overall system power consumption, the device's battery life can be extended by 5-10 times with the same battery capacity, effectively solving the problem of difficult battery replacement for IoT sensor nodes. It is particularly suitable for scenarios such as remote areas, harsh environments, and large-scale deployments.

[0022] Reduced maintenance costs: The long battery life significantly reduces the frequency of battery replacements and maintenance inspections, thereby lowering labor and material costs and improving the overall economic efficiency and maintainability of the IoT system.

[0023] Achieving a true "event-driven" architecture: The system transforms from the traditional "time-driven" mode to an "event-driven" mode, only waking up the main control SoC when a meaningful event occurs or when a timed reporting node is reached, avoiding a large number of invalid data collection and monitoring operations, and significantly improving the system's energy efficiency ratio.

[0024] Improved system real-time response: The low-power coprocessor continuously monitors the sensor status and can immediately wake up the main control SoC once a threshold condition is triggered. The response latency is much lower than that of traditional timed polling solutions, ensuring timely capture and reporting of critical events.

[0025] Support for energy harvesting applications: The extremely low system power consumption makes it possible for devices to achieve self-powered operation through environmental energy harvesting (such as solar energy, vibration energy, thermal energy, etc.), and even completely get rid of battery dependence, realizing a true green Internet of Things.

[0026] Flexible architecture adaptability: The collaborative processing architecture of this invention can be adapted to a variety of wireless SoC chips (such as Nordic nRF54L15, nRF52840, STM32WB series, etc.) and a variety of sensor types, with good versatility and scalability.

[0027] Simplified software development: The low-power coprocessor provides a graphical configuration tool, allowing users to set sensor parameters, threshold rules, and wake-up strategies through an intuitive interface, and automatically generate corresponding firmware code, which greatly reduces the development threshold and development cycle. Attached Figure Description

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

[0029] Figure 1 This is a flowchart illustrating a method for reducing power consumption in an IoT wireless sensor system according to an embodiment of the present invention. Figure 2 This is a diagram of a single SOC polling architecture in existing technologies; Figure 3 This is a diagram illustrating the collaborative processing architecture of a method for reducing power consumption in an IoT wireless sensor system according to an embodiment of the present invention. Figure 4This is a diagram illustrating the working principle architecture of an IoT wireless sensor system according to an embodiment of the present invention. Figure 5 This invention provides a simplified hardware block diagram of an IoT wireless sensor system. Figure 6 This is a comparison chart showing the power consumption and battery life improvement of the method for reducing power consumption in IoT wireless sensor systems according to embodiments of the present invention compared with traditional SOC solutions; Figure 7 This invention provides a state transition diagram for reducing the complexity of IoT wireless sensor systems in embodiments of the invention. Detailed Implementation To make the objectives, features, and advantages of this invention more apparent and understandable, the technical solutions of the embodiments of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this invention, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention.

[0030] Please see Figure 1 This is a method for reducing power consumption in an IoT wireless sensor system, wherein the IoT wireless sensor system includes a sensor array, a low-power coprocessor, a wireless SoC, and a battery module. The method includes the following steps: Step S1: System initialization phase, used to configure and initialize the connected sensors using a low-power coprocessor via I2C or SPI interface, and set the sensor's operating parameters, sampling period, threshold conditions, and configure the wake-up conditions and power management strategy of the wireless SoC using the low-power coprocessor. Step S2: During the routine inspection phase, a low-power coprocessor is used to take over system control, so as to completely power down the wireless SoC or put it into the deepest sleep state through the built-in power switch; and the low-power coprocessor uses the low-power coprocessor to poll the sensors autonomously according to a preset cycle, obtain sensor data, and temporarily store the data in the built-in SRAM. Step S3: Intelligent decision-making stage, used to keep the low-power coprocessor running continuously during the wireless SoC sleep period, autonomously manage sensor monitoring tasks, and power the wireless SoC through the power switch and wake up the wireless SoC when the wake-up conditions are met; Step S4: Instantaneous response phase, used to power the wireless SoC with a low-power coprocessor via a power switch and wake up the wireless SoC via an interrupt signal; and use the low-power coprocessor to transmit critical event data temporarily stored in SRAM to the wireless SoC via I2C or SPI interface. Step S5: Main control processing stage, used to quickly read sensor data provided by low power coprocessor after the wireless SoC is woken up, perform data processing and analysis, and send the data to the gateway or cloud server through the wireless communication module; Step S6: Task completion stage, used to send a sleep command to the low-power coprocessor after the wireless SoC completes data processing and wireless transmission; the low-power coprocessor cuts off the power supply to the wireless SoC through the power switch, and the system returns to the managed mode of step S2, where the low-power coprocessor continues to perform daily monitoring.

[0031] In some embodiments, the step of powering the wireless SoC via a power switch and waking it up when the wake-up condition is met includes: The low-power coprocessor compares the sensor data collected in real time with preset threshold rules. If the sensor data does not trigger the threshold rule, monitoring continues, and the wireless SoC remains in sleep mode. If the sensor data triggers the threshold rule, proceed to step S4.

[0032] In some embodiments, a low-power coprocessor is connected to the sensor array via an I2C or SPI interface to autonomously manage sensor configuration, polling, and data acquisition, perform threshold comparison and wake-up decisions, and has built-in power switch and SRAM data storage functions. The low-power coprocessor adopts subthreshold design technology, with standby current below 100 nanoamps and operating current in the microamp level.

[0033] The wireless SoC connects to the low-power coprocessor via an I2C interface and is used to perform data processing and wireless communication tasks in the wake-up state. It supports multiple wireless protocols such as Bluetooth Low Energy, Zigbee, LoRa, and proprietary 2.4GHz.

[0034] A battery module is used to power the low-power coprocessor, wireless SoC, and sensor array.

[0035] In this embodiment, the low-power coprocessor continues to run during the wireless SoC's sleep period, autonomously managing sensor monitoring tasks, and only powering and waking up the wireless SoC via a power switch when the wake-up conditions are met, thus realizing the system's architectural transformation from "timed polling" to "event response".

[0036] In some embodiments, the low-power coprocessor has a built-in programmable threshold comparator and state machine, supporting up to four sensor inputs to independently set different preset rules for each sensor. The preset rules include wake-up thresholds and / or trigger conditions to implement a flexible "event-driven" monitoring strategy.

[0037] In some embodiments, the preset rules include: Event-triggered mode, used to wake up the wireless SoC when the sensor data exceeds a preset threshold; or / and, A timed trigger mode is used to wake up the wireless SoC when a preset timed reporting point is reached; or / and, An external trigger mode is used to wake up the wireless SoC when an external interrupt signal is received.

[0038] In some embodiments, the low-power coprocessor has a built-in 128-byte SRAM for temporarily storing sensor initialization commands and key event data, so as to ensure that the main SoC can quickly obtain complete context information after waking up and reduce the processing delay after waking up.

[0039] In some embodiments, the wireless SoC uses the nRF54L15 chip, which supports multiple wireless protocols such as Bluetooth Low Energy BLE 5.4, Zigbee, Thread, and proprietary 2.4GHz; the low-power coprocessor uses the nPZero chip, which supports I2C / SPI communication interfaces and integrates a power switch function.

[0040] In some embodiments, the power switch is integrated within the low-power coprocessor or implemented through a separate MOSFET, and is controlled by the coprocessor to switch on and off according to wake-up conditions, so as to realize on-demand power supply for the wireless SoC.

[0041] In some embodiments, the IoT wireless sensor system includes: A sensor array, including at least one sensor, for acquiring environmental parameters or physical quantity data; A low-power coprocessor connects to the sensor array via an I2C or SPI interface. It is used to autonomously manage the configuration, polling, and data acquisition of the sensors, perform threshold comparison and wake-up decisions, and has built-in power switch and SRAM data storage functions. The low-power coprocessor adopts subthreshold design technology, with a standby current of less than 100 nanoamps and an operating current in the microamp level. The wireless SoC connects to the low-power coprocessor via an I2C interface and is used to perform data processing and wireless communication tasks in the wake-up state. It supports multiple wireless protocols such as Bluetooth Low Energy, Zigbee, LoRa, and proprietary 2.4GHz. A battery module is used to power the low-power coprocessor, wireless SoC, and sensor array. The low-power coprocessor runs continuously during the wireless SoC's sleep period, autonomously manages sensor monitoring tasks, and only powers the wireless SoC and wakes it up via a power switch when the wake-up conditions are met.

[0042] In some embodiments, the sensor array includes one or more of a temperature and humidity sensor, an accelerometer, a gyroscope, a light sensor, a pressure sensor, a CO2 sensor, and a PM2.5 sensor, and is connected to a low-power coprocessor via an I2C or SPI interface.

[0043] In some embodiments, the system uses a graphical configuration tool of a low-power coprocessor to set parameters, including sensor parameter configuration, threshold rule setting, wake-up strategy configuration, and wireless protocol configuration. After configuration, the corresponding firmware code and configuration file are automatically generated.

[0044] In some embodiments, the IoT wireless sensor system has a standby power consumption of less than 1 microamp, which reduces power consumption by up to 90% compared to traditional single-SoC polling solutions and extends battery life by 5-10 times.

[0045] The above technical solutions will be described below based on different embodiments: Example 1: System Architecture Design In the traditional approach, please refer to Figure 2 The wireless SoC (master MCU) needs to be frequently woken up to poll the sensors, and it is in an idle state even when nothing is happening. The power consumption level is still as high as 100-500μA in standby mode. The system behavior is time-driven, and the SoC undertakes all tasks alone, including a large amount of invalid listening.

[0046] This embodiment provides an IoT wireless sensor system that differs from traditional ones, employing a collaborative processing architecture. Please refer to [link / reference]. Figure 3 The system adds a dedicated low-power coprocessor (such as nPZero) between the wireless SoC and the sensors. This coprocessor acts as a "smart manager," with a standby current of less than 100nA and a typical operating current in the 1μA range. Most of the time, the main SoC (such as nRF54L15) can be completely powered off, allowing the low-power coprocessor to autonomously manage up to four sensors, performing data acquisition and threshold comparison at set intervals (such as once per second). Only when sensor data exceeds a preset threshold, reaches a scheduled reporting time, or receives an external interrupt signal, does the coprocessor power up the main SoC and wake it up via its built-in power switch.

[0047] like Figure 5 and Figure 7 As shown, the IoT wireless sensor system of this embodiment includes the following modules: (1) Battery module: Button batteries (such as CR2032, with a capacity of about 225mAh), lithium-ion batteries (such as ER14505, with a capacity of about 2700mAh) or AA alkaline batteries are used to provide power to the entire system.

[0048] (2) Power Management Unit (PMIC): Responsible for battery voltage monitoring, voltage regulation and power distribution to ensure that each module obtains a stable operating voltage.

[0049] (3) Power Switch: Integrated into the low-power coprocessor or implemented through a separate MOSFET, controlled by the coprocessor, used to power the main SoC on demand or cut off its power.

[0050] (4) Low-power coprocessor (such as nPZero): It adopts subthreshold design technology, with standby current <100nA and operating current of about 1μA. It supports I2C / SPI communication interface and has a built-in programmable threshold comparator, state machine and 128 bytes of SRAM. This coprocessor can manage up to 4 sensor inputs, and each input can be independently configured with wake-up threshold and trigger conditions.

[0051] (5) Wireless SoC (such as nRF54L15): It adopts Arm Cortex-M33 core and integrates multi-protocol wireless transmitters (supporting BLE, Zigbee, Thread, private 2.4GHz, etc.). When it is not needed, the coprocessor can completely power off to achieve zero power standby.

[0052] (6) Sensor array: including temperature and humidity sensors (such as SHT40), accelerometers (such as LIS2DH12), gyroscopes, light sensors, pressure sensors, etc., which are connected to low-power coprocessors via I2C or SPI interfaces.

[0053] (7) SRAM data temporary storage area: integrated inside the low-power coprocessor, used to temporarily store sensor initialization commands, real-time acquisition data and key event data, which can be quickly read after the main SoC is woken up.

[0054] Example 2: Workflow of an IoT-based wireless sensor system: like Figure 4 and Figure 5 As shown, the workflow mainly includes the following four core stages: Phase 1: Routine Inspection (Managed Mode). After system power-on initialization, the low-power coprocessor takes over system control. At this time, the main SoC is completely powered off (or its power supply is cut off via the power switch), entering a zero-power state. The coprocessor autonomously polls the connected sensors at a preset cycle (e.g., once per second) to acquire data such as temperature, humidity, and acceleration, and temporarily stores the data in the built-in SRAM. During this phase, the system power consumption comes only from the coprocessor's operating current (approximately 1μA) and the sensor's sampling current (typically <10μA), and the overall system standby power consumption can be controlled below 1μA.

[0055] Phase Two: Intelligent Decision-Making (Threshold Wake-up). The coprocessor compares the real-time sensor data with preset threshold rules. For example, the user can preset rules such as "temperature exceeds 30°C" or "acceleration change exceeds 0.5g". If the data does not trigger any rules, the coprocessor continues monitoring, keeping the main SoC in sleep mode; if the data triggers a rule, it enters Phase Three.

[0056] Phase 3: Instantaneous Response (Wake-up and Handover). When any of the following conditions are met, the coprocessor powers the main SoC via the power switch and wakes up the main SoC via an interrupt signal (such as a GPIO interrupt): (1) Event Trigger – Data from a certain sensor exceeds a preset threshold; (2) Timed Wake-up – The preset time for reporting data is reached (such as reporting environmental data once every hour); (3) External Trigger – An external interrupt signal is received (such as a button trigger or an external device request). At the same time, the coprocessor transmits the key event data temporarily stored in SRAM to the main SoC via the I2C interface.

[0057] Phase Four: Auxiliary Functions (Data Storage and Transfer). After the main SoC is awakened, it quickly reads sensor data and event context from the coprocessor, processes, analyzes, and packages the data, and then sends the data to the gateway or cloud via the wireless communication module. After the task is completed, the main SoC sends a sleep command to the coprocessor, which then cuts off the main SoC's power supply again, and the system returns to the managed mode of Phase One.

[0058] Throughout the entire timing process, the low-power coprocessor remains running (constantly consuming approximately 100nA-1μA), while the main SoC is only woken up when needed (consuming approximately 3-8mA). The power consumption is highest during wireless transmission (approximately 8mA), but due to the extremely short transmission time (typically <100ms), the impact on the overall average power consumption is limited.

[0059] To verify power consumption and battery life, this application also provides Embodiment Three, which compares the power consumption and battery life of the traditional system and the system of this application embodiment, as detailed below: Example 3: Power Consumption Comparison and Battery Life Analysis As shown in Table 1 and Figure 6 As shown, the power consumption performance of this embodiment in each operating mode is compared with that of the traditional solution: Table 1 Power Consumption Comparison

[0060] Taking a CR2032 button cell battery (225mAh) as an example, the traditional solution, with an average power consumption of 300μA, has a battery life of approximately 225mAh / 0.3mA = 750 hours ≈ 31 days (about 1 month). However, this patented solution, with an average power consumption of 2μA, has a battery life of approximately 225mAh / 0.002mA = 112,500 hours ≈ 12.8 years. Considering battery self-discharge and actual usage conditions, the actual battery life can reach more than 5 years, which is about 60 times faster than the traditional solution.

[0061] Taking the ER14505 lithium-ion battery (2700mAh) as an example, the traditional solution has a battery life of about 18 months, while this solution can last for more than 180 months (15 years), basically achieving the goal of "install and forget" maintenance-free operation.

[0062] To verify the industrial applicability of the methods and systems provided in the embodiments of this application, the embodiments of this application also provide an analysis of typical application scenarios, as follows: Example 4: Typical Application Scenarios This invention can be widely applied in the following scenarios: (1) Smart Agriculture Monitoring: Deploy sensor nodes for temperature and humidity, soil moisture, and light intensity in farmland, greenhouses, orchards, etc. Since agricultural areas are typically vast, have harsh environments, and are difficult to maintain, the long-lasting battery life of this invention can significantly reduce inspection and battery replacement costs. Typical battery life can reach more than 5 years.

[0063] (2) Industrial Equipment Condition Monitoring: Vibration, temperature, and current sensor nodes are deployed in scenarios such as factories, substations, and oil and gas pipelines to monitor equipment operating status and perform preventative maintenance. Industrial environments typically have adverse factors such as electromagnetic interference, high temperatures, and dust, resulting in high manual maintenance costs. The low power consumption and long battery life of this invention offer significant advantages. Typical battery life can reach more than 3 years.

[0064] (3) Cold chain logistics tracking: During the cold chain transportation of vaccines, pharmaceuticals, fresh food, etc., continuous monitoring of temperature and humidity is required. Tracking tags are usually small in size and cannot be frequently replaced with batteries. The ultra-low power consumption of this invention can ensure reliable monitoring throughout the entire transportation cycle (which may last for several weeks or even months). Typical battery life can reach more than 2 years.

[0065] (4) Intelligent building environment sensing: CO2, PM2.5, temperature and humidity sensor nodes are deployed in buildings such as office buildings, hospitals, and schools for indoor air quality monitoring and intelligent control of HVAC systems. Due to the large number of sensor nodes in the building (possibly hundreds to thousands), the low power consumption of this invention can significantly reduce overall energy consumption and maintenance costs. Typical battery life can reach more than 4 years.

[0066] Furthermore, the low-power coprocessor proposed in the above embodiments supports graphical configuration tools, allowing users to set parameters through an intuitive web interface or desktop application without writing complex low-level code. Specifically, a concrete embodiment will be used to demonstrate this: Example 5: Software Configuration and Development (1) Sensor parameter configuration: Select sensor type (I2C or SPI interface), set sampling period (e.g., 1 second, 10 seconds, 1 minute), and configure sensor range and resolution.

[0067] (2) Threshold rule setting: Set wake-up threshold and trigger conditions for each sensor, and support multiple comparison operators such as "greater than", "less than", "equal to", "rate of change exceeds", and support multiple condition combinations (such as "temperature > 30°C and humidity > 80%RH").

[0068] (3) Wake-up strategy configuration: Set the timed wake-up cycle (e.g., report once per hour), external interrupt triggering method (rising edge / falling edge / double edge), and the main SoC working time limit after the event is triggered.

[0069] (4) Wireless protocol configuration: When the main SoC is woken up, configure the wireless communication parameters, including protocol type (BLE / Zigbee / LoRa), broadcast interval, transmit power, target gateway address, etc.

[0070] Once configured, the graphical tool automatically generates the corresponding firmware code and configuration files, which users simply need to download to the low-power coprocessor and the main SoC to complete the deployment. This "low-code" development approach significantly reduces the development threshold and timeline for IoT applications.

[0071] To verify the actual effect of the present invention, a specific embodiment is used to demonstrate the comparative effect, as follows: Test conditions: Using the same hardware platform (nRF54L15 development board, SHT40 temperature and humidity sensor, CR2032 battery), temperature and humidity data were collected every 10 seconds at a room temperature of 25°C and reported once per hour via BLE. The temperature threshold was set to 30°C (reporting immediately if the temperature exceeds the threshold).

[0072] Traditional solution (single SoC polling): The nRF54L15 wakes from deep sleep every 10 seconds, reads sensor data via I2C, compares it to a threshold, and then returns to sleep. Test results show that the average current consumption is approximately 280μA, and the CR2032 battery lasts for approximately 33 days.

[0073] This patented solution (co-processing) involves the nPZero coprocessor reading sensor data and comparing it to thresholds every 10 seconds, at which point the nRF54L15 is completely powered off. The nPZero only wakes up the nRF54L15 for data processing and wireless transmission when the temperature exceeds 30°C or when the hourly reporting time is reached. Test results show an average current consumption of approximately 2.1μA and a CR2032 battery life of approximately 4.9 years.

[0074] Test conclusion: Under the same hardware platform and application scenario, the patented solution reduces the average power consumption of the system by about 99.3% and increases the battery life by about 54 times, fully verifying the technical effect and practical value of the invention.

[0075] Furthermore, this application reduces the average power consumption of the system to the microamp or even sub-microamp level, enabling IoT sensor nodes to achieve self-powering through environmental energy harvesting, and even completely eliminate battery dependence. Specifically, energy harvesting can be performed in the following ways: (1) Solar energy collection: Under indoor lighting conditions (about 200-500 lux), a small amorphous silicon solar cell (1cm×2cm) can generate a current of about 10-50μA, which is sufficient to support the continuous operation of the system of the present invention.

[0076] (2) Vibration energy acquisition: In industrial equipment monitoring scenarios, the minute vibrations generated by the operation of the equipment can be converted into electrical energy by a piezoelectric energy harvester. A typical piezoelectric harvester can generate a current of about 1-10 μA under an acceleration of 0.1g.

[0077] (3) Thermal energy harvesting: Thermoelectric generator (TEG) is used to convert the ambient temperature difference (such as a temperature difference of 5°C between the equipment surface and the air) into electrical energy, which can generate a current of about 10-100μA.

[0078] (4) Radio frequency energy harvesting: Energy is harvested by receiving radio frequency signals in the environment (such as FM radio, WiFi, cellular base stations). Although the energy at a single point is low, it can be used as an auxiliary energy source in urban environments.

[0079] The above-mentioned energy harvesting methods can be used individually or in combination, along with small energy storage capacitors or supercapacitors, to provide continuous power to the system of this invention, achieving the goals of "perpetual power" and "zero maintenance".

[0080] In summary, the method and system for reducing power consumption in IoT wireless sensor systems provided in this application have the following effects: Significantly reduced system power consumption: By introducing a low-power coprocessor to offload the daily monitoring tasks of the main control SoC, the main control SoC is in a completely powered-off or deep sleep state most of the time. The overall standby power consumption of the system is reduced from 100-500μA in traditional solutions to below 1μA, with a power reduction of up to 90%. Taking the CR2032 button battery as an example, the traditional solution provides a battery life of about 6 months, while this solution can extend it to more than 5 years.

[0081] Extended battery life: Due to the significant reduction in overall system power consumption, the device's battery life can be extended by 5-10 times with the same battery capacity, effectively solving the problem of difficult battery replacement for IoT sensor nodes. It is particularly suitable for scenarios such as remote areas, harsh environments, and large-scale deployments.

[0082] Reduced maintenance costs: The long battery life significantly reduces the frequency of battery replacements and maintenance inspections, thereby lowering labor and material costs and improving the overall economic efficiency and maintainability of the IoT system.

[0083] Achieving a true "event-driven" architecture: The system transforms from the traditional "time-driven" mode to an "event-driven" mode, only waking up the main control SoC when a meaningful event occurs or when a timed reporting node is reached, avoiding a large number of invalid data collection and monitoring operations, and significantly improving the system's energy efficiency ratio.

[0084] Improved system real-time response: The low-power coprocessor continuously monitors the sensor status and can immediately wake up the main control SoC once a threshold condition is triggered. The response latency is much lower than that of traditional timed polling solutions, ensuring timely capture and reporting of critical events.

[0085] Support for energy harvesting applications: The extremely low system power consumption makes it possible for devices to achieve self-powered operation through environmental energy harvesting (such as solar energy, vibration energy, thermal energy, etc.), and even completely get rid of battery dependence, realizing a true green Internet of Things.

[0086] Flexible architecture adaptability: The collaborative processing architecture of this invention can be adapted to a variety of wireless SoC chips (such as Nordic nRF54L15, nRF52840, STM32WB series, etc.) and a variety of sensor types, with good versatility and scalability.

[0087] Simplified software development: The low-power coprocessor provides a graphical configuration tool, allowing users to set sensor parameters, threshold rules, and wake-up strategies through an intuitive interface, and automatically generate corresponding firmware code, which greatly reduces the development threshold and development cycle.

[0088] It should be understood that the disclosed apparatus and methods can be implemented in other ways, given the several embodiments provided in this application. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules or components may be combined or integrated into another system, 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; the indirect coupling or communication connection between apparatuses or modules may be electrical, mechanical, or other forms.

[0089] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical modules; that is, they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0090] Furthermore, the functional modules in the various embodiments of the present invention can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module. The integrated modules described above can be implemented in hardware or as software functional modules.

[0091] If the integrated module is implemented as a software functional module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. 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.

[0092] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that the present invention is not limited to the described order of actions, because according to the present invention, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to the present invention.

[0093] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0094] The above is a description of a method and system for reducing power consumption in an IoT wireless sensor system provided by the present invention. For those skilled in the art, based on the ideas of the embodiments of the present invention, there will be changes in the specific implementation methods and application scope. Therefore, the content of this specification should not be construed as a limitation of the present invention.

Claims

1. A method for reducing power consumption in an IoT wireless sensor system, characterized in that, IoT wireless sensor systems include sensor arrays, low-power coprocessors, wireless SoCs, and battery modules; The method includes the following steps: Step S1: System initialization phase, used to configure and initialize the connected sensors using a low-power coprocessor via I2C or SPI interface, and set the sensor's operating parameters, sampling period, threshold conditions, and configure the wake-up conditions and power management strategy of the wireless SoC using the low-power coprocessor. Step S2: During the routine inspection phase, a low-power coprocessor is used to take over system control, so as to completely power down the wireless SoC or put it into the deepest sleep state through the built-in power switch; and the low-power coprocessor uses the low-power coprocessor to poll the sensors autonomously according to a preset cycle, obtain sensor data, and temporarily store the data in the built-in SRAM. Step S3: Intelligent decision-making stage, used to keep the low-power coprocessor running continuously during the wireless SoC sleep period, autonomously manage sensor monitoring tasks, and power the wireless SoC through the power switch and wake up the wireless SoC when the wake-up conditions are met; Step S4: Instantaneous response phase, used to power the wireless SoC with a low-power coprocessor via a power switch and wake up the wireless SoC via an interrupt signal; and use the low-power coprocessor to transmit critical event data temporarily stored in SRAM to the wireless SoC via I2C or SPI interface. Step S5: Main control processing stage, used to quickly read sensor data provided by low power coprocessor after the wireless SoC is woken up, perform data processing and analysis, and send the data to the gateway or cloud server through the wireless communication module; Step S6: Task completion stage, used to send a sleep command to the low-power coprocessor after the wireless SoC completes data processing and wireless transmission; the low-power coprocessor cuts off the power supply to the wireless SoC through the power switch, and the system returns to the managed mode of step S2, where the low-power coprocessor continues to perform daily monitoring.

2. The method for reducing power consumption in an IoT wireless sensor system according to claim 1, characterized in that, The step of powering the wireless SoC and waking it up via a power switch when the wake-up condition is met includes: The low-power coprocessor compares the sensor data collected in real time with preset threshold rules. If the sensor data does not trigger the threshold rule, monitoring continues, and the wireless SoC remains in sleep mode. If the sensor data triggers the threshold rule, proceed to step S4.

3. The method for reducing power consumption in an IoT wireless sensor system according to claim 2, characterized in that, The low-power coprocessor has a built-in programmable threshold comparator and state machine, and supports up to four sensor inputs to independently set different preset rules for each sensor. The preset rules include wake-up thresholds and / or trigger conditions.

4. The method for reducing power consumption in an IoT wireless sensor system according to claim 2, characterized in that, The preset rules include: Event-triggered mode, used to wake up the wireless SoC when the sensor data exceeds a preset threshold; or / and, A timed trigger mode is used to wake up the wireless SoC when a preset timed reporting point is reached; or / and, An external trigger mode is used to wake up the wireless SoC when an external interrupt signal is received.

5. The method for reducing power consumption in an IoT wireless sensor system according to claim 1, characterized in that, The low-power coprocessor has a built-in 128-byte SRAM for temporarily storing sensor initialization commands and key event data, ensuring that the main SoC can quickly obtain complete context information after waking up, reducing processing latency after waking up.

6. The method for reducing power consumption in an IoT wireless sensor system according to claim 1, characterized in that, The power switch is integrated inside the low-power coprocessor or implemented through a separate MOSFET. The coprocessor controls the on / off state according to the wake-up condition to achieve on-demand power supply for the wireless SoC.

7. An IoT wireless sensor system, characterized in that, include: A sensor array, including at least one sensor, for acquiring environmental parameters or physical quantity data; A low-power coprocessor connects to the sensor array via an I2C or SPI interface. It is used to autonomously manage the configuration, polling, and data acquisition of the sensors, perform threshold comparison and wake-up decisions, and has built-in power switch and SRAM data storage functions. The low-power coprocessor adopts subthreshold design technology, with a standby current of less than 100 nanoamps and an operating current in the microamp level. The wireless SoC connects to the low-power coprocessor via an I2C interface and is used to perform data processing and wireless communication tasks in the wake-up state. It supports multiple wireless protocols such as Bluetooth Low Energy, Zigbee, LoRa, and proprietary 2.4GHz. A battery module is used to power the low-power coprocessor, wireless SoC, and sensor array. The low-power coprocessor runs continuously during the wireless SoC's sleep period, autonomously manages sensor monitoring tasks, and only powers the wireless SoC and wakes it up via a power switch when the wake-up conditions are met.

8. The IoT wireless sensor system according to claim 7, characterized in that, The sensor array includes one or more of the following: temperature and humidity sensor, accelerometer, gyroscope, light sensor, pressure sensor, CO2 sensor, and PM2.5 sensor, and is connected to a low-power coprocessor via an I2C or SPI interface.

9. The IoT wireless sensor system according to claim 7, characterized in that, The system uses a graphical configuration tool of a low-power coprocessor to set parameters, including sensor parameter configuration, threshold rule setting, wake-up strategy configuration, and wireless protocol configuration. After configuration, the corresponding firmware code and configuration file are automatically generated.

10. The IoT wireless sensor system according to claim 7, characterized in that, The IoT wireless sensor system has a standby power consumption of less than 1 microamp.

Images