View source for Mcu 0084-voltage-datalogger


Voltage data logger

This project came to life when I wanted to measure my solar-panel assisted 124Ah SLA battery in my shed. I wanted to use the battery for powering other projects and realised that ideally I should be able to measure the voltage at regular intervals to make sure that the voltage isn't running too low. 

Ideally what I want for this device is:

* a small handheld device
* battery powered using common batteries
* long battery lifetime
* recharge batteries through USB port (not implemented yet)
* measure input voltages between 0 - 15V (0 - 20V as it turns out)
* (almost) no drain on the battery being measured
* basic information through LCD module
* able to set accurate sampling times (e.g. every n second(s), minute(s), hour(s), day(s))
* store measurements in the device
* extract measurement data through USB connection to a PC



==Phase 1 determining the functional design==

Similar as above:

===a small handheld device===

I wanted a device that I can bring to the voltage source that I am interested in, so anything running of mains power was not considered. Since I've made some other projects with microcontrollers I was keen to come up with a design that would fit in the palm of your hand, about similar in size to a TV remote control unit. The biggest components would be the LCD module and the battery compartment. 


===energy efficient microcontroller===

I have been using the ATtiny85 and 84 microcontrollers for various projects over the years. When in sleep mode these devices draw about 5uA. These will be quite suitable for this project. Since I will be driving an LCD module I expect to need some extra IO hence the 14-pin ATtiny84 will be the device of choice for this project.

[[File:T84.jpg|thumb|none|200px|ATtiny84]]

===battery powered using common batteries===

The ATtiny84 can be fed with anything between 2.7V and 5.5V DC. All the other components it needs to interface with can also run in this range. I decided to run the mcu and the main peripherals on 5V using a boost converter. The LTC3525 uses only 3 external components to output 5V and it's very simple to use. Soldering the chip required a steady hand. The total width of the chip is only 2mm and the pin spacing is about 0.65mm!

[[File:LTC3525 recommended placement.png|thumb|none|250px|LTC3525 400mA Boost Converter]]

[[File:LTC3525-ESC6-5-PBF SC70.jpg]]

[[File:LTC3525.pdf]]

Input voltage range for the boost converter is between 0.5V and 6V so this can easily be accomplished by feeding it with 2x AA or 2x AAA batteries. The handheld enclosure I can pick up easily from my local electronics store has a compartment for either 1x 9V or 2x AA batteries. Since the capacity of a 9V battery is very poor and the AAA are not a good fit for this enclosure I decided to go with 2x AA batteries. With rechargeable NiMH this will give us 3V and a capacity of around 2800mAh for two batteries in series and with non-rechargeable Alkaline it will be around 1500mAh for two in series.

(I did not end up using a battery charger circuit in this version, so although rechargeable batteries will work, I will have to take them out and charge them externally with a separate charger)


===long battery lifetime===

The device should be able to take measurements for extended periods at regular intervals. My aim is to have enough power to have the device running on a single charge for at least a few months. We can achieve this by choosing low-power components and putting the microcontroller in sleep mode in between sampling. There are trade-offs of course. One being that the LCD module can not be constantly powered between measurements because it draws too much power. If we take a conservative approach and assume that we're running off non-rechargeable Alkaline batteries we will have about 1500mAh to go around. To get a lifetime of a year we must make sure the constant current drain does not exceed 171uA (1.5A / 8760 hours in a year). In the end it will be a combination of a much lower current drain for the sleep period (e.g. perhaps around 50uA) and a much higher current drain during the actual taking of the measurement (e.g. 20mA, to wake up the mcu, perhaps briefly enable the LCD, drive some FETs and/or transistors, activate a voltage divider, do the processing, etc..) and then go back into sleep mode.

===recharge batteries through USB port===

(Nice to have, but the current project design did not include this feature)

