What is needed is an automatic system that grounds the antenna when not in use.
Given: When there are no users on, the antenna needs to be grounded. A remote coax switch normally grounds antennas when not in use but this installation only has one antenna and no remote coax switch. This project will perform that function.
Certain parts are already in place. A Polyphaser lightning arrestor offers protection but when a lightning event occurs a Polyphaser will let through 1000 volts and destroy equipment. A relay that grounds the antenna when the power is off is already installed but now it must be activated manually over the Web. Here is a white-board sketch proposing an automatic solution. It uses Node Red software.
The Weeds
Node Red
Node Red will listen over the LAN for a user to be logged in and then activate the grounding relay. It sounds complicated but the flow below shows how simple it really is. A Raspberry Pi running Node Red is already on site being employed to log the usage. For this new project all that needs to be done is to add a new flow.
Explanation: On the left is a node that queries the Flexradio for information including any clients who might be logged in. In the center is a “function” node that looks only at the data field for the client’s identification. If the field is empty, null, the function outputs a boolean “false”. If there is a client logged in, the function outputs a boolean “true”. On the right is a node labeled “PIN: 16”. PIN 16 is a digital output pin on the Raspberry Pi where a relay module will be connected. The contacts on the relay control the existing antenna grounding relay. The debug nodes above are used only for testing.
Here is a look at each of the configurations of the nodes mentioned above. First, the “flexradio-discovery” node. There is very little here except the port number for the radio. Written by Steven Houser, the Flexradio nodes are quite easy to use, with default settings of “automatic”. The node will find the radio on the LAN and use port 4992 to poll the data.
Below is the function node. The function node contains a Javascript Function. In the first line the command examines the data “client_stations”. If the data is not empty, that is, does not equal a null, it returns a payload of true. Else it returns a payload of false.
Note: How was this function code written? With the help of the new tool, chatGPT, of course. (Yes, chatGPT does more than write essays) Here’s how:
Finally, the output node “PIN 16” tells the Raspberry Pi to make pin 16 (GPIO 23) high or low. The Raspberry Pi nodes are easy, like the Flexradio nodes. Just click the radio button for the pin to use. It even has a sketch of the pin layout that matches the layout of the Pi itself.
Hardware
This is a Raspberry Pi with the relay module attached, ready to be moved to the remote site.
Status: Currently the Node Red flow has been tested in the lab and seems to work without a hitch. The flow has been deployed into the existing Raspberry Pi at the remote location. Next, a site visit to install the 3.3 volt relay between the Pi and the antenna grounding relay, is scheduled for Monday, May 8, 2023. Update: …….Installed at the remote site, complete with heat shrink to protect the relay module.
The existing grounding relay, now activated automatically, is mounted on the single-point-ground-panel where the cables enter the building:
A week with several thunderstorms in May and no lightning damage. Of course, the big improvement is, no one had to worry about manually activating the grounding relay.
Concerns
Node Red might suffer a crash which would prevent users from having the use of an antenna. The current Raspberry Pi has been running 4 months without failure, logging away with Node Red. And there is a backup copy of the Node Red flow that could be used to restore this Pi or a replacement Pi if needed. Hopefully the odds are in our favor on this one, too.
This dashboard project is for the following purposes:
1. Improving performance of the heaters on the batteries.
2. Reducing RFI from the solar panels.
3. Displaying status such as the Flexradio final transistors temperature.
Hardware is a Raspberry Pi 4 located at the remote site, connected over the LAN to Web relays.
Modbus
The flow first polls Modbus data from the solar controllers and in turn performs actions like closing relays. A Node Red flow polls the modbus, then converts the modbus floating point data to readable decimal, and finally, turns relays on and off. One feature improves the battery heater operation by bypassing the thermostats as needed. Another feature reduces RFI by disconnecting the solar panels from the solar controllers when batteries are fully charged. The most difficult task so far has been converting the floating point data to decimal. That flow is what is discussed first.
Data from the modbus is in the format of IEEE 754 half precision 16 bit floating point Little Endian which is unreadable by humans. Many JavaScript functions are available to perform a conversion operation but they have all proved impossible to implement during this project. Thanks to chatGPT a solution was finally implemented that works. It took 7 iterations of chatGPT to develop a Node Red function node which produced the correct output and no errors. The successful node is shown below to get it down on paper for preservation.
It was a huge milestone to get the floating point conversion node working. Below is what the output of the big achievement looks like. The number is the actual voltage of the 24 volt battery as measured by the solar controller and processed by the Node Red flow.
It’s easy to confuse the use of the word “function”. To offer some clarity, the node above is a Node Red “function” node. Inside this function node is a JavaScript “function”. The JavaScript function is the first thing in the node. The JavaScript function is declared and defined, making it ready to be used. Next element is at the bottom and that is where the JavaScript function is called, data is passed to it, and the output is moved into the msg.payload object.
The Flow
The object is passed to the next Node Red node which is a debug node (debug 22).
On the left above is the Modbus Read node, named Stras 88. It’s settings are shown below.
In the Server field above, the name is Stras 88 which indicates the location of the solar controller and the port number. It’s I.P. address is entered by clicking on the pencil icon on the right. The Address in the Address field is obtained from the Morningstar documentation. The FC field is always FC 3 when reading a holding register per the Modbus specifications.
A big project has begun. Onward to the next part, the outputs.
These relays are currently wired up to remotely turn on and off the solar panels from the solar controllers manually. Despite mechanically working perfectly, turning on and off the relays manually did not happen. Too much work? Along came Node Red and this function can now be down automatically. First, the command set for the 1216H is available on the Webswitch website and also posted elsewhere in this journal: https://w0qlremotebase.wordpress.com/2023/02/12/microbit-remoterig-1216h-webswitch-command-set/
TESTING
In Node Red a node called EXEC can be used to execute a command. The command can use curl to send a web request over the internet to the 1216H, and the response will be the status of that request. In the flow below, an http request is encapsulated in a curl command in an exec node:
The configuration in the exec node is shown below, with a fake I.P. address. Enter your own here.
In the next chapter some nodes will be wired together in such a way as to turn off the solar panels when the battery is fully charged and RFI is occurring.
Step 1 is to do a modbus read of a solar controller looking for the High Voltage Disconnect (HVD) bit. Morningstar controllers have this feature when using Lithium batteries. When the HVD bit is positive, tell the 1216H to close a relay corresponding to that controller. The closure in turn opens a higher current relay and disconnects the panels. Boom. RFI stops.
(Preliminary – needs more testing ) Observations after 3 months in operation: Log file has grown too big to print out. The Pi bogs down. New idea is to process the client logon and logoff before making a log entry. One entry per visit. Shorter log.
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.
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.
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 by right-clicking on cmd and clicking on “run as administrator”).
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
Project 7 of 7 for October, 2020 – projects to keep sane during Covid-19 Lockdown
Status: All work is completed.
A new Yaesu G-450ADC rotator was ordered from GigaParts. Still needed are the rotor plate, the cable, and the interface to make it remote controlled. Cable and interface are on order from DXEngineering and HRO. This project has hit a snag. Rotor plate is special order and has a November ship date. It has not even been ordered and by the time it gets here the weather could be too wintry to install it.
Universal Towers saved the day. An order was placed directly with them today and they promised a much earlier delivery date.
“The rest of the story” is this tower is decrepit. It was used 10 years to hold up wireless Internet antennas on a windy hill. It has two blow outs from being overloaded. Even though the blowouts have been repaired the concern now is it might not be able to keep the A3S in the air. Torque is the tower killer when wind makes a beam twist. An overloaded tower can fail from that twisting motion. When this tower is down for the rotor installation a torque arm will be attached in an attempt to reduce the twisting motion.
Remote Controlling The Rotator
All parts have arrived. The Yeasu G-450 rotator is the new DC version which makes absolutely no detectable difference in the operation but it makes lightning protection easier. Relays had to be used on the AC rotator because the AC voltage was too high for the 26vac/31vdc MOV’s on hand. Perfect for the 20 volts DC the new version uses. Modifying the controller for access over the Internet looks like this:
Actually the controller is not modified. A few wires are tacked onto existing terminals inside. Wires are brought out through an existing hole. The controller could be easily restored to original. In the picture above, the green thing at the bottom is the remote interface from RemoteRig.com model RCU-1216:
The interface talks to the RemoteRig 1216H Webswitch and will get mounted inside the controller. A Webswitch already exists at the remote site to provide remote access of the first rotator on the taller tower. That missed getting written up. That’s why this is being written up now. The unit has the capability of two rotators so all that was needed was this interface to the Webswitch. The installation just needs some hookup wire and a solder iron.
There is no brake release button on Yaesu control boxes so a brake release connection is not needed. Only the Pot potentiometer connection and the two motor activation buttons are needed. A data pair and a power pair connect back to the Webswitch.
For this rotator the two jumpers, P5 and P6, are opened up to accomodate the voltage on the Yaesu rotator for direction indication potentiometer. Voltage maxes at 1.3 volts on the pot. Next attach a little Blue Tack or 3M gray stickem to hold the interface in place.
Stick it to the inside of the cabinet and you’re done. It should look something like this:
Coming out of an existing hole in the back are two pairs of wires. One is for 12 volts DC. The other is the 1-wire data pair (1-wire really means 1-wire and ground). Next step is to install and test at the site.
Today the rotor plate was mounted and the rotator is mounted to the plate. A short piece of aluminum tubing was cut to go from the rotator to the mast. A hole was drilled for a bolt to keep the mast from twisting and slipping.
The tower was raised a few feet to see if it is too heavy with the rotator. It is noticeably heavier and harder to lift but not impossible. None of the gin components complained. The rotator only weighs 7 pounds and the wire is probably 2 more pounds. Another 9 pounds is apparently not overdoing it. Next the cables will be extended where needed for slack and they will be dressed. The bolt will be installed. The rotator connector will have a waterproof boot installed. The balun will be reworked to provide enough slack for turning the antenna (the balun is near the center of the picture with cable ties holding it to the tower leg). The rotator cable will be run through the cable entrance at the shed and MOV lightning protection will be provided. Inside the shed the controller will be connected to the RemoteRig Webswitch and all will be tested. It will be really nice to be able to turn this beam in the direction of the signals as they change.
Today, the balun was rebuilt by replacing the RG-58 windings with LMR-400. It is still 5 turns through a stack of 4 Mix 52 ferrite toroid cores. It looks like it can handle a lot more power now. Only the common mode current is flowing through the toroid.
Proving the balun is working is a matter of observing the signal pattern on pskreporter. In this case it is a nice flashlight beam shape in Europe indicating the balun is doing it’s job. It’s job is to keep common mode currents from generating stray radiation which distorts the pattern. No pattern distortion, the balun is working.
The rotator mounting is completed and the cables are dressed. Ready to raise the tower.
Back up in the air the rotator turns the beam perfectly with no issues. As for remote control, a relay is being used to switch between the two rotators. The other rotor turns the 203BA 20 meter beam on the big tower. One rotor at a time is accessible over the Internet.
Changed out the old Linksys E2500 router today for an upgraded Linksys EA6350. Two problems are addressed. First the E2500 has the lowest lan-to-wan throughput of any Linksys router, per tomshardware.com. The EA6350 is much better. Second, out of all the Linksys routers the E2500 is one of only a few that are susceptible to the new vpnfilter malware, per https://www.symantec.com/blogs/threat-intelligence/vpnfilter-iot-malware. The E2500 has blocked some web sites even when using the I.P. address which is a good hint that it has the malware.
Temperatures of 104 degrees Fahrenheit were common inside the shed when outside temps were still only 85. This had to be improved. Step one was to cut two 6″ circular vents into one gable and add a solar powered fan. No noticeable improvement. Step two was to cut in a second vent in the opposite gable. Same result. Third step was to cut in a 8″ X 16″ vent midway up the north wall. Same result. Fourth step was to paint the shed white. This helped. Inside and outside temps since have been nearly the same. The cute barn red shed is now almost ugly white. But it’s cool inside.
Why the concern? We were worried more about the batteries than the equipment. The electronic equipment was still within specified operating range at 104. Sources say batteries, on the other hand, can exhibit thermal runaway (catch fire) at 122 degrees. Summer’s highest temperatures hadn’t even arrived yet.
W0QL - My Remote Base Journal 