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

I’m using the weather shield…my apologies, I should have clarified. The MOD plug from the rain gauge is wired to D2…I see the source of the confusion now.

1 Like

I’ve done something similar in the past on a PIC. I setup one of the timers to increment on the edge of an external source… making it a counter. This worked in sleep mode. I’d wake up every x minutes (or on timer overflow) and calculate rate and accumulated counts based on the TMRs register value.

Can this be done on the photon?

Kinda seems like you’re hijacking my thread. Be that as it may, what I’m trying to get at is I need a way to wake up my photon from it’s routine deep sleep cycle by pulsing the WKP pin high using a pull down resistor. That’s all well and good, but I have to trigger the WKP pin in some fashion, simply connecting a resistor between WKP and GND will not accomplish this and since the rain gauge input on my sparkfun photon weather shield has a trace to D2, I’m stuck using that pin to trigger the WKP pin. I guess that I’m asking for some sort of validation that this will work or if I’m completely off base. I do like this trigger idea but I want to make sure I implement it correctly.

@raenrfm, seems I stirred the pot!!! First, let’s be clear on nomenclature:

STM32F205 “standby” mode = Photon deep sleep with RTC or rising edge on WKP wake - when the Photon wakes, it resets the processor. This mode offers the LOWEST power consumption for the processor.

STM32F205 “stop” mode = Photon sleep with interrupt on any EXTI wake - when the Photon wakes, execution starts from the instruction AFTER the sleep command. This mode requires more power for the processor.

VBAT keeps standby RAM active when VIN/3V3 is disconnected.

Presently, none of the Photon power modes preserve power to the peripherals, including the timers. So having a hardware timer/counter increment while the Photon is essentially sleeping is not supported at this time. It is possible, but not with the existing system firmware.

2 Likes

The pull-down resistor only ensures that the WKP pin does not float "high" without an actual trigger from your bucket. It will never create a rising edge.
Sure enough the rising edge has to come from your bucket, and since you now clarified that you are not free to change D2 for WKP, you'll be most likely needing to bridghe D2 to WKP.

For my edification and the OP’s, “bridge” meaning pull a wire between the two or something more involved?

Yup, just a boring ol’ wire will do :wink:

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?