Since USB will be used to retrieve data (see below) we can make use of the power lines of the USB port of the host system (PC or Laptop) to recharge the on-board batteries. There should be a physical switch as well as some intelligence to determine whether or not the unit contains rechargeable batteries but if it has then we can use up to 500mA from a USB port for a battery charging circuit. The battery charging circuit should be able to measure and adjust the voltage down from 5V (maximum of about 3.5V across 2x AA NiMH batteries in series) and it should also be able to measure and adjust the charging current (charging 2800mAh AA NiMH's at 1C would be 2.8A but we're limited by the USB port to about 500mA, so this results in about 17% of 1C). During charging the circuit should constantly measure voltage, current and battery temperature and time elapsed. It should automatically cut off when the batteries are charged. The charging time is probably going to be several hours but it should be a simple plug-in-and-wait scenario.

UPDATE: the battery charging feature is useful to have, but after having used this datalogger for a few years now I haven't really had a need for it. Most times my datalogging needs were completed after a few days, with some experiments spanning a couple of months. The batteries last a long enough time to not have to worry about it and it also minimises the risk of leaking chemicals by having to remove batteries every once in a while anyway.


===(almost) no drain on the battery being measured===

A simple resistor voltage divider seems perfect for measuring the input voltage. However, if this device is used to measure the self-discharge of a single AA NiMH battery then it becomes apparent that the voltage divider needs to be disconnected when the mcu is in sleep mode. This can be achieved by adding a P-channel FET in series as they are voltage-controlled devices and draw almost no current (see schematic below). The microcontroller will be able to switch on the P-channel FET using an N-channel FET with practically no additional current draw and when the measurements have been taken the FETs are turned off and the voltage divider returns to high-impedance and will cause no further load on the voltage source to be tested.


===measure input voltages between 0 - 20V===

Most voltages that I am able to work with safely (and legally) in and around the house can be up to 24DC. When charging batteries the voltage can go up to 15 Volts so I thought 0 to 20 volts would be a good range. I should be able to change this to 0 - 50V or so if I want to measure Solar panel open-circuit voltage but that's not an immediate need. The ADC on the t84 can be set to 10 bits resolution, so with 20V maximum input voltage that could give a theoretical resolution of about 0.019uV per step.

* NOTE: I have not yet taken the steps to incorporate a dedicated reference voltage chip as I'm fairly hopeful that the boost converter will produce a steady voltage. If however the sampling is not stable enough I will have to work on this part at a later stage. There is a possibility to use an internal 1.1V reference voltage. This is a feature inside the ATtiny84. All that's required to use this method is to change the voltage divider resistors with parts that bring down the maximum voltage to 1.1V and modify the code slightly to change a multiplier to a value that is calibrated with the real voltage.


Shown below is a basic resistor voltage divider that will bring down the 0V to 20V input voltage to 0V to 5V for the ADC.

[[File:0084-pfet-vdiv-0.png]]

Although this technique will work fine, it will constantly discharge the voltage-device-to-measure a little bit through the resistors. At 12V the drain will be around 1.7mA. Even though this is not much, we want to limit this current drain as much as we can. Imagine a setup where a measurement is taken once per hour. The datalogger will be in sleep mode for 99.99% of the time and only wake up for a few ms to take a sample and then go back to sleep again. The above voltage divider will continue to drain the battery-under-test even when we're not taking samples. Ideally we want to 'disconnect' the voltage divider (between the V1 and R2) when the micro is in sleep mode. One way to do this is by using a FET (Field Effect Transistor) in series with the resistor voltage divider network.


{{Info
|info = ''
In this design I will be using FETs to connect and disconnect the voltage divider from the device under test. 
To clear up some terminology I will be using the following terms in this document:

* DUT 

The Device Under Test (dut), aka the DC voltage source we wish to measure. In most cases this will be a 12V battery, 
but it could also be a single AA battery at 1.5V.

* FET

Field Effect Transistor. I will be using enhancement-mode FETs and they will either be P-Channel (pfet) or N-Channel (nfet) types.

* Conducting FET

When the FET is conducting I will often use the terms 'low impedance', 'on' and 'conducting' interchangeably.

* Non-Conducting FET

When the FET is not conducting I will often use the terms 'high impedance', 'off' and 'non-conducting' interchangeably.

* open vs close

The terms 'open' and 'close' are mostly avoided as it can be interpreted both ways when saying that a fet is open. Do we mean it is open-circuit and not conducting or open for current to flow?

''

}}


The idea is that we want to have a FET at high impedance during sleep mode and aim for minimal (preferably no) drain on the device under test.



