**LOW** Power applications

[Giorgis]

Hi Guys, I would like to setup a data logger that will log about 10
sensors over 12 weeks on battery power alone. The interesting data will
come in only as a few events over those 12 weeks. How can I go about
it.

I would like to keep the size and the price low. Any ideas ?

regards
George

 

[Joerg]

Hello George,

Hi Guys, I would like to setup a data logger that will log about 10
sensors over 12 weeks on battery power alone. The interesting data will
come in only as a few events over those 12 weeks. How can I go about
it.

I would like to keep the size and the price low. Any ideas ?

If it has to be cheap you'd have to design it. But for only 12 that
won't make sense. If you want to you could use the TI MSP430 and let it
go to sleep mode until an interrupt happens. How to do that will
dependson the sensor output.

If you don't want to roll your own check if one of these could work:
http://www.lascarelectronics.com/PR...b6889ffa2-6C18B0D6-15C5-5FA1-6233D7AA92D37861

 

[Giorgis]

Thanks Joerg, I know of these and already have the temp logger.
I am now going down the path of designing one my self.
I will have to log a single event that will happen for an instant and
then go away.
So an interrupt will wake my device and then the event is no longer
there.

I am still considering my options

Kind thanks
George

 

[Spehro Pefhany]

Hi Guys, I would like to setup a data logger that will log about 10
sensors over 12 weeks on battery power alone. The interesting data will
come in only as a few events over those 12 weeks. How can I go about
it.

I would like to keep the size and the price low. Any ideas ?

regards
George

12 weeks is not a long time for battery power. If the sensor takes
little power and if it only has to be checked once in a while, almost
any CMOS microcontroller will do the trick. MSP430, PIC (preferably
the low power series) etc. A typical approach would be to use a watch
crystal to clock the unit under most conditions, and perhaps a second
clock source such as a 4MHz crystal for serial communications when
it's time to upload the data. You can make it run from a lithium
button cell, AA batteries or whatever. Depending on the micro you may
need to provide BOR or other functions off-chip to get the current low
enough.



Best regards,
Spehro Pefhany

 

[Luhan]

Hi Guys, I would like to setup a data logger that will log about 10
sensors over 12 weeks on battery power alone. The interesting data will
come in only as a few events over those 12 weeks. How can I go about
it.

I would like to keep the size and the price low. Any ideas ?

Maybe this will give you some ideas...

http://members.cox.net/berniekm/spydar.html

Luhan

 

[linnix]

12 weeks is not a long time for battery power. If the sensor takes
little power and if it only has to be checked once in a while, almost
any CMOS microcontroller will do the trick. MSP430, PIC (preferably
the low power series) etc.

Or an AVR, 1.8V / 0.02 mA at 32KHz. 5V / 20 mA at 2MHz.

A typical approach would be to use a watch
crystal to clock the unit under most conditions, and perhaps a second
clock source such as a 4MHz crystal for serial communications when
it's time to upload the data.

If time is not absoulely critical, you can use the internal RC. Set it
to 32KHz regularly and boost it to 2MHz (for 19200 baud) for data dump.
You also need to switch off the RS232 drivers (eg. Max232), since it
draws 10mA all the time. You can log the start and end real time to
recalibate your data stream.

You can make it run from a lithium
button cell, AA batteries or whatever. Depending on the micro you may
need to provide BOR or other functions off-chip to get the current low
enough.

BOR/DOD included in most AVR. Triggered at 2.7V or 1.8V.

We are currently running an experiment with such:
Run at 2Mhz for 1/10 of a second, use A2D to check the battery voltage.
Talk to the PC. Drop to 32KHz for 9/10 of a second. We are using 2
1600mA C cells. It is day 2 of the test, with the max232 connected.
The next test will have the max232 power off as well. I will report
back on the results.

 

[Luhan]

Or an AVR, 1.8V / 0.02 mA at 32KHz. 5V / 20 mA at 2MHz.


If time is not absoulely critical, you can use the internal RC. Set it
to 32KHz regularly and boost it to 2MHz (for 19200 baud) for data dump.
You also need to switch off the RS232 drivers (eg. Max232), since it
draws 10mA all the time. You can log the start and end real time to
recalibate your data stream.


BOR/DOD included in most AVR. Triggered at 2.7V or 1.8V.

We are currently running an experiment with such:
Run at 2Mhz for 1/10 of a second, use A2D to check the battery voltage.
Talk to the PC. Drop to 32KHz for 9/10 of a second. We are using 2
1600mA C cells. It is day 2 of the test, with the max232 connected.
The next test will have the max232 power off as well. I will report
back on the results.

Good approach. Works the same way with PICs. Also, data may be stored
in internal (256 bytes) or external (mucho) eeprom and dumped later.
If logged events cause a digital data transistion, then there is also
Sleep mode - could run that way for years.

Luhan

 

[Joerg]

Hello George,

