Tracking User Activity with Node Red

(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.

1. Free open source software that resides on a Raspberry Pi.
2. Dashboard that is accessible from the Internet to show if someone is connected to a radio in real time, with details.
3. A log file showing who the users have been, including user details, what time the connections were made and what time they were disconnected.
4. The log file uses the Comma Separated Values (CSV) format so it can be uploaded to an Excel spreadsheet for detailed analysis.
5. All features are accessible from the Internet by anyone with the correct privileges.
6. Simple to use.

Steps to recreate this project for your own club’s use are below:

1. 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.
2. Use >sudo raspi-config to enable ssh and vnc.
3. Install Node Red by following the instructions on this link: https://nodered.org/docs/getting-started/raspberrypi
4. Using Palette Manager, install the following node: node-red-contrib-flexradio written by Stephen Hauser and explained here: https://nodered.org/docs/getting-started/raspberrypi
5. 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.

[
{
“id”: “fa203948d0e6d9d0”,
“type”: “tab”,
“label”: “Flow 1”,
“disabled”: false,
“info”: “”,
“env”: []
},
{
“id”: “251fb659293c42f1”,
“type”: “flexradio-discovery”,
“z”: “fa203948d0e6d9d0”,
“name”: “”,
“port”: “4992”,
“x”: 330,
“y”: 240,
“wires”: [
[
“8287e170289d500a”
]
]
},
{
“id”: “3f09eb82379ac711”,
“type”: “ui_text”,
“z”: “fa203948d0e6d9d0”,
“group”: “b09e9ca25cf6b31d”,
“order”: 0,
“width”: 0,
“height”: 0,
“name”: “”,
“label”: “Radio”,
“format”: “{{msg.payload.nickname}}”,
“layout”: “row-spread”,
“className”: “”,
“x”: 910,
“y”: 200,
“wires”: []
},
{
“id”: “db9955fa27cf75d0”,
“type”: “ui_text”,
“z”: “fa203948d0e6d9d0”,
“group”: “b09e9ca25cf6b31d”,
“order”: 1,
“width”: 0,
“height”: 0,
“name”: “”,
“label”: “Status”,
“format”: “{{msg.payload.status}}”,
“layout”: “row-spread”,
“className”: “”,
“x”: 910,
“y”: 260,
“wires”: []
},
{
“id”: “e7be831eddfaae4b”,
“type”: “ui_text”,
“z”: “fa203948d0e6d9d0”,
“group”: “b09e9ca25cf6b31d”,
“order”: 2,
“width”: 0,
“height”: 0,
“name”: “”,
“label”: “Client I.P.”,
“format”: “{{msg.payload.gui_client_ips}}”,
“layout”: “row-spread”,
“className”: “”,
“x”: 900,
“y”: 320,
“wires”: []
},
{
“id”: “fa301f57cad7d937”,
“type”: “ui_text”,
“z”: “fa203948d0e6d9d0”,
“group”: “b09e9ca25cf6b31d”,
“order”: 3,
“width”: 0,
“height”: 0,
“name”: “”,
“label”: “Client Station”,
“format”: “{{msg.payload.gui_client_stations}}”,
“layout”: “row-spread”,
“className”: “”,
“x”: 890,
“y”: 360,
“wires”: []
},
{
“id”: “ed6cd3458551a577”,
“type”: “ui_text”,
“z”: “fa203948d0e6d9d0”,
“group”: “b09e9ca25cf6b31d”,
“order”: 4,
“width”: 0,
“height”: 0,
“name”: “”,
“label”: “Client Host”,
“format”: “{{msg.payload.gui_client_hosts}}”,
“layout”: “row-spread”,
“className”: “”,
“x”: 890,
“y”: 420,
“wires”: []
},
{
“id”: “92f266ba0fe72027”,
“type”: “ui_text”,
“z”: “fa203948d0e6d9d0”,
“group”: “b09e9ca25cf6b31d”,
“order”: 5,
“width”: 0,
“height”: 0,
“name”: “”,
“label”: “Client Program”,
“format”: “{{msg.payload.gui_client_programs}}”,
“layout”: “row-spread”,
“className”: “”,
“x”: 880,
“y”: 460,
“wires”: []
},
{
“id”: “e16b56205f6185a9”,
“type”: “ui_text”,
“z”: “fa203948d0e6d9d0”,
“group”: “b09e9ca25cf6b31d”,
“order”: 6,
“width”: 0,
“height”: 0,
“name”: “”,
“label”: “Client Handles”,
“format”: “{{msg.payload.gui_client_handles}}”,
“layout”: “row-spread”,
“className”: “”,
“x”: 880,
“y”: 500,
“wires”: []
},
{
“id”: “8287e170289d500a”,
“type”: “trigger”,
“z”: “fa203948d0e6d9d0”,
“name”: “”,
“op1”: “”,
“op2”: “”,
“op1type”: “pay”,
“op2type”: “pay”,
“duration”: “10”,
“extend”: false,
“overrideDelay”: false,
“units”: “s”,
“reset”: “”,
“bytopic”: “all”,
“topic”: “topic”,
“outputs”: 1,
“x”: 330,
“y”: 340,
“wires”: [
[
“59718a62747b10aa”
]
]
},
{
“id”: “59718a62747b10aa”,
“type”: “rbe”,
“z”: “fa203948d0e6d9d0”,
“name”: “Filter: block all but changes”,
“func”: “rbe”,
“gap”: “”,
“start”: “”,
“inout”: “out”,
“septopics”: false,
“property”: “payload”,
“topi”: “topic”,
“x”: 400,
“y”: 420,
“wires”: [
[
“a2d9d4f4aa370116”,
“5ef3f2abc0776143”,
“d6d6658a8cc20e0f”,
“3f09eb82379ac711”,
“db9955fa27cf75d0”,
“e7be831eddfaae4b”,
“fa301f57cad7d937”,
“ed6cd3458551a577”,
“92f266ba0fe72027”,
“e16b56205f6185a9”,
“dca3db48af21a307”
]
]
},
{
“id”: “1d2574fc485d623f”,
“type”: “change”,
“z”: “fa203948d0e6d9d0”,
“name”: “Stations”,
“rules”: [
{
“t”: “set”,
“p”: “payload”,
“pt”: “msg”,
“to”: “payload.gui_client_stations”,
“tot”: “msg”
}
],
“action”: “”,
“property”: “”,
“from”: “”,
“to”: “”,
“reg”: false,
“x”: 720,
“y”: 580,
“wires”: [
[
“9c48e2830ef9d446”
]
]
},
{
“id”: “76a6532bc40dc4a6”,
“type”: “file”,
“z”: “fa203948d0e6d9d0”,
“name”: “”,
“filename”: “/var/www/html/test.log”,
“appendNewline”: true,
“createDir”: false,
“overwriteFile”: “false”,
“encoding”: “none”,
“x”: 700,
“y”: 1020,
“wires”: [
[]
]
},
{
“id”: “6b1041bab320ca67”,
“type”: “moment”,
“z”: “fa203948d0e6d9d0”,
“name”: “”,
“topic”: “”,
“input”: “”,
“inputType”: “msg”,
“inTz”: “America/Denver”,
“adjAmount”: 0,
“adjType”: “days”,
“adjDir”: “add”,
“format”: “”,
“locale”: “en-US”,
“output”: “”,
“outputType”: “msg”,
“outTz”: “America/Denver”,
“x”: 180,
“y”: 700,
“wires”: [
[
“bf431a5acd90b832”
]
]
},
{
“id”: “bdb049085cc97475”,
“type”: “change”,
“z”: “fa203948d0e6d9d0”,
“name”: “Timestamp”,
“rules”: [
{
“t”: “set”,
“p”: “payload”,
“pt”: “msg”,
“to”: “”,
“tot”: “date”
}
],
“action”: “”,
“property”: “”,
“from”: “”,
“to”: “”,
“reg”: false,
“x”: 170,
“y”: 640,
“wires”: [
[
“6b1041bab320ca67”
]
]
},
{
“id”: “a2d9d4f4aa370116”,
“type”: “delay”,
“z”: “fa203948d0e6d9d0”,
“name”: “”,
“pauseType”: “delay”,
“timeout”: “50”,
“timeoutUnits”: “milliseconds”,
“rate”: “1”,
“nbRateUnits”: “1”,
“rateUnits”: “second”,
“randomFirst”: “1”,
“randomLast”: “5”,
“randomUnits”: “seconds”,
“drop”: false,
“allowrate”: false,
“outputs”: 1,
“x”: 530,
“y”: 660,
“wires”: [
[
“1d2574fc485d623f”,
“8cd903664f096da0”,
“cfab0638431b3f19”,
“8cabe28af2d37e8c”,
“b6eccdc3bda00895”
]
]
},
{
“id”: “8cd903664f096da0”,
“type”: “change”,
“z”: “fa203948d0e6d9d0”,
“name”: “Client I.P.”,
“rules”: [
{
“t”: “set”,
“p”: “payload”,
“pt”: “msg”,
“to”: “payload.gui_client_ips”,
“tot”: “msg”
}
],
“action”: “”,
“property”: “”,
“from”: “”,
“to”: “”,
“reg”: false,
“x”: 720,
“y”: 620,
“wires”: [
[
“f46629eecd4972e9”
]
]
},
{
“id”: “cfab0638431b3f19”,
“type”: “change”,
“z”: “fa203948d0e6d9d0”,
“name”: “Program”,
“rules”: [
{
“t”: “set”,
“p”: “payload”,
“pt”: “msg”,
“to”: “payload.gui_client_programs”,
“tot”: “msg”
}
],
“action”: “”,
“property”: “”,
“from”: “”,
“to”: “”,
“reg”: false,
“x”: 720,
“y”: 700,
“wires”: [
[
“3b931ee1682dd15f”
]
]
},
{
“id”: “8cabe28af2d37e8c”,
“type”: “change”,
“z”: “fa203948d0e6d9d0”,
“name”: “Handles”,
“rules”: [
{
“t”: “set”,
“p”: “payload”,
“pt”: “msg”,
“to”: “payload.gui_client_handles”,
“tot”: “msg”
}
],
“action”: “”,
“property”: “”,
“from”: “”,
“to”: “”,
“reg”: false,
“x”: 720,
“y”: 740,
“wires”: [
[
“0f4f8fc63bf77a90”
]
]
},
{
“id”: “0f4f8fc63bf77a90”,
“type”: “rbe”,
“z”: “fa203948d0e6d9d0”,
“name”: “Filter: nulls”,
“func”: “rbe”,
“gap”: “”,
“start”: “”,
“inout”: “out”,
“septopics”: false,
“property”: “payload”,
“topi”: “topic”,
“x”: 1170,
“y”: 720,
“wires”: [
[
“dbfa56fdd624c7e4”
]
]
},
{
“id”: “d6d6658a8cc20e0f”,
“type”: “function”,
“z”: “fa203948d0e6d9d0”,
“name”: “New line”,
“func”: “msg.payload = msg.payload + \”\n\”;\nreturn msg;”,
“outputs”: 1,
“noerr”: 0,
“initialize”: “”,
“finalize”: “”,
“libs”: [],
“x”: 420,
“y”: 700,
“wires”: [
[
“dbfa56fdd624c7e4”
]
]
},
{
“id”: “5ef3f2abc0776143”,
“type”: “delay”,
“z”: “fa203948d0e6d9d0”,
“name”: “”,
“pauseType”: “delay”,
“timeout”: “25”,
“timeoutUnits”: “milliseconds”,
“rate”: “1”,
“nbRateUnits”: “1”,
“rateUnits”: “second”,
“randomFirst”: “1”,
“randomLast”: “5”,
“randomUnits”: “seconds”,
“drop”: false,
“allowrate”: false,
“outputs”: 1,
“x”: 190,
“y”: 580,
“wires”: [
[
“bdb049085cc97475”
]
]
},
{
“id”: “b6eccdc3bda00895”,
“type”: “change”,
“z”: “fa203948d0e6d9d0”,
“name”: “Host”,
“rules”: [
{
“t”: “set”,
“p”: “payload”,
“pt”: “msg”,
“to”: “payload.gui_client_hosts”,
“tot”: “msg”
}
],
“action”: “”,
“property”: “”,
“from”: “”,
“to”: “”,
“reg”: false,
“x”: 710,
“y”: 660,
“wires”: [
[
“accffad613c92103”
]
]
},
{
“id”: “f46629eecd4972e9”,
“type”: “function”,
“z”: “fa203948d0e6d9d0”,
“name”: “Append comma”,
“func”: “msg.payload = msg.payload + \”,\”;\nreturn msg;”,
“outputs”: 1,
“noerr”: 0,
“initialize”: “”,
“finalize”: “”,
“libs”: [],
“x”: 880,
“y”: 620,
“wires”: [
[
“0f4f8fc63bf77a90”
]
]
},
{
“id”: “accffad613c92103”,
“type”: “function”,
“z”: “fa203948d0e6d9d0”,
“name”: “Append comma”,
“func”: “msg.payload = msg.payload + \”,\”;\nreturn msg;”,
“outputs”: 1,
“noerr”: 0,
“initialize”: “”,
“finalize”: “”,
“libs”: [],
“x”: 880,
“y”: 660,
“wires”: [
[
“0f4f8fc63bf77a90”
]
]
},
{
“id”: “3b931ee1682dd15f”,
“type”: “function”,
“z”: “fa203948d0e6d9d0”,
“name”: “Append comma”,
“func”: “msg.payload = msg.payload + \”,\”;\nreturn msg;”,
“outputs”: 1,
“noerr”: 0,
“initialize”: “”,
“finalize”: “”,
“libs”: [],
“x”: 880,
“y”: 700,
“wires”: [
[
“0f4f8fc63bf77a90”
]
]
},
{
“id”: “dbfa56fdd624c7e4”,
“type”: “csv”,
“z”: “fa203948d0e6d9d0”,
“name”: “”,
“sep”: “,”,
“hdrin”: “”,
“hdrout”: “none”,
“multi”: “one”,
“ret”: “\n”,
“temp”: “”,
“skip”: “0”,
“strings”: true,
“include_empty_strings”: “”,
“include_null_values”: “”,
“x”: 690,
“y”: 960,
“wires”: [
[
“76a6532bc40dc4a6”
]
]
},
{
“id”: “9c48e2830ef9d446”,
“type”: “function”,
“z”: “fa203948d0e6d9d0”,
“name”: “Append comma”,
“func”: “msg.payload = msg.payload + \”,\”;\nreturn msg;”,
“outputs”: 1,
“noerr”: 0,
“initialize”: “”,
“finalize”: “”,
“libs”: [],
“x”: 880,
“y”: 580,
“wires”: [
[
“0f4f8fc63bf77a90”
]
]
},
{
“id”: “bf431a5acd90b832”,
“type”: “function”,
“z”: “fa203948d0e6d9d0”,
“name”: “Append comma”,
“func”: “msg.payload = msg.payload + \”,\”;\nreturn msg;”,
“outputs”: 1,
“noerr”: 0,
“initialize”: “”,
“finalize”: “”,
“libs”: [],
“x”: 440,
“y”: 820,
“wires”: [
[
“dbfa56fdd624c7e4”
]
]
},
{
“id”: “dca3db48af21a307”,
“type”: “debug”,
“z”: “fa203948d0e6d9d0”,
“name”: “”,
“active”: true,
“tosidebar”: true,
“console”: false,
“tostatus”: false,
“complete”: “false”,
“statusVal”: “”,
“statusType”: “auto”,
“x”: 1070,
“y”: 400,
“wires”: []
},
{
“id”: “b09e9ca25cf6b31d”,
“type”: “ui_group”,
“name”: “Discovery”,
“tab”: “0613cce6f287631c”,
“order”: 1,
“disp”: true,
“width”: “6”,
“collapse”: false,
“className”: “”
},
{
“id”: “0613cce6f287631c”,
“type”: “ui_tab”,
“name”: “FlexRadio Dashboard”,
“icon”: “dashboard”,
“disabled”: false,
“hidden”: false
}
]

Noise Chase

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

Node-Red Aux Dashboard – Part 1

An Artist’s Conception of Remote Station W0QL

Thanks to Rosa Colon for the Union of Concerned Scientists in 2021 Calendar.

Ms. Colon probably never heard of W0QL but the solar panels beside a radio tower was too good to pass up.

WSPR Station

Project 5 of 7 for October, 2020 – projects to keep sane during Covid-19 Lockdown

Status: Completed and on the air as of June, 2021

WSPR has been played with for so long it has gone through may iterations. As of May, 2022, the latest attempt is to use a TAPR WSPR board on a Raspberry Pi. This runs 200 mW on one designated band. In our case, 10 meters. Watch for progress. Continue reading below to learn about earlier attempts.

The object of building a WSPR station is to be able to see signals first hand real time that are coming into this qth. A band to operate on can be chosen more quickly and more efficiently. WSPR per se is explained here: https://en.wikipedia.org/wiki/WSPR_(amateur_radio_software)

While it would be great to have a WSPR transmitter as well as receiver that is not feasible at the remote site or at home. The radiated signal from WSPR would cause interference to other services. A reasonable alternative exists and that is to receive only. Stations decoded will be posted to WSPRnet.org which shows a map of where those stations are located.

Hardware and software is about as simple as it can get. All parts are already in place and just need to be connected and configured. A computer that is already on site can run the WSJT-X software. An antenna that is already on site, the DXEngineering RF-PR-1B Active Magnetic Loop, can provide a signal on multiple bands. A receiver that will work well is the SDRPlay. The new model RSPdx is on site and is an excellent choice because of it’s additional bandpass filter on the low bands. It will enable monitoring of 630 meters all the way up to 10 meters. Virtual audio channel software will need to be installed to provide a software connection between the SDRPlay and the WSPR decoder. Virtual com port software will be needed for cat control to change frequencies. Power budget will be low because the pc and the receive loop already run 24 hours a day. The SDRPlay is the only additional power draw and it is insignificant. It plugs into a usb port on the pc and draws power from the pc.

Updates to follow as the project is implemented. Example display of WSPRnet.org is below.

It’s working! Check it out at wsprnet.org. Running on 30 meters alone provides this result.

All it needed was to reload SDRUno with the latest version, vspn port emulator software, and vb basic virtual audio cable software. A YouTube instruction video by the SDRPlay technical department helped a lot.

Final step will be to open up all bands, not just 30 meters. That works but the whole WSPR operation is not at all stable. This project is not done. It is stable so long as it is not disturbed but accessing the pc with remote desktop. That disturbance stops the WSPR operation.

It has been stable for more than a day by starting the applications on site and not using remote desktop. This is not a solution because we need remote desktop to reach other applications. Work in progress.

Currently working on an antenna on the house back in Denver to become the beacon antenna. How long before the HOA notices?

Update – June, 2021: Relocated to the site of the remote base, using Hustler 6BTV vertical antenna and Yaesu FT-817 transceiver. Running 1 watt on 80,40,30,20,15,10, and 6 meters. The computer is an Intel NUC i3 running Windows 10 and WSJT-X 2.4.1. Here is a typical example of performance. The best spot is Iceland hearing W0QL with it’s 1 watt and a vertical.

Above is an example of 30 meters early one evening. One watt and a vertical is amazing.

RSPdx and SDRConsole

Next up in the quest for the perfect FT8 decoder is the SDRplay model RSPdx.  This is SDRPlay’s latest receiver.  Several software packages are capable of running this SDR including the one that comes with it, SDRuno.  Most popular is probably SDRConsole and it has the advantage of coming with a built-in server for remote access which is a requirement.  The RSPdx antenna input is connected to an external splitter and continues on to an active receive loop, the DXEngineering RF-PRO-1B.  The other output of the splitter is connected to the IC-7610 RX-IN jack.  A direct comparison of the number of FT8 decodes was made by running two copies of WSJT-X simultaneously.  The 7610 wins by a mile.  Here are screen snaps of the same pass for the two radios.  First, from the 7610.

Next, from the RSPdx.

Observing the decodes for pass 193730, the top image has 32 stations and the bottom 19. In this one pass the winner is clearly the IC-7610. The RSPdx might not be optimized considering it was just installed today.  Next step is to try to optimize the RSPdx.

Followup

Trying to find a way to optimize the RSPdx performance it was found by turning the SDRConsole gains up and the agc off the same number of stations can be decoded on each radio.  Gain has to be reduced to the WSJT-X application so it won’t be overdriven.  The number of decodes are the same on both receivers now and the SNR (signal to noise ratio) is within a few dB.  On RSPdx both the RF gain and the IF gain are set to max.  Even with the gains set wide open SDRConsole is not showing any signs of overload.  This result might indicate the signals from the active antenna, which are attenuated when they go through a splitter, are very weak.  Still the IC-7610 has no problem with the levels and the RSPdx perhaps shouldn’t either.  At least a way was found to make the performances equal.  It would be interesting to remove the splitter however that would produce meaningless results since the two receivers would then be on different antennas.  The new Flex radio should arrive soon and that will provide a third radio for comparison.

KiwiSDR Receiver

Today marks a milestone in being able to access a standalone remote receiver at the W0QL station.  A KiwiSDR arrived.  It consists of a I/Q receiver board attached to a Beaglebone Green micro controller.

For more information see the link http://www.kiwisdr.com/ks/using_Kiwi.html

KiwiSDR is a receiver capable of tuning from 10 kHz to 30MHz accessed exclusively over it’s Ethernet connection which in this case will be the Internet.

Within 5 minutes of arriving it was up and running—truly plug-n-play.  Software was pre-loaded and all needed hardware and peripherals were included in the kit ( $300 ).  The KiwiSDR was decoding WSPR stations with the builtin wspr extension and displaying them on an iPad over the Internet.  It is also sending spots to wsprnet.org.

Two projects are targeted for this radio so it’s possible a second one will have to be added for the second project.  The first project is a dedicated wspr receiver capable of receiving and spotting several bands at once.  This will provide information 24 hours a day about what bands are open at this particular location and instant in time.  The other project is to have a second receiver to pick up FT8 signals.  This would provide a “pseudo”  SO2R receiver for use in single operator, two radio mode. Today is just the start of the projects.

Oops.  Silly person.  The KiwiSDR can have up to 8 users at a time completely independent from each other.   Two KiwiSDR’s are not needed.  One Kiwi can serve the purposes of different users.  For example wspr can be on 7 bands simultaneously and an eighth receiver slice can be on FT8.   Or mix and match as one wishes.  The limit is CPU processing power.

Day 2 discovery:  Catch 22.  Can’t decode FT4 perhaps due to latency.  WSPR and FT8 are ok but FT4 transmissions appear to be delayed too much by the Internet.  FT4 transmissions are only 4.48 seconds compared to 12.64 seconds for FT8.  A few milliseconds latency is a larger percentage of the shorter transmissions.

Meanwhile a SDRPlay RSPdx receiver has also been installed. There is a fundamental difference between the two receivers and that is where the FT4 transmission is decode by WSJT-X.  RSPdx does it locally and KiwiSDR does it at the client site.

.The Kiwi processes the I/Q signals at the receiver site using the Beaglebone microcontroller.  A client computer dials into the Beaglebone over the Internet to obtain the processed I/Q signals (audio SSB).  WSJT-X runs on the client computer and decodes the audio ssb FT4 transmissions.  The RSPdx does it differently.   It sends the I/Q signals over a USB cable to an external cpu on site, typically a Windows pc.  The pc processes the I/Q signals and sends them internally to the WSJT-X application running on the same pc.  Next the WSJT-X display screen with decoded FT4 information is transported over the Internet using Remote Desktop where latency is not an issue.  There is an issue for Remote Desktop, though, and that is Internet bandwidth.  It uses a lot and running more than one Desktop on one Internet connection does not work well with the service at the remote base site.

One possible solution for KiwiSDR would be to delay the time clock on the client pc by the same delay as the latency.  How would this be accomplished?  Another solution is better Internet service.

Late Winter Frost

A heavy frost makes the guy ropes look like a spider web.   This is just a peaceful scene that is representative of how well everything has been working through the winter with no mishaps.  Knock on wood.

5 Loose Ends Tied Up

1. Is the beam pointing in the direction the rotor says it is?    It was within 5 degrees which is good enough considering the antenna has a 30 degree beamwidth.
2.  Replace faulty power unit.  Bit the bullet and bought a new Rig Runner 4005i to replace the one that had been damaged by a lightning surge in the summer.  Moved the damaged one down the line to the radio and some peripherals. It still turns the power on and off; it just can’t read the voltage or current since the lightning surge.
3. The Internet controlled interface to the solar controller can be reset over the Internet now.  The Morningstar Sunsaver Duo and it’s remote, the EMC-1 sometimes locked up and couldn’t be read over the Internet.  Installed are relays on the EMC-1 wiring to allow it to be reset remotely.
4. Braided straps on the big vertical antenna should improve the rf path through the tuner to the ground radials.  These straps replace the single 12 gauge wire we had been using.  The tips of the straps are soldered to keep water from seeping into the connection.

5.   Waterproof the tower legs sticking down into the concrete.  Water in the legs from the summer rains was pumped out and expanding foam was squirted in. Water does not drain out the bottom like one would expect.  On the last tower it took 10 years but the steel legs finally rusted through and had to be replaced.  Hopefully this problem has been eliminated with the expanding foam sealant.

More loose ends:  put up a sign on the east side targeting the easement, “Danger, 13,400 Volts”.  Will that make some people keep their distance?  Maybe.

checked and topped off battery fluid, labeled all equipment with i.p. Address and port number.

Repainting To Control Summer Heat

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.

Station Upgrades

Nothing reinvigorates interest in operating a ham station more than an upgrade.  Finally some upgrades and changes are in progress.  (All we want is more, right?)

• Two 40 meter dipoles at a height of one half wave length (65 ft.), one for Europe, the other for Asia
• Decommissioning Parker site
• Replacing one TS-480 with a Elecraft K3 and K3/0 Mini
• Erecting a 60 foot tower with a 20 meter monoband yagi, web access for the rotor control
• Web access for a coax switch
• A 630 meter station
• A reservation for a Icom IC-7610 for the future because it has a builtin remote base server and an excellent performance sales pitch.

These upgrades and changes should make this station significantly more competitive.  Some of these upgrades are a culmination of what has been previously discussed in this blog. Others, like 630 meters, are a result of new happenings in the world of amateur radio.

Progress report on 40 meter dipoles:  South support pole is up and waiting for the north support pole to be readied.  South pole is in the foreground and the other pole is in the distance behind the shed. The pole is 65 feet tall.  Picture a dipole running between the tips of these two poles for 40 meters.

Update:  It blew down 3 days later.  What’s left of the aluminum is now a support for a 6 meter dipole for the sporadic E season.  It’s windy out there on them thar’ plains.

June 8, 2017:  Big progress on hole for tower.  Today we finished digging the 4’X4’X4′ hole and got a rebar cage built and lowered inside the excavation.  Next step is to put the tower base in.  My rotator cuff suffered minor damage and was quickly repaired by a little physical therapy.  My advice is next time get someone younger to do the digging.