Good golly, what can this possibly be?!? I'll explain: There's been a lot of land development in my community, here in Maricopa, AZ, USA, and the resulting upheaval has sent many burrowing owls scurrying off to new home locations. Unfortunately, the developers didn't have a relocation plan, and they should have. It's the law.
I'm part of a group of residents who partitioned an area in our community where we built burrows for relocating owls. In our first attempt, we tented and fed a mated pair, only to see them fly off to parts unknown when we lifted the tent. So this next time around, I'm going to build a device ("Burrowing Owl Relocation Sound Box") that plays burrowing owl calls so that our owls think that there are other burrowing owls in the area, which actually makes them feel safer!
When I first introduced myself at dronebotworkshop, I immediately got some great information. I'm hoping to continue the dialog here, as well as document the process I will use for construction. Perhaps others will try this project as well, and help relocate wildlife in their own areas.
So initially, I'm writing a microPython script to allow the user to set time values so start, pause, and repeat the owl noises. This needs to be very flexible because we only want to play the audio during certain times of the night and at natural intervals for about a week at a time. I actually completed about 90% of the Python programming. I just need to add the physical devices (Pico microcontroller and Icstation sound module). My real challenge will be the electronics, which I hope to start very soon.
Should I be posting my source code here? Would that be of interest to anybody?
@papajoe0418 If you are having trouble with it sure for the few who read python, otherwise wait until done and post in the Show and Tell sub-forum.
First computer 1959. Retired from my own computer company 2004.
Hardware - Expert in 1401, and 360, fairly knowledge in PC plus numerous MPU's and MCU's
Major Languages - Machine language, 360 Macro Assembler, Intel Assembler, PL/I and PL1, Pascal, Basic, C plus numerous job control and scripting languages.
My personal scorecard is now 1 PC hardware fix (circa 1982), 1 open source fix (at age 82), and 2 zero day bugs in a major OS.
@zander Sounds good! Hopefully, it will turn out to be an owl relocation success story. 😀
My next challenge on this project (after Python programming) is power. This is a remote device (i.e. out in the desert where wildlife abound), so a USB power pack is not desirable. This is my first Raspberry Pi Pico project, so I'm going to describe what I think I will do, in the hope that someone will have a better idea:
I intend to use the Pico to activate a sound player (Icstation mp3) via relay. (The player will be powered separately with a 3.7v lithium battery.) The purpose of the Pico is to trigger the sound player at specific intervals over several days.
So I plan to connect the Pico's 3.3v GPIO (e.g., pins 36 and 33) to one side of a 5V relay which then triggers the other side of the relay to close its circuit and turn on the music. (I think 3.3v is sufficient to trip a single channel relay.)
I'm thinking that I can use three AA batteries (at pins 39 and 38) to power the Pico. My existing Python code will keep track of time and send the occasional wake-up to the player.
Am I making a rookie mistake somewhere?
@papajoe0418 Instead of a relay, use a MOSFET, uses almost no power to trip it. If you really want to save power, either attach an RTC or see if the PICO has a deep sleep mode like the esp32's have.
First computer 1959. Retired from my own computer company 2004.
Hardware - Expert in 1401, and 360, fairly knowledge in PC plus numerous MPU's and MCU's
Major Languages - Machine language, 360 Macro Assembler, Intel Assembler, PL/I and PL1, Pascal, Basic, C plus numerous job control and scripting languages.
My personal scorecard is now 1 PC hardware fix (circa 1982), 1 open source fix (at age 82), and 2 zero day bugs in a major OS.
Hi @papajoe0418,
Not a rookie mistake, but something to look out for.
Battery consumption of the Pico needs to be considered. As an example, I'll try to do a rough 'back of an envelope' calculation. Note that the 'data figures' I am using are only rough guides ... treat them as demonstrations of the calculations and measurements you need to make - not as 'final answers'.
AA capacity is apparently Alkaline batteries from 1,700 mAh to 2,850 mAh ( https://en.wikipedia.org/wiki/AA_battery). The voltage will fall as the battery discharges, so you will not be able to use 100% of that capacity. Hence pick a lower value ... maybe 2000 mAh ?
As the Pico is powered all the time, if we say 1 day is 25 hours, and want it to run for 8 days on 1 set of batteries, then this is 8 x 25 = 200 hours.
Then, average 'available' current consumption is 2000 / 200 = 10 mA.
Power consumption of a computer is notoriously difficult, as it both software and hardware dependent.
Quick Google showed:
taken from https://picockpit.com/raspberry-pi/everything-about-the-raspberry-pi-pico/
This table suggests that for just 'being awake' the consumption could be 10 mA, whilst actively computing could be almost 100 mA.
This very crude estimate suggests a 'borderline' situation, with no margin, unless you can make the Pico 'sleep' for most of the time.
Thus, assuming you have a Pico, I would recommend trying to set up some measurements of actual current consumption whilst it is actually performing the function.
I haven't done any work on a Pico, but I know others, working on older microcontrollers, have sometimes found implementing 'sleep' functionality can be tricky. Of course, the Pico has many users and you may find it is not a problem, but I suggest you try it out, before committing it to the rest of the project.
------
A parallel consideration, is that whilst a relay is simple and reliable to implement, it does require an appreciable current to operate it. In the most obvious configuration, this current would also come from the AA batteries. It may be that the relay is only closed for a very short period of time, but I don't know how much time per night it will be energising the MP3/amplifier section.
An alternative is to use a solid state switching, probably a MOSFET. Bill (@dronebot-workshop) has at least one article + video on the subject, at https://dronebotworkshop.com/transistors-mosfets/
which introduces the topic.
------
Hope this is useful. Best wishes, Dave
@davee yes, absolutely useful! I expect that the circuit will be closed for under a minute, once per hour during nighttime hours. The vast majority of the remaining time, I'm using Python utime.sleep() function. Will bench test and will do the math, as well as look into a possible deep sleep mode mentioned by Ron. 👍
Although I don't have enough experience to offer solutions may I say how heartening it is when I see people who really care about the survival of other species. Unfortunately very few take an active interest in the natural world they only care about their human environment and other humans. Animals are only useful to them if you can eat them or use them as pets.
Hi @papajoe0418,
The text surrounding the table I snipped from the reference https://picockpit.com/raspberry-pi/everything-about-the-raspberry-pi-pico/ says
You might be wondering: what is the difference between DORMANT and SLEEP?
Dormant requires an external trigger that manipulates a GPIO pin to wake the Raspberry Pi Pico while SLEEP can run an internal clock to wake the RP2040, as illustrated in the RP2040 datasheet.
In the Raspberry Pi Pico FAQ, they further clarify that,
“SLEEP mode is when processors are in wfi/wfe and DMA is inactive, so you can shut off most system clocks, including things like bus fabric.
DORMANT mode is when you shut down all oscillators, and so is lower power still, but then you have fewer options for waking.”
First glance suggests that the nearest equivalent to 'deep sleep' may be called 'Dormant' for Pico ... and the table shows consumption is lower but not the very low value achieved by microcontrollers designed to run for 1 or more years on a coin sized battery. However, Sleep might be "good enough" and easier to implement.
-------
As an aside, I am not clear why you need two sets of batteries. The same reference says the Pico is happy with 1.8V to 5V. Sometimes, it is wise to have split supplies, e.g. high current motors, but I would have expected a 3.7V Lithium based cell could handle the entire job.
Of course, depending on how low you can get the microcontroller power consumption, you might need to increase the size of the cell, plus some additional decoupling capacitors and careful wiring is always good practice for a reliable result.
Worth an experiment I should have thought? (Also, could be more 'eco-friendly' as you are not using 'throw away cells'?) You can still use a MOSFET to switch the power the MP3/amplifier unit when it's needed.
---------
NB, regardless of the one or two battery discussion, you need to be a little bit careful about the data connections between the microcontroller and the MP3 player, as it is possible to have the situation when the microcontroller is powered but the MP3 player is unpowered, that the data wires can become a partial power source from the microcontroller to the MP3. This is not a healthy relationship for many reasons that need another sermon to explain.
I had a few seconds look for a pre-written explanation and I found this video for a starter
//youtu.be/2yFh7Vv0Paw
It might be possible to fix in software by ensuring the 'pin type' of the microcontroller data (output) pin type is set to input whenever the MP3 player is unpowered, so that it is unable to supply current.
You may decide to 'park' this issue for now, but at least watch the first two minutes which demonstrates the effect of the problem ... then put it on your to-do list.
------------
Best wishes, Dave
@papajoe0418 Check this link out if not already mentioned HERE
First computer 1959. Retired from my own computer company 2004.
Hardware - Expert in 1401, and 360, fairly knowledge in PC plus numerous MPU's and MCU's
Major Languages - Machine language, 360 Macro Assembler, Intel Assembler, PL/I and PL1, Pascal, Basic, C plus numerous job control and scripting languages.
My personal scorecard is now 1 PC hardware fix (circa 1982), 1 open source fix (at age 82), and 2 zero day bugs in a major OS.
@zander This looks like something I recently read...like yesterday. The sadist in me is considering rewriting this in C. But first I'll digest Davee's info and do some bench testing to determine just how much power drain I'm looking at. The prospect of drawing only 1.4mA is enticing.
@robotbuilder Your comment compelled me to look for the "thumbs up" button. (Found it!) Thumbs up to you for empathizing with our furry and feathery friends.
I tested my software in main.py using the onboard LED in place of my owl sounds. The LED flashed at the correct intervals (once per sleep cycle). After breadboarding the RPi Pico and Icstation sound module, I see that the sound module has a momentary switch that I had forgotten about. Looking back at all of your comments above, I'm thinking about how this switch changes the game. It looks like I can power both units in parallel with the same batteries, and just connect the momentary switch to the Pico. That is, I can I use the Pico to programatically "push" the momentary switch with .value(0) and value(1). This would seem elementary to anyone who fully understands how the Pico GPIOs work. Me, I'm just guessing, being much more familar with Python than with Ohm's Law.
EDIT: It actually seems to be working perfectly if I wire the momentary switch to pins 17 (GPIO) and 18 (GND). Then I toggle PIN 17 between .OUT/.PULL_UP and .IN/.PULLDOWN with a short pause in between to turn the sound on, then repeat that to turn the sound off. Too easy? I don't smell anything burning yet. 😀
Too easy to be right. 🙄