Just wondering if there is a reasonably simple way of detecting a blackout and quickly making note of the occurrence in memory before the power caps lose charge and the system turns off.
I doubt there would be any easy way. What do you guys think?
Just wondering if there is a reasonably simple way of detecting a blackout and quickly making note of the occurrence in memory before the power caps lose charge and the system turns off.
I doubt there would be any easy way. What do you guys think?
Making a note of WHAT, specifically ? Date/time ?
How does that counter-question help, Indy? Just assume that it is something that gets noted in non-volatile memory (time, or just a count of occurence, or...) and give some advice. Or not.
Cameron: Look into the brown-out detector of the AVR. That is one possibility, given that you have a supply that can feed the AVR long enough for the write (to EEPROM?) to complete.
More options might be available if more info of the AVRs environment is given. E.g. if you are monitoring mains-outages.
More options might be available if more info of the AVRs environment is given. E.g. if you are monitoring mains-outages.
Your statement is like my question . Both are requests for info .
Just wondering if there is a reasonably simple way of detecting a blackout and quickly making note of the occurrence in memory before the power caps lose charge and the system turns off.I doubt there would be any easy way. What do you guys think?
- monitor the rectified DC before the diode feeding your regulator
- when it falls, service the pin change interrupt
- write the date/time into the battery backed RAM of your DS1307 chip
- when power is restored, read the current date/time and send it with the previously stored values out your serial port to the GSM modem to the private number of the Power Authority's CEO with your claim for denial of service.
The diode will ensure that your BBC (bloody big cap) will not be discharged before you have finished saving the date/time.
Have fun.
Ross
Or, do some conditioning on the 100/120 Hz pulse after the rectifier circuit and use this as a keep-alive notifier via an interrupt line. As soon as you don't reveive such an interrupt within 1/100 (1/120) second, the mains is gone...
You can save an eeprom byte or a flash page in about 1,6ms. That is usually enough to save the event. Just make a write command and power-down the chip asap. If that allows your Vcc to be within write specification for 1,6ms - Atmel guarantees write is successful. Both eeprom and flash write is asynchronous w.r.t the core - you cannot stop it with reset pin, BOR, watchdog etc.
It's DC powered. 7.5v DC plug pack -> 5v regulator -> 3.3v regulator -> MCU. The capacitors hold a decent amount of charge, so I do have sufficient time before it shuts down.
Going by what valusoft said, I would voltage divide the 7.5v dc plug pack voltage to within 3.3v for the mpu pin change interrupt (load may change but as long as it's less than 3.3v I guess), and have that going through a current limiting resistor to the pin change pin. Any issues with that?
What am I doing? Let's say there is a data logger logging to the internet every so often. If I check on the internet I might find that there is no data for a period of time. I would like to just make note that there was a power outage, and when the power comes back on I will log that this happened such that the outage makes more sense when viewed online.
Going by what valusoft said, I would voltage divide the 7.5v dc plug pack voltage to within 3.3v for the mpu pin change interrupt (load may change but as long as it's less than 3.3v I guess), and have that going through a current limiting resistor to the pin change pin. Any issues with that?
You'd be better off using the comparator (you didn't state which AVR you have, so I'm assuming your AVR has one) rather than relying on the voltage divider output crossing some rather imprecisely defined logic low level.
- S
Quote:Going by what valusoft said, I would voltage divide the 7.5v dc plug pack voltage to within 3.3v for the mpu pin change interrupt (load may change but as long as it's less than 3.3v I guess), and have that going through a current limiting resistor to the pin change pin. Any issues with that?You'd be better off using the comparator (you didn't state which AVR you have, so I'm assuming your AVR has one) rather than relying on the voltage divider output crossing some rather imprecisely defined logic low level.
- S
324p. It doesn't have one inbuilt.
Errrmmmm... The datasheet (doc8011.pdf) for the 324p describes the analog comparator in section 19.
- S
Why not just do the logging at power on? From the description of what you want to do that should be adequate, and much simpler. If you want to suppress logging for an intentional power up just provide a button that you hold down during power up.
I think you might need something like a backup battery as such.
your 220 -> 7V probably has a large cap then you probably added some more so you might see a failing 220V probably when it might be too late.
you could sense that the 7V input drops below 5V and then do detection on that. if you add enough capacitance to your avr supply then you should be able to just make it....
... you could sense that the 7V input drops below 5V and then do detection on that. if you add enough capacitance to your avr supply then you should be able to just make it....
Lots of prior discussions on this. Perhaps start with this one:
https://www.avrfreaks.net/index.p...
... and my views on using the analog comparator ...
https://www.avrfreaks.net/index.p...
In this thread I repeated my method for finding "the number":
https://www.avrfreaks.net/index.p...
"The number" is the result of testing how many EEPROM bytes can be written after an impending power loss is detected and before the BOD kicks in. Typical time in my production boards is about 100ms after power-suckers are turned off. that allows for a comfortable dozen or two bytes of EEPROM writing.
If "the number" isn't high enough to be comfortable you can set the early warning level higher, or don't average it as hard. IME you >>will<< then get more false trips in many apps.