**LOW** Power applications

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

Reply to
Giorgis
Loading thread data ...

Hello George,

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:

formatting link

--
Regards, Joerg

http://www.analogconsultants.com
Reply to
Joerg

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

Joerg wrote:

formatting link

Reply to
Giorgis

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

--
"it\'s the network..."                          "The Journey is the reward"
speff@interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com
Reply to
Spehro Pefhany

Maybe this will give you some ideas...

formatting link

Luhan

Reply to
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.
Reply to
linnix

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

Reply to
Luhan

Hello George,

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.

--
Regards, Joerg

http://www.analogconsultants.com
Reply to
Joerg

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

Joerg wrote:

Reply to
Giorgis

In article , Giorgis wrote: [....]

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.

--
--
kensmith@rahul.net   forging knowledge
Reply to
Ken Smith

In article , linnix wrote: [...]

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.

--
--
kensmith@rahul.net   forging knowledge
Reply to
Ken Smith

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

Reply to
linnix

Hello George,

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).

--
Regards, Joerg

http://www.analogconsultants.com
Reply to
Joerg

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

Reply to
Giorgis

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

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.

Reply to
Tim Shoppa

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.

Reply to
linnix

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

Very power hungry

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

Reply to
Giorgis

In article , Giorgis wrote: [....]

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

--
--
kensmith@rahul.net   forging knowledge
Reply to
Ken Smith

In article , linnix wrote: [...]

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.

--
--
kensmith@rahul.net   forging knowledge
Reply to
Ken Smith

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.

Reply to
Tim Shoppa

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.