I am planning to read out a rain sensor (the kind with a tipping bucket), which sends short impulses whenever a certain amount of rain has fallen. So far so good.
I am currently contemplating options with using a "regular" Arduino Nano or an ESP8266 with Arduino core. I don't think this matters though for my below question.
As the device will be powered by battery, and there might be no rain for weeks, it would make sense to use some kind of deep sleep/power saving mode. And the impulse from the sensor can be used to wake the device up. I think I'll manage this by connecting it to the reset pin as well. I might need to create a NOT gate, depending if the impulses are HIGH or LOW. I'll see once I have the sensor. (LOW impulse is needed to reset/restart microcontroller)
Now finally to the question: There is the possibility that the arduino is still processing the first impulse from the sensor when the next one already arrives. In this case, it should of course not reset the arduino.
How can I prevent that a LOW signal at the RST pin actually resets the microcontroller?
I played around with using another digitalout HIGH also connected to the RST pin, but then I can't put the arduino into powersaving mode without resetting it immediately...
Use a different pin. Don't use reset to wake from deep sleep. Just wake up, you don't need to reset the board to do that.
How hard do you expect it to be raining? I don't think a tipping bucket could physically keep up with a processor no matter what you had rocking it. Trying to tip the bucket at anything approaching even 1/100th of the speed of the processor wouldn't be possible without breaking the bucket.
I agree with @Delta_G . Don't use reset pin for this. Use an external interrupt pin (pins 2, 3 on Nano) and put the Nano into STANDBY sleep mode.
Nano is not the best for low power projects because it's built-in USB-serial chip and power led consume some power even when not connected to the PC. Pro-Mini would be better, especially if you remove its power led.
Esp8266 doesn't have a sleep mode equivalent to STANDBY. It has a DEEP SLEEP mode but I don't think an external interrupt pin can wake it from that mode. You would have to connect the sensor to its RST pin.
ESP takes a relatively long time to wake from DEEP SLEEP (about 250ms I seem to remember), but as @Delta_G says, you won't get signals that frequently from a rain sensor anyway.
The other problem with using ESP like this is that, naturally, waking it by using RST will mean it's ram memory is wiped, so will have lost track of previous signals from the sensor. If recording each event in EEPROM/SD card/remote database, that might not be a problem, but, especially with a remote database, it will take 5~10 seconds to connect to WiFi, send the update and receive the response, you might miss signals from the sensor in heavy rain.
In STANDBY mode, the Nano can retain the count of signals from the sensor, because walking it with an external interrupt pin does not cause a reset.
The thing I was worried about is that the controller is still connecting to WiFi and transmitting the data (I guess to MQTT) while the next impulse arrives. This does take about max 20 seconds in total. I am not worried of getting interrupted while those things are happening. Not within like the first second or so.
Will look into this standby mode of the nano or pro-mini. Thanks!
I am sending the data to my homeautomation system. Which actually uses "pulses" as input. All I need to send to it (through MQTT) is a "1" whenever the bucket tipps. So I don't need to manage data on the ESP/Arduino. I really just need to wake up, connect, send the "pulse", disconnect and sleep again. Seems like it is not as easy as I thought
Ok, that does make things a little simpler. An ESP would not need to count the pulses in any way, so using its reset pin could work.
But if you use a Nano/Pro Mini, how will that connect to the MQTT server? If you still plan to use an ESP for that, it seems wasteful and inefficient to use both MCU when the ESP could do it alone.
Now your question about prohibiting hardware reset makes sense. In heavy rain, a second pulse might come within the 20s it could take to send the MQTT message.
Have you tested to see if this will genuinely be a problem? Maybe put the sensor in the shower and see how much time passes between tips?
So I will test it, in the meantime I did some estimations based on weather data (it tips for every 0.2794mm of rain). I think it is safe to say that with "normal" rain, I will never get more than 100 tips per hour, which should be manageable. There is a possibility that during heavy thunderstorms there are short bursts which could be in too quick succession to handle.
I am thinking now that it would not be the end of the world if it misses a tip here and there, especially in thunderstorms the measurement is never entirely accurate due to the heavy winds.
But I am also thinking if there is a simple way to store the tips. So after booting the MCU, first thing would be to store the informatio e.g. on a SD card. Then try to connect etc. And just when it was sent to MQTT remove it again from storage.
And the part which sends the information to MQTT will always check if there are more tips to send on the SD card and loops through those.
Yes, Nano and ESP have either EEPROM or Flash memory.
Your sketch could increment a counter stored in EEPROM/Flash as the first thing done after a reset, before connecting and sending MQTT message. After sending the message, a copy of the counter can also be saved in EEPROM/Flash. If a second/third reset occurs before the message is sent, the counter will be 2 or 3 counts ahead of the saved copy, instead of the normal 1 count difference. Your code can detect this and send 1, 2 or 3 messages as needed.
