How to keep track of rain with photon and deep sleep?

Thanks for the clarification @peekay123 .
Too bad the peripherals are not powered. looks like D2 (https://docs.particle.io/datasheets/photon-datasheet/#pin-out-diagrams) is connected to TIM3_CH2. He wouldn’t have had to create a jumper to WKP pin… just wake up periodically and checked the register as long as TIM3 isn’t used by something else in the system firmware.

Didn’t mean to hyjack - just coming up with an idea to answer your question of “is there some way to keep track of the bucket tips even in deep sleep mode”

@gjaman Still need to trigger the WKP pin externally somehow though, regardless of other pins on the photon that the WKP is connected to because it’s asleep. No worries about the hijack, we’re all learning something here.

@peekay123 According to the documentation it seems I can enable the backup ram SRAM and like @ScruffR already mentioned with the retained command on your variables they should survive resets as long as vbat or vin is maintained.

[quote=“raenrfm, post:29, topic:19439”]
with the retained command on your variables they should survive resets as long as vbat or vin is maintained.
[/quote] That is correct!

@gjaman, to have the timers run while in low power mode is no longer deep sleep. This mode would require some manipulation of low level registers to manage onboard resources to keep power consumption low.

Alright this is going to work out good, so barring a noah’s ark type rain of 40 days and nights my photon should keep humming along as long as I can find a sweet spot to keep the battery at a manageable level. To protect from totally killing the battery I will use the alert trigger of the battery shield to shut it down for a prolonged period in order to have the solar panel make headway on the battery. Thank you gentlemen, very helpful.

2 Likes

Actually just thought of one other concern and maybe you can help. When the photon is in deep sleep and the rain bucket triggers the WKP pin, I’m assuming that bucket tip will get missed in the code because the photon will not be awake to register it? I guess I will need to determine if the photon was woken up by the bucket and not just the timer expiring and manually register a bucket tip in the code somewhere?

I don’t know if there is a way to distinguish whether the device was awakened from deep sleep by a timer or the WKP pin. There was a discussion about that in this post, Waking from SLEEP_MODE_DEEP ? status flag. @mdma, has anything changed regarding this issue?

@raenrfm, since waking causes a reset, you will need to use the retained RAM to store the time (eg Time.now()) the last time you did a timed update. On reset, you wait for Time to sync with the cloud and compare against your stored time to see if 60mins have gone by. If not, then it was a bucket event that woke up the Photon. You will need to implement a “first boot” flag that sets the retained time and itself once so they don’t repeat at every boot.

If the bucket event was slow enough, you could read the WKP pin after waking but there is a boot delay before user code runs that may prevent this approach from working.

1 Like

Just had an idea. Could you not use a simple flip flop circuit triggered by the rain bucket and then read the state of the flip flop with an unused pin and compare with that pin status before and after sleep? Couple transisters some capacitors and resistors and you’re good no?

EDIT: Actually think a 555 IC would probably be more reliable and stable, but I think this could be a way to store state information of non-active sensors while the photon is asleep.

@peekay123 & @raenrfm,

Awhile back @mdma had made a comment that he realized the status registers were being cleared prior to the user code receiving control so using time was the only solution to detect this, but my understanding is he had fixed this so that a status register could now be used to determine this in user code.

I have not tried to test, but if you figure it out please post the details as I would like to roll it into my product.

My only problem with using time is it seems somewhat un-elegant to me and wouldn’t necessarily be 100% reliable. Maybe it’s my own OCD kicking in…lol. I like the idea of an external latch circuit that will retain the status of the bucket cycle while the photon was sleeping. I guess in essence you’re making the rain gauge an active sensor that remembers what happened.

@HardWater, I’ll have to see what @mdma has to say about that.

@raenrfm, the external latch, especially a low power one, is a great idea. However, if, as @HardWater pointed out, you can read a register which indicates the wake event source, then that would be the best solution. :wink:

Depending on the external latch and its current draw, alternatively going for non-deep-sleep (stop) might be back in the race again too.

1 Like

I’ll need to do a bit more research on how to do that, I agree if I can get away without adding anything that draws current, this would be a more ideal solution. Can you point me to any discussions regarding reading registers on the photon?

I suppose you’re right, no sense in adding parts that will basically amount to the same current draw. I would like to retain the deep sleep cycle vs. standby configuration.

Was thinking a bit more about the pull down resister thing, I suppose using an unused pin on the photon as a pull down resistor vs a discrete resister wouldn’t work during deep sleep correct?

@raenrfm, a low power CMOS D-type flip-flop will do the job and has a standby current of 900nA. However, being able to read the internal registers is betting IMO. :wink:

Just wondering if you could elaborate on how I would be able to read those registers when the photon isn’t awake? I see this as a chicken and egg problem, the photon needs to be on to read the event, but it’s the event that wakes the photon.

Unless their is a way to distinguish if the photon was woken by the pin or the expiring timer? Other than trying to extrapolate time periods to deduce whether or not the timer expired. I’m using several different sleep duration’s depending on the condition of the battery charge (SOC) and it would get quite cumbersome to try and figure out a rain event based purely on time.

@raenrfm, you only read the register AFTER the Photon wakes in order to find out what the wake event was. If you can’t read the register, then you need to read the WKP pin to see if it was the triggering event which may require an external latch for the bucket event.

Ok, so if my rain bucket is on D2 I could try to see if D2 was triggered by reading it’s state because I can’t read the WKP pin if I’m understanding you correctly. I’m thinking I will miss the read because it’s just a momentary reed switched device. I guess I’ll just have to experiment with it to see if it bears fruit. Otherwise I suppose I’m stuck with the latch idea.

I did a bit more research and I think the caveat is that there is no register to differentiate between a wakeup from RTC or the WKP pin, therefore I think I’m stuck with building a latch circuit and using an unused pin to read the status of the latch. Guess I’m off to get some discrete parts or maybe a 555 chip.

EDIT: Just googling some 555 timer circuits and I think what would work equally well for this is a time delay circuit. I could program the circuit to delay the trigger from the rain bucket say 5 seconds, then pulse an unused pin to register an interrupt. I would still have to wire the rain bucket pin to the WKP pin but once that happens I’ll know I woke up from sleep from the rain bucket because I’ll get a pulse on a different pin once the photon is awake. Problem solved.

1 Like

Have a look at my water usage monitor, it monitors a reed switch to count the water meter pulses. It looks at the difference between the expected wake time and the time it woke up