The Arduino Pro Mini, the Baite BTE13-010, and the ultra low power consumption I achieved thanks to new programming tools

Please welcome my latest programming tool, the Arduino Power Cutter:

IMG_20150726_232059

The BTE13-010 is a cheap Chinese clone of the Arduino Pro Mini, manufactured by Baite, which can be found from their Aliexpress store (among other places). The internets and the producer are unfortunately lacking much documentation about it.

Today I was trying to achieve a very low power consumption on the BTE13-010. You might already have had a look to popular pages when it comes to power saving on the Arduino, two popular ones being Power saving techniques for microprocessors on Gammon Forum and Arduino sleep mode basics on EngBlaze.

However, at first I struggled to achieve the promised great savings, possibly because I was using the BTE13-010 instead of rebuilding a circuit from scratch, like many of them suggest?

To make a long story short, after browsing everywhere, I came up with these two subroutines that will cut (no pun intended) through your power consumption:

The power_saving_init() should be the first thing to be called at setup(), it will initialize all your pins to LOW. power_saving_sleep() will put everything to sleep, and wake up every 8 seconds. With these two, with the regular board (no bootloader modifications, with the power regulator on, etc) when sleeping I was able to achieve 3.24mA of power consumption, which is already pretty good considering it was draining about 10.2mA when fully powered on in the first place.

(I also tried to change the board internal clock with avrdude options, but that didn’t seem to be possible on this board. I also tried to clock it down via clock_prescale_set(), but nothing was gained).

But it doesn’t end here! That’s were the Power Cutter comes in. Thanks to Talpa PCB retrace of the BTE13-010 I was able to elaborate an evil power saving plan:

arduino_cutting

[Credits for this picture to Talpa, with a few corrections/additions by me]

With a cutter, I was able to cut (pun intended) thru power consumption by cutting the two traces in the picture (in light blue in the upper right), thus phisically cutting out the power LED and the regulation circuit (I wasn’t using that regulator anyway, both USB power and my batteries bypass it). The LED and the regulator were draining about 0.47mA and 2.44mA respectively. Note to adventurers: always check with a multimeter before and after attempting to cut traces.

Without those two components, my power consumption went down to 4uA.

For best results, use batteries with low self-discharge rates, like coin cell! AA batteries can have discharge rates up to 30 mA, it’s a lot!

Let me know your thoughts in the comments!

  • Andrew Sanjanwala

    I’d be curious to find out how much of your power savings came from the code you ran versus cutting out the LED and/or the linear regulator. Their low cost makes it almost laughably easy to experiment with the hardware itself.

    There seem to be multiple variants of the BTE13-010. My collection of Baite pro mIni clones are marked as BTE13-010A and have subtle differences in where the individual bits have been placed and the layout of their traces when compared against the -010 pictured. On my 5v/16mhz parts, the LED and resistor are awkwardly close. I’ll see if I can snap some photos.

  • Muzammil

    Hi
    i have tried connecting the BTE13-010 with the usb to ttl but had a code error 10 before, however after solving this error now the big issue is that the BTE13-010 isn’t getting programmed. Every time i uplode the sketch it shows me the following error.

    avrdude: stk500_recv(): programmer is not responding
    avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x28

    please help…

    • Simone

      Hi, the “not in sync” error, from my experience, can be due to a driver issue (especially if you are using something like Windows Vista), or more probably to a communication problem with the device, like: the Arduino IDE is configured to use a wrong port, wrong device type, bad wiring on the programmer (triple check this one), or, well, a failed device. I often had this kind of issue in my old Windows install and I often resorted to programming it from Debian. Hope this helps!