Be prepared to new Ultra Low Power Arduino Wireless Sensor Node

Why this new project ?

For some time being, I researching a way to have to have a kind of “universal” Arduino node sensor. When I say universal, I’m talking about connecting to it several sensors type (Temperature, Humidity, Lux, … such as LDR, NTC, PTC, DHT11, DHT22, DS18B20, I2C sensors). I found a lot on the net, some very interesting and fine products such as Moteino, Anarduino miniwireless, Jeenode, but as today, none are especially made for ultra low power with long battery life when using classic battery such as one AAA, CR2450 or CR2032 Cell Coin. So not using Lipo, or any rechargeable batteries.

At 1st research I tried lot of them, it works fine, but as soon as you want to power them with classic battery (one AAA, CR2032, …) you’re facing other challenges, be able to maximize the battery life and also be able to send wireless frames until battery is reaching it’s end of life.

I’ve also tested several RF modules such as RFM12B, RFM69, NRF24L01 and results are the same, this is logical since the power consumption reach the max when these modules are sending data over the air.

Challenges faced off.

Of course the battery life depends on accurate and optimized code for sleeping mode but during my prototyping I also saw that the conception of certain type of battery can cause node stopping sending data even if the battery has enough power (voltage). This is due to the internal resistor (IR) specially on cell coin battery (see this post for detailed information). When sending data, you may need to have peak current that will create a drop voltage on the internal resistor, this voltage drop can be large enough to stop wireless module to send frame. For example, imagine a CR2032, with 20 Ohm internal resistor. Let’s say that battery is running for some time and it’s voltage it’s about 2.6V, this mean the battery if far away from it’s end of life. When the node activate the wireless module to send data (example RFM12B) the consumption can reach 25 mA, this mean that 25 mA across 20 Ohms IR drop 0.5V, this drive your powered node driven by 2.6V – 0.5V = 2.1V which is under the RFM12B minimal voltage (Datasheet says 2.2V) and thus, this does not work anymore (in fact your node is working, but is unable to transmit frame to a gateway).

How to achieve the challenges ?

This is why decided to try to create a wireles node that remove all these limitation and that works very long time, until battery really reach it’s end of life. The challenge was strong enough but I can say now that it has been reached. I’ve been working and testing different prototype and technique until I found “the one”. I do not know if it’s the best, but this new one works fine. For this I also needed to change lot of things over “basic” Arduino wireless node. What I’ve done is detailed on the following steps :

  • Redesign and create a new hardware Arduino board to provide Ultra Low Power features and reduce the idle mode consumption to minimal
  • Change Optiboot bootloader to use the new hardware, reduce current consumption at boot up and add some features
  • Write rock solid Ultra Low Power code to drive multiple sensors and send node data over the air. Add configuration of sensors type and node stored into the node eeprom so you won’t need to flash firmware to change any settings of the node.
  • Create a Hardware Gateway (Arduino receiver based) to receive and do job with received information from sensors. The gateway can be of course any Arduino with wireless module (same of the sensor node of course), no specific need on this point, but I created PCB to fit into Raspberry Pi connector or TPLink routers such as WR-703N or MR-3022.
  • Write Gateway code for Arduino receiver that will send data over the serial
  • Create scripts on gateway that pool serial and to send data (emoncms for example) to have some graph. Of course, emoncms it’s just an example, you will be able to do whatever you want with the gateway and use any of existing piece of software capable of grabbing data received from serial port, such as node-red, python, perl,… . It’s really open to any existing software such as home automation.

Challenges reached.

I’m currently working on the 4st prototype generation and near to the mass production. Since it’s really a new product on the market (I did not found any one existing but if you know one, I will be interested to see), I hope it will wake up some kind on interests on the community. Of course if it can do a lot, it can do less, so ULPNode has also been designed to work in always powered mode (using it as a Gateway for example) or in always receiving Node mode (to be able to remote control things when receiving specific commands).

All the project will be open source, hardware and software, I will release the schematics and the code as soon as I will have the first batch of node produced.