Thanks Joerg, I know of these and already have the temp logger.
I am now going down the path of designing one my self.
I will have to log a single event that will happen for an instant and
then go away.
So an interrupt will wake my device and then the event is no longer
there.

I am still considering my options

Can you define "event"? Do you have to log a waveform, pulse shape, or
just a peak value? How long is the event? Required sample rate? That has
a large impact on how much to invest in analog pre-processing and how
much the uC can take over. For example, while a uC such as the MSP430 is
rather frugal even with a running oscillator (at a low frequency) this
changes dramatically if you'd need to keep the ADC and a reference running.

Next, what size batteries can you afford? A couple of AA, or a couple of
D cells? Also a huge difference.

 

[Giorgis]

The event can be described as a crash. Let's say I will have this
device in a car and all it will do is record when the crash will occur.


The current thaught is that it should sleep and when the event occurs
an interrupt will be generated. Now is it possible the accelerometer
record the level and some how the device wakes up, stores the value and
goes to sleep again ?

Kind thanks
George

 

[Ken Smith]

The current thaught is that it should sleep and when the event occurs
an interrupt will be generated. Now is it possible the accelerometer
record the level and some how the device wakes up, stores the value and
goes to sleep again ?

If the time it takes for the micro to wake up is well known you can use a
circuit that works like this:


---/\/\----
----!+\ ! !
! >-----+---->!-----+---+----
--!-/ !
! !
---------------------------+
!
---
---
!
GND

The circuit as drawn won't actually work. I've left stuff out so it is
easy to explain the concept. The diode allows the capacitor to be quickly
charged by the op-amp. The resistor makes for a slow discharge following
a predictable curve. The micro reads the voltage at a known point on the
curve so you just have to scale the result and you have the peak voltage.

In real life, the diode's function is more likely to be done with a
transistor. You want a low idle current in the op-amp but you also want
to charge the capacitor quickly to the needed voltage.

 

[Ken Smith]

If time is not absoulely critical, you can use the internal RC. Set it
to 32KHz regularly and boost it to 2MHz (for 19200 baud) for data dump.
You also need to switch off the RS232 drivers (eg. Max232), since it
draws 10mA all the time. You can log the start and end real time to
recalibate your data stream.

I would advise against using any Maxim part. In this case, you may be
much better off making your own RS-232 driver. An RS-232 signal needs to
rest at -3V or more. Instead of making your own minus voltage, I suggest
you use the RS-232 signal from the PC used to read out the data as a
supply.

 

[linnix]

I would advise against using any Maxim part. In this case, you may be
much better off making your own RS-232 driver. An RS-232 signal needs to
rest at -3V or more. Instead of making your own minus voltage, I suggest
you use the RS-232 signal from the PC used to read out the data as a
supply.

Oh no, I would not depend on Maxim. I am using second sources from
Sipex, ST and TI.

 

[Joerg]

Hello George,

The event can be described as a crash. Let's say I will have this
device in a car and all it will do is record when the crash will occur.

The current thaught is that it should sleep and when the event occurs
an interrupt will be generated. Now is it possible the accelerometer
record the level and some how the device wakes up, stores the value and
goes to sleep again ?

Yes. Ken hinted in the right direction. Assuming the accelerometer
output is analog you can develop a circuit that catches the peak and
holds that value for a few hundred msec or whatever time it takes for
the uC to wake up. A MSP430 can wake up in under 10usec but it'll still
need some time after that to read the analog value which will commonly
reside in a small storage capacitor.

So, the analog circuit would do two things:

a. Generate a digital interrupt to the uC, to one of its port pins. This
is commonly done by employing a comparator whose output logic status
changes when a preset threshold has been exceeded. That is your "event
signal". This causes the uC to wake up and then, after verifying that
its innards work ok it would jump to the memory address that contains
your code.

b. Track the accelerometer signal and store the highest value in analog
fashion. That would become your "event magnitude indicator". This could
be done via an "ideal rectifier" comprised of comparator stages. So if
you spend enough time on it you could possibly do it with a cheap quad
comparator plus maybe an opamp and a few discrete parts, plus that mirco
controller and whatever else you'd like to provide behind it (Horn,
LEDs, display, comms port, wireless link etc).

 

[Giorgis]

Oh no, I would not depend on Maxim. I am using second sources from
Sipex, ST and TI.

Guys, I am floored !!! This is looking exactly like what I want.

Would you beleave I started thinking I need an SBC and they seem to
consume about 1W. Over 12 weeks it seemed like I needed $300 of battery
with about 300 cycles before death the whole excersize looked like a
fizzer. Now It looks very possible and alot of fun

Thanks a million

Regards
George from Sydney

 

[Tim Shoppa]

The event can be described as a crash. Let's say I will have this
device in a car and all it will do is record when the crash will occur.

The traditional way of doing this (dating from pre-digital watches!) is
to read what the watches on the corpses say!

The current thaught is that it should sleep and when the event occurs
an interrupt will be generated. Now is it possible the accelerometer
record the level and some how the device wakes up, stores the value and
goes to sleep again ?

