Coin cell-powered OpenThread sensor board can send data every 20 seconds for three years

Monkey Store’s Thread Sensor Tag is a pressure, humidity, temperature, and light sensor that connects to the OpenThread network, and is capable of transmitting MQTT/UDP data every 20 seconds over a period of around three years from a single coin cell battery.

As a reminder, OpenThread is an implementation of the Thread IoT network protocol that was unveiled in 2016 by Nest Labs (now Google/Alphabet). This has not been widely used so far, but we did write about MKR SharkyPro development board with OpenThread support via STMicro STM32WB5MMG wireless module earlier this year, and Monkey Store is telling us both Google and Apple are working on devices with support for the IoT protocol.

Thread Sensor Tag specifications:

  • Wireless module – Minew MS88SF2 based on Nordic Semi nRF52840 multi-protocol 2.4GHz wireless Cortex-M4 microcontroller
  • Sensor
    • VEMLS6030 I2C light sensor
    • MS8607 pressure, humidity, and temperature sensor
  • I/Os – 7x through holes with Tx/Rx, 1x GPIO, 3.3V, GND, and CLK signals
  • Misc – RGB LED, user and reset buttons
  • Power – Coin cell battery
  • Power Consumption
    • Deep sleep – 3.19µA
    • Sensors acquisition – 54 µA
    • Wakeup cycle 1.7 sec including RF – 125 µA
  • Dimensions – 36×33 cm

We’ve said the board transmits sensors’ data over MQTT/UDP in the introduction. But more exactly, the sensors and battery data is sent over UDP to save power, and a Border Router running a Python script packages them into an MQTT message sent to a platform like Node-RED or an IoT cloud service for visualization and processing.

Data path
Data visualization in Node-RED

The Thread Sensor Tag is open-source hardware with the KiCAD design files and Zephyr-based firmware available on Github, and detailed documentation, including how to set up a Raspberry Pi as a Border Router, can be found on the Home Smart Mesh website.

The Thread Sensor Tag used to be sold for $49.95 just two weeks ago, but it can now be purchased for $29.95 on Tindie.


Share this:

Support CNX Software! Donate via PayPal or cryptocurrencies, become a Patron on Patreon, or buy review samples

