The main component of this project is the microcontroller which also has to serve as a Zigbee radio. Compared to Wi-Fi or Bluetooth, Zigbee support is less common in microcontrollers. Espressif offers the ESP32-C6, which seems like a good fit at first. However, due to its high power consumption in active mode and long boot-up time, it’s just not ideal for a battery-powered sensor. I like doing some rough calculations very early for battery powered projects like this. The math is straightforward: You always have a standby-mode current and an active-mode current. Then you factor in the time the device spends in each mode. Based on the battery capacity, you can then calculate an approximate battery life. This can be done quickly in Excel but Oregon Embedded’s online calculator is also very convenient:

https://oregonembedded.com/batterycalc.htm

Assuming 40mA during active mode and 3 seconds per measurement every 5 minutes, the ESP32-C6 would only run for around two months on a AAA cell. The standby current barely matters in this case as the device would waste the majority of its power during transmissions.

Besides Espressif, various other manufacturers like Nordic, TI and Silicon Labs offer low-power MCUs designed specifically for Zigbee applications. Based on good availability, price, and the fact that you can obtain an evaluation board easily, I chose the Nordic nRF52840. It’s based on a Cortex-M4, has plenty of I/O and it includes a number of low-power optimizations, like an on-chip DC/DC converter and a switch for supplying external circuitry. Nordic specifies a standby current of 1.5 µA and a peak transmit current of under 5 mA. Doing the same calculations as before, yields a theoretical battery life of over 4 years. Of course, real-world factors like battery self-discharge will shorten this considerably. But it does look promising!

One of my design goals was using a standard 1.6mm PCB. The nRF52840 uses quite a wild 7x7 mm QFN73 package with two rows of pins. Because of the density, not all of its pins are accessible without using plugged vias and a 4 layer PCB. This would not be an issue for this project since only few I/O pins are necessary - as long as none of the inaccessible pins need is essential. Unfortunately, one of these pins is the reset signal, which is quite important. I was almost considering switching to a different microcontroller before discovering Nordic’s nRF52840 Dongle, which also uses a low-cost 2-layer PCB. How did they solve this issue? I checked the design files and found that the reset-signal was simply routed through a few unused IO-pins. This seems a bit sloppy but if the manufacturer does it, so can I. 
The Dongle design also integrates a compact 2.4 GHz trace antenna that happenes to match the width of my board, so I used their antenna layout as a starting point. In general, there’s nothing unprofessional about copying antenna designs from evaluation boards. Nordic even recommends this specifically, since these are proven and certified designs. 

While most microcontrollers come with reference circuits from the manufacturer, Nordic provides a whole seven different circuit configurations for the nRF52840. These vary based on the power supply type and which features are enabled. Since I’m not using USB or NFC and have no use for the internal DC/DC converter, I chose configuration No. 6, which also happens to have the lowest part count. Nordic lists the 32.768 kHz clock crystal as optional, because the chip has an internal RTC crystal. But what is hidden a little deeper in the documentation is that using the external crystal reduces the power consumption by 1 µA vs using the internal one. I assume this is because the internal crystal needs more frequent calibration. 

The nRF52 support a wide supply-voltage range, but with a minimum of 1.7 V, it can’t be powered directly from a 0.9-1.2 V AAA cell. That calls for a step-up (boost) converter. I previously used the MPC1640 in an earlier project to step up 3.3V to 5V for a low-power display, but its 19 µA quiescent current (current that the regulator itself consumes) would have meant too big of a hit to the battery life. Instead, I chose the TPS61098, which has less than 1 µA of quiescent current. On paper, it can start running at an input voltage of just 0.7 V, but the actual minimum depends on the output current. There are several variants of this device; I’m using the TPS61098, which supplies 2.2 V by default. The TPS610981 would be a drop-in replacement providing 3.3 V, which slightly increases the overall power consumption. 

