Best way to sleep for long periods

Status
Not open for further replies.

snusmumriken

Active member
I'm a wildlife biologist working in a conservation context where we need to determine which predators home-in on the sounds made by hatching bird chicks. I want my Teensy 3.2 working on a battery pack to play a WAV file through a mono amp and speaker at intervals, but to sleep to conserve battery power when the device is idle. The interval between play events is to be configurable between 1 and 60 minutes. The volume and the sound file played can obviously be varied at will too, perhaps iultimately n response to PIR sensors detecting approaching predators - I can build increasing levels of sophistication over time.

I have got the WAV-playing part working (with help from forum members), and now need to implement the sleep and interrupt routines. I can put the amp to sleep OK from one of the Teensy's digital pins, it's just the CPU I now need to attend to. I've successfully used Arduinos before for other purposes, but evidently the SAMD sleep behaviour is very different.

I'm looking to use library functions because I'm not competent enough to use low-level commands. What is my best option:
  1. Use Snooze library, with a timer interrupt, and use the RTC to check whether enough minutes have elapsed every time the CPU wakes? I will be calling the RTC anyway in order to record a date/time stamp in a file on the SD card for each play event - this is to allow comparison with data on nearby cameras; and to let me see when the last play event was before batteries expired. (I haven't added the crystal and button cell yet, but will be doing so.)
    What is the maximum value for the timer interrupt?
  2. Use a watchdog? If so, how? Is that essentially what timer is in the Snooze library?)

Also, I'm not clear what will be retained in CPU memory with the different sleep levels? Where can I find that information, please? I would like everything that's established in the set-up loop to be retained.
 
Even with sleeping the Teensy you should look into shutting down all the external components when you want the Teensy to sleep. In my audio applications the Teensy 3.2 actually is the least power hungry piece of electronics I had to deal with.

If you plan to sleep long periods of time use the rtc and a coin cell, the watchdog should be used for lockups not sleeping with the the 3.2 and Snooze does not use the watchdog.

If your using Snooze library's deepSleep or hibernate, then the ram is retained so that should not be an issue for you. Again if your using external Audio equipment that will be where the real power consumption will be so I would focus on that. Low power is tricky so be prepared to do a lot of testing and research on how to cut power to external stuff the Teensy part is easy compared to that.
 
Many thanks for your reply.

Even with sleeping the Teensy you should look into shutting down all the external components when you want the Teensy to sleep. In my audio applications the Teensy 3.2 actually is the least power hungry piece of electronics I had to deal with.
...
If your using Snooze library's deepSleep or hibernate, then the ram is retained so that should not be an issue for you. Again if your using external Audio equipment that will be where the real power consumption will be so I would focus on that. Low power is tricky so be prepared to do a lot of testing and research on how to cut power to external stuff the Teensy part is easy compared to that.

My only accessories are the voltage regulator and the amp. I've used the same voltage regulator in other applications, and its current drain when quiescent is very acceptable. I can sleep the amp as mentioned, but could alternatively control its power via a MOSFET, which again I have done in a previous application.

If you plan to sleep long periods of time use the rtc and a coin cell, the watchdog should be used for lockups not sleeping with the the 3.2 and Snooze does not use the watchdog.

Please could you explain this in a bit more depth? I have used pin interrupts successfully with an Arduino Uno, so I have a little experience to draw on. I thought the idea of a watchdog interrupt was to wake the processor at intervals (on an ATmega 328 it's a maximum of 8 sec). You can then see if it's time to do something, else go back to sleep. So in my case, I would wake up and use the RTC to test whether 30 min (or whatever) had elapsed since the last 'play' event. If yes, play it again, then sleep. If no, just go back to sleep. Have I misunderstood something fundamental?

What do you mean by lockups as opposed to sleeping?
 
Many thanks for your reply.
Please could you explain this in a bit more depth? I have used pin interrupts successfully with an Arduino Uno, so I have a little experience to draw on. I thought the idea of a watchdog interrupt was to wake the processor at intervals (on an ATmega 328 it's a maximum of 8 sec). You can then see if it's time to do something, else go back to sleep. So in my case, I would wake up and use the RTC to test whether 30 min (or whatever) had elapsed since the last 'play' event. If yes, play it again, then sleep. If no, just go back to sleep. Have I misunderstood something fundamental?

What do you mean by lockups as opposed to sleeping?

OK, after dipping into the hideous NXP manual, I think I may be able to answer my own questions. It seems to be a difference in terminology between the Atmega386 and the ARM Cortex-M4. In the '386, the watchdog timer (WDT) can be configured to cause either a reset or an interrupt, or both. In the M4, the WDT only does resets (hence your warning), and a timed interrupt is implemented by a Periodic Interval Timer (PIT) or a Low Power Timer (LPTMR). The latter presumably corresponds to 'timer' in the Snooze library?

Please would you confirm that I've understood this correctly?
 
Not really relevant to the question of using a watchdog to awaken a CPU from sleep, but for those who read these comments, I have an update on how the Kinetis watchdog hardware works.

In the M4, the WDT only does resets (hence your warning)
I use a watchdog setting the Kinetis parts to fire both an interrupt and reset by the watchdog. We use the time between interrupt and reset to record a few interesting state variables before the reset kicks in.

I agree with Duff that the watchdog is best used for its original intended purpose (recovery from lockups, etc.) and that either the low power timer or RTC would be better suited for the purpose of waking the system. The RTC has an alarm register (RTC_TAR), which looks like the designers' intended method for waking the system. The LPTMR seems to be intended more for tracking signals over time under low power conditions.
 
Status
Not open for further replies.
Back
Top