Here are a few statements regarding a P-Channel FET:

* If the Gate and the Source are both at the same voltage, a P-ch fet does not conduct.

* The fet will (start to) conduct when the Source voltage is 'Vgs(th)' (a few volts) more positive than the Gate voltage.

* Lowering the Gate voltage will turn the fet on (and make it conducting). Alternatively, increasing the Source voltage has the same effect. 



Let's walk through the following scenarios:

* pfet off (high impedance) when not taking ADC measurements
* pfet on (low impedance) when taking measurements


Let's say we have a pfet on the high side with the Source connected to 5V+, the Drain through a 4k7 + 2k2 resistor voltage 
divider to Ground and the Gate held high by connecting it to a 100k pull-up resistor also to 5V+. 


[[File:0084-pfet-vdiv-1.png]]

The difference between Source and Gate is practically 0V because they're both connected to +5V. A pfet with a Vgs(th) of around -3V will be in high-impedance mode. Therefore in the above schematic, the fet will be turned off and the voltage divider network will measure 0V. The drain on the DUT is very close to 0A, probably only a few nA.

So for a pfet we can say:

Vgate equals Vsource   --> high impedance (aka 'disconnected')

Vgate a few volts below Vsource  --> low impedance (aka 'conducts')

In the above schematic the ADC (the tap point that goes to the microcontroller to measure the voltage using the Analog-to-Digital Converter) will practically see 0V at any voltage because the pfet is always in high impedance. There will be almost no current drain on the Device Under Test (DUT, the voltage source such as a battery we wish to measure). This is exactly what we want when the microcontroller is not taking any measurements.


Next we need to find a way to bring the p-fet into a conducting state.


The easiest way is to bring the Gate to ground (0V). The difference between Vgate and Vsource will then be greater than Vgs(th) and Vsource will be more positive than Vgate. Doing so will turn the fet fully on, which is what we want to make use of the voltage divider network for ADC sampling.


Let's introduce a microcontroller that will have an OUTPUT port that can control a device (here shown as a 'switch') that can control whether the P-ch fet's Gate is connected to ground or not. If it is connected to ground the 100k resistor will draw a bit of current, but this is negligible for the short duration of sampling. If it is left floating, the Gate of the p-fet will go high to the Voltage of the DUT. 

[[File:0084-pfet-vdiv-2.png]]

The question is, what kind of a device does this? In theory a mechanical relay could do the trick, but it has three main drawbacks: due to its mechanical nature it has a very limited lifespan (metal fatigue), over time the arcing of the contacts could cause the relay from working properly and lastly the coil to engage the magnetic field is not very efficient and draws several milli-amps.

The preferred solution is again a fet. This time however we'll use an N-Channel fet because we will be switching ground on and off.


INSERT: blurb about why fets and not bjts


Here is a proposed schematic that allows us to switch two fet's with with hardly any current and will have practically no current draw when the fets are turned off.

[[File:0084-pfet-vdiv-3.png]]

Here the OUT port of the microcontroller is simply a digital out that switches HIGH to 5V (supplied voltage from V2) or LOW to 0V. Setting these voltages to the gate of the N-ch fet (a common 2N7002) will cause it to respectively conduct or not. When the N-ch fet is conduciting (when supplied 5V) it will provide a path to ground for the Gate of the P-ch fet and we can take a sample from the voltage divider R3/R2 (the naming of the resistors may have changed with earlier schematics). 


There is however one big problem with this setup.

The title of this section mentions that we wish to measure DC voltages from 0V to 20V. The current schematic will not be able to measure voltages lower than Vgs(th) than the P-ch fet is rated for.

Let's see why this is the case:

Here is a table that shows the various voltages of interest

===Table 1: on/off fet switching at 5V DUT=== 

{| class="wikitable"
|+FET Gate voltages
|-
|V2 (uC)
|V1 (DUT)
|Vg Nfet
|Nfet state
|Vs Pfet
|Vg Pfet
|diff Vgs Pfet
|Pfet state
|Comments
|-
|5.0
|5.0
|0.0
|not conducting
|5.0
|5.0
|< Vgs(th)
|not conducting
|uC Output LOW (0V), Resistor voltage-divider: OFF
|-
|5.0
|5.0
|5.0
|conducting
|5.0
|0.0
|> Vgs(th)
|conducting
|uC Output HIGH (5V), Resistor voltage-divider: ON
|}

