Burrowing Owl Relocation Sound Box

@davee @papajoe0418 Hibernation still leaves the RTC running and a few pins. Here is one link and I grabbed a screenshot as well. LINK1

Here is another link HERE  with some good MPU block diagrams showing what is active or not for each state.

I am a belt and suspenders guy so I would use the DS3231 to provide a reliable clock and using the pseudo-code I posted here yesterday implement a dual timer to start and end the daily cycle.

Yes it can all be done in the esp32 (you still need a way to set the esp32 internal clock (logical))

If you don't use the DS3231 and are worried about clock drift and HIBERNATION reliability, then use deep_sleep and wake hourly using an internally maintained logical clock (still needs to be initially set some how) This uses at least twice the power, but it is still very low power measured in the micro amps.

@davee In deep sleep you might be able to use eeprom in order to set an initial date time since the esp32 has no built in clock, it always starts at 0. The hibernate mode is even more troublesome.

NEWS I just saw something that might solve the memory problem, see pic

Hi Ron @zander, @papajoe0418 , @byron,

  I agree using a DS3231, possibly with its own coin cell battery, makes some operational issues easier, and may be the preferred option, but providing the ESP32 timer accuracy isn't too bad, and its power consumption claims are valid, it seems to me there is a good chance of finding workarounds to avoid needing an external RTC.

In more critical situations, particularly safety critical, I too would have at least one back up plan. The same applies if it is 'one-off' personal project, where a few extra pounds/dollars is less important the potential inconvenience. However, I am assuming this is not the situation here, and that this is a preliminary trial for a bigger project.

I don't know how cost sensitive this project is, and in particular, i am not clear how many units would be envisaged if the first few prove to be a success, but assuming it is, or will be, very cost sensitive, then I would start with the aim of the bare minimum, and only add stuff when it has been shown to be essential. In the commercial design world it tends to be a lot easier to make something more sophisticated and expensive, than it is to make it cheaper.

Of course, @papajoe0418 the choices and responsibilities are all yours!

Best wishes, Dave

Hi Ron @zander,

  As a postscript to my last reply, I am unclear how the ESP8266 and ESP32 differ in the area of deep sleep and hibernation, a pit I fell into earlier when looking at the length of the timer register, but I am not sure the ESP32 can wake ITSELF up from hibernation, whilst I think it can wake itself up from deep sleep.

However, if it it can wake itself up from deep sleep, AND deep sleep gets the power consumption down to the microAmps region, then that should be 'good enough' to get a 4 week battery life, so it doesn't matter whether or not hibernation is too restricted in its capability.

Best wishes, Dave

@davee FYI @papajoe0418 Yes the esp32 CAN wake itself with a timer or a special GPIO pin (see block diagram)

I agree re deep sleep over hibernation if that gives the battery life wanted. I think from an engineering design point of view that it is wise to only go as deep as needed to get the battery duration wanted. Deeper sleep modes are as a general rule less stable. 

In a similar vein, using the DS3231 will make the clock maintenance FAR easier, the esp32 code simpler.

Consider if NO DS3231

Some sort of method will need to be designed to set a start and end time of the non hooting window as opposed to just listening to a pin connected to the DS3231.

Some method will need to be designed to enter an initial time at the site and anytime the batteries are changed. This is why the DS3231 was invented, it supplies an almost GPS quality time plus 2 alarm triggers for many years on a single CR2032.

Hi Ron @zander FYI @papajoe0418 ,

I agree the design process may be a little more obvious with DSxxxx, and I am sure the DS3231 will be more precise, but the jury has yet to be presented with the evidence for the ESP32, to establish if it is good enough.

I am assuming that programing to achieve "Some sort of method will need to be designed to set a start and end time of the non hooting window as opposed to just listening to a pin connected to the DS3231' isn't very hard". Sounds like a "Repeat until" or "While" based on the clock time?

