New project underway to observe the voltage on each of the four battery banks and see the results on a web page.
Hardware consists of four Arduino voltage sensors and an ESP32 module. Jumper wires are the only thing missing above to complete the hardware side of the project. It will be programmed using the Arduino IDE. An IOT broker such as Adafruit is planned for the web page display server. It is envisioned to display four gages and four graphs so the state of the four battery banks can be checked with a quick glance. It could also be programmed to send an alert notification at a voltage maximum or minimum.
The sensors come with a resistor voltage divider designed to present no more than 5 volts to the ESP32 analog input pins. Consisting of two smt resistors the top one is 7.5K ohms and the lower resistor is 30K. These values permit a maximum allowable voltage of 25. The 24 volt battery bank usually has more than 25 volts dictating different resistor values to protect the ESP32 input pins. Adding a 10K shunt across the top resistor will produce a maximum allowable voltage of 42 volts. Perfect. A 10K 1/4 watt roundy can be tack-soldered in parallel with the smt 7.5K resistor.
The blue battery bank was falling behind and the tan battery bank was fully charged by noon each day. As a solution a solar diverter was developed and installed to switch that excess solar power from the tan bank to the blue bank. Once state-of-charge falls behind on any of the battery banks it’s hard to catch up without some additional outside help. A solar diverter switches one array of solar panels from one battery to another. A nice feature of solar controllers is multiple controllers can be run in parallel to provide increased charge power to a battery. Hardware is a typical 30A automotive relay controlled by a 12 volt port on a Rigrunner 4005i. The station’s solar arrays each peak out at 18 amps so a 30A relay allows a good safety margin. Here is the white-board sketch and capacitor calculation.
Why the capacitor?
A relay typically takes 3 ms to switch from one state to another. During that 3 ms no battery is connected to the solar charge controller. With no battery a controller will shut down and pass through the 20 volt solar power directly to the load port by default. That would destroy the attached 12 volt equipment ( This has been learned the hard way unfortunately and more than one Rigrunner 4005i has been burned up ). Will a 470 uF capacitor from the junk box provide power long enough to bridge the 3 ms gap and prevent the controller from shutting down? Morningstar’s manual says the controller consumes 22 mA. Using ohm’s law that means the resistance is 614 ohms when battery voltage is 13.5 V. Plugging the known values into the formula for a time constant (T = RC ) produces a result of 300 ms or roughly a 100 times factor of safety. Happy with the results and moving forward with the installation, this is what the ridiculously simple solar diverter looks like.
After going live for two days no problems have appeared and the blue battery bank has increased it’s state-of-charge. It’s closing in on 100% probably in a day or two. Rigrunner 4005i’s have a built-in timer for each port so that feature enabled the solar diverter to easily be on a noon-to-8pm schedule. No spikes have been noticed.
Update 7/3/2021 – Rethinking the above modification with regards to cold weather. Each controller has a temperature sensor on the battery it serves. Let’s say it’s the middle of winter and the diverter is on, diverting power from the tan battery to the blue. How does the tan controller know the temperature of the blue batteries? It doesn’t. It only knows the tan battery. What if the tan battery is above freezing but the blue is below freezing? The tan controller would charge the blue batteries and damage them. Not good. The diverter is ok for summer but not winter.
Next Power Tweak
One of the batteries is still struggling occasionally even with the plentiful midsummer sunshine. The WSPR station is the only load on the Green batteries and that small load is too much. It runs down after a cloudy day. Extras like WSPR, KiwiSDR, Pixel loop antenna, NUC pc’s, security camera, weather station, and mobile hotspot seem to be the culprits system wide. Batteries do fine if the extras aren’t loaded on. Extras impose a heavy load because they tend to run 24 hours a day. For example the WSPR station only draws one amp but over 24 hours that’s 24 amphours. That’s enough to effect the power budget. Next power tweak is to try moving the extras to their own dedicated battery. Green battery is the natural choice because it is already dedicated to serving an extra device. It’s running down with one device so it clearly needs an upgrade. Currently it has two panels. How many more does it need?
All the extras total a daily load of 87 AH which has to be generated by solar during the 5 hour window of peak sunshine (engineered for the shortest day of the year). For 87AH / 5 HR = 17 amps per hour. Panels generate 6 amps during peak which means we need 3 panels ( 3 panels X 6 amps = 18 AH). Currently the green batteries have 2 panels. One more can be easily added ( for $100 ). Will the green battery have enough capacity to hold up through a cloudy day?
It was capacity-tested at 142 AH. Derating for a range of 20% to 90% state-of-charge, usable capacity is 99 AH. At the start of a cloudy day it has been 19 hours since it was fully charged and has discharged 68AH ( 19 X 3.6 AH or 68 AH ). That leaves 99AH – 68AH = 31AH for the next 24 hours until peak sunshine returns. Clearly not enough because 31AH is way less than 87AH. Although adding more battery capacity would be the obvious solution, the cost rules that out for now. Plan B? Shedding some load with timers or with turning off certain devices. Plan C? Just let the low-voltage-disconnect turn off the extras when the battery is dead. They would automatically be reconnected when enough sunshine returned. Here’s an estimate of adding adequate battery capacity.
How much is needed? The original batteries would need to be replaced because batteries of differing ages or capacities cannot be added on to. The cost for a new string with a derated capacity of at least 87 X 2 = 174AH, would be $261 as of this writing.
Increasing battery capacity means more solar is needed, too. Battery capacity jumps to 174 AH. Dividing by 5 peak hours of sunshine the needed amps is 35A. The controller maxes out at 30Amps so a bigger controller is needed. A compromise is to stay below 30A and that would make the number of solar panels 5. That’s 2 more than the 3 already installed for an additional cost of $200. Total cost with a compromise is $461. Adding hardware and cables comes up to a good estimate of $500. Doing it right with a new controller is probably ruled out because Morningstar does not offer a higher current controller with low temperature foldback. Choice at this time is Plan B: adding one panel, keeping same battery and controller, and shedding load when needed. Cost $100.
Power Tweak No. 3
With the third panel added, all battery banks now have the same number of solar panels. It seems that transfer relay was superfluous and was removed. Once the loads were rebalanced and distributed more evenly all batteries are charging normally. The relay was repurposed to disconnect the solar panels from the controller when it was generating rfi. See the post on solar panels and rfi at:
Using PSKReporter, stations were being spotted on 6 meters in Colorado that were not being copied by this station. That was incentive to switch from stacked halo antennas to a yagi to hear better. Being heard by others is not the problem. PSKReporter shows spots everywhere in the country when the band is open plus there is an amplifier that can be turned on any time. The problem is hearing those last 5 states needed for Worked All States. It was a quick swap out of antennas. The coax and rotator were already in place so it was just a matter of taking down the halos and putting up the yagi — done in a day. Cushcraft makes a very inexpensive 5 element antenna that is a good choice for a trial. Don’t you think it makes a pretty stack?
Performance results to follow.
Update – May 31, 2021: Worked 2 of the 5 needed states so far. It works! Still need DE, AK, and HI.
Update – July 15, 2021: Got all 3 remaining states and now have WAS on 6 meters! Yay!
For a long time there have been multiple signals on this remote base that appear to be digital hash and not legitimate radio signals. On the water fall they look like noise from switching power supplies. Considerable work has been done trying to get these signals chased down. Over the last year each switching power supply has been replaced with a linear supply or the switching power supply has been mounted in a metal box with ferrite chokes on the leads. Since the noise continued, looking elsewhere was necessary. The next suspects are the solar controllers considering they switch power on and off rapidly just like a switching power supply and considering they are about the only devices that haven’t been investigated. Searching the web turned up numerous reports that solar controllers are major contributors of rfi. The controllers used at the remote site* are specifically selected because of their FCC Class B certifications. They aren’t supposed to be generating rfi. That’s why they haven’t been investigated earlier. Today’s testing was very revealing. The controllers are generating tremendous rfi. Later it was discovered the interference occurred only in the mode where the batteries are fully charged. The controllers are in a state of “high voltage disconnect” to avoid overcharging the LifePO4 batteries. When the system is in a charge state there is no interference. Below is a picture of a water fall on 17 meters on a sunny day when the solar system is generating full capacity in a “high voltage disconnect” status.
Obviously those big wide bands of yellow-green are not supposed to be there. They are digital hash caused by something. Their huge signal strength indicates the source is probably local. Next picture is with one of the four controllers turned off. Observe the band on the right and the band in the center have disappeared as the waterfall continues to scroll down. Two bands on the left are still present.
Next, another of the controllers is turned off revealing an amazingly rfi free band. What a stunning difference. Apparently the other two controllers are not generating hash, for some reason yet to be determined.
Toroid chokes on the controller wires should be an easy fix. A hand full of Mix 31 ferrite toroid chokes was placed on the wires that come in and out of the controllers and no noticeable change occurred. Paraphrasing the captain of the boat in the movie Jaws, “We’re going to need a bigger choke”. Upon more Web scouring back home, an article was found that discussed a rarely mentioned bit of information about ferrite chokes.
“Ferrite material choking performance degrades in the presence of strong DC current. For this reason, it is better to pass both DC wires from the solar panels through the same snap on ferrite as this will eliminate the DC bias in the core.”
The chokes had been placed on individual wires in the initial test. About 15 amps of DC was present on those wires. Is this DC current enough to degrade the performance of the chokes? On the next trip to the site, both wires will be placed through the cores and the results will be reported here.
*The controllers used at the remote site are Morningstar PWM ProStar PS-30 and Morningstar MPPT ProStar PS-MPPT-25M.
Chokes On Both Wires Together
Next site visit and the first thing noticed is that different controllers are causing interference than the ones that caused it last time. Here is the first picture upon walking in the door without any testing.
Two lines of digital hash coming down the waterfall are from two of the four controllers, but not the same ones as last time. Next picture is after turning off three controllers and at the 7 second mark placing a choke on both wires of the 4th controller.
The choke clears up a good amount of noise but not nearly all of it. More chokes were added and there was almost no more improvement. Chokes don’t seem to be the answer.
Next topic is why only two controllers at a time cause interference. What is the difference? PWM and MPPT controllers are both contributing equally. It was soon noticed that the interference is coming from the controllers where the batteries are fully charged. When a battery is not fully charged and the controller is working hard there is no interference. When a battery reaches it charged state and the controller stops charging, it starts generating the digital hash. Solutions come to mind both elegant and crude. An elegant solution would be to monitor the modbus data output and watch for the fully charged messages. Use a microcontroller like an Arduino to turnoff the controller. That sounds like a lot of coding and debugging and time spent. Turning to the crude solution, that would be a relay on the solar input cables driven by a voltage sensor on the battery. When the battery reaches full voltage the relay would open and effectively turn off the controller. Call this solution the Rube Goldberg, band-aid, patchwork-quilt solution but voltage sensors and relays are now on order from China. The interference will have to be lived with for a month until the parts arrive.
While waiting for the parts from China an article surfaced that suggested trying 4 turns of both wires through one toroid of mix 31. That was tried and it did not reduce the noise noticeably. In an act of desperation bypass relays were inserted in the solar panel input leads so the panels could be cut off completely if they were causing interference. This is the method referred to above as “Rube Goldberg”. The difference is the relays are controlled remotely from home over the Internet instead of by an Arduino monitoring the modbus or instead of a voltage detector. So far it works perfectly. Case closed. For now.
When LifePO4 batteries are located in an unheated outdoor equipment shed in climates like Colorado their winter temperature can fall below freezing quite often. LifePO4 batteries will be damaged if they are charged when they are colder than freezing. A couple of uninviting options exist. First, the shed can be insulated and heated, which could be a lot of work and expensive. Second, the batteries could just not be charged until the temperature warms up. Even on a sunny day that typically means around noon and leaves only time for a partial charge on short winter days. A third option appears to be the least painful and that is to provide some external source of heat directly to the batteries through the use of heaters. There doesn’t seem to be any product marketed specifically as a LifePO4 battery heater. Researching alternatives, one possibility is the silicone heaters used to warm the bed of 3D printers. It is flat, comes in various shapes, voltages, power ratings, and it is inexpensive. A sampling was ordered and tried out. Finally selected is a 20 watt 12 volt heater shown below.
These pads fit nicely between alternating cells so each cell is adjacent to one heater. Leads are brought out and connected in parallel with wire nuts. Each heater draws 1.5 amps and in the lineup below 4 heaters draw 6 amps.
Getting this far was the easy part. Figuring out how to power the heaters is the next challenge. It was quickly learned that using the batteries themselves was a net negative. Heaters use too much power. The batteries don’t get fully charged before the sun goes down. An external set of batteries was tried but that just shifted the problem. After a few days the external batteries don’t have enough charge to run the heaters. Another failure was the use of timers to only turn on the heaters right before the sun came up. A new idea was needed. Time for …
Innovation
While the batteries are too cold to charge and the heaters are running, the solar cells are sitting idle wasting generated power. Duh. Why not use the solar power to run the heaters? This idea was tried and has been working successfully for several cold winter months. Power was tapped where the solar panels go into the solar controllers. The tap is the small red and black wires in the picture below.
Raw voltage is typically 20 volts and that would burn out the heaters. A 10 amp buck converter was inserted in the line to keep the voltage at 12 volts, one buck converter for each of the battery banks. A metal box limits the rfi emitted from the digital buck converters.
A W1711 thermostat rounds out the installation. This little guy is set for 5 degrees Celsius which allows some margin to make sure the batteries are kept above freezing when the sun is up. When the sun isn’t up there is no concern because there is no solar power available to damage the batteries. What happens when there is solar power but the batteries haven’t warmed up above freezing? The Morningstar controllers were specifically chosen because of their feature called “low temperature fold back”. Even when there is solar generation, if the batteries are below freezing the Morningstar controller will refuse to charge the battery.
Problem: When the Flex is connected to the mobile hotspot with reverse ssh tunnel the radio can be accessed just fine from a pc but not from the Maestro. When the Flex is connected to the dedicated Internet connection with a static i.p. and port forwarding the Maestro works fine but the pc experiences drop outs and packet loss.
Solution: Change the existing conventional router to a Dual WAN router. This reduces the number of LAN’s from two to one. With only one LAN the Flex is always on the same LAN as the client. The Maestro can come in on the dedicated Internet connection and reach the Flex on the LAN. The pc can come in on the reverse tunnel and reach the Flex on the LAN. With Flex’s new Multi-Flex protocol the two can come in at the same time and share the Flex.
Several models of Dual WAN routers are available in the $100 range and they are currently be evaluated. One example is the Ubiquiti EdgeRouter Lite shown above. Notice the ports are labelled eth0, eth1, and eth2 rather than WAN and LAN. The ports are configurable to be either function.
Followup: It’s never as easy as it sounds. Load balancing is the first issue. The dual wan router is now installed, configured, and working as designed but not doing what was hoped for. At issue is which WAN a client is connected to when the reverse tunnel is established. If it’s on the wrong WAN the whole concept is defeated. One available option is to specify what ports go to which WAN. A SSH tunnel is using the SSH port which is 22. Directing port 22 traffic to the higher speed WAN will be the next experiment. Ultimately the Edgerouter was pulled from service and returned to Microcenter. The whole idea of a Dual WAN really hasn’t proved out. The original one-WAN router is back in the circuit and all is working just fine. As for having just one LAN, the two NUC’s are tied together back to back, one on each LAN. The interconnect is the second ethernet port for each NUC. The hardware is a USB ethernet dongle. The two LAN have different subnets. To reach the other LAN one just enters the address for the other LAN and the NUC routes out the second ethernet port. Thus there are two LAN’s but they are routed to each other by the NUC’s. Crude but it works. Later the interconnect was removed and one NUC has a connection to both LAN’s. No conflicts have occurred. On that NUC a reverse tunnel is established and connected to from the outside world. Other resources can be reached on the other LAN from that same NUC with no issues. It appears the dual wan router was never needed. The NUC is handling any routing needs quite elegantly. There are two LAN’s but the second LAN has only one resource connected and that’s the NUC’s second ethernet port. Every other resource is connected to the main LAN including the Flex radios. It all works well so far.
Or How To Use Starlink or Mobile Hotspot For Remote Internet Access
Both the Starlink and the AT&T Mobile Hotspot have firewalls that prevent traffic from coming in from the outside world. There are two terms for this, “Double Natting” and “Carrier Grade Natting”. The end effect is there is no public i.p. that can be accessed from the outside. Port forwarding won’t work because with no public address there is no way to reach the router. (On the server end port forwarding is needed, however. ). Not to fret. There are two solutions. One is Chrome Remote Desktop (or similar remote desktop service but not Windows remote desktop). The other is Reverse SSH Tunneling. They both work the same way.
First lets define some terms. The local computer is the one on the user end and the remote computer is located at the far end behind the firewall. The username on the local computer is “hamstation@outlook.com”.
The first and simplest solution is to run Google Chrome Remote Desktop on both computers. The remote computer can be reached even through a firewall because of an easy secret. The secret is, Chrome Desktop on the remote computer opens a connection automatically to another server somewhere in the outside world. All the user at the local computer has to do is connect to that same server which in turn bridges the connections. The nice part is, Chrome Remote Desktop does all that automatically with no intervention or set up needed by the user. It’s amazingly easy to use and more importantly, it bypasses the firewall. Add the Chrome Remote Desktop extension to the Chrome Browser on each computer.
A second much more elegant solution has been around for over 20 years and does not require Google. It is called Reverse SSH Tunnel and is much easier to use than it is to explain or understand. Even the figure above is way too confusing. The concept is identical to Chrome Desktop. A remote computer behind a firewall opens up a connection to another server in the outside world. A client then connects to that outside server and the connections are bridged. That connection is called a tunnel. A simpler alternative exists and that is for the client’s computer to be that outside server itself. No need for a second connection or a bridge. No need for a separate server in the middle. Explaining the name, “Reverse” means the connection is going in the reverse direction from the normal way, from the inside out rather than the outside in. “SSH” stands for secure shell. SSH is a standard that encrypts all the data so there are no security issues. “Tunnel” is the term used to describe what this connection is. Let’s take a look at how to implement Reverse SSH Tunneling.
Requirements — For Windows: OpenSSH Client and OpenSSH Server are needed on both computers. On Windows the apps are included but need to be installed. They are found in the Apps window under Optional Features. For Raspberry Pi both applications are already included.
Once installed and started at both ends open a command line window on the remote computer then enter the following instruction. This will tell the remote computer to open a tunnel to the local computer. That tunnel can then be used for traffic back from the local computer to the remote computer (in “reverse”).
That’s it. Explanation: ssh means the arguments that follow are going to open up a tunnel
-R means the direction of the tunnel is going to be reverse.
8888 is an arbitrary port number chosen at random which will be used later by the user at the other end on the local computer.
localhost is the computer where the application will be executed, in this case the remote computer. “localhost” just means the name of whatever computer you’re currently on which in this case is the remote computer.
3389 is the port for Windows Remote Desktop. Remote Desktop Connection is the application that will be executed.
hamstation@outlook.com is the username on the local computer. Replace it with your own username on the local computer.
@174.51.135.253 is the i.p. address to reach the local computer from the remote (port forwarding is used at the local computer end) Replace this address with the i.p. of your local computer or router.
When the line is entered on the remote computer the response will be to connect a tunnel from the remote computer to the local computer. A password will be asked for and that is the password for the username on the local computer. If everything worked correctly the remote computer will just sit there listening for incoming traffic on the tunnel.
On the local computer the user will open Remote Desktop Connection and enter this information in the “Computer” field:
localhost:8888
The password will be needed for the Remote Desktop Connection for the remote computer.
Traffic to flow back down the tunnel from the local computer to the remote computer and a remote desktop screen will pop up on the local computer. Any operation that can be done on the remote computer can now be done on the local computer including operating the Flexradio and all the peripherals.
Persistence
How to keep the tunnel up when not in use? That’s a challenge and it has a name—persistence. Persistence is quite easy with Linux systems. One would use autossh instead of ssh. Autossh has built-in tools for keeping the tunnel alive when not in use. Windows does not have those tools and autossh does not run in the Windows operating system. Several 3rd party apps exist but they look like unworkable kluges. This challenge is a work in progress. So far the tunnel is being established when needed and it times out a few hours after it’s no longer being used.
To determine what tuners will work with a 43 footer the impedances need to be known for each band so tuners can be utilized that can handle those impedances.
The vertical tested here is a DX Engineering DXE-MBVE-5A 43 foot vertical. Radials are four pieces of welded wire fencing each 25 feet long laid flat and terminated on a DX Engineering DXE-RADP-3 radial plate. The fencing is 48 inches wide. A RigExpert model AA-55 was used to make the measurements. Each band was tested, 160 meters through 10 meters, except 12 meters. Here are the results including the (poor) snapshots of the AA-55 screens.
160 Meters
|Z| = 506.9 ohms (notice the R component is only 11.8 ohms)
SWR = infinity
80 Meters
|Z| = 216.6
SWR = infinity
60 Meters
|Z| = 58.6 ohms
SWR = 3.5
The 60 meter frequency of 5357 kHz is very close to the resonance of a 43 foot vertical. A dip at 5957 confirms the expectation.
A quarter wave vertical with a perfect ground system should have an impedance of 36 ohms. For curiosity the AA-55 was adjusted to the antenna’s resonance at 5957. Here is what this antenna measures:
|Z| = 45.7 ohms
SWR = 1.10
This reading of 45.7 ohms indicates a ground loss of 9.7 ohms (45.7 – 36 = 9.7) or approximately 10 ohms. This value agrees with the amateur literature for a typical ground system. One example is Phil Salas, AD5X’s presentation on The 43-Foot Vertical : “Assume 10 ohms of ground loss — Probably a much better ground than most hams have”. The efficiency calculation in the AD5X presentation should match the vertical in today’s test very closely. AD5X calculates 78%. For every 100 watts delivered to the antenna 78 watts is radiated.
An idea for improving this blog post would be to test a 43 Footer over a better radial system for comparison.
40 Meters
|Z| = 131.9 ohms
SWR = 4.8
30 Meters
|Z| = 636 ohms
SWR = 12.77
20 Meters
|Z| = 227.7 ohms
SWR = 17.03
17 Meters
|Z| = 102.7 ohms
SWR = 2.93
Notice another dip. This one at 17180 is the third harmonic of the fundamental frequency of 5957 kHz.
15 Meters
|Z| = 385.3 ohms
SWR = 7.8
10 Meters
|Z| = 61.2 ohms
SWR = 1.23
Conclusion
Matching 30 meters should be the most difficult at 636 ohms but that’s well within the range of most automatic tuners. An additional challenge should be 160 and 80 meters with their infinite swr’s. One of many good tuners to use as an example is the MFJ 998RT. It is specified to handle impedances from 12 to 1600 ohms and swr’s up to 32:1. In practice with this model of tuner installed on this 43 foot vertical it matches beautifully on 80 thru 10 but not on 160, maybe because the R component is only 11.8 ohms on 160. Optional coil and relay kits are available to add 160 meters. No matching problems have been noticed on 30 or 80.
A note of caution. Just because an antenna matches does not guarantee it is getting out possibly due to objects nearby or due to radiation patterns on each band. It may match perfectly at 10 meters but all of the energy is straight up to the clouds, with only a little radiation at low angles.
On the other hand antennas with a poor match still can make contacts with even a small amount of power being radiated, although inefficiently.
Insolation is a big word meaning how much sunshine is there? That’s an interesting bit of information when one is trying to keep batteries charged with solar panels. It’s just a cross check to see if the charge amperage is consistent with the amount of sunshine each day.
The project consists of a photo cell and an Arduino-based device called a ESP32. The hardware looks like this. Very minimalist. The breadboard is just to hold the ESP32 in place. A USB cable brings in 5 volt power.
The ESP32 connects to the Internet over wifi and uploads data every 10 seconds using the protocol MQTT, “the standard for IoT messaging” . Data consist of the resistance of the photo cell. A server processes the data and provides a web page GUI. The server is called a broker and in this case the broker is provided free for personal use by Adafruit. The ESP32 is also a product of Adafruit. The ESP32 cost $20 at Microcenter.
Below is a screenshot of the GUI page, putting it all together.
Ideas for the next version: Mount the ESP32 inside a solar powered yard light and eliminate the USB cable. Disconnect the light and power the ESP32 instead.
This solar powered led yard light was chosen at random and it was chosen for it’s reasonable price. When it arrived it looked like this:
Opening it up revealed a pleasant surprise which had not been mentioned in the sales description. It has an actual 18650 lifepo4 battery. Perfect. This battery should power a ESP32 for many hours. The ESP32 draws 100ma at 5 volts which is one half watt. The 18650 is rated at 4.4 watt-hours (4.4 watts for an hour). That would be 4.4/.5 or 8.8 hours. In reality that time would be extended by the ESP32 going into sleep mode when it’s not sending data. It would never need to send data constantly for 8.8 hours.
Unfortunately the controller board that comes with the unit will have to be discarded because it doesn’t have the features needed for the ESP32.
Will the ESP32 fit inside the waterproof cabinet? Looks like it will.
In fact, a LORA board will fit very nicely, too, and that can come in useful for the next project, building a LORA network.
Reading up on how to power a ESP32 from a solar yard light has revealed some challenges but also solutions. First, the cell voltage is 3.7 as can be seen in one the pictures above. The ESP32 needs either 5 volts or 3.3 volts, neither of which is close to 3.7 volts. What is needed is either a boost converter to get up to 5 volts or a buck converter to get down to 3.3 volts. The battery voltage of 3.7 is nominal. The voltage can vary from 4.7 to 3.2. When it’s 3.7 or above the buck converter works fine but when the voltage drops below 3.7 the buck converter shuts down. That rules out the 3.3 volt option. Looking at the 5 volt option, there is a possible solution. Connect a standard charge controller between the solar panel and the battery such as the TP4056 Charging Module 5V Micro USB 1A 18650 Lithium Battery Charging Board with Protection (5 pieces for $5.95 on Amazon) which looks like this. It’s output will vary with the voltage of the battery.
Boost converters exist ($7.29 for 5 pieces on Amazon) that will provide a constant output of 5 volts with an input as low as 1 volt or as high as 5 volts and look like this.
The concept is the charging module will regulate the solar input to keep the battery properly charged. As the battery charges and discharges the output voltage will vary. The boost converter will take that varying voltage as input and it will output a constant 5 volts.
Moving on to the next step, those parts will be ordered today. Total additional cost $2.86 per unit.
