|
Post by SDL on Feb 26, 2019 9:16:23 GMT -8
Lutz,
Again you show great sophistication. BP asked me to read your whole posting on the IOT chicken coop. When you are finished with the project, we would like you to submit a blog with all your information and trials and tribulations (all the text above is a great start).
I like what you are doing.
Best regards, John Shovic
|
|
|
Post by lbendlin on Mar 4, 2019 14:36:12 GMT -8
I got an uptime of 8 days out of the current setup, albeit with the help of some nice sunny days. So, when things go well, what do we do? Of course, tear them apart and modify them. I had planned to replace the MG996R servo with a waterproof version, and at the same time improve on the connection between servo and solar panels (the original design put all the burden on the servo axle connected to the center point of the panels). This also gave me an excuse to include the I2C rotary encoder into the equation. The new design now has the waterproof servo as the top hinge and the rotary encoder as the bottom hinge for the panel assembly.
The new servo is much quieter than the MG996R but it also seems to be much easier to move. I will have to see if the wind load causes the panels to flap around more (they were rock solid with the MG996R). Worst case I swap the MG996R back in.
You can see the servo on the top and the rotary encoder at the bottom (it is not yet wired into the i2c bus). The smaller solar panels to the right are mostly for decoration, the two big panels are sufficient to provide all needed power.
It's now running for a day and a half, even capably shaking off the snow that fell overnight. We'll see how long I can make it run this time.
|
|
|
Post by lbendlin on Mar 8, 2019 4:58:34 GMT -8
TIL: I am always looking for ways to reduce power usage. Since my ePaper display only gets updated every five minutes (I am even debating not updating it overnight, but that would defeat its purpose of being the source of the final information before something goes wrong) I was worried about the associated service (epd-fuse) running at all times and consuming a considerable chunk of processor time (in the 5% range). The good folks at pi-supply suggested I look into subprocess.check_output. I was not aware of that option, but here it is in its full glory
r = subprocess.check_output(['sudo','service','epd-fuse','start']) text = PapirusTextPos(rotation=180) text.AddText(t, size=10,fontPath="/home/pi/Roboto-Light.ttf") r = subprocess.check_output(['sudo','service','epd-fuse','stop']) So now I only start the display driver when I want to update the display, and then I stop it again when the write process has finished. The ePaper display really needs no power in between updates.
For OLED displays (or other non-permanent displays) similar savings could be achieved by using a push button approach - the display could light up only while a button is pressed (by you).
|
|
|
Post by lbendlin on Mar 12, 2019 4:21:17 GMT -8
I bought a 5V fan for venting the box (to prepare for the expected summer heat, but I have already seen the battery temperature reach 90F on a mild winter day with full sun). Trying to decide where to place the fan and how to wire the fan in.
Placement: I am thinking bottom of the box or back side (pointing north). Should I direct the air stream outwards (pull air out of the box)or inwards (push air into the box)? If I pull air out of the box it would be replenished through the lid gaps (the lid is watertight but not airtight), but that may pull in hot air since the lid is in full sun. If I push air into the box I might make the temperature situation worse by distributing the hot air in the box more evenly?
Wiring: I am tempted to give the fan its own solar panel since my two 6W panels are often overwhelming the charging circuit which can only push 950mA into the battery. Plus, this would be a self regulating setup - the fan would work exactly when needed most. Alternatively I could control the fan from the battery temperature readings, so it could also run on a very hot but overcast day (but not much charging would happen then, and such a scenario is not very likely at this latitude - yet)
Any suggestions?
|
|
|
Post by SDL on Mar 12, 2019 6:46:25 GMT -8
Well, I see your point about the auto regulation. Sounds like a simple solution. You could use a Grove PowerDrive board to switch the power on and off under computer control. That's what we do on Project Curacao2.
BP
|
|
|
Post by lbendlin on Mar 12, 2019 7:19:01 GMT -8
Well I do have the QPM board, but all its channels are in use at the moment (I love the flexibility of being able to switch individual panels on or off). The fan only pulls 180 mA at 5V, so I guess I'll go with a dedicated small panel.
What about the location of the fan?
|
|
|
Post by SDL on Mar 12, 2019 7:51:40 GMT -8
Since you are pulling air into the box at the outside air temperature , I don't think it matters much. I would push air out of the box just because you get multiple sources of cooler air.
I ran a fan like this in Project Curacao1 and 2 and it was fun watching the fan turn on (at least figure out how to sense if the fan is on) and seeing it adjust the temperature.
BP
|
|
|
Post by lbendlin on Mar 14, 2019 4:46:07 GMT -8
I agree - pushing out the air also helps to keep critters and rain etc out more.
I added the fan, and wired it directly to my secondary solar panel (for the servo circuit). The panel pushes about 250 mA in good conditions, so it's enough for the fan (180 mA), the load (15 mA) and even a bit of charging.
Let's see how long the fan motor holds when subjected to the constant ups and downs of the panel energy. Supposedly it supports variable speed mode. Will be fun to observe the impact the fan has on the battery temperature.
I also put another 10000 mAh battery in on the main circuit (parallel to the existing one, after making sure they had the same voltage/charge level) just to see if I can increase the runtime when the weather is overcast. Despite the low 950 mA max charging current I think I can still eeke out enough wattage from the panels to fill both batteries when there is full sun.
I am still a little concerned about the impact of the larger battery capacity on the agility of the hysteresis process, but I only let SunControl decide for the upper limit (I use my own battery voltage threshold measurements for the low voltage shutoff as I found the hysteresis to be too unpredictable). Hopefully the voltage pressure during full sun charging will be sufficient to get the algorithm "over the hump" (ie will switch on the load) equally soon as it does now. What I mean is that when the battery reaches 3.7V while charging the actual battery voltage might be quite a bit lower (say, 3.55V) when you measure after removing the energy input. Nevertheless, the hysteresis kicks in, and that's a good thing.
|
|
|
Post by lbendlin on Mar 14, 2019 17:49:09 GMT -8
The fan seems to work fine - note the difference in the battery temperature between day before yesterday and today - the battery temperature is hugging the outside temperature much closer even with direct sun on the box.
(Data for yesterday is missing as I was messing with the Raspberry Pi to make the SD card more read-only (disabling swap and file system checks which resulted in some mild data loss)
|
|
|
Post by lbendlin on Apr 10, 2019 4:41:56 GMT -8
It's been a long time since my last post, and that's a good thing. The setup has worked perfectly for a couple of weeks. And then the other day, the solar panel stopped turning, and the AM2315 stopped responding. And I thought to myself "No, not that again!" when I hauled the setup in for troubleshooting.
What transpired though was that the setup itself was fine. The outage was caused by optimistic stupidity. In order to not damage the servo battery by constantly overcharging it I have a piece of code that checks if the servo battery is below a "safe" voltage, and then switches the servo solar panel on. (Fun fact is that the servo battery also powers the i2c bus. Another fun fact is that the servo solar panel also powers the fan). Guess what - the servo battery voltage dipped below the "safe" range just as we were entering a very rainy and drab day (bottom chart).
So yes, the panel turned on as it should (black line), but it had no chance to actually replenish the battery and then the battery went south very quickly after that, since the constant consumption was met with quickly shrinking voltage (top chart)which required higher current (middle chart) etc.
As a lesson I have now raised the "safe" voltage on that battery from 3.6V to 3.8V which should give me at least another day of buffer where the solar panel can do its thing.
Another lesson is to really think about weather much more. If I know that the forecast calls for overcast/rainy days ahead then I should make every effort to top off the batteries even if that means driving them outside of the optimal range (70% to 80% capacity).
|
|
|
Post by SDL on Apr 10, 2019 6:54:17 GMT -8
Lutz, As usual, your postings are fantastic. On one of our prototype systems here, we have a 5V fan controlled by a Grove PowerDrive board that turns on when the inside temperature of the box hits about 100 degrees F and turns off when it cools to about 90F or so. It is powered by the main battery. Here is what it looks like turning on and off during a hot spell we had a bit ago. The blue line shows the fan state. This is part of the SkyWeather project development. In most cases, we won't need the fan, but we wanted to add it as an option. John Shovic Attachments:
|
|
|
Post by lbendlin on Apr 11, 2019 3:40:02 GMT -8
I think HVAC is where solar energy really shines (pardon the pun). It provides the energy for fans or heat exchanges exactly when it is needed most (when the sun shines the hardest). I wired my fan directly into the secondary solar panel, so it only comes on when the panel (and the utility box) gets the direct hit from the past-noon sun, and still leaving enough wattage to replenish the battery. The fan may even act as a quasi-Zener to keep the idle voltage of the solar panel under control. And all this with no circuitry and no programming!
On a more urgent note, the chicks are here and I need to start on phase two of the world domination plan. Namely, motorize the coop door and think about the RFID tags. Wonder if I can wrap the tag around the leg?
Right now they are still in the brooder box that I built from scrap wood and plexi glass. The Pi uses an infrared camera (with IR light assist) and you can see the black heating lamp. I use a wifi smart plug and the temperature sensor on the Pi (SHT21) to keep the ambient temperature between 78 and 82F. There's also a brooder plate (left back) for the overnight heat.
|
|
|
Post by SDL on Apr 11, 2019 6:47:24 GMT -8
And the Saga continues. You are right about the "self regulating" of your system. In the winter however, you may find yourself turning the fan on when you don't want it!
I am copying this to my friend RuthAnn, who needs to know about your Chicken Coop Saga.
BP
|
|
|
Post by lbendlin on Apr 22, 2019 11:24:22 GMT -8
Next step in the process - the RFID tagging. I plan to place a MFRC522 reader under each of the nesting boxes, and one or two under the entrance to the chicken coop. The chicks will carry lightweight keyfob style tags (supposedly that doesn't bother them, and can even count as leg jewelry), and the humans can use the standard MiFare cards (for example to log cleaning events). I tested one of the MFRC522 and it works very well (once I had weeded out the bad/broken keyfobs). Very neat, you can not just read the fobs but also write to them (each has 1KB or EEPROM I think) for whatever data is worth storing.
There's just one catch - by default these MFRC522 boards come configured with SPI interface which provides maximum speed but also restricts the connection to just one client. I need four or five... There are some tutorials on how to convert these boards to I2C but they are very scary, involving either desoldering or drilling holes right next to the IC. Has anyone else here been successful in converting the MFRC522 to I2C interface?
|
|
|
Post by lbendlin on Apr 23, 2019 4:56:08 GMT -8
I should have done better research. In other words - I admit defeat. After trying for hours to modify the RC522 chip (chopping off pin 1 in the hope that would make it float to high and switch to I2C mode) nothing really changed and it still works in SPI mode. However, there are other boards available that can easily be switched to I2C mode with dip switches, and even have address pin breakouts. The PN532 based boards, for example. So now I ordered a couple of those to test that I can make them work on I2C at the same time. As an added bonus I found tiny flexible RFID tags that might just work directly as leg rings (as opposed to the key fob appendage option) - Adafruit item 2800. Not sure about the peck-proofiness, but we'll handle that when the time comes.
|
|