Welcome to the W0QL remote station journal. The station is located on the Colorado plains about 35 miles east of Denver, controlled over the Internet, and powered exclusively by solar panels. Begun in 2016, 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. To the right is the vertical which is the director for the 160 meter yagi. Then comes a DX Engineering 43 foot vertical which has a MFJ 998RT tuner at it’s base. In the foreground 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, the heart of the whole station. On the right hand side are all the solar controllers and Internet equipment. The LifePO4 batteries are on the floor.
Now let’s get going, with the most recent post beginning below.
As more clubs get remote bases a new demand has surfaced and that is tracking users’ activity. Luckily, tracking is a well matched skill of a recent programming language called Node Red. Node Red needs little actual coding skills, developed by IBM, targeting home automation and Internet of Things devices. Recently hams have adapted Node Red to automate ham radio equipment, especially Flexradio 6XXX series. In the last three years many dashboards have been written to automate radio control for contesters and remote bases, thank to Node Red. An excellent example comes from WO2X.
A local club has offered to it’s members the use of a Flexradio remotely since July, 2022 and and now wants to track it’s activity. Searching the Web for a tracking application has proved fruitless, as has networking with other clubs. The response has always been, “We’re looking for the same thing. If you find one, let us know.” Or, “Why don’t you develop one and give us a copy”.
So, we did. This project was developed with a lot of help from YouTubers like Steven Houser, Kyle Klein, Michael Walker, Dave de Coons, and many others, and the Web in general. Currently the project is deployed at a local club station and is being field tested for improvements or for bugs. Features include the following.
Free open source software that resides on a Raspberry Pi.
Dashboard that is accessible from the Internet to show if someone is connected to a radio in real time, with details.
A log file showing who the users have been, including user details, what time the connections were made and what time they were disconnected.
The log file uses the Comma Separated Values (CSV) format so it can be uploaded to an Excel spreadsheet for detailed analysis.
All features are accessible from the Internet by anyone with the correct privileges.
Simple to use.
Steps to recreate this project for your own club’s use are below:
Install an image of “Raspberry Pi OS (32-bit)” on a Raspberry Pi, Model 4 if available. Use Raspberry Pi Imager. Go through the steps of setting location, time zone, keyboard layout, and do the updates.
Connect the Raspberry Pi to the same router the Flexradio is connected to. Configure port forwarding on the router to direct the following ports to the Pi’s I.P. address: 22, to allow online access to the log file; 1880, which is the Node Red application; and 5700, which is the VNC port.
A screenshot of the Flow and comments is to be inserted here.
Here is a copy of the Flow used in this project. Import it to your Node Red. Open an import window and copy and paste everything below. Node Red Version 2.2.2 was used as the development platform. Feel free to modify the flow, of course.
For the 2021 160 meter season the DXCC country count only went up a few countries and stands now at 66. Slightly disappointing, plus something is arcing at 750 watts. It’s ok below 750 watts. Capacitors with larger spacing were purchased and installed.
This picture shows both capacitors connected in an omega match configuration. The antenna would not tune correctly at 1840 kHz but it does tune at 1500 kHz. Over the summer one more change had been made. The capacitors may be wired wrong. These are both butterfly caps but they got wired in parallel as if they are two independent caps. That will be corrected on the next trip. Meanwhile, Bill, N0CU, made an on site visit and provided great consultation. He also provided a link to a great video that added insight.
The video sent us back to the books. Reviewing Section 6.9, Using the Beam/Tower as a Low-Band Vertical, in ON4UN’s Low -Band DXing, Fifth Edition the author offers that the omega match might not be necessary in some cases. He suggested trying the gamma match, too. That is easy to try by just disconnecting the capacitor that goes to ground, on the left. Doing so produced a dip of 1.45 SWR at 1840 kHz, just what the goal is. Next, it’s time to test it out.
Early results: Using 80 watts on FT8, 8pm local time October 3, Pskreporter shows a spot as far away as Israel with a nice report of -18dB. Unfortunately the station was not on the air, only monitoring, and so no contact could be attempted.
The following morning at dawn luck was better. Australia showed up on FT8 and was worked with only a few repeat transmissions, still using 80 watts. This is a new country on 160 meter. Very promising.
The new system has not been tested yet at high power. That is next. After re-wiring the caps, that is.
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. Which one you use is up to you. Either one works equally well. The first workaround 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 in the pc to do network shell routines. This routine can change the MTU on the PC. Open cmd with administrator permissions (run as administrator) 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”. If you’re using wifi, it might say “Wi-Fi”. Observe the value in the MTU column. Is it 1500?
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.
Fall 2022 update: Directivity is not being seen like it was on the 40 meter vertical yagis. After doing more reading, the lack of directivity may be caused by using short verticals. The 40 meter yagi was using full size quarter wave verticals. On 160, that is impossible with the given resources. The idea of a yagi on 160 meters may get put on the shelf in favor of using the tower as a single radiator.
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 .
W0QL - My Remote Base Journal 