Re-implementing the electronics in a digital bathroom scale, for. low power consumption and cost.
To make the experience fit your profile, pick a username and tell us what interests you.
Shortly after the last update, everything was attached together into one board, sprayed with conformal coat, and installed into the scales. It's been in use for about 14 months now by my parents, and the backlight has been extremely appreciated. Battery reading according to the ATTiny is still above 4 volts despite regular use. It was calibrated by very simple y=mx+c, with the m factor being determined by stacking two scales together and standing on them both. The c factor of course is zeroed out by tare-ing.
It still lacks polish - zeroing is indicated by the appearance of a decimal place, and there's still some noise. However further testing revealed at least one source of changing reading was the human body's pulse - you bounce ever so slightly with each heartbeat.
A memory efficient exponential smoothing with a long time constant solves most problems though.
Next steps are to document with photos, confirm battery reading, polish software, and maybe add a heartbeat mode. Checking the calibration has maintained is also important, though that's largely due to the strain gauge itself and there's little ability to change an intrinsic flaw like that.
All the parts have arrived now, including the HX711 ADC module.
The first step with such small, poorly documented boards is to check out the schematic. As this board did not come with one, it has to be derived. Pencil, paper, and a rubber works OK for small boards.
The most important things I can tell from the schematic are: The digital output/input pins have 10k pullups, and the on chip regulator is set to 1.25*(4.7+1.8)/1.8=4.51 V
(Note the datasheet actually has the formula wrong, and has swapped R1 and R2!)
This is no good, since I'm running it from a lithium battery, so I need to find another resistor pairing to make it approximately 2.6-3 V. (2.6 v as per datasheet minumum, 3 v as 3.2V minus pessimistic dropout). I tried 2.5 v before re-reading the datasheet. In the end, I've chosen the resistors 3.6 and 4.7k, to give 1.25*(3.6+4.7)/3.6 =2.9V. The exact value doesn't matter, though it helps in precision applications to have matched temperature coefficients here. (so the voltage doesn't change with temperature)
Ok, so a quick sketch done with the https://github.com/bogde/HX711 library, and my LCD showed the following:
Quick verification then - What should full scale be? - according to datasheet 0.5(AVDD/GAIN), so 9.77 mV. This affects the sensitivity estimate, so something somewhere is out by ~15%. At this point it doesn't matter too much, provided that it doesn't change sensitivity with temperature!
The noise figures are concerning, and additionally the drift which was massive. There is jumper to enable a slower, less noisy reading, and additionally one can average multiple readings. Given the noise contributions of other components, oversampling is probably most suitable. Quantified tests can be carried out - but that is another topic! My main suspicion is the non-strain half of the wheatstone bridge, achieved for now with the slightly strange two independent potentiometers.
The next task (With an arduino to prototype more rapidly with) is to get the serial communications to share fewer pins, so there is one spare on the ATtiny for wake input. Additionally, get the noise figures down to manageable levels.
The display arrived today - at £3.80 it wasn't too bad.
Now I have it, it's time for the testing. For now, I've just used the ebayer's provided library, and a simple routine for measuring the AVR's internal voltage at 10Hz. No optimisations have been done on the ATtiny85, asides from making it run at 1 MHz.
A quick test was done to check all the segments and features worked, at the rated 5V. Then it was moved to solderless breadboard and attached to meters.
The next step was of course to check out the display over the operational voltage range - using a power supply. The current consumption of the display alone was also measured at a few points.
Overall, not bad: the voltage measured matched the input fairly well over the 5v-2v range
Which matches up plenty well enough to use for threshold testing of a battery! Once it's on a final style board (so minimal resistive losses) I can retest this relationship to end up with a better calibration. For now, simply changing the Vref value in code to 1100*1.0279=1130 should provide a more accurate system. The 0.1 v offset is likely be somewhat due to resistive losses in all the wiring from the power supply.
Top left: The display, showing the uncorrected voltage on the ATtiny85, as measured by the AVR. Top Right: Proposed lithium ion batteries (4.06v). Bottom right: Breadboard with ATtiny85 and wires. Bottom left: Multimeter in current mode, reading 1.70 mA total draw.
Typical LCD current draw was 270 µA at 4.0V, dropping to 136 µA at 3.0V. The datasheet value for the controller at 3.0V is 150 µA, so this is great!
Additionally, the LCD contrast varied quite a lot over the range , and in fact was best between 4 and 3 volts. This may need to be a topic of future change - there is a 20k resistor to VLCD on the LCD board, and the controller can drive at 1/3 and 1/2 bias - which may change the characteristics.
So, this is about using piezoelectric element to trigger logical events on the processor.
Note this is different form just hooking up a piezo element to an ADC pin, and sampling. This needs to give digital signals -it's going to be the wake source.
In this implementation the scales should be triggered by a light tap.
So a simple test is done - an oscilloscope connected to the piezo (conveniently as a 1 Mohm load), set to peak detect mode, and then the piezo tapped.
While I can tap sufficient to give +-2.5V, it's hard, and not very reliable. A reasonable level is more like 1V for light tapping.
So, some amplification is needed - the first port of call is to look at the existing circuit. This clearly worked, and felt 'right':
However, it's a bit over complex. Yes, the top transistor was indeed set up like that.
So I simplified - using the same components for the front end.
As can be seen by the dubious Falstad simulation, idle current draw when active is only a couple of microamps. When the piezo is at zero, the idle draw is near zero (0.1 pA apparently). The value of the 200k resistor can be tweaked to affect sensitivity to tapping.
The zener diode is there (at 4.7V) to protect the transistor from emitter-base being above 5v, as per the datasheet.
The output now is HIGH when the piezo is still, and oscillates between HIGH and LOW as the piezo flexes and rings.
Next, to breadboard and test it waking an AVR from sleep!
This is applicable to any project that's looking at doing truly low idle power consumption.
Note that excessive optimisation is pointless on some battery technologies - the internal self discharge may be orders of magnitude more important on lifetime.
For example, a standard 2600 mAH 18650 lithium ion cell at 20 degrees may lose e.g. 17% over a year.
That's 442 mAh per year, or an equivalent current of 50.5 microamps.
Optimising a circuit to draw 0.1 uA instead of 0.5 uA is not going to be very productive if used in such a system.
However, there are certainly applications for low current draw, and it is interesting to see how low power one can go.
For power sources with a higher than needed voltage:
e.g. Lead acid batteries, 9V batteries.
Some form of regulation is needed.
The simplest way is a 3-pin voltage regulator, traditionally the 7805, though a huge range exist.
My Seeeduino has an ams1117, for instance.
The important bits to look out for in this application are:
Quiescent current, and minimum load current.
In the case of the AMS1117, the quiescent current is typically 5 mA. This is unacceptable - we're targeting <1 uA. The minimum load current is the same - 5 mA typically.
In general, the lower total power from a regulator, the lower quiescent current.
Since the scales are mostly asleep, but woken up occasionally, the load when active should also be handled well. Unfortunately, this is 3-4 orders of magnitude more current than idle, and most regulators struggle to have good specs at the low end.
I've not got one suitable - yet!
There's also a very simple regulation - a zener diode.
The reverse voltage through a zener diode is quite predictable, and can be e.g 4 V (to drop froma 9V battery).
Again, there are problems when going from 5 mA to 1 micoamp - there will be a sizable change in voltage.
A voltage that changes (a lot) under load will cause problems in a sensitive system, e.g. an ADC.
I've not got one suitable lying around.
The main benefit is that there's no quiescent current - though there is leakage (the voltage increases at light loads)
There's not much to do with cells at 1.5V or below.
e.g. AA/AAA alkaline, NiMH
They can be boosted by a boost converter - but as an active system the quiescent current is large.
One can if clever use an AVR to operate it's own boost converter - sprite_tm has done this with style: http://spritesmods.com/?art=ucboost. However it needs a button press to start.
This leaves cells or batteries with a voltage the MCU can run off directly
E.g. 2/3 AA/AAA cells, li-ion, li-poly, CR2032 cell...
For these, it is mostly easy.
Simply check that at all voltages they will operate at, all the peripherals work (e.g. my display module), and plug in directly.
As a plus you can indirectly measure the voltage using your AVR chip itself.
There is one concern here though - and that is rechargeable lithium ion batteries.
As a rule, you do not want to discharge below 2.5V. You may want to limit at 3.2-3.5 V typically.
*Note the battery voltage will drop a lot at below freezing temperatures.
To this end there are protection circuits that sit on the battery. A common one is the DW01A chip, which switches a separate mosfet to protect from under or overvoltage.
(see http://www.ebay.co.uk/itm/5pcs-TP4056-with-Battery-protection-LIPO-Charger-Module-Board-Micro-USB-TE420-/301905672102?hash=item464afaf7a6:g:YecAAOSwneRXQqwy for an example of a charger with a protection circuit built in)
This has a typical quiescent current of 3 uA. In the example the TP4056 charger chip is also connected, with another 3 uA of quiescent current.
A lot of the lithium cells will come without surch protection circuits, and this is good for quiescent current. However, because I do want to be able to recharge my battery without damaging it, I'd tie in li-ion usage with the AVR measuring it's own voltage. Since the AVR is measuring it - it can warn of a low battery with the display,...Read more »
To effectively collaborate, a plan is needed to share tasks. This way different bits can be completed simultaneously.
Minimise Active power consumption
Minimise Idle power consumption
This is a rough plan of how the electronics will be joined up.
9V Battery->Diode(s)->5V rail -> All digital components.
HX711->MCU (2 wires)
HT1621->MCU (3 wires, one shared with HX711)
LCD->HT1621 (Built into carrier board)
Half bridge+Set resistors -> HX711 (build on protoboard)
Reset-switch->MCU (build on protoboard)
The ATtiny85 is a small microcontroller with (for it's size) a decent amount of memory.
It's also £1 in one-off quantities from ebay. (I may need to do a comparison between these and a genuine one from Sparkfun!).
They don't ship with a bootloader, and in this project we don't want a bootloader either - it just takes up time when turning on. Because of this we need a programmer to load code onto the device.
Thankfully, a normal Arduino board is perfectly capable of becoming a programmer. Because the ATtiny85 will need to be reprogrammed many times, I've adapted the top of a protoshield to include a 8-pin DIP socket. (pictured?). It's wired according to the excellent instructions here: http://highlowtech.org/?p=1229. There is one exception - I don't need a capacitor to keep the original Arduino from resetting, since I have a Seeeduino V2.1 - it has a switch to disable auto-reset (as well as a 3.3v/5v switch!).
The code also needs to be somewhat updated from the instructions, as the Arduino IDE has gone through several versions since then.
Anyway, once it's all operational, a simple breadboard test should show it works.
Become a member to follow this project and never miss any updates