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 turning on that feature enabled the solar diverter to easily be on a noon-to-8pm schedule. No spikes have been noticed.
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.
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. Below is a picture of a water fall on 17 meters on a sunny day when the solar system is generating full capacity.
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 two bands on the right 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.
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 “firstname.lastname@example.org”.
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.
email@example.com is the username on the local computer. Replace it with your own username on the local computer.
@220.127.116.11 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:
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.
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.