Backdoor Remote Access

It has always been a goal to have remote access for troubleshooting. There are times when the primary connection is down and remote access is not possible. It is those times when backdoor remote access saves the day. It could prevent a site visit, a trip to the site. This year a previous IoT (Internet of Things) sunshine monitor project is being expanded to add a battery voltage monitor, keeping track of the voltage of each battery pack. Switches and relays can also be turned on and off enabling reboots remotely. This IoT uses a wifi connection to the Internet to post data on a dashboard web site. No pc with reverse tunneling is needed because the IoT device does all that work. For backdoor remote access an IoT device is a viable solution. Here are the plans

Introducing the Arduino Nano 33 IoT microcontroller( $20 at Microcenter). Many others would work, too. The Nano wifi connects to the AT&T Mobile Hotspot already installed. Battery voltage will be monitored through a potentiometer (voltage divider) to the Nano’s A/D analog pins. A powerful new Arduino IoT Cloud web app will provide the software interface for dashboard web access. The code will be provided below. To be independent of the station’s infrastructure power will be supplied by a separate solar panel tied to a cell phone external battery, then through a USB cable to the Nano.

Technically it’s only a remote battery monitor but that information is so vital to the system’s performance it doubles as backdoor access. While not as powerful as a true backdoor with a pc the IoT provides most of the necessary functions. One can check battery voltages and reboot hardware devices with the IoT. If a pc becomes necessary one could be switched on and used over a reverse tunnel just like the old days, or with Chrome remote desktop. Happy troubleshooting.

Programming steps

Define a pin

Define a variable and a cloud-variable

Read a pin and assign the value to the cloud-variable

Convert the binary reading to volts

Build a Dashboard with a guage

Link the guage to the cloud-variable

The Sketch:

/*
Sketch generated by the Arduino IoT Cloud Thing “W0QL Thing”
https://create.arduino.cc/cloud/things/e702de16-6601-4492-8a11-1bcf55411168

Arduino IoT Cloud Variables description

The following variables are automatically generated and updated when changes are made to the Thing

float batt1val;
float batt2val;
float batt3val;
float batt4val;

Variables which are marked as READ/WRITE in the Cloud Thing will also have functions
which are called when their values are changed from the Dashboard.
These functions are generated with the Thing and added at the end of this sketch.
*/

include “thingProperties.h”

int pinbatt1 = 0;
int pinbatt2 = 1;
int pinbatt3 = 2;
int pinbatt4 = 3;

float batt1volt;
float batt2volt;
float batt3volt;
float batt4volt;

void setup() {
// Initialize serial and wait for port to open:
Serial.begin(9600);
// This delay gives the chance to wait for a Serial Monitor without blocking if none is found
delay(1500);

// Defined in thingProperties.h
initProperties();

// Connect to Arduino IoT Cloud
ArduinoCloud.begin(ArduinoIoTPreferredConnection);

/*
The following function allows you to obtain more information
related to the state of network and IoT Cloud connection and errors
the higher number the more granular information you’ll get.
The default is 0 (only errors).
Maximum is 4
*/
setDebugMessageLevel(2);
ArduinoCloud.printDebugInfo();
}

void loop() {
ArduinoCloud.update();
// Your code here
batt1val = analogRead(pinbatt1);
Serial.println(batt1val);
batt1volt = (batt1val / 40.9);
batt1val = batt1volt;
Serial.println(batt1val);

batt2val = analogRead(pinbatt2);
Serial.println(batt2val);
batt2volt = (batt2val / 40.9);
batt2val = batt2volt;
Serial.println(batt2val);

batt3val = analogRead(pinbatt3);
Serial.println(batt3val);
batt3volt = (batt3val / 40.9);
batt3val = batt3volt;
Serial.println(batt1val);

batt4val = analogRead(pinbatt4);
Serial.println(batt4val);
batt4volt = (batt4val / 40.9);
batt4val = batt4volt;
Serial.println(batt4val);
delay(2000);

}

Here is what the Dashboard looks like on a pc display with a 13.8 volt battery connected to port 3:

Here is what the hardware looks like:

The potentiometers above have been adjusted so 25 volts input will present 3.3 volts to the Nano pins. Midscale on the Dashboard will be 12.5 volts.

Vertical Yagi For 40 Meters

An update from a post of March, 2018

