Burrowing Owl Relocation Sound Box

@byron Yes, an 8266 is an excellent choice. I forget it's available as I usually need more pins but not in this case.

Can someone please point me at @davee post that talks about the following

But the rpi pico, with the addition of a simple circuit as proposed by Davee that switches off the power entirely may be just a good.  For that calculation the amount of power drawn by the pico on power on followed by a short runtime will have to be measured.

@papajoe0418 FYI @davee @byron Just an FYI on DS3231 RTC battery life. That is the MAX, I would plan on a 2 yr life for the case where the RTC is moderately busy. These CR2032 coin batteries are powerhouses with 2,700 - 3,400 mAh of capacity at a 50mA draw. However NOT rechargeable.

Hi Ron @zander, @papajoe0418, @byron,

Supporting @byron's experience, I just came across this, regarding the ESP8266

https://www.espressif.com/sites/default/files/9b-esp8266-low_power_solutions_en_0.pdf,

which includes the following ..

and also the following, for which at first glance, curiously the text looks slightly different, depending on the copy method ... take your pick?

4.1. Features
Unlike the other two modes, the system cannot go into Deep-sleep automatically. Users
can call the interface function system_deep_sleep to immediately enable Deep-sleep.
In this mode, the chip will turn off Wi-Fi connectivity and data connection; only the RTC
module is still working, responsible for periodic wake-ups.
4.2. Interface
4.2.1. Enable Deep-sleep
The system goes into Deep-sleep mode via the following interface.
void system_deep_sleep(uint32 time_in_us)

Parameters:
4.2.2. Configure Deep-sleep
Users can configure the software workflow during the wake-up from Deep-sleep via the
following interface to adjust the average power consumption during long-time running.
bool system_deep_sleep_set_option(uint8 option)

⚠ Noticeғ
To enable Deep-sleep, you need to connect GPIO16 to the EXT_RSTB pin of ESP8266.

So uint32 suggest maximum of more than 4,000,000,000 , which would include 1 hour value of 3,600,000,000 wake up interval.

------

@byron, can you provide any experience on the longer term (weeks-months) accuracy of the RTC clock when it spends virtually all of its time in deep sleep, bearing in mind it won't be able to resync the time using Internet servers? The random notes I found on the web for the ESP32 were somewhat contradictory.

A few minutes over a few months would probably not be an issue, but a several hours over a few months might get the owls very confused!

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

And Ron, regarding your question:

Can someone please point me at @davee post that talks about the following....

I think the first to mention MOSFET was you (on page 1 of this thread), as an alternative to a relay ... I have subsequently mentioned using a MOSFET triggered by an external RTC in a few places. As with any good discussion, the "who said what" is quite tangled, as it a collaborative effort!

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

Best wishes all, Dave

@davee @byron @papajoe0418 As to RTC DS3231 hs an accuracy of a few minutes per year. It's older less capable brother the RTC DS1307 is about 5 mins per month. Battery life for both is measured in years.

Accuracy is as posted a moment ago, 5 mins per month for the older board, a few minutes a year for the newer board.

Alarms can be a single date, all the expected periodic like 1st of month, every Friday, every 3rd Thur and so on. And on the finer end, hourly, every 15 min, etc. 

It wasn't about MOSFET's, it was THIS  post. It appears some of you have a misunderstanding of the RTC, it doesn't need to wake the PICO to have it check the time, the RTC is the king of the time. You simply pre-program it to wake up the hooter every hour between civil sunset and civil sunrise hourly, or every 53 minutes and 12.5 secs or whatever. And yes, it can be programmed to account for the date but NO, not the latitude without the addition of a GPS.

Hi Ron @zander,

  Re your statement:

These CR2032 coin batteries are powerhouses with 2,700 - 3,400 mAh of capacity at a 50mA draw.

I don't think so ... that is more like an 18650 capacity ... and even then the spec might be optimistic ....

More realistically,try https://data.energizer.com/pdfs/cr2032.pdf

They claim about 150 mA-hour before the starts dropping, maybe a maximum of around 200 mA-Hr if your load can continue to work down to about 2.5V.