I am assuming the unit will be returned to some kind of base for at the end of each 1-4 week tour of duty, for new batteries, and probably a new schedule, so that would be an opportunity to reset the clock.

In addition, assuming the batteries are changed before they completely expire, I think there is a good chance the onboard decoupling capacitors (that I have already recommended) could maintain the internal RTC for a minute or more, assuming it is sleep mode, giving the possibility of doing a 'quick swap' without the clock losing time.

Clearly i am in a skinflint mood ... but these are just possibilities. Of course, the DS3231 might add convenience.

Best wishes all, Dave

@davee Good idea with the capacitors, but they will still need a way to enter (keyboard and screen) a starting date/time. If the cap trick doesn't work then a laptop at the desert site is required.

@byron

Posted by: @byron

↑

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.

Okay, so I think that @byron hit upon the perfect video for me to exercise my "learn-by-example" brain cells. I watched it end-to-end. Combined with the font of valuable info from all of you, I now have sufficient data to embark on my prototype 2.0. This video even has 80% of the C code I need to replace the Python code I had previously written. And it's downloadable from GitHub! 

I'm moving forward with ordering up an ESP32, whose internal RTC is more than adequate for my needs. I'll forgo the DS3231 for now, pending a burn-in phase. As well, I'll leave the three -- no, two! -- AAs as is for now. I can always add either or both later. Lastly, I'll use a MOSFET to trigger the sound player, so that it can be separately powered by a 3.7v button cell.

There's still about of page and a half of conversation on this thread that I've yet to read. But I'm sure 🤨 that no new contradictory information is going to change my strategy moving forward...yet.

Cheers!

P.S. RTC SRAM includes 8K usable space for variables that I don't want to lose. Perfect!

Posted by: @davee

↑

I am assuming the 'schedule' of when to hoot, etc. will be 'programmed in', either as a table or an algorithm, and hence stored in the non volatile memory section

Yes, per https://forum.dronebotworkshop.com/postid/38082/ , I have several tiny variables and they all can fit neatly into the ESP32 RTC SRAM, which does not go to sleep. 👍 

Posted by: @zander

↑

Some method will need to be designed to enter an initial time at the site and anytime the batteries are changed.

"Initial time" -- This is indeed a long-term challenge. Currently, all of the variables are programmed into the source code. All but one of the variables are intended to be optimized based on scientific research by the San Diego Zoo Wildlife Alliance. So they should never need to be changed (in theory) but can be reprogrammed differently before placing into the field.

The only real issue is DELAY-BEFORE-INITIAL-HOOT-CYCLE, i.e. after I press the ON button, how long should it wait before starting the first hoot cycle? (Note that I use relative times, not clock times.) Currently, setting that delay requires that I plug the device into a computer and upload the software...or simply press ON at a specific time of the day. Not a good solution at all.

My plan...!

...is to add a set of 3 DIP switches that can be set in the field for 0 through 7 hours delay. This is not an elegant solution, but is probably the best solution for a project whose budget is $0. 

Posted by: @papajoe0418

↑

The only real issue is DELAY-BEFORE-INITIAL-HOOT-CYCLE, i.e. after I press the ON button, how long should it wait before starting the first hoot cycle? (Note that I use relative times, not clock times.) Currently, setting that delay requires that I plug the device into a computer and upload the software...or simply press ON at a specific time of the day. Not a good solution at all.

My plan...!

...is to add a set of 3 DIP switches that can be set in the field for 0 through 7 hours delay. This is not an elegant solution, but is probably the best solution for a project whose budget is $0. 

Perhaps a potentiometer, a momentary press switch and a 2 digit 7-segment display might be an alternative. When you hold down the momentary switch it powers on the display and the ESP starts reading the pot. Turning the pot from one end to the other represents, say, a 12 hour time range. That allows you to use the pot to set the start time and the 7-seg display tells you how many hours the delay will be. Once the momentary button is released the power is cut to the pot/display section of the circuit and the microcontroller uses the last pot setting as the delay time.

