​Updated Low Power Home Network Weather Monitoring

This updated version of the Low Power Home Network Weather Monitoring relies on the Launchpad SensorTag kit CC1352R or LPSTK-CC1352 for the nodes.

The hub is a LaunchPad CC1352, connected to Node-RED running on a main computer through serial.

The radio operates in the sub-1 GHz band. The hardware was sampled by Texas Instruments.

Hardware

The Launchpad SensorTag kit CC1352R or LPSTK-CC1352R ​is the third iteration of the SensorTag, after the CC2540 SensorTag and the SensorTag CC1350. 

The Launchpad SensorTag kit CC1352R inaugurates a new form-factor with a 40-pin connector so it can be expanded with the BoosterPack boards to plug-in on top.
​
Two sensors are used:
  • HDC2080 humidity and temperature sensor by Texas Instruments,
  • OPT3001 ambient light sensor by Texas Instruments (except when a display is added).

The display is a modified Sharp Memory LCD BoosterPack 128, as the default configuration suffers from major conflits on pins allocations.

Software

The project uses updated versions of the libraries, including ​
EasyLink still remains very basic and doesn't provide any QoS feature. As a result, some packets are lost.

The dashboard is managed by Node-RED. The hub now sends the time, so the clocks of all the nodes are synchronised.
​
The dashboard now lists the time stamps from each node, plus mean and variance for each series of measures as statistics.

I tested the consistency of the sensors by placing 4 nodes in the same room. Temperature variance is nil, while humidity variance is often high. 

Additionally, the dashboard displays voltage and signal strength.

Low Power

Measuring low power with EnergyTrace faced unexpected challenges from both CCS 9.3 and the alternative command-line stune utility.

I submitted a ticket at the E2E forum and received a prompt answer. It appears the USB XDS110 debug probe is more stable than the built-in programmer-debugger. Similarly, the command line utility stune requires fewer resources.

​The main surprise is the baseline current consumption, close to 2 mA. Why is it so high? Is is due to the fact the LPSTK-CC1352R uses two buses, I²C and SPI, to communicate with the sensors?

Turning off all the sensors and exiting I²C and SPI didn't solve the issue. It seems I am not the only one to face this issue: it has been reported at the E2E forum under Large standby current consumption (1.7 mA) with LPSTK-CC1352R as sensor.
After some help from the E2E forum, I managed to reach a power consumption while in idle mode consistent with those expected.

  • When idle, the node only requires 0.0267 mW / 0.0081 mA. 
  • Acquiring and sending data take 350 ms and need more power.
The active part runs every 10 minutes and  includes three main actions:
  • The node acquires the measures from the sensors;
  • The node sends the data to the hub, and 
  • The node keeps reception open for 66 ms in case the hub sends the correct time for synchronisation. 
The whole process takes 350 ms and peaks at 13 mA.
The battery life for the same CR2032 almost doubles, reaching 22 months compared to more than a year from the previous generation, according to the EnergyTrace estimate.

This could be explained by two main factors:
  • Idle mode requires 0.0267 mW, almost half of the 0.0505 mW from the previous generation. 
  • ​Active part, including acquisition and communication, only takes 350 ms, much faster than the 607 ms from the previous generation. 

Conclusion

Porting the project from the CC1310/CC1350 to the CC1352 was easy, and so was adding the clock synchronisation. Low power requires extreme caution for its implementation.

However, EasyLink appears as too basic, especially for the lack of QoS resulting in loss of packets. 

With all the focus on home and building automation, let's hope some popular and emerging standards are going to be available for rapid prototyping with Energia. 

Links


Posted: 04 March 2020
Updated: 14 March 2020