You can use the same idea as "read the watches from the corpses", just
continually store all the relevant parameters however many times a
second you need, UNTIL the trigger occurs when you stop storing.

You are still extremely vague are power requirements and data rates,
and this is VITAL for what you want to do. Many here work in the
nanosecond realm but for typical land vehicles getting updates a few
times a second is normally pretty fine-grained!

Having had my hands on some detailed black-box data, for a typical land
vehicle having speed/velocity/acceleration for a few seconds before the
event at a resolution of 1/100th of a second is EXTREMELY instructive.
That's way more resolution than you need, for most purposes 1/20th of a
second is good enough.

If you need "exact time" then clock drift of a free-running clock
becomes an issue. Synchronizing with some outside-the-vehicle data for
timing is often essential. In the vehicle black-box recorders that I
work with, having clocks that are off by an hour or more is very common
(the clock is set when the vehicle is new or in for major overhauls,
which may be a different time zone or a different DST, and then it
starts drifting.)

Tim.

 

[linnix]

[...]
If time is not absoulely critical, you can use the internal RC. Set it
to 32KHz regularly and boost it to 2MHz (for 19200 baud) for data dump.
You also need to switch off the RS232 drivers (eg. Max232), since it
draws 10mA all the time. You can log the start and end real time to
recalibate your data stream.

I would advise against using any Maxim part. In this case, you may be
much better off making your own RS-232 driver. An RS-232 signal needs to
rest at -3V or more. Instead of making your own minus voltage, I suggest
you use the RS-232 signal from the PC used to read out the data as a
supply.

Oh no, I would not depend on Maxim. I am using second sources from
Sipex, ST and TI.

Guys, I am floored !!! This is looking exactly like what I want.

Would you beleave I started thinking I need an SBC and they seem to
consume about 1W. Over 12 weeks it seemed like I needed $300 of battery
with about 300 cycles before death the whole excersize looked like a
fizzer. Now It looks very possible and alot of fun

The trick is power management. At 10mA, the Max232 is drawing several
time more power than the micro at idle. I am redesigning my circuit to
turn it on only when a cable is connected (A2D the DTR signal). The
Max232 (started out at Maxim, second sources from many) is about $1,
but it requires 4 1uF caps (a penny each). Siplex actually has a part
with build in caps, but they wants $3 each.

 

[Giorgis]

The traditional way of doing this (dating from pre-digital watches!) is
to read what the watches on the corpses say!

Its a thaught but that sounds event has to be fairly terminal.

You can use the same idea as "read the watches from the corpses", just
continually store all the relevant parameters however many times a
second you need, UNTIL the trigger occurs when you stop storing.

Very power hungry


<<SNIP>>


I am leaning towards an analogue circuit that is faily low power. This
circuit will store the peak data in a capacitor until the devices wakes
up, records the data, maybe recordes the sensors for a few minutes and,
discharges the capacitor and goes to sleep.

George

 

[Ken Smith]

I am leaning towards an analogue circuit that is faily low power. This
circuit will store the peak data in a capacitor until the devices wakes
up, records the data, maybe recordes the sensors for a few minutes and,
discharges the capacitor and goes to sleep.

You can get a bit more data by recording both polarities of the peak and
perhaps doing the peak detection in two frequency bands.

 

[Ken Smith]

The trick is power management. At 10mA, the Max232 is drawing several
time more power than the micro at idle. I am redesigning my circuit to
turn it on only when a cable is connected (A2D the DTR signal). The
Max232 (started out at Maxim, second sources from many) is about $1,
but it requires 4 1uF caps (a penny each). Siplex actually has a part
with build in caps, but they wants $3 each.

You can power the output circuit from the connected RS-232. This would
require that you not use the MAX232. I'm thinking along these lines:


!!-- Vcc
From micro -------!! P-MOSFET
!!--------+-------------- TXD
!
\
/
\
! C1
+--!!--GND
!
V
---
!
------------+--------------- RXD


If Vcc is at least 3V, this will work. With the RS-232 cable not plugged
in, the circuit floats and only the leakage in C1 matters. The P-MOSFET's
leakage is taken out of the picture.

 

[Tim Shoppa]

I am leaning towards an analogue circuit that is faily low power. This
circuit will store the peak data in a capacitor until the devices wakes
up, records the data, maybe recordes the sensors for a few minutes and,
discharges the capacitor and goes to sleep.

May work for you but I think you're missing the most valuable data.
Again you're being intentionally vague about what this is all about,
but BY FAR the most interesting data from a black-box recorder is the
minutes (even half hour or hour if you're concerned about equipment
failure, correlated with "normal" operations) before the crash! Not the
minutes after the crash.

I know you're looking at power-hungry boards for doing this but truly
the CPU horsepower is minimal: recording a dozen parameters a hundred
times a second should not take more than a few milliamps! And you have
the 12V vehicle battery (at least up to the crash), right?

Tim.