The product will we called ULPNode, for Ultra Low Power Arduino Node and here are the features currently working on ULPNode :

  • Standalone self powered hardware management engine that can also be controlled by the ULPNode firmware. This is the core and the most advanced ULPNode feature.
  • Multiple battery support (CR2032, CR2450, one AAA, CR123) depending on what you wand to do with the node.
    • For example CR2032, CR2540 or one AAA works fine for “sending only” node, It’s the lowest consuming node and ULPNode was designed for this mode.
    • But if you want add more functions such as a node always listening to react to incoming data, it’s better to have stronger battery such as CR123, because this mode consume much more power (due to the radio module that is always powered)
  • High range of input voltage, for always powered Node for example, or Node powered by Lipo (that can reach 4.2V on the input)
  • Can work even with battery indicated as “dead” or “low bat” by other devices (Oregon Scientific sensors for example), this make this product type as “Green” and working with old battery so it won’t cost you any $ to power the module if you can grab some old battery.
  • Radio module use 8 pins standard NRF24L01 connector type and RFM12B/RFM69C solder pad on bottom side. You will be able to put directly a NRF24L01 radio module but I will make available RFM12B and RFM69 boards (with flash memory) that fits on this connector.
  • Will work with classical RF library depending on the wireless module used such as Felix’s from lowpowerlab RFM69, modified RFM12B library or even RadioHead library from Mike.
  • Large various sensors can be used (Temperature, Humidity, Luminosity, Thermistance, LDR, NTC, PTC and also digital sensors such as DS18B20, TH02, DTH11, I2C sensors ….). Board is designed to simply place the sensors on it.
  • Accurate Analog sensor reading with 1% precision pullup resistors and integrated Steinhart–Hart coefficient calculated for several type of sensor (see how to get the coefficient there). New device coefficient can be added easily.
  • Onboard Thermistor 1% always available to be able to do temperature compensation with the Radio module (RFM69)
  • Firmware configuration stored in EEP and accessible with Serial configuration mode, this mean that it can be used on other boards type without “conditionnal” compilation. You can setup which sensor to use, which type of NTC, LDR, pins where are connected the sensor, the Radio module type. …) No need to reconfigure after flash, the configuration will be kept and dedicated to the node in EEP
  • Advanced low power battery reading with pad selectable divider (ex 1.5V AAA over 3.7V Lipo) to have an accurate ADC range measure.
  • Powering / Unpowering sensors and Radio module to reduce consumption to minimal into sleep mode.
  • 2 x Free analog/digital input/output with 1% precision pull up to connect various sensor type (NTC, LDR, PT1000, Thermistor, DHT11, DS18B20). These I/O can be also used as input/output to make pulse counter for example
  • 1 x I2C grove connector
  • … May be some other surprises…..

Now just to keep your interest, I want to let you know that my currently working nodes under testing with one old AAA battery are sending sensor frame (temperature and luminosity) approx every 30 seconds to my gateway. And the consumption on the AAA battery is about 0.4µA, Yes this is 400nA. Trust me, I though my uCurrent device was not working at 1st time !!!.

Edit : October 10th : The following measures were done with quite old AAA battery (1V), I tested with fresh cell coin and the idle consumption is more approx 900nA in this case (this is still excellent by the way) And this totally makes sense, since voltage is 3 times higher. And this confirm my first powering choice, with cell coin, battery life is excellent but with AAA it’s even better and the preferred choice for powering the node. End Of Edit

What does this means ? Quite simple, let’s assume that reading the sensors and then sending the result frame data over the air is taking 100ms (and with Analog sensor such NTC/LDR it’s really, really slower than that, but I’m taking a “bad” case in term of time).
So : 100ms usage every 30 seconds, this mean that ULPNode is consuming on the battery only 400nA but also this consumption is occurring for 99.6% of the time, the other 0.4% consumption occurs when reading sensors and sending data.

