The remote station is located on the Colorado plains about 35 miles east of Denver. It is controlled over the Internet and is exclusively solar powered. Begun in 2016, it now has a variety of antennas and equipment. In this picture, from the left, is a 60 foot tower with a Hygain 203BA 20 meter yagi. The tower is also used as the driven element for a 160 meter vertical yagi. Next is the equipment shed which has the Internet dish on the roof and a dipole for 12 meters on the right end. Next is the vertical which is the director for the 160 meter yagi. To the right of it is a DX Engineering 43 foot vertical which has a MFJ 998RT tuner at it’s base. Next is a 30 foot tower with a Cushcraft A3S triband beam for 17, 15, and 10 meters. The yagi on top is a Cushcraft 505S 5-element 6 meter beam. Both towers tilt over for maintenance and additions. The dark-red posts are gyn poles to help lower the towers.
Inside, above my head is a Victron 3000 watt 24 volt to 230 volt inverter for the linear amplifier. Two Yeasu rotor controllers make the yagi’s turn. On the counter are the linear amplifier and a Flexradio transceiver. On the right hand side are all the solar controllers and Internet equipment. The LifePO4 batteries are on the floor.
The maximum transmission unit (MTU) is the largest size frame or packet — in bytes or octets (eight-bit bytes) — that can be transmitted across a data link. It is most used in reference to packet size on an Ethernet network using the Internet Protocol (IP). A deprecated term is “window size”. Default is 1500 which is too big for the remote station network. Symptoms are, the radio shows up in the Smartlink window but a connection attempt times out.
At least two workarounds are possible which will have no effect on any other applications or users on the router. The first one is to change the settings in the main router for the home. Find the settings for MTU in the network configuration and change the MTU to 1438.
The second workaround uses the command line to do network shell routines. This routine can change the MTU on the PC. Open cmd with administrator permissions and enter these commands.
>netsh
>interface
>ipv4
>show int Look for the line that shows the connection to the Internet and write down it’s name. An example is “Ethernet”. Observe the value in the MTU column. Is it 1500?
Enter the following command.
>set subinterface “Ethernet” mtu=1438 store=persistent where “Ethernet” is the name obtained in the previous name.
An “ok” will be returned if these steps worked. To test, enter the following command:
>netsh int ip show int
The results returned will show the current MTU.
Note that the magic number may be lower or higher. Experiment, if the one above doesn’t work.
Meshtastic is described as an off-grid text message project. The text messages travel entirely over a network consisting of LoRa devices connected in a mesh. What does “off-grid” mean in this context? It means the text messages use a network that has nothing to do with wifi or the Internet or cell phone service. Instead the messages are transported over a mesh network made up of multiple LoRa devices. The device that sends and displays the texts is a smartphone, connected by bluetooth to a LoRa device. The LoRa device is in turn part of a mesh network with other LoRa devices. Again, wifi, the Internet, or the cellular network are not involved. Bluetooth is used only to connect between the smartphone and the LoRa device. Thus the entire end-to-end text message is completed off the grid. Meshtastic is a firmware version that is installed on a LoRa device. One example of a LoRa device is a TTGO T-Beam, shown below. Meshtastic firmware has been installed.
What does LoRa and Meshtastic have to do with a remote station?
The answer to that question is, it can be used for station telemetry. That means temperature, voltage, and current can be texted back to the client automatically. The text messages can be generated by an Arduino microcontroller or a Raspberry Pi Pico microcomputer and fed into the Lora device. On the other hand the client can send texts that turn on relays or turn off relays. Equipment can be rebooted. Equipment can be turned on and off.
It is a plan to implement a Meshtastic system at the W0QL remote station once a Lora signal path is reliable.
Upon further study, it appears that the above scenario would work fine if the two endpoints were less than 2 miles a part. With distances of 35 miles it is not a solution. Meshtastic requires the mesh nodes, that is, the relays in the middle, to be under the control of the same operator as the end points. Given the t-beam units have a range of 2 miles, several nodes will be necessary as relays. The purchase cost, maintenance, and installation of multiple nodes may be a limiting factor to using Meshtastic. Moving on to similar technologies, would LoraWAN work?
Research on LoraWAN shows it needs a gateway to the Internet. Any gateway at the remote station site would be down if the Internet is down and therefore not usable at the very time it is needed most. Finding another gateway that is reachable out in the country is a challenge. Gateways require authorization and that’s where this technology is limited. So as of now there doesn’t seem to be a solution for telemetry monitoring over a 35-mile link that is within reason. Project is on hold.
Mike Walker at Flexradio introduced us to KMTronic. He uses this device in his remote station to simplify turning equipment on and off remotely over the web. The KMTronic has a built in web page providing a simple user interface. All that is needed is a web browser and the KMTronic’s i.p. address. Priced at less than $100, it is a great solution for remote station users.
At the W0QL remote station a KMTronic has been installed to provide two backdoor access functions. One is LAN isolation between the AT&T Mobile Hotspot and the main LAN. Four relay contacts are used to electrically bridge the two LAN’s, or to isolate them. The other four contacts are used to reset the BMS’s on the four battery banks. If a BMS has tripped, the KMTronic can be accessed over the Internet and the corresponding relay can be activated that will reset the BMS remotely. This saves a site visit.
How To Use
Internally the i.p. address of the KMTronic is 192.168.1.204. It can be reached remotely by any device on ZeroTier with a network id ending in ee4.
Abstract: It has always been a goal to have “backdoor” remote access for troubleshooting. There are times when the primary Internet connection is down and normal 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.These are the specific essential building blocks:
AT&T Mobile Hotspot
Raspberry Pi running ZeroTier, ipforward and iptables
Same subnet but separate ranges of i.p. addresses
Let’s get started: First, an explanatory overview. The hotspot provides Internet access over a different path by using the cellular data network. This specific hotspot costs $35 a month for unlimited data. T-Mobile’s $50 service would probably also work. Up and down bandwidth is 30 Mbps, even in the rural location. Luckily there is an AT&T cell tower not too far from the remote site. Not so lucky is the fact that the hotspot provides only a private i.p. address and not a public address so it cannot be reached from the outside world. Called “carrier grade NAT” or CGNAT, it is a heavy duty impenetrable firewall. Not to fear, however.
A great solution to the CGNAT problem is a product call ZeroTier which becomes the second detail of this project. ZeroTier is an application that runs on a computer behind a firewall and reaches out over the Internet to a software defined LAN. A software defined LAN is similar to the user side of a home router. Instead of the hardware connections like a home router uses, a software defined LAN does it all with algorithms and the Internet. Other computers running the same application and same credentials can reach the same software defined LAN and communicate as if they were all in the same office. For backdoor access one instance of the application is running on a computer at the remote site (a Raspberry Pi) and another instance is running on a computer (Windows 11 pc ) at the home location. Competing products exist and might also work, like Tailsscale, reverse TCP tunnelling, SoftEther, WireGuard and possibly others that do NAT traversal. ZeroTier has been the most comfortable and successful of the ones tried at this remote station.
How To Use
Any device anywhere worldwide on the same ZeroTier network can reach the LAN at the remote site. As this is written the network id ends in ee4. To reach the i3 NUC: Power is on the ‘Station’ circuit on the 4005i using port 82. The NUC i.p. on the LAN is 192.168.1.100. It can be reached using Remote Desktop Protocol. The Pi is at 192.168.1.204 and it can be reached with Putty. The KMTronic is at 192.168.1.204 and it can be reached with a browser. If the main LAN is down the only device that can be reached is the Pi. Other well known ports:
Follow the instructions on the ZeroTier web page to make an account and to create a network. Their free plan has all the features needed.
This brings us to the third detail, the Raspberry Pi computer.
A Raspberry Pi is fully capable of running the ZeroTier application and then some.
Shown above is a Raspberry Pi model 3 which is the model being used in this project. Follow the instructions on the ZeroTier web page to join the network created above. With a hotspot and a Pi running ZeroTier the hardware and some of the software to get into the site is complete but no connection has been made to the main LAN yet.
Each detail has involved challenges but probably the biggest challenge of all has been how to connect to and how to communicate with the existing LAN at the remote site. At this point there are two LAN’s, one providing a data link between the hotspot and the Pi and the other LAN providing communication for all the existing equipment. Connecting any two LAN’s requires a router, but not just any router. An ordinary home router will not do. Turns out the solution is simple and elegant thanks to the Linux operating system running on the Raspberry Pi. It can run a few built-in processes and perform the necessary router functions. A nice writeup of how to configure this routing function is published by the ZeroTier developers: “Route between ZeroTier and Physical Networks“
sudo iptables -t nat -A POSTROUTING -o $PHY_IFACE -j MASQUERADE sudo iptables -A FORWARD -i $PHY_IFACE -o $ZT_IFACE -m state –state RELATED,ESTABLISHED -j ACCEPT sudo iptables -A FORWARD -i $ZT_IFACE -o $PHY_IFACE -j ACCEPT
Another essential process is ipforwarding:
sudo sysctl -w net.ipv4.ip_forward=1
Edit /etc/sysctl.conf to uncomment net.ipv4.ip_forward. This enables forwarding at boot.
Next, take steps to avoid two devices having the same addresses on the combined LAN: On the hotspot, set the dhcp i.p. address range to the highest 50 addresses in the subnet, and make the subnet identical to the main LAN subnet. Turnoff DHCP on the hotspot. On the main LAN, set the router dhcp range to exclude the top 50 addresses and leave DHCP on.
A few items remain to polish the backdoor project. The whole idea is to be able to access the remote network at all times. There is no way to know what the source of the failure might be. It could be power down inside the remote station. In that case the backdoor needs to have it’s own power. For that reason, the hotspot and Pi have their own battery and solar panel separate from the rest. Considering the main LAN goes through a big ethernet switch and that switch could be down, the hotspot and Pi have their own switch. That small switch is also powered by the separate battery. Rebooting devices remotely is invaluable. Some devices, like computers, can be rebooted with software commands or they might need a hardware reset. Other devices, like BMS’s and EMC’s require a hardware reset. Relays wired to provide the hardware reset, controlled over the Internet through the backdoor can save a trip to the site. At this site relays are wired to short out the BMS’s (which is how they are reset if they have tripped). Another bank of relays is installed to reset the EMC’s if they lock up ( like they have been prone to do ). Almost all equipment has a method of being rebooted or reset remotely.
A successful backdoor access project provides a lot of comfort knowing the every day remote operation has tools for a better chance of recovery when something goes wrong.
Thoughts for future improvements – One improvement could be to move all the non-radio equipment to the secondary Internet connection, leaving the entire bandwidth of the main connection to the radio. That would be easy because the hardware connections are already in place. It would just be a matter of changing the i.p. settings on each piece of equipment to static with the gateway address of the secondary connection. A second idea is to combine the two Internet connections into what is called “dual-WAN” service. A product exists to do this easily (according to the sales literature). It is called Speedify and is worth checking out someday.
One additional thought. Use bridging instead of routing to see if bridging would pass the broadcast packets. What this means is the packets that advertise a service are being blocked (by the hotspot??) when using routing. It is possible bridging would fix this. The hotspot would not see the packet headers and thus not know any particular packet was a broadcast packet.
One more additional thought. Use iptables “mangle” to create a mangle table which will be a MSS filter. Set the filter size to, in turn, create an MTU size that will pass through the PPPoE Internet connection at the radio end.
Here is an example of a line of code to create the mangle table:
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1452
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.
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.
Note this caution from page 45: “You must adjust each trap with the antenna completely assembled – traps cannot be adjusted before assembly.” Therefore the readings taken in the top picture are useless. The picture should be titled, “How NOT to measure a trap”.
The unmounted components from the top picture have been mounted in a small enclosure:
The resistors are all 120 ohm, 1/4 watt or smaller wired as shown here. A goal of this arrangement is to present 50 ohms to the NanoVNA but at the same time the trap is loaded as little as possible.
In practice this method is good for determining if a trap is defective — are turns shorted, for example. For tuning a trap vertical, adjusting the trap by sliding the sleeve up or down and measuring the SWR of the antenna in place is much more effective .
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 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.
W0QL - My Remote Base Journal 