This table shows how the various voltages change when the microcontroller sets the OUT line from LOW to HIGH. 

For clarity I have added also the V1 and V2 sources, but it can be concluded that the maximum voltage the microcontroller can set on the OUT line is its Vcc voltage (i.e. 5V). Therefore, the Gate voltage on the N-Ch fet will never receive more than 5V. This is enough over overcome Vgs(th) on the N-ch fet as it's between Ground (0V) and the OUT HIGH (5V). We can conclude that Vg Nfet simply depends on whatever voltage is supplied to the micro by V2.

In a similar fashion it can also be concluded that Vs Pfet is simply the voltage on the Device under Test (V1).

Lastly (and this is the problem), in this arrangement Vg Pfet can only be set to 0V or 5V.


To show where the issue is, let's measure DUT voltages from 5V down to 0V in half-volt steps.

===Table 2: measuring 0-5V DUT=== 

This table uses a P-Ch FET with a Vgs(th) of around 2.35V. This means that when the voltage on Vg comes to within 2.35V of Vs the fet will stop conducting (assuming that Vs is always equal to or greater than Vg). Watch the column showing the difference between Vg and Vs and it will become clear what is happening.

{| class="wikitable"
|+FET Gate voltages with DUT voltages between 0 - 5V
|-
|V2 (uC)
|V1 (DUT)
|Vg Nfet
|Nfet state
|Vs Pfet
|Vg Pfet
|diff Vgs Pfet
|Pfet state
|Comments
|-
|5.0
|5.0
|5.0
|conducting
|5.0
|0.0
|> Vgs(th)
|conducting
|uC Output HIGH (5V), Difference Vgs(th) way greater than 2.35V, all good
|-
|5.0
|4.5
|5.0
|conducting
|4.5
|0.0
|> Vgs(th)
|conducting
|Diff Vgs(th) around 4.5V, all good
|-
|5.0
|4.0
|5.0
|conducting
|4.0
|0.0
|> Vgs(th)
|conducting
|Diff Vgs(th) around 4.0V, all good
|-
|5.0
|3.5
|5.0
|conducting
|3.5
|0.0
|> Vgs(th)
|conducting
|Diff Vgs(th) around 3.5V, all good
|-
|5.0
|3.0
|5.0
|conducting
|3.0
|0.0
|> Vgs(th)
|conducting
|Diff Vgs(th) around 3.0V, barey conducting
|-
|5.0
|2.5
|5.0
|conducting
|2.5
|0.0
|~ Vgs(th)
|half conducting
|Diff Vgs(th) around 2.5V, linear region, pfet is going high impedance
|-
|5.0
|2.0
|5.0
|conducting
|2.0
|0.0
|< Vgs(th)
|not conducting
|Diff Vgs(th) around 2.0V, pfet is high impedance, voltage to ADC is now 0V
|-
|5.0
|1.5
|5.0
|conducting
|1.5
|0.0
|< Vgs(th)
|not conducting
|Diff Vgs(th) around 1.5V, pfet is high impedance, voltage to ADC is now 0V
|-
|5.0
|1.0
|5.0
|conducting
|1.0
|0.0
|< Vgs(th)
|not conducting
|Diff Vgs(th) around 1.0V, pfet is high impedance, voltage to ADC is now 0V
|-
|5.0
|0.5
|5.0
|conducting
|0.5
|0.0
|< Vgs(th)
|not conducting
|Diff Vgs(th) around 0.5V, pfet is high impedance, voltage to ADC is now 0V
|}


To illustrate this in a graph, here is a plot of two lines. The green line is the DUT voltage and the blue line is the voltage measured at the ADC tap point.

[[File:0084-pfet-vdiv-4.png]]
x-axis: DUT voltage, y-axis: ADC voltage

Follow the ADC trace (blue line) from right-to-left and notice that for a DUT (green line) above 2.5V the ADC connected to the voltage-divider is able to get a proper reading, but as soon as the DUT voltage goes below 2.5V the pfet cannot open anymore and the voltage divider never gets connected to the DUT.