35 Replies to “Coin cell-powered OpenThread sensor board can send data every 20 seconds for three years”

    1. The udp mqtt we used in the sensorTag software stack is even simpler than the mentioned mqtt/udp reference. I simply send a text payload that consist of “topic{json_payload}” that’s all, it is only intended for sensors broadcast on a broquer configured on server side. The python script running on the gateway is only few lines of code, see the script from the repo link.

  1. Ten years on coin cell using BLE….

    Low-Power PIR Motion Detector With Bluetooth Smart & 10-Year Coin Cell Battery Life Reference Design

    Monkey Store could likely use some of the techniques from this TI design to extend the battery life of their device. This design uses some very low power chips.

    1. I could not see the exact parameters/assumptions for the 10-year battery life though.
      The sleep current (1.63 uA) is quite lower, and Tx appears to be lower too (1.57 mA for 56.66 ms vs 0.125mA for 1.7s), but there’s probably fewer data transmitted on the TI device.

      1. TI sends 168 messages a day. So once every 9 minutes. This timing is variable and driven by events the PIR sees.

        There is some trick in the power supply where they disconnect the battery for long periods and run off from capacitors during sleep. I think that is the key to getting 10 years of life.

        This reference design will work as advertised. TI is an extremely good engineering company.

        Assumptions on Page 9

        1. At such low currents I think it becomes envisionable to partially recharge your capacitors by harvesting current from nearby RF emissions, by using a tiny solar panel, or even by leaving a wire hanging to collect static electricity 🙂

          1. Solar panels indoors yield very little power, you quickly need to get pretty large panels to get anything worthwhile, and the size, cost and complexity will far outweigh the simplicity of simply picking the right battery. But I would love someone to tell me otherwise 🙂

          2. We used to have desk calculators running off 3cm² panels. It’s possible to yield a few microwatts out of them indoors (especially the brown ones, I think they are the monocrystaline ones).

        2. Your second link (with the assumptions on page 9) is for a different use case with a sub-1 GHz link and a different chip (and ACKs and retransmits and keepalives). The assumptions for the BLE case are on pages 2 and 32 of your first link. Note that there are no ACKs or retransmits here, no periodic BLE advertisements either, and a very minimalist (and short) advertisement on events, only an ON event (start detecting movement) and an OFF event (no longer detecting movement). Not a real-life use case, by far.

          1. There are pro and cons here. Do sensors really need to continuously advertise? I don’t think they do, who is listening? And do sensors really need to get ACKs to their events? I don’t think that they do. There are even technical problems with that, what if multiple devices listening to the sensor? Note that as someone moves around the PIR is going to trigger multiple times sending multiple events.

            A big pro — 10 year battery life.

            For real-life your would proxy the sensors in a nearby mains powered device. Those proxies make the sensors look like permanently connected devices. The proxy would record the events allow them to be queried at will by other network nodes.

          2. If you have a BLE sensor, you probably want it to advertise (even infrequently) so you can connect to it to manage it (either from a phone or from a gateway).

            For a sensor sending data where it’s not important if you miss some (e.g. an electricity, gas, or water meter, which is anyway always increasing) having unacknowledged packets is not an issue. Probably the same for environmental data (temperature, humidity, etc. like in the post’s sensor). This is why those are the ideal scenario for LoRaWAN where ACKs are often an issue.

            For a PIR detector, getting the data timely (and at least getting it at all) is usually much more important. Details vary on the exact use case (intrusion alarm, occupancy measurement, occupancy detection for flexible workplaces…), but you can’t just consider that it doesn’t matter if the info is lost. You could either broadcast the info at regular intervals (so that even if the original event packet is lost you get the info at the next broadcast), or you could need ACKs.

            PIR detectors will most likely be linked to a network to trigger some action, even if it’s just logging presence (as opposed to sensors where you just read the data when you open the app on your phone), so with mains-powered gateways, proxies, access points or whatever you want to call them. You would indeed expect a specific gateway to send the ACK.

            The other TI scenario (the second link above) which uses a sub-1 GHz radio actually includes ACKs, retransmits, keep-alive packets, and so on. Not sure why they didn’t include those in the BLE version (especially since a lot of stuff was copied-and-pasted from one to the other, the BLE doc still has plenty of references to the sub-1 GHz version).

          3. The PIR triggers multiple times as the motion occurs, so it will send multiple packets.

    2. Jon,

      I am not sure if TI included the power consumption of the PIR sensor. From the specs of the parts that TI used, they are about 1.6 uA not including the PIR sensor. The PIR sensor has to be on to generate the wakeup signal.
      A general PIR sensor power consumption could be 1-3 w. There are low power PIR sensors with current down to 1uA, which becomes expensive in this level.


      1. Some of the cheap ones use very low power. I used to have one in a cheap AA battery-powered outdoor lamp close to my door. It worked for 3 years before something died in the lamp, turning the LED always on and depleting the battery in a few days.

      2. 1-3W? Even ultra cheap sensors are 4 orders of magnitude below that. A cheap PIR sensor uses about 50 µA, which amounts to about 165 µW at 3.3V. Granted, 50 µA is a lot more than the 1.6 µA quoted, but far from 1-3W.

        Also remember that the PIR sensor itself (the part that receives the IR and emits a signal) does not need any power, it’s by definition passive. It’s what little circuitry beyond that to make it into a usable signal (amplifier and comparator) which needs current, and in their case they reduced that to about 0.5 µA, so I believe it’s included in the total sleep quoted (since the CC2650 is 0.1 µA in shutdown and 1 µA in standby).

        1. Willy, Jacques, Jon,
          Thanks for the information. I got the PIR number from the quick search. If the module is passive, then it is possible. The PIR module that TI used does not mention power consumption or leakage current.
          The two power Amps consume 346-471nA each; two comparators consume 150nA. When we add these four parts up, the total is 1uA minimum not counting other current loss such as leak current.
          A quick search gives the lowest power consumption of 1uA of the PIR sensor. If the 1uA is the current consumption when it is on, and some leakage current when it is off, then TI’s number could be correct.

      3. The PIR power is included in the TI numbers. Note that TI did not use a PIR module they directly interfaced to the PIR chip.

    1. Projecting from the TI numbers this Monkey Store device is only going to make it three months, not three years.

      1. Mine already runs longer then that – but the device does not route! Its a sleepy device of course. It wakes up every 3s in the currently running setup and sends its data for already longer then 3 month. If we make that 30s instead of 3s (which was just for testing) it will last even longer. Thread is actually quite low power and fast as well, the connection is done in no time. The range is debatable tho – its bluetooth range, which is not much.

    2. It might be feasible but very challenging. As a comparison, the new ultra-low power wireless vibration sensor SVT200-V can acquire samples, analyze data, encrypt data and send result every 2s up to five years:
      SVT200-V’s battery capacity is 1200mAh (use 1100mAh for battery life estimate). Idle current is 2.1uA.
      If SVT200-V sends result every 20s, then the battery capacity can be reduced to 200mAh and lasts five years (2 years extra). But SVT200-V is not using thread. Thread consumes higher power, so it is challenging.

    3. Hey – I am the creator of that Sensor Tag. I actually was not expecting an article about my hardware tbh. 3 years on a coin-cell isn’t that impossible, the Tag is running already multiple month now at home and I am still at 2.8V and this Firmware version actually sends the packets every 3s!! Thread was actually made to be energy efficient.

    4. 3 years is a rather conservative prediction I made, we used a power profiler kit device PPK2, to measure current consumption at 100ksps, the tools shows the consumption at different stages, sleep, wake up, rf,… the rest is pure mathematical extrapolation. A current stress test with broadcast every 3 seconds shows consistent measures with those predictions.

      We also created a forum to discuss with the community and get feedback from different people. Feel free to have a look at the details there. It is even the same hw that can achieve 10 years of battery life, but I did not want to pretend that because that would not match what we envision as a realistic and practical home automation use case. With 20 sec sampling and 0.01° precision, you can monitor effects of every door and window opening, with 3 sec sampling, even detect a light breese of wind, that opens the door to a multitude of analysis possibilities.

  2. Even though I am the person who added 802.15.4 (which became Thread) to the Linux kernel, I am no longer a major fan of it. My current preferred design is BLE back to a nearby, mains powered proxy device. I am definitely not a fan of battery devices as routing nodes in a mesh. Meshes are fine with mains power and they have their places — a common mesh is BLE between light bulbs. The main reason I prefer BLE is that you can configure the initial security for the devices using your phone without needing a 802.15.4 gateway. Another caveat, an unstable mesh is extremely difficult to debug.

    1. Hi John,
      thank you for the hint and the feedback, I developped the sw for the SensorTag, and as you noticed, the hw is BLE and 802.15.4 capable, we would highly appreciate if you’d like to join the open source project and contribute to a BLE version or at least its architecture and concept.
      Before I use openthread, I developed my own custom mesh protocol in the past, which I still use in a UWB application where a controlled rf scheduling is very important. 802.15.4 did not became thread by the way it is only a PHY that’s used by Zigbee too. The charm of thread or openthread is that both uC and server can use standard networking tools (sockets,…) no longer mixing the transport with the app. Mesh is only needed in a home automation with large area cover, imagine an alley with 10 lights, you can’t have a direct BLE connection for each. Although BLE is a user smartphine centric protocol, it also can add a mesh transport, but I could not find reasonably easy examples.
      After all, this initiative is more about hw, I could not find that many sensors based on nRF52840 thread capable chips, so we made one, we’d be happy if the community use it for BLE or Zigbee or custom mesh.

  3. Looks more like 5 swiss francs in size, unfortunately one would have to open the board in kicad or gerbview to get the dimensions.

    Quite funny still people are playing this x years on a xyz-cell.

    We did our thesis about a zigbee gadget on 4AA cells I guess we calculated 3 years too.

    The project never materialised after the thesis…

    1. > Looks more like 5 swiss francs in size, unfortunately one would have to open the board in kicad or gerbview to get the dimensions.

      Based on the 2.54mm holes at the bottom, that looks like 34.3mm or 1.35 inches wide for me.

    2. The dimensions are actually 36x33mm 🙂

      We are not testing the device for 3 years already, thats is true – we simply calculated the consumption which we measured with the PPK II from nordic (I highly recommend it, nice device). for one cycle (sleeping + collecting data + open thread connect + sending udp packet) the device draws 125uA and it takes around 1.7s.

      You can read more about it here:

      1. Nordics are definitely very nice devices and in general use should be equivalent to the TI devices. But if you are going to for a record on battery life, then the TI designs are better. I have many boards with chips from both vendors.

          1. TI has a lot of low power WAN chips. In general what is most interesting about the TI stuff is their app notes and reference designs. They tend to do extreme reference designs. Dig though all of the ones saying 10-year battery life, there are multiple designs.

            TI has a multi-protocol version of chip than can run Thread or BLE too.

            You can buy the reference boards straight from TI if they have made them available. They are usually less than $100.

            Look for the SensorTag too. That is one of their BLE/Thread chips with about a dozen different demo sensors on the PCB.

        1. The sleep current of the nRF is 3uA which is really great. Does TI also offer ready made modules which already contain an pcb antenna etc.?

          1. I do not believe TI makes the modules. But.. there are dozens of vendors selling modules based on TI chips. The quality of those modules varies all over the map so you will have to evaluate them individually to make sure they used low power peripheral components.

Leave a Reply

Your email address will not be published.