Welcome to the W0QL remote station journal. The station was born in 2016 and is located on the plains east of Denver. It’s controlled over the Internet and powered exclusively by a solar system and lithium batteries.
The Flexradio is the heart of the whole station.
Now let’s get going, with the most recent post beginning below.
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.
Specifically, grounding for the DC circuits, and why is equipment being damaged?
It’s been 6 years since the last article on this blog about grounding. No damage from lightning (knock on wood) all these thunderstorm seasons later, is a good testimonial to the lightning ground. However, lately a few devices have been destroyed or damaged not by lightning but by something else. Considering there have been no thunderstorms the damage probably has been caused by voltage spikes from somewhere. But from where? A ground loop? A relay with no diode? One inadvertent source of a ground loop has been discovered. The negative side of the DC power bus has been connected to the Single Point of Ground since 2017. No noticeable problems have been observed due to this, probably because of luck.
Dereck Campbell, KF5LGW, has a good explanation of why connecting the two together is a bad idea. Note that Dereck is talking about an AC to DC power supply and the remote system has only a DC battery supply. Read around the references to AC line in the explanation below, please. Pay attention mostly to the right hand side of Dereck’s drawings.
The objective is to isolate AC and DC power systems and remove your radio equipment from the ground loop by relocating the ACEG to the same point the shack uses. To understand what is happening, let us draw the circuit out and see what is happening.
FIG 3A shows how 2-wire and 3-wire systems are incompatible. Look closely at the 2- wire system chassis (ground) and DC Negative circuit conductor and the same conductors bonded together inside your 12-volt radio equipment. That is not compatible with 3-wire systems. As you can see the red arrows result forcing normal DC operating current on ground conductors.
The result is DC flowing on equipment grounds, coax shields, and GES. Look what happens when I induce the same AC Line-to-Ground fault inside the DC power supply in FIG 3B. Follow the fault current paths like before. One path is on the ACEG conductor like you planned, and the other unplanned path goes through your radio equipment needlessly and can cause significant damage to your radio equipment and coaxes.
Take note. The 14 AWG ACEG conductor from the breaker panel to the wall outlet can be 30 to 100 feet in length. The unintended secondary path created is through your radio equipment using a 6 AWG conductor of approximately the same distance going back to the same point as the 14 AWG. They are in parallel. Which of those two parallel paths do you think will carry the bulk of the fault current? The 6 AWG or 14 AWG? All you need to know is how Ohm’s law works; no math required. Isolate the 2- systems, and you eliminate the problem!
Lost in a ground-loop creates two more issues. One a minor annoyance generating RFI/EMI. You have a piece of wire (you radio ) bonding the two ground electrodes together with a common-mode current flowing through your EGP. The second problem can be extremely hazardous if lightning strikes nearby. Equalization current path is right through your equipment, acting as a piece of wire.
Now, look at Fig 4A and Fig 4B. I removed the bonding jumper hiding inside the DC power supply. Follow the red arrow current again. What happened? AC and DC systems are isolated. No DC is flowing on any ground conductors. Removing the bonding jumper broke the DC galvanic bond across the transformer inside your DC Power Supply. AC and DC systems are isolated, allowing you to interface your home 3-wire system to your radio’s 2-wire system. The DC system can be a Grounded System, but do not use your DC power supply chassis ground because the transformer’s primary side is part of the AC system, including the chassis.
Why Is Equipment Being Damaged?
One possible explanation is the DC negative bus being grounded but that hasn’t caused known issues for many years. Could the damage be from “back-emf” from an inductance? When a relay is activated and then eventually deactivated there is a voltage spike from the coil which is back-emf caused by the inductance of the coil. A diode across the coil will short-out that back-emf voltage spike. There are several high amperage relays in the remote station that have large coils and large voltage spikes. Those relays all have diodes installed and it is unlikely those relays are the cause of the damaged equipment. What has changed lately is the West Mountain Radio 4005i power controllers have been replaced by a KMTronic 8 relay unit and a DC power strip. In the past, each device was powered individually by a port on the 4005i’s. Instead, now several devices are lumped together and get their power from the DC power strip through a relay on the KMTronic. Power to that strip is turned on and off by the KMTronic unit. Some of the devices are in the shack and others are out at the end of long runs of power cable. In-the-shack devices are in parallel with those long cables on the DC power strip. One tuner is 100 feet away and one security camera is also 100 feet away. That long cable may have enough inductance to induce a back-emf voltage spike when the KMTronic deactivates it’s relay. The plan is to add 1N4001 diodes across the long cables and then to add 14 volt Zener diodes across the inside-the-shack devices. It is hoped the diodes will provide protection from spikes and stop the damage to equipment. Or isolating the DC negative leads from the green-wire ground bus (single point of ground) will. Updates to come.
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.
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 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.
W0QL - My Remote Base Journal 