Above, my final created unit is shown operating in two different containers, as well as being powered by a USB power bank (instead of a coin battery).
I wanted to make a small interesting timer to use with games like Boggle. I had an Attiny85 Digispark board so I decided to put it to use.
Further, I decided to use the Digispark over a bare Attiny85 chip because:
- I had the board on hand and no bare chips
- It provided easy wiring & mounting
- The board was easier (albeit not as easy as other boards) to program repeatedly than a bare chip.
Nonetheless, I would advise (if you know how & have means to program it) to use just the bare chip with a socket as you won't have to take so many measures to reduce power consumption during sleeps.
Step 1: Parts
The parts you'll need are:
- Digispark ATtiny85 board http://digistump.com/products/1 or http://www.ebay.com/itm/262085283993
- 3 LEDs (a green, a yellow and a red) http://www.ebay.com/itm/321464065222
- a 100 ohm resister.
- a tilt switch http://www.ebay.com/itm/191212877291
- an active buzzer http://www.ebay.com/itm/281280117872
- CR2032 battery and holder www.ebay.com/sch/?_nkw=Coin+Cell+Holder
- a transparent container
- various equipment and tools (the usual stuff ... PC, cables, wires, strippers ...)
Above is an idealized diagram of how these parts interconnect for this project.
Step 2: Reducing the Power Consumption on the Digispark Board
The intention was to have no on-off switch and have the battery last as long as possible.
Under normal operations Digispark board consumes about 18-36 ma. And while fully asleep 12-24ma. Note that current measurements will vary as the Vcc voltage level used varies (I used 3 to 5V respectively). Half of this is consumed by the 78M05 voltage regulator (while not in use). Using a 3 volt battery, this regulator is less than worthless. So we cut it out of the circuit. This is done by cutting all three leads coming out of it (look close at image above). One lead was not connected in the first place. That the device remains soldered down is of no concern.
At this point typical power use is about 10-20 ma going to the MCU and LED(s), and a low power sleep is approximately 2.2-6 ma. The LEDs use 2-2.5 ma each. The one connected to PB1 is not an issue as the software controls it.
Cut the trace between the power-on LED and its supply resister (see image above). Do not remove either of these components; this way you should be able to reactivate the power-on LED with a little conductive ink placed over the cut. http://www.ebay.com/itm/191724561789
Afterwards, with 3.1volts on Vcc, I measured 8ma while MCU was awake and 0.37ma while asleep. Using 5v Vcc it was 15ma awake and 1.5ma asleep.
Step 3: Optional Additional Power Saving Measures
For those who plan to cut off the battery supply for long term storage, via switch or battery removal, this is more than enough power savings.
If this is not the case and you are proficient with fine soldering and caring for surface mount components, then you may want to take these additional measures.
To further reduce ambient current drain, I also cut the trace to the resister R3 used to pull up the PB3 signal (for USB download communications) Digispark schematic. This is rather problematic, as it has to be effectively undone in order to allow download via USB. Furthermore it seems that the loaded logic which runs on power-up gets stuck if the data line connected to R3 is not pulled up. Thus, I had to solder in (very carefully and precariously a diode (1N4148) from the '5v' line to the end of R3 I had cut the trace by. So it might be best to only take these actions once you're pretty sure you are done playing with the code.
Using PB3, for the tilt switch, continued to cause operational and perhaps power management issues, so I stop using it. Also note that many USB battery power banks connect the data lines together which causes cross talk between PB3 & PB4. This significantly confused my testing, when using these convenient power sources.
With these actions, I was able to get the power consumption during a deep sleep down to 0.02ma ( 20 micro-amps) with a 3 volt supply. This will allow for about one year life for the battery, without excessive use. I have heard that others got a bare Attiny85 down to 0.2 micro-amps (0.0002 ma) I tested my modified board with the code they used, from http://www.technoblogy.com/show?KX0 And I measured 0.02 ma. So I don't know where the current difference is going. Granted I could not wake it up as I did not modify my on-board chip so it would respond to a reset, but the power use should have been the same, given the coding used. I then thought that there might be leakage through the zener diodes attached to the USB data lines but I was unable to get that to prove out.
It would be great to extend the battery life, while connected to a Digispark board, another order of magnitude; so if anyone manages it please let me know.
Step 4: The Assembly
For prototyping this, I used a solderless breadboard assembly; shown above.
For a reduced part count I used one resister to limit the LED current flow. Since only one LED is lit at a time and all three illuminate close enough to the same brilliance with the same limiting resistance (of 100 Ohms) there is no big advantage of using separate resisters.
I wired the parts directly to the Digispark board so as to have an assembly which would fit inside of a small vessel. I used a semi-transparent 35mm film container. Sorry but I can't tell you where you can obtain one of these. You may consider using a pill bottle or a small glass decanter.
Be sure to mount the tilt switch so it is normally open while the container sets how you want it while it is timing and during storage.
To hold the project assembly still while the container was being rocked back and forth, I hot glued the spring metal from a binder clip to the inside of the container's top. I first drilled a hole in the lid and the base of the spring metal clip so the glue could have a place to hold better. I did put a piece of masking tape inside the clip so the glue would not ooze into the inside. Additionally I filed the USB edge of the board so it could be wedged in the clip more easily. And to prevent gouging of the contacts or shorting them together, I wrap a piece of paper over the edge of the board before pressing it in. You can make all this out by closely studying the last few images above.
When finally putting my assembly into the tightly fitting container I had to file off the corner of the buzzer. I also secured the battery holder to the PCB with a little hot glue.
To my pleasant surprise, I found that the lid from the film container also fit on the small pill bottle I had.
Step 5: The Code
I believe the code is pretty straight forward. Assuming prior use of the Arduino IDE . The code includes comments to aid understanding.
When programming the MCU (uploading the sketch) be sure to select the board as “Digispark (Default – 16.5mhz)”, else the timing will not be right; unless you also 'burn a fuse' setting reflecting the CPU clock change.
If you have not programmed a Digispark with the Arduino IDE check out this Digispark tutorial: http://digistump.com/wiki/digispark/tutorials/conn...
Step 6: Operation
After an initial power up the timing between LED flashes is about 4 seconds instead of a minute. That is to facilitate testing and to validate assembly health.
When the unit has been flipped over and put back up right, there will be three quick flashes and chirps. This marks the beginning of the timer period. The following is what happens on each successive minute.
- quick Green flash and a chirp
- quick Green then Yellow flash + chirps
- flash of Green – Yellow then long Red LED flash with buzzer
- four quick Yellow flashes + chirps
- five Red flashes + chirps and ending with a buzzer
These can, of course, all be changed to one's liking in the software.
Watch the video above, it shows the device in the initial accelerated mode, but all of the flashes and beeps are as they will be when there is a full minute interval between them.
The device will go into the power-down sleep mode after it completes it timing function and anytime there has been no change of state of the tilt switch. Don't leave the device on its side, the switch may make sporadic contact.
Note, I have applications for both 3 & 5 minute time outs. By the way, the whole timing process can be stopped at any point by simply turning the timer back over.
Step 7: Epilogue
While this device works fine with three volts, I found that my unit, with an old battery, would begin to fail when the voltage being supplied fell below 2.9 volts.
I found that the main contributors to this situation were:
- The Digispark uses an ATtiny85-20SU, which is designed to operate at up to 20MHz but its lowest operating voltage is spec-ed at 2.7v (so it should have worked, Right !?)
- The buzzer was drawing an additional 14ma for up to 1 second. This put a total of 30 or more milliamps being pulled from the button battery.
- The battery has a limited current drain rate. The instantaneous use was more than 10% of its capacity rating of 200mah. Causing it to sag.
Viable solutions to the above:
- New fresh battery
- Reduce current use of Buzzer (by activation time; or could have put a 50ohm in series)
- Don't light an LED and buzzer at the same time
- Run CPU at low MHz, to allow slightly lower Vcc use.
- Add a compact 100-1000uf cap, to reduce Vcc sag. [found to be effective, but I don't know for how long]
- Instead use a ATtiny85V (1.8v-5.5v) chip for low power operation
With the last solution in mind, having started with a bare chip (given it was of the '85V' variety) in the first place looks like a better idea then I had considered it to be.
Items 2 and 3 above are now done in the project software.
Update: With low voltage, the PB5 line was giving insufficient drive to the third (red) LED. Which is to be expected per wiki/digispark/quickref.
So I moved my red LED to PB3. Now it looks fine. however ... Whereas the switch I had earlier on PB3 would prevent new code uploads if the switch was closed; The side effect of LED-100ohm resister on PB5 was the LED flashing at power up (due to the boot-loader trying to communicate) and loader failures due to too much load on the line. So to alleviate this when doing updates, I temporarily jumper-ed a 270ohm resister from where the 100ohm attaches to the LEDs and Vcc, to offset some of the pull down effect of the 100ohm.