Burrowing Owl Relocation Sound Box

@byron There are several add-ons available to extend the battery life of all the popular boards, but at a greatly increased cost. My understanding is this is a volunteer effort with limited financial resources and tech ability so changing store-bought batteries once a month is ok but that is my read of the situation, let's see what the op wants.

Wow, I haven't taken such copious notes since my college days! This is quite the hot topic. My comments appear below.

Posted by: @davee

↑

it seems like a 'hooting season' lasts just 1 week

Yes, the process is as follows: We erect a tent over a burrow and place a mated pair inside the tent. We feed our captive pair dead mice for 30 days. Some time during that period, we play a week or two of owl noises during the night to make them think that there is a community. (Burrowing owls are social by nature.) This is experimental, so the "hooting" period may be longer or shorter, but never more than the 30 days that the tent is erected. Then we remove the tent and hope that our birds don't fly away. 

Posted by: @davee

↑

assuming power source will be 3 AA alkaline cells, with the possible addition of a coin size lithium (e.g CR2032) for the RTC

Yes, I went with the three AA to accommodate the maximum recommended voltage for the sound player, which is 5v. I'll be looking into the DS3231 next (or possibly the DS1307) to see how to best program the device, given the multiple starts and stops I require (per my explanation in my previous post). I'm keen to leave that as is (i.e. not switch to the high capacity alternatives), as these will be easy batteries to replace at the start of the next "tenting", which may not be for another few months.

Posted by: @davee

↑

you intend to do some experiments to ensure the design is robust before the full trial

Yes, this is one big experiment. Even though it's the desert, we stop our activity before the real heat sets in. Ironically, night time temps might actually be beneficial to battery life.

Posted by: @davee

↑

How would you feel about looking at ESP8266 (or ESP32 which seems similar in the RTC department) instead?

I'm reluctant to use the ESPxxxx series because of the limited deep sleep capability that I'm reading in this thread. But I'll look into them anyway to see if overall functionality of those simply makes more sense than the Pico. I'm not married to the Pico, but rather I stumbled across it as a good alternative to a full-on Arduino or Raspberry Pi, both of which are overkill. That same stumble-step landed me in this forum. 😀 

Posted by: @davee

↑

microPython may also not be the wisest choice for low power applications. Given the relatively small software contribution envisaged, would you mind transferring to C/C++, if you hit issues  with microPython?

Yes, I may buckle under and dust off my C++ skills, if for no reason that to use compiled code that is inherently more efficient due to the increased speed of processing.

Thanks so much to everyone who has contributed to this conversation! 🤓 

@papajoe0418 The PICO deep sleep code is not yet stable. The gold standard of low power is the esp series.

@zander Oh, you're right, that was discussed, wasn't it. I think what I had in mind was to add a DS3231 (or similar), in lieu of deep sleep, and in lieu of ESP series deep sleep, which this thread tells me has an upper limit of around 70 minutes.

For further reference, I've generated a graph of the anticipated sleep/wake cycle over a 24-hour period to provide better visualization of where the low/no power state can best serve the situation.  👍

@papajoe0418 That was the other thing, DS3231 over DS1307. Sorry I don't know minutes, but deep sleep for the esp8266 is 20 micro amps, for the esp32 it is 10 micro amps and esp32 dormant is 2.5 micro amps. Those are the bare chip numbers, the dev boards most of us use may add extra capability at higher sleep cost. At the moment the best solution is the esp32 hibernation mode at 2.5 micro amps. I am attaching screen shots of the tables in the manuals, and the pdf esp manuals for both esp8266 and esp32. The esp32 uses 1/2 the power of the esp8266. If you do NOT use a DS3231 which is about the size of a quarter, then the best bet is the esp32 deep sleep which is 10 microamps, the dormant mode requires the ds3231 but also requires more code and special set up coding. Many of us here recommend the following web site for good esp examples and info, check them out at 

HERE

@papajoe0418 70 MINUTES !!!!!! Maybe 70 days, certainly not minutes. @byron has an esp8266 that runs on 2 AAA batteries for 3 MONTHS and it uses WiFi which is the biggest power consumer. See his post HERE

Actually, I was referring to the sleep max time of the internal RTC, per DaveE...

Posted by: @davee

↑

A possible confusion arises if you do not have a DS3231 ... but instead use the internal ESP32/8266 as the RTC.

This RTC does not have an alarm function like the DS3231, but the processor has a 32-bit 1MHz countdown timer, that can wake up the processor. The 32-bit size means the maximum time it can delay wake up is around 71 minutes.

