Recently, I built a touch activated LED toy based on the Attiny85V from Microchip (née Atmel). The schematic is shown below
I got the PCBs made from every hobbyist’s favorite PCB manufacturer OSHpark. On the surface, the project seemed pretty simple. It gave me an opportunity to work on touch sensors and learn their functioning and implementation. I decided to go with an external touch sense solution(MTCH102 from Microchip as well), as I had plenty of board space to spare and, the it wouldn’t add much cost to the BOM. Also it would save me a lot of development time as implementing a robust power efficient capacitive touch library could be an interesting project in itself!
when starting with the project I set the following constraints:
- Cost < $12 (for qty < 10)
- Power (powered from a CR2032, the battery should last at least a month)
The cost target was an easy one, the most expensive component was the Attiny itself at around $2.25, other components were virtually “free” .
Meeting the power target though was a bit challenging. This post is mostly about how I was able to reduce the power consumption, mostly through firmware modifications.
- Utilizing the sleep mode was an obvious choice since that could improve the standby time of the device literally by orders of magnitude. I used the following setup to measure sleep current. Vd was the vdrop across the rather large shunt. This rather large shunt worked for me since I was only concerned about the sleep/standby current and the voltage drop across the shunt would be pretty minuscule across the resistor at such low currents (<1 mA).I used a Vichy VC99 DMM and my Rigol Ds1054z (this scope is amazing value for the money!, mine doesn’t play well with USB thumb drives though ) to measure and analyse the current draw.
2. on initial measurement through the DMM the current draw seemed be varying quite a bit, this took me down another rabbit hole of how the touch sensor actually functioned. the MTCH102 has a pretty interesting power down mode, and the datasheet doesn’t do it enough justice. I was using the aptly named Low-power mode in my implementation. which basically involved tying down the MTPM, low-power mode selection pin to ground
3. down the rabbit hole we go! It seems that the chip implements a pretty intersting psuedo-random algorithm to scan during the burst mode. the datasheet just calls it the burst scan. The chip sends out random length of pulses to the sense pad. The pulses are always in multiples of 16. And always between one and 10 sets of these 16 pulses are sent out.
one set of pulses
4. This reflected on the current draw was as well, when the chip would be in burst scan mode the power consumption was up to 1.2mA. the scope capture below shows the Vd (across the 100Ohm shunt) when two sets of pulses were sent out through the sense pin.
5. the only work around for this was to use the smart scheduling mode. This way I could control when the burst scan occurred, instead of every 256 ms i could set it occur say every second or so. I could go this route cut down the power consumption significantly! but then I would have to respin the board
6. but wait… the base line power consumption when the MTCH102 in sleep was still kinda high. about 300uA. a google search later, is stumbled upon this app note about reducing power consumption on the AVR. one of the first things that they had mentioned was to enable the internal pull ups on un used GPIOs to prevent power drain due to floating gates. I had three unused GPIOs that were essentially floating, made changes to the code and viola! I was able to shave off ~100uA
7. with sleep mode and implementing the internal pull ups and disabling the unused modules I was able to get the average current consumption to under 200uA. a typical CR2032 cell is rated for 240mAh. this would give me an estimated standby time of about 1200 hours (or 50 days). Also the internal resistance of the cell increases as its charge depletes. Also considering the device consumes ~20mA when awake for about two seconds. Assuming the device wakes up once a day, we should theoretically still have enough charge for a run time of over 30 days(240mAh – 0.03mAh- 144mAh = 95.97mAh leftover).
To conclude I think this project was an overall success and met its primary goals. There is some room for optimization and I think the power consumption can still be reduced further, but for now I think I should move on to the next project!