This is pretty fine, but let’s try to calculate our battery life in different case with RFM12B and RFM69 modules. This calculation is just an approximation but will give us one idea. Only testing under real condition will give us real answers.
Assuming we transmit wireless data at speed of default libraries and we’re sending 18 bytes (3 bytes of preamble,  2 bytes Sync, 2 bytes headers, 2 bytes of CRC (see Felix’s RFM69 frame description) and says 9 bytes of payload (1 for payload type + 4 sensors of 2 bytes). This make a total of 18*8 bits resumed on the following table in term of duration of the transmit time :


Ok now let’s go to the battery life calculator. I entered the following values :

  1. Capacity rating
    1. 240mAh for CR2032
    2. 620mAh for CR2450
    3. 1200mAh for AAA
  2. Current consumption of device during sleep : 0.0005 so 500nA October 10th Edit : push this value to 900nA if powering with cell coin
  3. Current consumption of device during wake :
    1. 30mA instead of 23mA for RFM12B,
    2. 50mA instead of 40mA for RFM69
    3. 150mA instead of 140mA for RFM69HW
  4. Number of wakeups per hour :
    1. 120 so every 30 seconds
    2. 12 for every 5 minutes
  5. Duration of wake time : 10ms instead of 4ms

As you can see, I overloaded the values to be sure and to compensate consumption of reading sensor (passives ones) for digital ones it can be more but really depends on sensor type and datasheet. I’ve also increased the duration of wake up to 10ms instead of 3ms. I think these values are safe for a basic calculation. The following table presents the calculation results :

Battery TypeModuleWake Up every
Current on
Wake Up (mA)
Battery Life

Wowww, Wowww, Wowww, I’m not really sure this calculator is accurate but the results are just amazing. If it is realistic, I will not be anymore alive to see some of the results.

What’s interesting, is that with a CR2450 with RFM69 Node sending every 30 seconds (at full power), the life duration would be over 3 years, this making these node really, really, Ultra Low Power as my wish ;-). But once again only real tests will give the answer. I’m seriously in doubt about these results.

Ok, if you’re still reading, this means that you’re surely pointing on some interest on this post, so let’s get started with some description on how to reach this.

Let’s get started

I decided to write some articles and give you more detailed information. The following articles will be written on the fly and be released as soon as I will go trough the production. They will show you step by step the advanced techniques used to achieve this project. I hope they will be interesting and let you having some fun reading them and more, using them in your own projects

Every Article will give you some clues and indications on how all of this kind of magic has been achieved, I strongly suggest the 1st reading on the bootloader that will come in few days, you will see code control and optimization and some advanced technique to share bootloader code and Sketch code. In all this project I will refer to the bootloader code as “Kernel” code to drive low level core function of driving the ULPNode hardware.

  • Customize Optiboot Bootloader for ULPNode
    • Part 1 : Hardware description for Low Power modes.
    • Part 2 : Implementation of Bootloader, export functions to be accessible from sketch
  • ….
  • Other to come, not decided of the order yet….

And here are a picture of different early prototypes

ULPNode Early Prototypes

ULPNode Early Prototypes

I apologize for the time needed, but please be patient, writing is really time consuming and between, test, conception, headaches, hardware problems, software debugging, and my main full time job, remaining time is really really limited…

