www.postcogito.org
          ...sine propero notiones

Kiko
You are here: Kiko > PostsInEnglish > EnBlogEntry2008Jan10A Printable | topic end


Start of topic | Skip to actions
Versão em Português

The device
The early concept sketch schematics

Ideas for a Power Minder Device

Rec 10-jan-2008 21:00

Lately there have been a lot of cases where I have been designing computer systems that get installed in places with unreliable power sources. The problem is I don't realize just how unreliable power is at those locations until systems get installed there and, as a result, availability is poor.

That made me wish for a datalogger device specializing in monitoring the mains power lines, taking note of the exact times and durations of power interruptions (or, better yet, overvoltgages and undervoltages). While we are at it, we could also measure the frequency of the AC waveform (60Hz here in Brazil) -- it varies slightly with the load on the grid.

The first step of every project is, of course, research. Googling around, I found this project at the Circuit Cellar's AVR Design Contest 2004. While the design does seem somewhat like I want, I had my misgivings about a detail: it didn't seem optimized for recording quick power "hiccups" -- the AC waveform is filtered through a capacitor. This capacitor slows down the "reaction time" of the device. It also didn't have a backup power source to keep it alive during power failures, which I think it's a must-have for such a device. Besides, I think the design can be considerably simplified.

Recording those hiccups is important to me precisely because they happen a lot in those places I've been talking about. In many occasions, the power goes out for just about a second (maybe less) -- which is enough to make some computers reset. When we have UPSs, we hear their relays click when they engage and disengage quickly in response to the transient.

I also found the kill-a-watt at ThinkGeek and the What's Up family of products. Reading Watt's Up Pro manual did make me want one, but for different reasons -- they're energy meters and would be invaluable to optimize power consumption. However, what I want here and now is a different kind of beast -- I want a power availability logger.

So I set out to (loosely) define my main requirements:

  • Must work both in standalone mode and when plugged to a computer
  • Must be able to capture power failure events on the tenths-of-a-second scale
  • Must log a considerable amount of data -- it may sit forgotten for months before someone comes to collect the data
  • Should keep working for quite some time even during long (>10h) power outages

Oh, and the usual "must be cheap, as simple as possible, and not use exotic components" requirement.

Immediate consequences:

  • If there is a standalone mode, it should have some kind of display. I opted for a 20x4 LCD as there will be lots of stats to display. We may also need buttons.
  • "Work during power failures" means battery. Battery means "keep power consumption as low as possible". Low power means schottky didoes, such as the 1N5158, and low dropout voltage regulators such as the LM2931.

I briefly sketched a concept schematic, shown in the figure. It all starts with a simple variation on the classic power supply: AC power goes to the transformer (protected by a 100mA fuse), gets converted to 6VAC rms and is rectified by the diode bridge. There it goes to ways -- to the signal conditioning unit and to the voltage regulation unit. A battery connected provides backup power, with a diode to prevent reverse current flows. The regulator unit is the classic LM2931 regulator with its two side capacitors, taken verbatim from its datasheet. At the end we have regulated 5VDC power for the digital circuits.

If we can keep the device's power consumption below 10mA, a set of ordinary AA alkaline batteries, with their ~2800mAh capacity, might keep the device alive for well over 280 hours in case of mains power loss. We could then dispense with rechargeable batteries and their associated control circuitry.

The signal conditioning unit is just a resistor-based voltage divider to reduce the 8.4Vpp (remember, to convert from VAC rms to volts peak-to-peak, you multiply by the square root of two) from the transformer and halve it down to 4.2Vpp. With two 10k resistors, current here won't be larger than 0.5mA, so we use a 5V1 zener to protect us from transient overvoltages. The conditioned signal goes to the MCU's ICP (input capture pin) for frequency measurement and to the ADC for voltage measurement.

I think it's a good thing that the ADC is getting the "almost raw" alternating current, because it gives us a lot of flexibility -- at the price of some complexity in the software. For instance, the Vpp to Vrms conversion will have to be done in software; to avoid floating point, we may need some integer arithmetic gymnastics.

To keep things simple, we'll communicate over serial. We can always add a USB<->UART bridge later. We could do software-USB, but that would force our clock to be 12MHz and might present formidable timing constaints. I don't want this complexity right now. Anyway, I haven't settled on an exact RS-232 level converter just yet because I'm considering circuits using optocouplers to keep the signals electrically isolated from the rest of the circuit as an additional safety precaution. What I do know is that I don't want a MAX232, because it takes a good 3mA and we're trying to be very low power.

We'd also have the classic LCD interface with E/RS/RW+D4..D7. Maybe we'll need to provide a LCD shutdown line to conserve power when operating through the battery.

We need something for mass storage. We could have a SD card, but that would mean a whole big set of burdens: at least 512 bytes of RAM for the write buffer (or twice that if we need double buffering), which limits our MCU choices; and we'd need a 3.3V rail as well, along with level converter for the data lines. For simplicity, at this point I'm going with a standard 24C512 (64 kibibyte) I2C EEPROM, perhaps just because I happen to have one lying around here.

Next time I'll consider some of the basic calculations, clock and MCU selection, etc. See ya.


Follow-up posts:


top


You are here: Kiko > PostsInEnglish > EnBlogEntry2008Jan10A

top

Creative Commons License   The content of this site is made available under the terms of a Creative Commons License, except where otherwise noted.
  O conteúdo deste site está disponibilizado nos termos de uma Licença Creative Commons, exceto onde dito em contrário.