Hand tools and fabrication machines
The Internet of Things and all its previous forms and acronyms (Wireless Sensor Networks, M2M) had something in common: the low-power requirement.
A low power application and device, from my perspective, is the one you forget to charge eventually, until politely asked by the device to do so. Having power-hungry devices nowadays affects both possible applications in terms of maintenance and attendance costs, efforts and pain. It also affects the way we interact with the applications, even changing our behaviour and routines: running everywhere with a mobile charger or having the night-stand populated with several devices charging at night are small examples.
Even if modern ARM processors (such the RE-Mote Cortex-M3) are designed to be low power, how low-power are really? The CC2538 has down to 1uA in its lowest power mode (retaining 16KB RAM out its 32KB), is this what we have in mind?
On the long run having a device running on 1uA and only sending data frequently (every 10 minutes or so, drawing 45mA over 100ms or so) yields in 84,9uA average. Using regular 2xAA batteries (with a capacity around 2500mAh) this means a battery life of 7123 hours (calculated with DigiKey calculator), around 28 months.
Further reducing the current draw for the lowest consumption down to 170nA reduces the average to 76.7uA, more or less 31 months (>2.5 years).
An obvious comment is: we can further save on the active time (45mA) and have an even lower power consumption, so why bother lowering the minimum power consumption anyway? Well because is easier to achieve this, there are radio duty cycling schemes that bring down the 40mA to 10mA already... but when you have to power your application from the most unexpected energy harvesting sources, every Joule matters.
Note also the above 1uA consumption is just the CC2538, there are normally several components in a hardware platform (you can quickly be in the hundreths of uA, even mA's), connected sensors, etc. Having to implement hardware solutions to disable peripherals and external devices can quickly increase both prices and complexity of the design.
The RE-Mote implements a
power management block, featuring a
shutdown power mode that effectively power downs the node to 170nA. The only running components are a configurable nano timer gating the external battery, and a Real Time Clock Calendar (RTCC) programmable to also awaken the application at a given time and date.
Is fairly easy to think of situations in which we only require to send data at a lower frequency, such as temperature, humidity and other slow-changing variables. Also as we have plenty of digital sensors it is quite common to have interruption-capable pins to generate an alert i.e if a given threshold is reached, being possible to use one of these interruptions to awake the system off shutdown mode.
In the next example a RE-Mote sends a message every minute and seconds afterwards goes to
A Second RE-Mote is kept running with the radio on to receive messages from the sleeping node and printing them to console over the USB cable.
shutdown mode requires the RE-Mote to be running on external batteries (good thing the RE-Mote also charges the battery when connected over USB). When powered over USB the RE-Mote ignores the power management.
Flashing the sleeping node
To compile and flash the RE-Mote with the power management block, go to the
examples/zolertia/zoul directory and run
make test-power-mgmt.upload , it will automatically pick up the USB port in which the RE-Mote is connected, compile and flash the application.
If you need more information on how to install Contiki, flash the RE-Mote etc, go to Zolertia Resources page.
Below is the debug console output of the RE-Mote (over USB). Disconnect the RE-Mote off the USB, and power over external batteries.
Contiki-3.x-1903-g5e14c22 Zolertia RE-Mote platform Rime configured with address 0f:6c Net: Rime MAC: CSMA RDC: ContikiMAC PM: FW Version 0 Firmware PIC-Power Manager Version: V0.0 Status -> Nano Timer enabled Goodnight!
Flashing the receiving node
As the receiver node you can use the zoul-demoexample in the
examples/zolertia/zoul directory, just run
make zoul-demo.upload , it will automatically pick up the USB port in which the RE-Mote is connected, compile and flash the application.
Below is the log of the
zoul-demo example (with timestamp) with 2 radio events from the
1450793712 Contiki-3.x-1903-g5e14c22 1450793712 Zolertia RE-Mote platform 1450793712 Rime configured with address 0e:74 1450793712 Net: Rime 1450793712 MAC: CSMA 1450793712 RDC: ContikiMAC 1450793712 Zoul test application 1450793736 Counter = 0x00000002 1450793736 VDD = 3166 mV 1450793736 Temperature = 32619 mC 1450793736 ADC1 = 2312 raw 1450793736 ADC3 = -2147483648 raw 1450793740 *** Received 1 bytes from 15:108: '0x000a' (...) 1450794040 Counter = 0x00000028 1450794040 VDD = 3137 mV 1450794040 Temperature = 33571 mC 1450794040 ADC1 = 2392 raw 1450794040 ADC3 = -2147483648 raw 1450794040 *** Received 1 bytes from 15:108: '0x000a'
Notice the radio events are 5 minutes between. This is the
shutdown period, that is, the configured time the nano timer is set to wake-up the application off the
shutdown mode, allowing the application to be restarted in this given period. The
shutdown period is also the time in which the RE-Mote will be powered-off by the power management block. A given application can enter the
shutdown mode earlier by invoking the following macro:
To change the
shutdown period (default is 1 minute) you need to replace a resistor as shown below.
R47 resistor is the one to be changed, its values allows to select a
shutdown period from 100ms to 2 hours. The value of
R47 can be found in the Texas Instruments TPL5110 datasheet.
Below are the most common values:
- 500 Ohms (100 ms)
- 2.5K Ohms (500 ms)
- 5.202K Ohms (1 second)
- 22.021K Ohms (1 minute)
- 42.887K Ohms (5 minutes)
- 57.434K Ohms (10 minutes)
- 92.233K Ohms (30 minutes)
- 170K Ohms (2 hours)