It now becomes obvious that the pfet is ineffective when the difference between Vs and Vg is less than Vgs(th).


So how can we measure DUT voltages between 0V - 2.5V ?


Remember that the issue is that the difference between DUT voltage and 0V is less than Vgs(th)? If we can't increase the DUT voltage, why not go lower than 0V? A negative voltage.


===Negative bias to the P-FET===

Let's see what our results look like if we just look at providing -3V at the Gate of the pfet.

[[File:0084-pfet-vdiv-5.png]]

All the way down to 0V a perfect slope on the ADC tap point. This proves that providing a negative voltage will work.

There are few simple techniques that can achieve this. If we pulse-charge a capacitor, prevent power going in the positive direction and provide a discharge path other than to ground we can get a pulsing negative voltage. With two caps and two diodes we can easily get to -4.7V which will be enough to properly 'close' the P-Channel FET for measurements close to (and even a bit below) 0V. (another technique uses a bootstrap capacitor but we won't go into that here, for more information locate AN-6076.pdf at https://www.fairchildsemi.com/application-notes/AN/AN-6076.pdf)

Since we're already using a microcontroller for ADC sampling it becomes a fairly easy job to generate the required pulses.



Here is a schematic using a similar technique to provide an LCD Bias Voltage when driving the LCD at lower voltages. The application is different but the idea is perfectly usable for our project.

[[File:Charge-pump-based-negative-voltage-gen.png]]


Commercial products are also available, like the CAT661 from OnSemi ( http://www.onsemi.com/pub_link/Collateral/CAT661-D.PDF ). We're just going to build our own using the PWM feature from the microcontroller.



Here is the final schematic of the voltage-divider ADC sampling section including the FETs that turn everything on and off.

[[File:0084-pfet-vdiv-6.png]]


* The PWM ranges from 0 - 5V and has a duty cycle of 50%. It can be seen on the light-blue trace.

* The negative voltage generated is about -3V and can be seen on the red trace.

* The DUT voltage is plotted in the green trace

* The ADC tap point is in dark-blue


As you can see, all the way down to 0V do we have a useful voltage at the ADC sampling point.


Turning the PWM off will bring the N-Ch fet Gate and the Source to 0V potential and seen from the Drain it will be high impedance. The pull-up resistor between Gate and Source on the P-Ch fet causes the Gate to float up to DUT voltage. This makes the P-Ch fet non-conducting.

===basic information through LCD module===

The handheld enclosure defines the maximum size of an information display. I have used several 2x16 character LCD modules and their setup is now very familiar to me. 

[[File:SD1602G2.jpg]]


Without backlight the LCD will have a current draw of around 25mA. This doesn't seem much but running on batteries it could run them flat in about 120 hours (5 days) of constant use. Great for short-term projects where the device is running off USB or switched on for short periods at a time but not ideal for a measurement task that could last a week. There will be some pushbuttons underneath the LCD to navigate to some sort of setup menu. This menu should allow the user to select a sampling interval and maybe some other parameters (e.g. LCD sleep timeout, data export, wipe memory, etc..)

===able to set accurate sampling times (e.g. every n second(s), minute(s), hour(s), day(s))===

The ATtiny mcu can do sleep modes just fine but the waking process isn't accurate in it's timing. Initially I used a watchdog-timer to wake up the t84 at intervals, but it turns out these intervals are depending on internal clock speed and without a crystal they can be very inaccurate. I decided not to use an external crystal for the mcu as it still didn't allow me to accurately time wake-up events without a constantly proces of waking up the mcu, checking a counter, go back to sleep. 

After finding a low-power RTC (RealTime Clock) that can be controlled over I2C and draws only 5uA I knew I had something I could work with. The component I'm keen to use for this application is the Intersil ISL1218.

[[File:Isl1218.jpg]]

[[File:ISL1208.pdf]]

The device can be set to a certain time (say, 1 hour from now) and send an interrupt to the mcu to wake it up to do a measurement. The RTC only needs an external crystal to work.

It also caters for a backup battery (in the scenario where you can replace the 2x AA batteries in between measurements and have the datalogger perform the next measurement exactly on time as if nothing ever happened. I am not planning on using this feature but it is nice to know.

===store measurements in the device===

Voltage samples that are taken should be stored-and-retrieved using on-board non-volatile memory. EEPROM with an I2C interface is the preferred choice here. This means it doesn't take up any extra pins on the micro and it can just sit on I2C bus. Devices like the 24LC512 can store 64kBytes of data and are very low power (less than 1uA) when idle.

[[File:24LC512.jpg]]

At some point I may even wish to expand this feature to make use of a micro-SD card. These cards hold lots of storage and can be interfaced using SPI.

===extract measurement data through USB connection to a PC===

A micro-USB port on the device allows interfacing with a PC or laptop to retrieve measurement data. A third-party USB-to-UART module will be used to deal with the USB side to the PC and once connected it will spit out data at a rate of stock-standard 9600 baud 8-N-1. A simple serial terminal program (e.g. hyperterm, minicom) will receive the data once the micro receives an input character.

==Phase 2 selecting parts==

To put it all together I had to make a few decisions that determines some minimum and maximum values as well as what features are going to be incorporated in the final design.

===POWER===

* battery power

2x AA NiMH or Alkaline batteries in series. This will provide between 2.0V and 3.0V.


* battery charging

Battery charging to be done through USB 5V power lines, assuming a maximum capacity of 500mA. I'm planning on using 2800mAh NiMH batteries, giving a maximum of 17% C. This is well below the maximum charge rate so we're very much on the safe side. In the final design I doubt that we will be even getting 500mA as we need to step down to about 3.5V as the maximum voltage across a single AA NiMH cell is about 1.7V.


* running off USB power over battery power when USB is plugged in.

A simple Power-OR'ing circuit using a single P-Channel FET is used to switch between the battery and USB power. When USB is plugged in it will automatically start the battery charging circuit.


* internal power levels

Most components can be used at voltages between 2.7V - 5.5V. I decided to run at 5V as it gives a workable Vgs threshold with FETs to turn on and off. To get to 5V off the batteries I will be using a very small DC-to-DC Boost Converter from Linear Technologies, the LTC3525. The battery charger circuit will run off the USB port 5V power lines as we want it to be completely separate to our datalogger circuit. It is essentially switched of when USB is not connected.

NOTE: 

For versions of this or other projects where a small DC/DC boost converter is required I found the following other parts that deserve further investigation:

[Power Management - Switching Regulators - Step Up (Boost) Regulator]

* Texas Instruments: TPS61222(-EP), TLV61220, TPS61220, LM8850

* Semtech: SC4502, SC4505

* Maxim Integrated: MAX1722, MAX1723, MAX1724, MAX1834



Running directly off the batteries are:

- LTC3525 5.0V boost converter


The devices that will be running on the 5V produced by the boost converter are:

- main ATtiny84 'brains' of the datalogger

- ISL1218 Real Time Clock

- Microchip 24LC512 EEPROM

- Voltage sampling FETs

- SD1602G2_2x16LCD module, ATtiny85, 74HC595 shift register



Running of USB when attached:

- UART to USB module

- ATtiny85(?) NiMH battery charger and associated components

===LCD Module===

I have used the basic 2x16 LCD modules a few times in other projects and with an additional two components (an ATtiny85 and a 74HC595 serial shift register) I am able to drive it over I2C. The current draw is not super-low but it is a very versatile addition to the project and with a simple FET switching it on and off I can just put it to sleep or wake up whenever I need to. At this stage there is no need to graphically display a voltage curve, I rely on post-processing of the exported data using something like an electronic spreadsheet or so. Therefore the requirements for the LCD module is only to display text. I will provide two pushbuttons near the LCD to interact with an on-screen menu system to set certain variables. The size of the LCD module determines for a large part the 'smallness' of the design. The module I will be using is the SD1602G2.

===PC RS-232 interfacing===

These days very simple USB-to-UART converter boards are available on eBay. Instead of rolling my own I will be using a pre-made module to communicate over RS-232. 

[[File:CP2102.jpg]] CP2102-based TTL to UART over USB adapter

When connected to USB these devices will present a COM-port over USB for which drivers are either already on the system or very easily obtained. Since a variety of other devices use these drivers the chances are you may already have the drivers on your system. To keep things reasonably robust I will limit the transfer speed to 9600 baud. This is more than adequate for exporting the EEPROM memory over RS-232 in a few seconds. Speed is not essential here.

Resources:

* CP2102 Drivers for Windows XP/Server 2003/Vista/7/8/8.1 (v6.7)

[[File:CP210x VCP Windows.zip]]

===Sampling Speed and Interval===


===Minimum Current Draw===



==Phase 3 Design of Schematics and Circuit board==

Final schematic of v1.0 of the datalogger design. The board dimensions (8.6cm x 6.3cm) are based on a plastic Remote Control enclosure, Jaycar PartNr: HB5610


Schematic v1.0 of the datalogger

[[File:0084-v1.0-sch.jpg|none|thumb|200px]]


Schematic v1.0 in PDF format:

[[File:0084-v1.0-sch.pdf]]




[[File:0084-v1.0-pcb top.jpg|none|thumb|200px]]

Circuit Board top view




Version 1.0 of the schematics and PCB done in Diptrace

[[File:0084-voltage-datalogger-v1.0.zip]]

==Phase 4 Assembly of parts and testing ==

These are some first images of the very first unit fully assembled.

[[File:0084-v1.0-final.jpg|none|thumb|200px]]


[[File:0084-v1.0-inside top.jpg|none|thumb|200px]]


[[File:0084-v1.0-topview.jpg|none|thumb|200px]]


[[File:0084-v1.0-detail1.jpg|none|thumb|200px]]



==Phase 5 Datalogger Results==

With the device fully assembled and tested the initial results are quite promising.

[[File:0084-graph-1Ah-discharge-and-charge.png]]

This graph shows the discharge and recharge of a 12V 1Ah SLA battery. The discharge is through a 15 Ohm resistor. Recharging was done by a relatively cheap battery charger. It shows that the battery lasted for about an hour and a half and the recharging took about an hour. Sample interval: once every 5 seconds. Each time interval is 1 hour.

[[File:Powertech-MB-3526.jpg|none|thumb|100px]]



[[File:0084-graph-car-starting.png]]

This graph shows the voltage of my car's battery when starting it. You can see the individual compression cycles and the alternator taking over raising the voltage when the engine is running. Sample interval: about 20ms. Each time interval is 1 second.


[[File:0084-graph-solar-charge-controller.png]]

This graph shows my solar charge controller on a mostly overcast day. Interesting to see how the battery is kept topped up during the day. The solar panel goes into the shade fairly quickly so you're only seeing about 3 hours worth of power generation.


[[File:Powertech MP3129 solar-charge-controller.jpg|none|thumb|200px]]

So we know it uses around 35uA in sleep mode, but in practice, how long can I run the datalogger on two AA batteries for?

I decided to set up one unit to do a self-monitoring test, sampling the datalogger's own power supply, the two AA batteries. I put in two (probably not fully charged) NiMH batteries and set the sampling interval at once every 60 seconds. The idea is to let it run for about three weeks and then see what the battery voltage goes down to. 

This is the result:

[[File:0084-self-sampling-21days.png]]

The starting voltage of the 2x AA NiMH batteries in series was around 2.73V and over time went down to around 2.61V. Several sources on the net mention that AA NiMH batteries are considered empty (without risking too much damage to the battery) at around 0.8V - 0.9V. Given the above data it seems we could be running the datalogger for many months!


It confirms that in the three areas where I wasn't entirely sure how much power was being used there is no immediate need to further improve power consumption.

* the resistor-voltage-divider network to measure the DUT's (device-under-test) voltage isn't significantly draining the DUT's battery.

* the overall board's power consumption (using boost converters, microcontrollers and realtime clocks in sleep or idle mode) while running normally isn't significantly draining the datalogger's batteries.

* the current configuration of waking up every second (interrupt from RTC) and comparing a sample ticks overflow counter isn't significantly draining the datalogger's batteries.


The above graph doesn't even show the self-discharge of the NiMH batteries which is adding additional kindness to the results.


My next test will be to run the datalogger for a few months. I will get 4 AA Alkaline batteries from the same pack (measure them to be sure they're the same voltage) and then put two in the datalogger and leave two next to it. That way I can confirm self-discharge as well.