@papajoe0418 Real world use suggests otherwise. Again, see @byron's post at 

https://forum.dronebotworkshop.com/project-help/burrowing-owl-relocation-sound-box/paged/4/#post-38076

3 MONTHS on a pair of AAA batteries. I would still recommend a pair of AA for the esp32 and a lantern battery or similar to power the HOOTER. A simple MOSFET to control the HOOTER from a single pin on the ESP32.

Also, the real world example is using WiFi 4 times per hour around the clock so that is a lot of power consumption you will not have. 3+ months is waaaaaaay more possible then 70 minutes!!!!!

@zander Ron, I'm not sure we're on the same page here. I'm only referring to the ESP32's ability to wake itself up after 18 hours of sleep.

There's no doubt in my mind that ESP32 in a lean, mean, processing machine. Looking forward to replacing my Pico with it, if viable. I'm also no averse to an ESP waking up once an hour all day long, if the power consumption stays competitive.  

@papajoe0418 As I pointed out another member here has an esp waking every 15 mins and using WiFi that lasts 3 months on a pair of AAA batteries. I thought we were discussing battery life with different MCU or MPU. In your case waking once per hour would be less drain so the batteries would last longer.

@papajoe0418 @zander

A few quick points, mainly to be absolutely clear on the esp8266 with 2 AAA bateries lasting 3 months: 

1.  The esp8266 max sleep time is around 71 minutes but it can be about 5 years on esp32).  Of course the esp8266 can awake only to be put to sleep again if the time for action is not nigh.   A link is given below for my source on this info. (and of course from davee on the esp8266) Its probably worth a listen to the first couple of minutes of the video where the sleep on the boards is discussed.

2. The esp8266 I mentioned that got 3 months out of 2 AAA bateries was on a board ( a Cricket) especially designed for low power consumption that normal esp8266 boards would probably not achieve though its an indication of what the esp8266 can achieve.   

3. The sleep time available on the board, whilst it must have a bearing on overall power consumption due to how often it wakes, its the power consumption both whilst at sleep and during a hooting sequence will of course indicate the best board for the purpose.  The accuracy of the RTC may be an issue for some applications but seemingly it would not be relevant for this project.  (max was a 5% drift on the ESP8266 as per a post I made previously in this chain.

4. The power consumption is both based on the chip and how the power circuit on the board is designed.  To this end the ESP32 on the TinyPico board and the pyboard I mentioned somewhere in this posting chain are notable for their low power draw.   I've not done any maths on how much power this project will require / consume.  I will leave that to cleaver chaps @davee 😀, and I expect cleaver chaps like your goodselves, and a 'notable'  board is probably not really required for this project.

5. Better stop there Byron, your repeating yourself.. 😉   But interesting to hear what board you eventually choose and why. 

@papajoe0418 I forgot to mention, the 18 hrs should not be a problem as that is only 6.48 X 10^10 micro secs and the time to sleep is a unsigned 64 bit value which is in the 10^20 range I think. I think that's 5,124,095,576.0304307938 hours, so 18 should be fine.

FYI, that's over half a million years.

@byron @papajoe0418

The esp8266 max sleep time is around 71 minutes but it can be about 5 years on esp32).

Sorry, something does not compute, unsigned 64 number of micro seconds is about 100,000 times more than 5 years. See pic

Posted by: @zander

↑

@byron @papajoe0418

The esp8266 max sleep time is around 71 minutes but it can be about 5 years on esp32).

Sorry, something does not compute, unsigned 64 number of micro seconds is about 100,000 times more than 5 years. See pic

-- attachment is not available --

 

But what are are you counting in?  Hours, minutes, seconds, or microseconds.  But whats an epoch or two between friends. 

@byron fyi @papajoe0418 MICRO SECONDS, max number is 18446744073709551616  for UNSIGNED INT 64 which is 18446744073709.550781 secs or about HALF A MILLION YEARS. 

Some folks may get fooled into a smaller number if they don't deal with the uint64_t correctly especially if compiler warnings are set so as to not show ALL errors.

One coding solution, note the LL

#define uS_TO_S_FACTOR 1000000LL /* Conversion factor for micro seconds to seconds*/ 

esp_sleep_enable_timer_wakeup(uint64_t(SleepTimeSeconds) * uS_TO_S_FACTOR);

NOTE the define is LL, maybe even better is the use of a const instead of define especially in this case.

The Compiler warnings set to ALL will show you implicit casting errors that happen when 32 bit coders move to a 64 bit world.