This based on continous drain of 190 microAmps or 12 x 2-second pulses of about 2.8 milliAmps per day.

-----

Of course, a couple of years usage from a DS3231 is quite plausible.

Best wishes, Dave

@davee I got that data from your post yesterday at HERE

The older less accurate DS1307 is good for 17 years.

Hi Ron @zander,

  re: It appears some of you have a misunderstanding of the RTC, it doesn't need to wake the PICO to have it check the time ... etc.

The conversation may not have been clear, but so far as I can see, there are two different schemes, referred to below as A & B, depending upon hardware choices.

A/ You are correct in saying that the DS3231 could be employed as the 'master', in the sense that after each hoot, it could be programmed with the time (including date) of the next one, which could be two weeks time (say), if that was what is required.

B/ However, the alternative approach is to wake the processor (ESP, Pico or whatever) on a nominal periodic basis of say 1 hour, if the minimum time between two hoots is one hour. The processor would then determine the 'actual' time from an RTC and decide whether or not to hoot, then go back to sleep for another hour. This scheme has the advantage that the RTC does not need to include the alarm capability.

B/ could utilise a DS1307 ... not as good as a DS3231, but maybe 'good enough', and probably cheaper.

B/ could also use the internal RTC of an ESP8266 or ESP32. So far as I can see, the maximum 'deep sleep' time of these processors using internal wake up is just over 4000 seconds .. i.e. a bit more than 1 hour. Again, the long term accuracy of the ESP RTC needs to be verified to see if it is 'good enough' for that role.

I would agree that both of my B options need careful checking out, including measurements, before being implemented, as they are inherently less accurate. But they are also potentially cheaper.

It depends on the implemetor's design choices.

----------

I am not clear about your suggestion that latitude correction needs a GPS. I am assuming these devices will be fixed to the ground, and hence their latitude will also be fixed for their working life.

I can see that if they are to be issued to a number of areas with large variations of latitude, then some scheme might be needed to program or maybe pin select them depending on their location, but GPS seems a bit overkill.

Or am I missing the point?

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

Best wishes, Dave

@davee We are getting confused by different

but similar measures. The attached pic is correct, but that is for just a 210-220mAh CR2032. The Wiki article shows a picture of a 3V CR2032 which they normalize to 1.5V and although I know that chemistry is a powerhouse, I have no idea what math manipulations they used to come up with that number of roughly 3,000mAh. It's made more strange by the fact that the 18650's are rated at 1,600 AT 1.5V but it's the measuring conditions that tell the story.

For things like auto and solar batteries, the standard is known as the C20 standard. My LiFePO4 batteries are labelled as 100AH but the assumption is that is the C20 rating. The definition of C20 is

It is the energy a battery can deliver continuously for 20 hours at 80°F without falling below 10.5 volts.

I don't know what if any standard is being used in the two sets of numbers we are seeing but clearly they are different. 

Let's just keep it simple, coin batteries last a long time. My personal experience is 2 years for my photography and camera gear, and 5 years as large server backup to the internet.

If we go ultra-conservative and say change the battery once per year, I think we can agree that is doable, affordable, and safe.

@zander @davee  

I've just come in from the doing things outside and whilst there I had a look at my esp8266 based cricket i mentioned.  I was wrong in that I had not powered it with an AA battery (though a single AA battery would work), but I had powered it with 2 AAA batteries which, as said, last for approx 3 months.

It wakes every 15 minutes to send a temperature reading over wifi but I just use that reading to display the current temperature and I do not know how its RTC may drift over time.   My only knowledge of this is remembering some forum reads in the past (probably not this forum) where time drift has been discussed.  My impression was it was only minutes drift in a few months and to keep it accurate a periodic read from a time server (ntp) is necessary to keep it accurate to within a few seconds.  This is not applicable in this case of course. 

@davee Yes, you are missing the point and misdescribing how they work. There is no A or B option, it's all builtin.

