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.
In Part 1, Modbus data was figured out and it’s floating point output was converted to decimal. Additionally, knowledge of how to activate relays using Node Red was achieved.
In Part 2, the first sub flow will listen for a High Voltage Disconnect (HVD) and activate a relay accordingly. The sub flow will do a modbus read of a solar controller, and listen for the HVD bit. Morningstar solar controllers activate HVD when a Lithium battery is fully charged, to prevent overcharging . When the HVD bit is positive, Node Red will tell the 1216H to close a relay corresponding to that controller. The closure in turn opens a higher current relay and disconnects the panels and RFI stops. RFI is generated when a controller is allowing the solar panel to run with no load. Let’s begin.
Refer to the figure above as the remaining nodes are explained.
Focus on the node in the upper left corner that says, “Strass Gray HVD”. This is the Modbus-Read node which retrieves the byte with the HVD bit. It is configured in the pane below. A polling rate of 1 minute is adequate to determine when a battery is fully charged.
In the next node down, labelled “bit 4”, in the flow above, the correct bit is extracted from the byte, which is bit 4, per the Morningstar document. The tool chatGPT was asked to write a Node Red function using javascript to select bit 4 of the input, and output the selected bit. Below, the result has been copied and pasted into a function node. It looks like chatGPT started on the first bit and rotated to the right three times to get to bit 4.
Next node down is a switch node, labelled simply “switch”. A switch node can be thought of as an if-then-else logic block. If the input is one state the switch will output a result to one of it’s output ports. If the input state is different the switch will output to a different port. Here the switch is being used to output a 1 on the top port when the input is a 1, and a 0 to the bottom port when the input is 0.
Continuing around the flow, the next node down is an Inject node labelled “0”. When clicked on, this node will inject a 0 into the switch node. This will cause the relay to be turned off in case of emergency.
The next node down is a link. A link node takes the data from it’s input and links it to another link node somewhere else in the flow and transfers the data. In this flow the link is taking the data from the top output of the switch node and linking that data to the input of a node that will do a reset in that other flow. The logic behind doing this reset is as follows. When the top output of the switch is active that means a High Voltage Disconnect has occured because a battery is fully charged. Since the battery is fully charged it is at a State Of Charge (SOC) of 100%. The link to another flow resets a gauge for SOC to 100%. This allows the SOC to be calibrated each cycle. Next the nodes on the right-hand side will be explained beginning at the top.
The top node on the right is the Modbus Response. This node is necessary to complete the conversation with the mod bus, which was started by the Modbus Read node.
Next down the line is a complicated looking node with a lable of “curl http:\\192.168…..”. This is an exec node which has the power of executing any command that could be executed at the shell prompt (command line interface or CLI) of the machine running the node red application. In this case the command is a “curl”. Hubspot defines curl this way:
A command line tool that enables data exchange between a device and a server through a terminal. Using this command line interface (CLI), a user specifies a server URL (the location where they want to send a request) and the data they want to send to that server URL.
In other words, we can execute a command to go to a web page, in this case the Microbits 1216H module. Here is how the exec node is configured:
Notice the i.p. address above is a private local address. This address could just as easily be an address anywhere on the Internet and Node Red could do it’s job from a remote location any where in the world that has Internet access.
Next down is a function labelled “change msg.payload”. This node takes the “1” in the payload given it by the switch node and changes the payload output to “DISC” which stands for “disconnect”.
A similar function node is next down except this function node changes the payload to “NORM” which stands for normal. Both of these last two nodes feed into a text node which had the purpose of printing text to a dashboard. The configuration is slightly unusual in that two words are printed to the dashboard by the text node. The first word goes into the label field, in this case HVD. The second word comes in as the payload from the previous node, in this case either DISC or NORM.
This concludes the HVD subflow. Subflows remaining to be documented when time permits are:
Array and Battery Volts and Amps
Coulomb Counter
Display PA Temp
Heaters
The chain of subflows is duplicated three more times, one for each battery lineup.
Version 1.20 and newer has improved and extended support for controlling the relays(including Nexa remote switches), getting the status of the digital inputs as well as reading temperatures from 1 wire sensors via HTTP GET URLs. Version 1.23 adds the possibility to read the state of the relays.
Turn on all relays and Nexa remote switches: http://%5Bwebswitch address]/relaycontrol/on/all
Turn on only one relay or Nexa remote switch using an index number: http://[webswitch address]/relaycontrol/on/[a number] [a number]: 1-5=built-in relays, 6-10=extension relays, 101-125=Nexa remote switches number 1-25, version 4.0-> 201-225=local 1-wire digital outputs, version 4.31 HOME Denkovi 8 > 256-456
Turn on only one relay or Nexa remote switch using its name: http://[webswitch address]/relaycontrol/on/[relay/Nexa name] [relay/Nexa name] has to be URL encoded.
Turn off all relays and Nexa remote switches: http://%5Bwebswitch address]/relaycontrol/off/all
Turn off only one relay or Nexa remote switch using an index number: http://[webswitch address]/relaycontrol/off/[a number] [a number]: 1-5=built-in relays, 6-10=extension relays, 101-125=Nexa remote switches number 1-25, version 4.0-> 201-225=local 1-wire digital outputs, version 4.31 HOME Denkovi 8 > 256-456
Turn off only one relay or Nexa remote switch using its name: http://[webswitch address]/relaycontrol/off/[relay/Nexa name] [relay/Nexa name] has to be URL encoded.
Home: Pulse a relay high(on) for a selectable duration in seconds: http://[webswitch address]/relaycontrol/pulse/high/[relay/Nexa name/number]/[duration in secs] See above for [relay/Nexa name/number]
Home: Pulse a relay low(off) for a selectable duration in seconds: http://[webswitch address]/relaycontrol/pulse/low/[relay/Nexa name]/[duration in secs] See above for [relay/Nexa name/number]
Get current relay/Nexa state using its name: http://%5Bwebswitch address]/relaystate/get/[relay/Nexa name] [relay/Nexa name] has to be URL encoded.
Get current relay/Nexa state using an index number: http://%5Bwebswitch address]/relaystate/get/[a number] [a number]: 1-5=built-in relays, 6-10=extension relays, 101-125=Nexa remote switches number 1-25
Turn on two or more relays or Nexa remote switch using index numbers: http://%5Bwebswitch address]/relaycontrol/on/[a number]$[a number] etc [a number]: 1-5=built-in relays, 6-10=extension relays, 101-125=Nexa remote switches number 1-25
Example: Turn on relays 2, 3, 5 and Nexa 1: http://%5Bwebswitch address]/relaycontrol/on/2$3$5$101
Turn off two or more relays or Nexa remote switch using index numbers: http://%5Bwebswitch address]/relaycontrol/off/[a number]$[a number] etc [a number]: 1-5=built-in relays, 6-10=extension relays, 101-125=Nexa remote switches number 1-25
Example: Turn off relays 1 and 4: http://%5Bwebswitch address]/relaycontrol/off/1$4
Getting relay state by index, multiple relays: http://[webswitch address]/relaystate/get2/[a number]$[a number] (and so on)
The answer will be something looking like: 1,0 2,0 5,1 for an url looking like this: http://[webswitch address]/relaystate/get2/1$2$5
Local 1-wire inputs: http://[webswitch address]/input/get2/[a number] [a number]: 1-25=1-wire input number 1-25
Note that since it’s a dual input devices the answer will look like this: |[3-digit status code]|[Message in text]|[value] With [value] being formatted as A,B for input A and B, for ex. 1,0 means input A=1 and input B=0
Reading by index: http://[webswitch address]/temperature/get/[1-25]
Added in version 3.7: Reading “temperatur.nu” temperature: http://[webswitch address]/temperature/get/26
Reading by sensor name: http://[webswitch address]/temperature/get/[sensor name] [sensor name] has to be URL encoded.
Reading by index: http://[webswitch address]/temperature/get2/[1-25]
Added in version 3.2: Reading by index, multiple sensors. http://[webswitch address]/temperature/get2/[1-25$1-25$1-25] (and so on)
The answer will be something looking like: 2,24.4 3,21.4 4,23.8 for an url looking like this: http://[webswitch address]/temperature/get2/2$3$4
Getting date/time for last reset of max/min temperatures: http://[webswitch address]/temperature/reset/last Example of reply: |000|OK|2015-09-17 14:49|
http://%5Burl%5D/carheatercontrol/set/override/%5Bheater name]/[command]/[hour]/[minute] [heater name]: name of the heater [command]: today or tomorrow [hour]: hour of departure time in format 0-23 [minute]: minute of departure time in format 0-59
Set the state of an Auto Control Program Override: http://%5Burl%5D/acpcontrol/set/override/%5BACP name]/[command] [ACP name]: name of the Auto Control Program [command]: disabled, off, on
http://%5Burl%5D/acpcontrol/set/override/%5BACP name]/[command]/[hour]/[minute] [ACP name]: name of the Auto Control Program [command]: off, on [hour]: hour to turn on or off [minute]: minute to turn on or off
Set the state of an Auto Control Program itself: http://%5Burl%5D/acpcontrol/set/program/%5BACP name]/[command] [ACP name]: name of the Auto Control Program [command]: disabled, enabled
Get the state of the Auto Control Programs, including disabled programs http://%5Burl%5D/acpstate/get2 See below for the reply format.
[degree]=0-359 or >= 360 if no valid readings are available [preset]=Active preset 1-8 or 255 if no active. [power relay] = Power relay status: 0=Off, 1=On, 2=Not supported. [Aux relay] = Aux relay status: 0=Off, 1=On, 2=Not supported. [Page timeout] = Page time out: >0 = page active, 0 = page inactive [Status message] = Latest status in text format.
Every field, except [Status message], contains only digits.
General format of replies:
General replies are done with Mime type “text/plain” via HTTP in the following format using | as field separator:
|[3-digit status code]|[Message in text]|[status/value]
”|000|OK|[status/value]” “|100|Unknown command|[status/value]” “|101|Unknown relay: [id]|[status/value]” “|102|Unknown input: [id]|[status/value]” ”|103|Not a temperature sensor: [id]|[status/value]” ”|104|Invalid temperature sensor index: [index]|[status/value]” ”|105|Invalid temperature sensor name: [name]|[status/value]” ”|106|Unknown pulse command:[command]|[status/value]” ”|107|Invalid pulse length: [length]|[status/value]” ”|108|Pulsing already active: [relay]|[status/value]” ”|109|Unknown status: [relay]|[X]” ”|110|Unknown car heater: [name]||” ”|111|Invalid time: xx||” ”|112|Not a humidity sensor: [id]|[status/value]” ”|113|Invalid humidity sensor name: [name]|[status/value]” ”|114|Invalid Auto Control Program Override time|[status/value]” ”|115|Unknown Auto Control Program: [Program name]|X| ” “|116|Invalid rotator preset index|X|” “|117|Rotator power already on/off||” “|118|Unknown rotator power command|X|” “|119|Rotator aux relay already on||” “|120|Rotator aux relay already off|| “|121|Unknown rotator aux relay command|X|” “|122|Rotator aux relay command not supported||” “|123|Invalid rotator set command|X| ” “|124|Invalid rotator command|X|”
Temperatures: A number in Celsius degrees, for ex: 23.3000 Relative humidity: An integer, for ex: 45
For xml formatted replies the Mime type “text/xml” is used.
<carheater> <name>[Name of first heater]</name> <relay>[Used Relay]</relay> <temperature>[Current temperature]</temperature> <relaystate>[0=Off, 1=On, X=Unknown]</relaystate> <!– Added in version 3.0 –> <tempunit>Celsius/Fahrnheit</tempunit> <!– Added in version 3.0 –>
<engagetime> <hour>[Hour for engage time in format 0-23 or 255 if N/A]</hour> <minute>[Minute for engage time in format 0-59 or 255 if N/A]</minute> </engagetime>
<disengagetime> <hour>[Hour for disengage time in format 0-23 or 255 if N/A]</hour> <minute>[Minute for disengage time in format 0-59 or 255 if N/A]</minute> </disengagetime>
<tomorrowsdeparturetime> <hour>[Hour for tomorrow’s departure time in format 0-23 or 255 if N/A]</hour> <minute>[Minute for tomorrow’s departure time in format 0-59 or 255 if N/A]</minute> </tomorrowsdeparturetime>
<override> <mode>[Override mode, one of: disabled, on, off, today or tomorrow]</mode> <hour>[Hour for override time if mode today or tomorrow in format 0-23 or 255 if N/A]</hour> <minute>[Minute for override time if mode today or tomorrow in format 0-59 or 255 if N/A]</minute> </override> </carheater>
<carheater> <name>[Name of second heater]</name> <relay>[Used Relay]</relay> <temperature>[Current temperature]</temperature>
<engagetime> <hour>[Hour for engage time in format 0-23 or 255 if N/A]</hour> <minute>[Minute for engage time in format 0-59 or 255 if N/A]</minute> </engagetime>
<disengagetime> <hour>[Hour for disengage time in format 0-23 or 255 if N/A]</hour> <minute>[Minute for disengage time in format 0-59 or 255 if N/A]</minute> </disengagetime>
<tomorrowsdeparturetime> <hour>[Hour for tomorrow’s departure time in format 0-23 or 255 if N/A]</hour> <minute>[Minute for tomorrow’s departure time in format 0-59 or 255 if N/A]</minute> </tomorrowsdeparturetime>
<override> <mode>[Override mode, one of: disabled, on, off, today or tomorrow]</mode> <hour>[Hour for override time if mode today or tomorrow in format 0-23 or 255 if N/A]</hour> <minute>[Minute for override time if mode today or tomorrow in format 0-59 or 255 if N/A]</minute> </override> </carheater>
There will be 0-8 <pre> tags. Presets without texts are skipped. [Active] will be 0 or 1. [Aux relay mode] will be 0,1 or 2. 0=Off, 1=On, 2=Not supported. [Power relay mode] will be 0,1 or 2. 0=Off, 1=On, 2=Not supported. [Rotator type] will be a number according to the following list: 0=Analogue. 1=Prosistel D. 2=Array switch. 3=Green Heron RT21. 4=DCU 1. 5=Yaesu GS232B. 6=Alfaspid RAK.
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.
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
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.
Update February, 2023. Along came Node Red and big improvements have been made. Go To
Flexradio says the Maestro manufacturing has been held up for several months due to a shortage of parts caused by Covid-19. This unit was snatched up from the QRZ.com online swapmeet and it’s a beauty.
Shown above in it’s travelling mode. All it needs is a wifi connection. It has an internal battery that will run quite a few hours. Portable operation gets a lot simpler with this device. A mic or a paddle is all it needs to get on the air. Back at the shack it looks equally at home with a paddle and a microphone.
The Maestro is an option that is not essential because all operations can be done with a pc or a laptop alone but this is for those of us who still like knobs. The knobs on the Maestro have an expensive-radio feel. It’s a pleasure to operate with this option.
W0QL - My Remote Base Journal 