Forty meters:  Following a QST article from July, 1972, The W2FMI 20-Meter Vertical Beam, we scaled to 40 meters.  This is a three element yagi made of three quarter-wave verticals.  Gain is less than a dipole but better than a single vertical.  It will be aimed toward Europe. 

The pattern was very narrow right through central Europe, like a knife edge.

Three days after completion a wind storm blew down both the director and the reflector.  The driven element survived and was used for a time as a quarter wave vertical. Life happens. Inspired by the performance of this antenna, a 160 meter version was completed in 2021. A possibility also exists of resurrecting the 40 meter yagi. A 30 foot tower with a tri-band beam now resides on the site. Perfect for an omega match tuned to 40 meters. The old director and reflector are still around and could be re-installed. Radials were relocated so they would have to be re-installed. Capacitors for the omega match are in the junk box. If the weather stays nice this fall, this might be a good late fall project. DXCC is already accomplished on 40 but the DXCC Challenge always needs new QSO’s.

Vertical Yagi For 160 Meters

Were you imagining a horizontal yagi at 270 feet in the air? No way. It is actually a vertical yagi, meaning three 160m vertical antennas are in a line and spaced a typical distance apart for a yagi. Only the center vertical is driven and the other two verticals are a director and a reflector. The concept for this antenna came from an article in QST, W2FMI 20-Meter Vertical Beam, June, 1972, p 14, by Dr. Jerry Sevick. This is an autumn 2021 project with a goal of working the final 34 countries needed for 160 meter DXCC. Orientation is toward Europe.

The only vertical that didn’t already exist is the new reflector shown in the foreground. It is 50 feet tall. The tower with the beam on top is doing double duty. The beam is being used as a top hat for 160m. The tower becomes the 160m driven element thanks to Omega matching. Faintly visible in front of the tower is the director, which is a 43 ft. vertical with a top hat, resonated to 160m.

What distinguishes the yagi from a phased array is how it is driven. In a phased array all three verticals would be driven at certain phase angles and magnitudes with phasing cables and a phasing network. A phased array has more gain but is very complicated to implement. This yagi has only one driven element, no phasing cables, and is quite forgiving as to spacing. Yagi elements can be spaced for maximum gain or can be spaced for best front-to-back ratio. These yagi elements are spaced for gain using .2 wavelength. The reflector is resonated 5% lower in frequency than the driven element and the director is 5% higher. Center frequency is 1.840 MHz with a 2:1 bandwidth from 1.8 MHz to 1.885. The yagi will be ready for the winter 160m DX season.

A loading coil is housed in this enclosure at the base of the reflector. The coil is a roller inductor adjusted to resonate at 1744KHz, which is 5% lower than the driven element resonance of 1840 KHz.

At the base of the director (the other element) is an identical loading coil, resonated to a frequency 5% higher, or shorter, than the driven element. The director resonates at 1930KHz, shown below. SWR is irrelevant because it is not being connected to a feedline. It is connected directly to the radial ground screen.

Performance

In the pskreporter screen-shot below notice that the strongest reports (look at the “dB” numbers) are in a line to the northeast of the Colorado QTH which is very good news running barefoot at 100 watts.

How To Measure A Trap

Using a NanoVNA to measure the resonant frequency of a trap from a hf antenna is easy.

Six Meter Yagi

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!

Noise Chase

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 each of 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.

Lithium Batteries In a Non-Heated Environment.

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. Why not use that solar power to run the heaters? Duh. 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 from the panels is typically 20 volts and that might 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.

W1711 thermostats round out the installation. These little guys are 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.

-0-

How To Get Through A Firewall From The Outside World

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”).

> ssh -R 8888:localhost:3389 hamstation@outlook.com@174.51.135.253

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.

Fall 2021 update: This solution still works and could be used if needed. When COVID hit, the Internet service apparently got upgraded because it has been working much better. Currently there is no need for the reverse tunnel option and the straight main Internet connection is all that is be used.

Impedances and SWR’s of Typical 43 Foot Vertical Antenna

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.

For an interesting read on radials for vertical antennas see an extensive article by Al Christman, K3LC. http://ncjweb.com/bonus-content/k3lcmaxgainradials.pdf

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.

Click to access Vertical43RevA.pdf

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 Monitor Project

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.

For a closer look the link is here:

https://www.amazon.com/gp/product/B07ZSC6TNB/ref=ppx_yo_dt_b_asin_title_o08_s00?ie=UTF8&psc=1

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.