Stay tuned





  1. Hi,

    What is the difference with Jeenodes?
    For example, in this page: http://jeelabs.org/tag/lowpower/ they show three different batteries, which runs for a pretty long time.
    And looking at others posts, he explains how to power up and down the radio transmitter, how to check voltage without taking current like a resistor divider.

    • Jéremy,
      Well, this is a long story, in fact I have several Jeenodes, and done lot of tests with them (as some other modules). Of course powering them with Lipo is an excellent option since they have a lot of power and High voltage (approx 3.7V all time). But as soon as you’re using cell coin, you will at a certain time, face off the problem of the internal resistor. I’ve tried lot of coin, and as soon as you’re reaching about 2.5V transmission are subject to random and not already reliable. I spent lot of time to find out why before discovering the Internal Resistance’s law. And this article from TI is describing the problem with very good information. And this problem is more visible with new module generation such as RFM69, since these modules are more “power” consuming (about 45mA instead of 23mA during transmit). See Felix’s article.
      But to answer more precisely to your question, this new nodes have the hardware totally redesigned (and software also) to provide this power with an advanced technique and dedicated DC/DC chip used with some external components to maximize lowest consumption. With this technique, idle mode consumption going from about 5µA to 500nA using Total Power Down mode of Atmel, which result in reducing idle consumption by a factor of 10. The voltage of the node will always be 3.3V when doing “working” operation this mean we will not need to deal with varying voltage whatever the energy source (Coin, AAA, ..).
      But this is just a view from Power side.
      On other hardware view, the board will come with precise 1% NTC and a LDR with internal lookup table included in the firmware. Have some pins exposed to add your own sensors, and a firmware containing code to read them with precise calculation of NTC and LUX and accurate low noise ADC reading.
      There will be also a pad to put a really cheap temperature and humidity I2C sensor (TH02), A I2C Digital Light Sensor (TSL2561) if you need more precision than a LDR and some other. The Radio module will be changeable RFM12B, RFM69 or NRF24L01.
      This mean that you would be able to have a working box with classic sensors out of the box.
      On software view I customized optiboot bootloader (article under writing) designed to drive these Low Power function and done a major rewrite of the firmware to add all the features. The firmware will be “so” configurable so that you’ll be able to use it on any other Arduino clone to do the same function (except the hardware advanced Powering features which will not be on the boards), including Jeenodes for example 😉
      Hope this answering to your question.
      Stay tuned, really more to come, the bootloader article available in few days, will give you some clues.

  2. hi,
    I would love to keep up on the news with your ULP Node. Do you have any kind mailing list for when it will come out? I know many many people that will be very interested in your work.
    many thanks,

  3. Travis,

    Thank you for your interest. I do not have a mailing list but I can create one and add your email on it.

    I will put you in the loop when product will be available, be sure !


  4. Charles,

    Can you keep me in the loop.
    Im starting a project to monitor Dutch BeeHives.
    Het node wil go in a hive en must last one year on a coin battery the updat frequentie wil we 5 min. Ik would like temp, humidity, light, sound and tiltswitch.
    Looks like you are makeing it work for the sensors.


  5. Hi, can you keep me too in the loop please? I’d like to distribute multiple sensors in my home so this sounds perfect. Do the radio modules need to be in direct sight? And what is the approximate range? thank you 🙂

    • Giorgo,

      No problem, I will keep you into the loop. The sensors nodes won’t need to be in direct sight, this means that it can send data trough walls and other. In open air I get them working far than 100 meters, and I have no dead zone whatever I am in my house 😉

  6. Hi,
    your post i amazing!
    I begin to search a solution for an Architecture with a sensor modulo and a gateway bordato that comunicate between the with rf while the gateway board speak REST with a web server.
    I begin my test with seeduino sensorenode and a classi arduino board with ethernet shield but your solution are Better.
    Sorry for the too long comment, can you push me in the mail in list?

    • Hi Gianluigi,

      Thank for your comment, the solution you are looking for is exactly the same that I want to do. The gateway will be based on “Yun” type board with Linux listening to REST request.

      I put you into the loop, no problem


    • Hi Richard,

      your comment is amazing because the modbus gateway is the next stage I planned to exchange data coming from sensors. I’ve already choosen the gateway hardware and need to write the code to keep sensors data on modbus table. The connection to the modbus will be modbus TCP either Ethernet or Wifi.


  7. Hello Charles & Richard,
    Good idea for ULPNode. In fact, I stumbled upon this page while researching for low powered (read battery powered) node for MODBUS. In past, I had implemented MODBUS client and MODBUS server (on diff projects) and wanted to extend or generalize the concept. Thus, you may also keep me in loop related to this. Charles, you may write to me and I can explore If I can be of any help depending upon our experience and time available.

    • Rajeev,

      Thank you, sounds very interesting, modbus is the library I wanted to use. I wrote some quick and dirty code to do a POC and seems to work fine, but I need to learn more deeply the protocol, so any help or already written code would be welcome. My idea would be to have a modbus daemon listening to incoming modbus request (It’s always a pain for me the modbus notation of client/server), the RF gateway server would listen for incoming RF packet (from sensors) and send the daemon new data received, then the modbus daemon would update it modbus table. Just a first idea of course.

      I will keep your mail and send you a PM mail when I’ll be more on modbus writing.

      thanks again for your proposal.


  8. Excellent design. Seems you have been able to merge the best of many low power designs. Please keep me posted
    I’m sure you are aware…. but anyway: On the software side, the mysensors.org library should also be a good fit and need minimal adaption. I find it very easy to use, flexible and low power oriented.

    • Hi Hans,

      thanks for your comment, I checked from mysensors may be one year ago, just looked back, they seems to have done a great job. Way to investigate on the API, even if the Radio module could be different, the only thing to do would be that ULPNode speaks same Serial protocol at the gateway end (which seems relatively simple as soon as ULPNode has only one sensor data), like this it could be easily integrated.


  9. Hello I’m starting a project based on 4 secondary nodes and 1 primary. The primary will be pluget to a power supply (so the problem of power is solved) and the 4 secondary nodes will be powered with a cell coin. The secondary nodes will have a push button attached and when someone push them down, the node will send the event to the main node. I need the secondary nodes be active for at least 6 months and I believe with your ULPNode I can achieve this task. When are you going to release it? Can you keep me in the loop? I want to be one of the first ones trying it.


    • Hi Enrique,

      If your secondary nodes just need to send frame to primary when the button is pushed, I’m glad to announce that you will have the less consuming power mode of ULPNode. This is because it will wake up only when your button will be pushed. Of course this is true if you don’t push the button every second 😉

      I’m pretty sure you’re ok for years in this mode, and of course, I will keep you in the loop.


  10. Hello, Great work!
    I’ve just started to assemble a z-wave network at home and I wanted to use a number of different sensors, including door/window sensors but it appears that most of the existing are very big (and not really good looking) and quite expansive.
    So I looked into designing my own, and came across your blog. Sounds perfect.
    Using the RFM12B I should be able to have working as a Z-Wave device?
    Please add me to the mail list.

    • Jörgen,

      Thanks for your comment. Unfortunatly ULPNode is not a ZWave device, and it won’t be able to speak with a ZWave controller. It can work “like” a ZWave device (without repeater) but ifg far different on the protocol side. ZWave is not open and each ZWave developers need to pay fees to use and have ZWave SDK.

      But you will able to have full networked Low Power Devices with ULPNode, the release will contain Gateway code for this 😉

      I put you on the list.


  11. Very interesting product. Please keep me updated.

    Any intention to support mesh networking. I know Radiohead does this but it will also mean each node may need to synch awake times. Your thoughts?


    • Hi Leigh,

      Well, I’ve got a good news for new, I’ve been working on changing the library used. ULPNode now use RadioHead library. I’m not using the mesh but it should be easy to implement. But until the “meshed repeater nodes” are always powered with a dedicated power (USB or other), there is no way to use them on battery with long life. That the deal we’re facing all. Listener draw in permanent 10mA, which is far away of the few nA used by ULPNode in deep sleep mode.


  12. Salut Charles-Henri,

    Vraiement du beau travail! Your project looks extremely promising and is exactly what a school buddy and I are looking for for our project! please keep me in the loop as well and if there is anything that we can do to contribute let us know.


  13. Hi,

    When are you expecting to release the ULP modules with RFM69HW 915MHz? I am anxious to purchase a few. Thanks.

    • Hi Bruce,

      Native ULPNode will be able to receive RFM69CW (choice of frequency could be done :-). Due to space constraint you will not be able to solder a RFM69HW (not the same pinout) but I implemented a workaround, as there is an “NRF24” style 2×4 connector, you will be able yo use it to connect a RFM69HW breakout board like the one I’ve designed here

      During my final board testing, I faced some problem belonging to the tricky device sensor TH02 which does not work with other I2C device connected on the same I2C bus (and some others problem related to this poor sensor). For this reason ULPNode boards need some modifications, and that’s a shame because all other functions are working so fine. So I need to have a new design/test before releasing the product, so at least one month late. I will do also minor change on sensor placement to have better control for end user.



Comments on this topic in community Forums.