@byron The older 1307 is 5 mins per month, the newer 3231 is a few minutes per year. These are the boards used by most time critical operations as NTP backup. They continuously update their internal clocks with NTP but then when the net goes down they provide the time to the servers until the net comes back on. I worked for Dow and the time had to be correct for the markets so this was how it was done. A few minutes a year is of no concern in this application.

Hi Ron @zander,

I was confused, but I have just stumbled on what you saw ... you were hovering over the the line

 and a picture of a CR20232 coin cell appeared! Not one of Wikipedia's better days!

Unfortunately, the picture and the line are not closely related to each other!

A quick Google shows an FR6 cell that that table line refers to ... https://data.energizer.com/pdfs/l91.pdf

which is the AA cell size, but with a non rechargeable lithium chemistry.

I guess it would take a DSxxxx RTC a long time to discharge one of them!

-----

As for the main aim of this thread, I suspect most readily available external RTCs would run for years on a single coin cell, and I am assuming the unit will have an annual 'refurbishment', giving an opportunity to renew if required. My uncertainity is that their time keeping in the field environment without access to correction during a season will not be a cause for concern. I suspect the DS3231 would be fine, but would its cheaper alternatives also be good enough?

Best wishes, Dave

@davee I almost never fact check Wikipedia, seems like that is not a good idea. Either unit should be ok, whichever is cheapest is probably the key at this point.

I'm just now getting back to the forum after a half day and am delighted to see the amount of conversation going on. It will take me a while to read through it all, but I did want to add some context to this particular project, to possibly narrow the conversation:

• The purpose of the device is to play owl sounds at intervals every night for about a week.
• The following values are determined programmatically using MicroPython:
  • How long to wait before starting the program (e.g., so I can set it at 11am and the owls hoot at 9pm)
  • How long the owls hoot (this is the actual "up" time for my sound player board -- generally a minute or two)
  • How long to wait before hooting again (e.g., every half hour or hour, interdispersed with sleep)
  • How many times to repeat (e.g., over a 5-hour period, every half hour, we would loop 10 times)
  • How many hours between programs (set to 24 hours, so that it starts every night at about the same time, with a deep sleep in between)
• There is no need to capture actual date or time. The last parameter above is the "cycle period". It loops until somebody stops it or the battery drains.
• The last parameter above may be the only thing that I can replace with an external RTC or similar. It's important to note that there will be several starts and stops which are all controlled within the microcontroller in between utime.sleep() commands. I don't know enough about RTCs to know if they can be programmed on the fly, or in conjunction with 555s.
• My #1 biggest issue at the moment is minimizing the current during sleep. 

I hope to read through all of the thread by the end of the day. Thanks all!

Hi Ron @zander,

  Glad we got the cell capacity/Wikipedia confusion sorted .. Wikipedia is normally pretty good, partly because it is supposed to be based on references, not the author's private knowledge bank, but that case is misleading.

--------

The long term accuracy of the various RTCs are all dependent upon environment. Those in PCs, MACs, phones etc are regularly 'reset' by reference to NTP servers as you say. They also tend to live in an environment with at least some protection from temperature extremes.

In @papajoe0418's opening message, he said "This is a remote device (i.e. out in the desert where wildlife abound)".

I don't know which desert, and I don't much about deserts, but my impression is that temperatures can vary greatly, even between night and day, and much more with the season.

Hence my concern, that a specification derived in (say) an air conditioned lab is of little use to a unit bound for a desert environment.

----------

I don't know which part of my "A" and multple "B" suggestions is incorrect. So far as I can see, the design is presently undefined and I believe each of my alternatives are plausible, based on available evidence.

As I said previously, your description which corresponded to my "A" was indeed correct.

But if you use a different RTC, such a DS1307 which cannot generate alarm calls, or the internal ESP8266/32 RTC, for which program wake up times from deep sleep is limited to (2^32 microseconds) ... around 71 minutes, then a modified approach is required, which I grouped as "B".

My main uncertainities are:

• reliance on documentation that may have been 'economical' with the full picture
• use and availabity of hardware in more extreme environmental conditions

Both are typical of the type of problems that only come to light when you do something 'for real', as against the original paper design.

So sorry, but what I have I misunderstood?

Best wishes my friend and take care, Dave