@will @papjoe0418 Will's solution is better than PapaJoe's dip switches as it covers all possibilities. Since you don't plan on using the DS3231 to do the start and stop, you will need to wake up every hour and determine if it's a hoot time or not. A simple 24-slot array in conjunction with Will's pot will work nicely.

Posted by: @will

↑

potentiometer, a momentary press switch and a 2 digit 7-segment display

Yeah, I really like that idea @will. I was toying with adding a display from the start, which could make all of the settings easier to set and review in the field. The only thing stopping me was that this initial prototype needed to get done in a hurry in case we received a new mated pair this month (which we have not). Maybe will add in version 3 after my power consumption woes are fixed. Thanks! 

Posted by: @papajoe0418

↑

Okay, so I think that @byron hit upon the perfect video for me to exercise my "learn-by-example" brain cells.

Its a good video for sure on deep sleeping the esp32, but reading your post gives me a niggling feeling that using a board that has wifi on board is not the best board to use for a project where wifi is not desired.  I mentioned the espxx boards as they run micropython in which you developed your prototype.  Now that you are migrating the project C/C++ other boards could also have been worth consideration. 

I don't know how close to the limits you are with power consumption but if your project is getting close to the power limits of the battery life then the use of other boards may be worth thinking about.  For example I think that boards like the arduino nano can drop to a very lower power consumption and I don't think you have to do the trick of saving variables in the RTC and the program will resume from its suspended state.  (This is just from memory so don't rely on this remark).  And a final thought on your dear old rpi pico.  Deep sleep on this board was discussed only in relation to micropython it think (?).  It may work just fine if you program the pico with the C/C++ SDK provided by rpi. (not looked into this though)

My remarks in this post are a bit late in the day and for the back-burner should the esp32 not work out as planned.  I expect the ESP32 and C/C++ and turning off the wifi will be just fine  . 👍 

Hi @byron @papajoe0418 @will,

  Of course, I have no more input or insight or connection with the ESP32 than any of you, but if the WiFi implementation at the chip level has been done competently, and the manufacturing process ensures good quality product, then it does not need to be a matter of concern regarding power consumption, PROVIDING it is not actually enabled or used. MOSFETs can present an exceedingly high impedance to current flow, so providing that part of the chip is disabled, the leakage current should be very small.

The crucial requirement in this case is the current flow whilst 'sleeping', as that represents such a large proportion of the time. At the moment, all we can do is to set up a representative circuit + software and see what it does. If the 'sleeping' current flow is excessive, then it will obviously be a problem, but that can happen with even a very simple chip or even a single MOSFET.

As 'sleep' mode is an important aspect for some customers, I would hope that part of the chip testing would check current in that mode, which is essentially achieving by internally powering down parts of the chip, which would presumably include the WiFi section. And as it is the current flow during 'sleep' which will largely determine battery life in this application, all should be well!

Of course, I cannot guarantee the quality of devices that you receive, and you may even find one is good, the second is terrible, etc., but that can apply, regardless of whether a chip has WiFi provision. So @byron, I don't think you need having any regrets on recommending the ESP32 because it has a WiFi provision.

-------

As for adding local set up controls, I had considered mentioning it before, but avoided because of worrying that 'scope creep' could soon overtake the project. If you are looking for ideas for the Mark xxx version in the future, maybe take a hint from the cheap 3D printers who use a relatively low resolution LCD display and a cheap rotary encoder. This project could use the same encoder, and a smaller display. Of course this add on section would only be powered for a few minutes whilst actually being used, so again battery consumption would be minimal. The issues I would foresee are (1) temperature range for the display, although it has previously been suggested the these are not too severe for the expected usage period and (2) provision of the software and general hardware/software development learning curve. Alternate display technologies could replace the LCD if it is a problem, such as OLED.

-----------------

But for now, I would go for keep it simple ... and Happy hooting!

Good luck and best wishes all, Dave