The TPS61098 is directly supplied by the AAA battery. Out of habit, I initially included a p-MOSFET between the TPS and the battery for reverse polarity protection for the first revision of the PCB. This is usually a simple way to block current if the battery is inserted the wrong way but it only works if the battery voltage is higher than the MOSFET’s gate-source threshold voltage. For a NiMH-based cell, the voltage is not enough and would require a MOSFET with an extremely low threshold voltage. Otherwise, the MOSFET’s resistance causes a voltage drop that prevents the boost converter from starting. The trace below shows the battery voltage (yellow), the voltage behind the input fuse (blue), the voltage behind the MOSFET (purple) and the 2.2V supply voltage (blue):

It’s a similar case when using a Schottky diode for polarity protection. Even its small voltage drop is too much if the whole 0.9-1.2V range of a rechargeable cell is to be used. Reverse polarity protection at such low voltages is a real challenge, so I ultimately went with a purely mechanical protection, where the 3D-printed case physically prevents the battery from being inserted the wrong way.

 For temperature and humidity measurement, I’m using the TI HDC2080, because it is inexpensive, widely available and – unlike the HDC1080 – supports 2.2V operation. As with most of these sensors, the power draw is very low. The HDC2080 has a maximum sleep current of just 100nA so its negligible for the device’s battery life. The sensor communicates via i2c and includes a data-ready interrupt signal. Ttemperature sensors are usually placed at the edge of the PCB with some FR4 material around them milled away to reduce the thermal mass and make the sensor react faster to temperature changes. Because the PCB is what holds my battery contacts together, I did not want to impact the structural integrity too much, so I only have a c-shaped path milled around the sensor, which is centered on the board.

 For the contact-sensor functionality, the device has to detect a nearby magnet. Some designs use classic reed switches, which consist of two wires in a tiny glass tube that make contact under a magnetic field. A more compact and durable type of magnetic sensor is a Hall-effect sensor, which works without any moving parts. I chose the Honeywell SM351LT, which draws only 360 nA, operates at 2.2 V and has a push-pull output. The push-pull part is significant because if you need a pull-up resistor for the switch and you leave your door open, that pull-up might consume more power than the whole rest of the electronics (for example 220 µA through a 10 kOhm resistor). I intentionally positioned the sensor right in the middle of the board, so the magnet can be detected regardless of the device’s orientation.

 This is the first time I am building a device that has to run reliably on as little as 0.9V. As mentioned above, overlooking the threshold voltage of the polarity protection MOSFET was one of the mistakes that I made. But there are more lessons that I learned. For example, my first test for new boards is usually blinking an LED. Yet this tim, nothing happened despite the firmware running correctly. The issue turned out to be the LED itself. What I had not thought of at the time, was that different colored LEDs have different forward voltages. Blue especially is one of the worst colors to pick for a 2.2 V system because blue LEDs have typical forward voltages of 2.5-3.7 V. Suddenly, it made a lot more sense why Ikea would use a red LED for their AAA-powered Parasoll sensor (which internally also runs at around 2.2 V).

Another issue involved the input fuse. For a device like this, a fuse might not be as important as for a Lithium battery, but NiMH cells can overheat as well. Since the power consumption is so low, I initially used a resettable 100 mA polyfuse. The problem is that these fuses have a wide current range where their resistance will slowly increase. This caused the input voltage to drop below what the TPS61098 can handle whenever the nRF52 was transmitting. I solved this by switching to a 350 mA fuse which should still provide a good deal of protection.

But a low voltage also has its small perks. Since the microcontroller always runs at a higher voltage than its battery, measuring the battery voltage doesn’t require a voltage divider.

 Overall, there aren’t many parts on the board and placing them on the PCB was not too difficult. I even had room for a 2x5-pin JTAG connector which came in very handy during the software development. The total part cost is also well below my original design goal of 10€. Here is a short rundown of what the parts currently cost, when ordering 10+ units:  

• Nordic nRF52840: 2.73€
• TI TPS610981DSER boost converter: 0.79€
• Honeywell SM351LT hall effect switch: 0.28€
• TI HDC2080DMBR temperature and humidity sensor: 1.14€
• 2x MY-AAA-07 battery holder (Keystone 56 replacement): 0.14€
• Some neodymium magnets: around 0.20€
• Other small components: around 0.50€
• Circuit board: around 1€
• In total: 6,78€

 Obviously, this does not account for the cost of shipping, taxes, tools like the soldering stencil and a programming tool.