I am in the same situation but with ball tilt sensor to wake up the Photon from deep sleep and record the time. It can detect the pin is HIGH while it wake up so I know it is wake up from a push button not due to time. I tested it with a push button first and it work well but it does not work every time with a ball tilt switch. Sometime it wakes up and could not detect HIGH. I think because the ball bounds in the tube so fast that before it during wake up the switch already off.
So, my question is, how can I differentiate from waking from ball tile switch or due to time. If i set up it wakes up every 10 minutes, but before 10 minutes it wake up by switch sometime. I could not find a way to differentiate how it wake up.
@Joe1, setup an retained unsigned long variable that will hold the time just before going to deep sleep. When you wake, you can compare the retained time to actual time. If the difference is greater than the sleep time then you know it was the timer. For this to work, I suggest making sure the Photon’s RTC is properly synced with the Cloud before storing it in the retained variable in before doing the comparison on the reboot from deep sleep waking. Also, just use Time.now() to get the UTC time in seconds (no timezone stuff needed since you are just comparing times)
Software debouncing won’t work as the wake & read latency will usually be longer than a typical bounce anyway and hardware debounce is a tricky topic.
But my usual alternative to the “timed-guess” approach (which usually works well enough) would be an external sample’n’hold circuit to keep the pin in the desired state long enough for the system to wake and read the state.
@ScruffR, I've used a Schmitt trigger successfully for a number of projects ranging from using buttons, toggle switches, quadrature encoders and even analog sensor data where the voltage produced by the sensor is such that it fluctuates (at the point I'm interested in) and hysteresis of a Schmitt trigger helps with a clean on/off signal. So I'm curious what you mean, when you say "tricky".
The “tricky” bit applies to people who try to HW debounce pins with just descrete components and try to follow some of the “turorials” provided on the internet.
If you’re comfortable with transistors and op amps, things get much more reliable and not that complicated after all.
But then implementing a S’n’H circuit to prolong the input pulse will be just as easy, since IMHO the shortness of the trigger is the actual problem here.
The de-bouncing suggestion was for what @Joe1 was talking about with his tilt switch. Are you suggesting an a sample and hold for that issue? I guess a sample and hold circuit could work there too probably an "active" circuit (op amp, FET based). Even a latch/reset circuit could work with the caveat that it would need to be reset after the photon wakes up.
If the debouncing would also elongate the pulse, since I understood his till switch problem as "The trigger pulse might be too short to wake the device and stay on till the pin can be read in code".
My understanding of debounce is that it only protects against multiple fast triggers but not prolong one single short pulse.
I guess that's the part I was focusing on with the assumption that it's mechanical switch . [quote="ScruffR, post:19, topic:17930"]
My understanding of debounce is that it only protects against multiple fast triggers but not prolong one single short pulse.
[/quote]
Yes, that's correct. For mechanical switches, since the pulses are not square waves but more like ripples (AC) after the first pulse, a de-bounce with hysteresis would potentially to elongate the pulse duration. Nonetheless, if the issue is too short a duration of the pulse, a sample and hold is the way to go.
I just sometimes fall into these academic moods and just want to answer the question as is without thinking of the easy way out
But even with the IMO, the question would remain - how tell the difference between timed wake vs. wake on interrupt.
And for that both options stand “timed-guess” vs. “min-width-trigger”
I don’t see how an accelerometer would work for this particular use case (Unless I’m just missing something blatantly obvious).
The Photon is asleep until something tilts. So no power consumption at all until that event occurs.
In order to use an accelerometer (analog or digital) and use it’s readings you’d have to have the Photon running, or have some external circuit running that could convert the accelerometer’s data into a high/low output. Either case, some power is being consumed, waiting for the event to occur.
@shiv, IMU sensors - like the one on the Asset Tracker Shield - can often trigger an interrupt to wake a devices.
e.g. on the Asset Tracker the IMU sensor has a very low (~2µA) current draw while waiting for movement, so the Electon can be seent to deep sleep and only wake on movement signalled by the IMU sensor
True, but (ok, I'm making assumption about the OP's needs)
While waiting, it's consuming power. I'm guessing, (because the Photon is being put in sleep mode) the aim is to reduce power consumption or have no power consumption until the event occurs. So no power consumption vs very low power consumption may not be suitable in some cases.
Some movement, is not the same as a large movement. Tilt switches turn on when approximately vertical (not sure), the resting position of the "thing" could be 90 or 180 degrees from that position.
A lot of assumptions, but I do believe these two sensors each have their place.
In general you are right, but 2µA isn’t that much extra current, but (depending on the need) it might be worth while (although the OP might not need the extra convenience).
The thing is that on IMU sensors that some movement is controlable before going to sleep by setting the interrupt threshold and you will also be orientation independent, since - as you say with tilt switches, you are bound to the physical orientation of the switch (if it’s already closed on sleep, you need two actions - open and close again - to wake) on the other hand IMU sensors can be calibrated before sleep and will trigger on the first event immediately.
Again, probably academic for the OP’s question, but nonetheless “interesting” for a holistic picture of the topic.
Knowing both allows for a best suited decision.
BTW, deep sleep is not no power consumption either, so the extra 2µA need to be viewed in perspective.
@ScruffR, just to clarify, the Asset Tracker has an accelerometer, not an Inertial Measurement Unit (IMU) which typicall fuses several sensors including an accelerometer, a gyroscope and a magnetometer.
Some IMUs allow for the programming of a detection “profile” which characterizes a sequence of sensor values to detect prior to firing an interrupt. I think the MPU9250 has that capability.
@peekay123, thanks for that extra bit of clarification
I obviously was too careless with my wording there and traded correct info for a snappy acronym
But AFAIK the LIS3DH on the A.T. does allow to set the trigger threshold and calibrate the “rest” position from which orientation has to diverge to trigger.
Not as advanced as a full “multi dimensional profile” but still an advantage over mere tilt switches.
The LIS3DH can do tilt sensing in hardware, and you can set the limits for trigger. It’s pretty cool. Also, since it can latch the output on interrupt generation, you can read it upon wake, then clear the interrupt.