Monitoring conditions at a remote location is a typical IoT application. Let’s assume that, for example, you want to be aware of the air quality of a certain site. But unfortunately, it turns out that this specific site is not properly covered by a WiFi network, i.e. Internet connectivity is questionable. And there might be no power outlet at this location either. In this case, an IoT device should be powered by a battery and connected to a cellular network in order to ensure reliable operation and online connection. On top of this and for maximum effiency, suitable IoT devices should be maintenance-free, i.e. project owners want to avoid cost of efforts to recharge or replace batteries during IoT device lifecycle, i.e. you need an IoT device designed for 10yrs battery life.
This requirement is new and a real challenge for cellular networks which – originally – have not been invented for these kind of use cases. This is why 3GPP has to take a close look at IoT needs in an effort to address this important target market and to incorporate IoT features into network specifications. Latest results are LTE-M and NB-IoT standards which work as 4G-extensions and allow re-use of existing LTE infrastructure. New LTE-M and NB-IoT power saving mechanisms are supporting IoT use cases requiring low data rates with no need for immediate and permanent device availability (see recent article here on www.chip-info.com: Cellular Network Modules for IoT).
Design Concept
In order to achieve maximum battery lifetime, proper power management orchestration of three main components is required: network module, host MCU and sensor. Master MCU role is alternating between two of them: IoT application program is excuted by the host MCU, but wake-up management is handled by the cellular module in cooperation with the NB-IoT network. For this reference design a Bosch BME280 environmental sensor is used as an example. But same design concept also works fine with other low-power devices as long as standard interfaces like I2C or SPI or GPIOs are used. For example, you can use a smoke detector or fluid level meter or time-of-flight sensor for tracking presence of an object.
Figure 1: Reference Design – Block Diagram (© chip-info.com)
Our IoT device is based on a u-blox SARA-N2 NB-IoT low-cost cellular module for LTE Cat NB2 networks. For Internet connectivity an external LTE antenna is required. The device is powered by one or two 3.6V Li-ion 18650-sized batteries with a user-configurable total capacity of more than 6000 mAh. Data transmission control unit (i.e. so-called “DTE” = Data Terminal Equipment) and local host MCU of the IoT device is a simple 8-bit MCU, e.g. a low-power and low-cost PIC16F15313 with 3.5 kB onboard flash memory in a small 8-pin SOIC package. This MCU controls operation of the cellular network module and runs customer-defined IoT application software, e.g. to manage function of the peripheral sensor. In our case, a Bosch BME280 environmental sensor (temperature, humidity, pressure) is connected to the I2C bus of the host MCU. PIC16F15313 has an internal clock source of 32 MHz with a user-configurable system clock divider allowing to balance power consumption vs. performance according to application requirement according to specified 32mA/MHz@1.8V during operation.
Device deployment is kind of challenging because target locations might be unknown or unpredictable. Individual configuration and activation of each IoT device might be required. After delivery to target location, power up of the IoT device should reset all components automatically (see Figure 2: Program Flow, ❶) and each IoT device should be ready for manual installation ❷.
Note: Manual installation will require a dedicated service interface (e.g. USB) which is not covered by this reference design.
Figure 2: Program Flow (© chip-info.com)
After power-on reset (or after using reset button), the host MCU should be able to communicate with the network module (aka “modem”) via UART interface and configure it according to application requirements ❸. In particular, the host MCU firmware will have to make sure that the module connects to the closest local NB-IoT network tower covered by subscription plan of chosen MNO partner and corresponding SIM card. This process is important because distance to cell tower will determine device power consumption (see paragraph ”Estimation of Battery Lifetime”). Required transmission power should be as low as possible and network module configuration should be adjusted accordingly during device installation.
Our design concept is based on the idea that all local IoT actions are handled during a periodic activity time slot. After installation (i.e. after steps ❸ and ❹), the IoT device program will loop endlessly, no deviation from this flow is planned, and IoT device will not be reachable during PSW periods.
Note: If needed, the application can react to incoming network messages and wake up the device immediately. For this purpose, a customer design can take advantage of dedicated pin CTS/RI (RI = “ring indicator”) to send an interrupt to the host MCU.
As soon as the initial setup process has been finished and verified, the host MCU can prepare the IoT device for field operation. For this purpose, in step ❹ a set of AT commands will configure modem to enter PSM mode (see paragraph “PSM and eDRX Power Saving Modes”), to remain in PSM mode as a default (5µA typ.) and to wake up periodically automatically after x hours (configurable). The module will have to negotiate related timing parameters with connected NB-IoT network so that requests to the IoT device will be buffered during agreed inactivity periods. When done, cellular module as well as host MCU will enter power down modes ❺ as a default condition during product lifetime.
In fact, the NB-IoT PSM feature is used to wake-up the complete IoT device. Configured PSM wake-up schedule of the network module ❻ will trigger periodic activity slots for transmission of actual environment data to a preconfigured recipient, e.g. an IP address. This process is repeated every y hours (configurable) resp. according to application requirements. And it should be kept as short as possible because power consumption will dramatically increase when radio is turned on. Second intention is to use activity periods also for firmware updates or any new device configuration data, e.g. network parameters (see Figure 3: IoT Device Activity Cycle).
Module PSW wake-up event ❻ is used to trigger the local host MCU via interrupt pin which is taking control of all further actions during IoT device active period. As a first action, the local MCU will handle pending network requests to the IoT device, if any ❼. Then, local host will initiate a single measurement via I2C bus ❽. This request will wake up BME280 from default sleep mode (0,1µA) and takes around 1s to execute. As soon as sensor measurement data has been received, host MCU will submit AT commands to request transmission of IoT data according to selected protocol, e.g. MQTT ❾.
Now, for this activity slot, all planned tasks have been executed, and the IoT device is ready to re-enter idle mode until next PSM wake-up event will occur. For this purpose, host MCU will reactivate module PSM mode 🅐 and return to sleep itself 🅑. Then, application program loop will restart at ❺.
Figure 3: IoT Device Activity Cycle (© chip-info.com)
Estimation of Battery Lifetime
Keeping activity periods as short as possible is key for lowest power consumption. Most of the time, all active components remain in sleep mode:
- SARA-N2: 5µA typ. (PSM mode)
- PIC16F15313: below 1 µA
- BME280: 0,1 µA typ.
Even during active periods, power consumption of BME280 and PIC16F15313 are moderate:
- PIC16F15313: 8 µA @ 32 kHz (internal clock) resp. 32µA/MHz after reduction of clock frequency
- BME280: 3,6 µA
Most power is required by SARA-N2 in active mode (6 mA) and esp. when radio is turned on. During receive mode, current consumption will be 46 mA. During transmission, output power will be adjusted according to antenna characteristics and local environmental conditions, i.e. distance to cell tower, building density, noise, etc. For example: output power: 3dbM (2mW) → current: 78mA; 13 dBm (20 mW) → 100mA, 23 dBm (200 mW) → 220mA.
After module wake-up to active mode, reading sensor data takes 1s and occasional reception of pending messages might require some extra receive time (See Figure 3: IoT Device Activity Cycle). So, for our estimation, let’s take 10µA as the total current during idle period. And let’s assume that an overall duration of 2 seconds for each activity slot will be sufficient to reactivate an existing network connection and manage transmission of a few bytes at 100mA current consumption per second.
For our estimation we consider use of a Li-ion battery with 3000mAh. Two scenarios:
- IoT data is being transmitted once every hour.
- IoT data is being transmitted twice a day, i.e. every 12 hours
Calculation:
- Average current: (0,01mA * 3598s + 100mA * 2s) / 3600s = 0,065mA à 1923 days = 64 months = 5 years + 3 months
- Average current: (0,01mA * 12 * 3598s + 100mA * 2s) / 12 * 3600s = 0,015mA à 277 months = 22 years + 10 months
Timing parameters can be adjusted according to application requirements. Max. power consumption also depends on individual IoT device location. Final adjustment of software configuration during installation at deployment site is recommended. And, last but not least, our design offers an assembly option for one extra 18650 battery which allows to increase total battery capacity to more than 6000mAh.
Schematics
Figure 4: IoT Device – Schematics (© chip-info.com)
Board Layout
Figure 5: Board Assembly Layout (© chip-info.com)