I’ve been making a few improvements to my QO-100 Node Red Dashboard whilst waiting for the 2.4Ghz hardware to arrive. I’ve added the ability to split the RX and TX VFOs so that I can tune away from the TX frequency for working split stations or for tuning to slightly off frequency stations. I also added a series of tuning buttons to the top of the GQRX side of the dashboard to enable easy tuning using the trackball connected to my Kubuntu PC. This worked well but, I really missed having a real VFO knob like a conventional radio.
As I had a Griffin Powewrmate USB VFO from a previous SDR radio I added it to the flow as well so that I had a physical VFO knob for the SDR receiver. Details on how I got it working using evtest and a simple BASH script are in the Griffin Powermate article.
M0AWS QO-100 Node Red Dashboard Flow
The Node Red flow is looking a little busier with the addition of split mode and the Griffin Powermate USB VFO which has really enhanced the useability of the solution. It’s very impressive what can be achieved with Node Red with a little imagination. You really don’t need to be a heavy weight programmer to make things work.
M0AWS QO-100 Node Red Dashboard as of 07/06/23
I also put together some code to calculate the S Meter reading from the dBFS data the GQRX SDR software generates. It’s not 100% accurate but, it’s close enough to be useful.
On the IC-705 side of the Dashboard I also now display the 2.4Ghz uplink frequency so that it’s available for logging.
So with the QO-100 Dashboard ready to go live I have now started putting together the 2.4Ghz transmit path of the ground station. I have the 2.4Ghz transverter and matching 12w amplifier from DXPatrol, the IceCone Helix 2.4Ghz antenna from Nolle Engineering, some LMR-400-UF and connectors from Barenco and an appropriate water proof enclosure from Screwfix to fit all the kit into however, I’m now being held up by one simple little SMA male to SMA male connector that I need to connect the transverter and amp together.
M0AWS Waterproof enclosure from ScrewfixM0AWS Laying out the 2.4Ghz TX kit in the enclosureM0AWS LMR-400-UF coax from Barenco
The SMA connector has been ordered but, is taking a month of Sundays to arrive! Hopefully it’ll arrive soon and I’ll finally get on the QO-100 satellite and start enjoying the fun.
I’ve been gradually building my QO-100 ground station over the last few months and have had the receive path working for some time now. One of the things I really miss with the Funcube Dongle Pro+ (FCD) SDR is a real VFO knob for changing frequency.
My QO-100 Node Red dashboard is configured so that I can have the FCD track the uplink frequency from the IC-705 but, sometimes I use the FCD without the IC-705 in the shack and so a physical VFO would be handy.
Many years ago when I lived in France (F5VKM) I had a Flexradio Flex-3000 SDR, a great radio in it’s time and one that gave me many hours of enjoyment. One addition I bought for that station was a Griffin Technology Powermate VFO knob. It worked extremely well with the PowerSDR software for the Flex-3000 and I used it for many years.
Many years later I’m back in the UK and much of my equipment is packed away in the attic, including the Griffin Technology Powermate VFO.
I decided to dig it out and see if I could get it working with GQRX SDR software. Sadly I couldn’t get it working with GQRX however, I did find a way of getting it working with Node Red and thus could add it to my QO-100 Node Red Dashboard and then control GQRX with it via a simple Node Red flow.
Griffin Technology Powermate VFO
Plugging the Powermate VFO into my Kubuntu PC it wasn’t immediately recognised by the Linux O/S. After a little searching I found the driver on Github. I added the PPA to my aptitude sources and installed the driver using apt.
Once installed the default config for the Powermate device is to control the default audio device volume. To make the device available for use as a VFO knob you need to change the configuration so that the default setting is disabled. To do this is relatively easy, just edit the config file using your favourite command line editor (Vi/Vim in my case) and add the following entry.
vi /etc/powermate.toml
# Entry to control HDMI volume with Powermate
#sink_name = "alsa_output.pci-0000_01_00.1.hdmi-stereo"
# Set powermate not to work with volume control
sink_name = ""
As shown above, comment out the default “sink_name” entry (Yours may be different depending on audio device in your PC) and add in the Powermate “sink_name” entry that effectively assigns it to nothing.
Once this is done, save the file and exit your editor and then reboot the PC.
Next you’ll need to install a small program called evtest.
sudo apt install evtest
To check the evtest program has installed correctly, plugin your Powermate VFO to any available USB port and run the following command in a terminal.
evtest /dev/input/powermate
Turning the Powermate knob you should see output on the screen showing the input from the device. You should also see BTN events for each press of the Powermate device.
Input driver version is 1.0.1
Input device ID: bus 0x3 vendor 0x77d product 0x410 version 0x400
Input device name: "Griffin PowerMate"
Supported events:
Event type 0 (EV_SYN)
Event type 1 (EV_KEY)
Event code 256 (BTN_0)
Event type 2 (EV_REL)
Event code 7 (REL_DIAL)
Event type 4 (EV_MSC)
Event code 1 (MSC_PULSELED)
Properties:
Testing ... (interrupt to exit)
Event: time 1685816662.086666, type 2 (EV_REL), code 7 (REL_DIAL), value -1
Event: time 1685816662.086666, -------------- SYN_REPORT ------------
Event: time 1685816662.318638, type 2 (EV_REL), code 7 (REL_DIAL), value -1
Event: time 1685816662.318638, -------------- SYN_REPORT ------------
Event: time 1685816662.574615, type 2 (EV_REL), code 7 (REL_DIAL), value -1
Event: time 1685816662.574615, -------------- SYN_REPORT ------------
Event: time 1685816663.670461, type 2 (EV_REL), code 7 (REL_DIAL), value 1
Event: time 1685816663.670461, -------------- SYN_REPORT ------------
Event: time 1685816664.030421, type 2 (EV_REL), code 7 (REL_DIAL), value 1
Event: time 1685816664.030421, -------------- SYN_REPORT ------------
Event: time 1685816664.334389, type 2 (EV_REL), code 7 (REL_DIAL), value 1
Event: time 1685816664.334389, -------------- SYN_REPORT ------------
Event: time 1685816665.334255, type 1 (EV_KEY), code 256 (BTN_0), value 1
Event: time 1685816665.334255, -------------- SYN_REPORT ------------
Event: time 1685816665.558230, type 1 (EV_KEY), code 256 (BTN_0), value 0
Event: time 1685816665.558230, -------------- SYN_REPORT ------------
Event: time 1685816666.030161, type 1 (EV_KEY), code 256 (BTN_0), value 1
Event: time 1685816666.030161, -------------- SYN_REPORT ------------
Event: time 1685816666.182151, type 1 (EV_KEY), code 256 (BTN_0), value 0
Event: time 1685816666.182151, -------------- SYN_REPORT ------------
At this point you’re ready to stop evtest (CTRL-C) and then create the following little BASH shell script that Node Red will run to collect the O/P from the Powermate USB device.
#!/bin/bash
###############################################
# Griffin Technology Powermate control script #
# for Node Red. #
# #
# 04/06/23 - M0AWS - v0.1 #
# #
###############################################
VAL="1"
echo "STEP-1Hz"
/usr/bin/evtest /dev/input/powermate | while read LINE
do
case $LINE in
*"(REL_DIAL), value 1") echo "$VAL"
;;
*"(REL_DIAL), value -1") echo "-$VAL"
;;
*"(BTN_0), value 1") case $VAL in
"1") VAL="10"
echo "STEP-10Hz"
;;
"10") VAL="100"
echo "STEP-100Hz"
;;
"100") VAL="1000"
echo "STEP-1Khz"
;;
"1000") VAL="10000"
echo "STEP-10Khz"
;;
"10000") VAL="1"
echo "STEP-1Hz"
;;
esac
;;
esac
done
Once the BASH script is copied and pasted into a file called powermate.sh you need to make it executable by using the following command.
chmod 700 ./powermate.sh
If you now run the shell script in a terminal you’ll see a similar output to that shown below from the device when used.
As you can see above the shell script outputs a positive or negative number for VFO tuning and changes the VFO step size each time the Powermate is depressed.
Getting this output from the BASH shell script into Node Red is really simple to achieve using just 3 or 4 nodes.
In the Node Red development UI create the following nodes.
Griffin Powermate Node Red Nodes
The first node in the flow is a simple inject node, here I called it trigger. This sends a timestamp into the next node in the flow at startup to set the flow running.
The Griffin Powermate node is a simple exec node that runs the script we created above.
M0AWS Powermate exec node
Configure the node as shown above and connect it to the inject node that’s used as a trigger. Note: Change “user” in the Command field shown above to that of your username on your Linux PC)
Once done create the third node in the flow, a simple switch node and configure as shown below.
Switch Node for Powermate
The switch node has two outputs, the top one is a text output that is fed into a text field to show the current step size of the Powermate device and the lower output is the numeric output that must be fed into your VFO control flow so that the VFO value is incremented/decremented by the amount output by the Powermate device.
I’ve found the Griffin Technology Powermate USB device works extremely well with Node Red and GQRX that I use for controlling the FCD SDR radio and it’s now part of my QO-100 ground station build.
M0AWS QO-100 Dashboard with Powermate Step Display at bottom
As shown above you can see the Powermate Step size at the bottom of the dashboard, this text changes each time the Powermate device is depressed and will set a step size of 1Hz, 10Hz, 100Hz, 1Khz, 10Khz in a round-robin fashion.
The next stage of the build is the 2.4Ghz transmit path. I now have all the necessary hardware and so this part of the build can finally commence.
Over the long bank holiday weekend I started putting together my QO-100 ground station. To start with I’ve concentrated solely on the receive path. I’ll start the transmit path once I have the receive path operational at a satisfactory level.
A few weeks ago I purchased a 1.1m off-set dish antenna and a Bullseye LNB. These have been sat in my garage waiting for the weather to improve so that I could start the build in the dry.
QO-100 Dish MountThrough wall bolt
Fortunately we’ve had a mini-summer for the last 2 days and so I started work on getting the dish mount built. Using some timber from the local saw mill I made a braced 3m tall post which I screwed to the side of the cabin to provide a stable fixing platform. I used a couple of threaded bars to bolt through the walls of the cabin to ensure a solid fixing.
Next I mount the metal dish bracket to the top of the wooden post taking the total height up to around 3.2m above ground. This gives plenty of head clearance down below.
Next I assembled the dish and and attached it to the metal dish bracket at the top of the wooden post.
QO-100 1.1m dish mounted on the 3.2m AGL fixing
Attaching and cabling the Bullseye LNB was an easy job. I used some high quality coax cable that I purchase from the Satellite Superstore when I purchase the dish. I also had to set the LNB skew to -17.8 degrees. The marking on the LNB are tiny and go up in fives and so it’s pretty much impossible to get exactly -17.8 degrees so I turned it to 15 and then a tiny bit. It was as close I could get it!
Next I needed the information on where to point the dish. Fortunately there is a great web app on the BATC website where you can move a pin on a map to your location and all the information you need to align the dish is automagically calculated for you.
Armed with this info I set about aligning the dish. Getting it as close as possible I lightly locked off the dish and continued getting the coax in to the radio room so that I could connect it to my Funcube Dongle Pro+ (FCD) SDR receiver. Since the LNB needs a 12v DC feed I had to put inline a “Bias Tee” unit. This unit allows you to inject 12v onto the coax going up to the LNB but, stops it from coming back into the receiver. I used a Bias Tee that I purchased from Amazon with the Bullseye LNB.
Bias Tee mounted under the station desk
Connecting the coax to my Funcube Dongle Pro+ I was really pleased to see that I was receiving signals from the satellite perfectly well. I decided to take my laptop up onto the roof of the cabin and see if I could improve the reception further. To my amazement with very tiny changes in elevation and azimuth I was able to improve the QO-100 beacon signal by a further 10dB.
Being pleased with the dish alignment I started to tighten it so that it couldn’t move in the wind. Unfortunately this caused the dish to move a tiny amount which reduced the signal strength. I loosened the bolts off again and realigned the dish once more. This time when I tightened the clamps I did it a bit at a time on each bolt working my way round them so that the dish didn’t move. Doing it this way I still lost 1dB off the QO-100 beacon signal due to tiny amounts of movement but, decided I could live with the 1dB reduction.
QO-100 dish successfully mounted & aligned with HF antennas in the background
Below is a very short video clip showing a German station talking on the QO-100 satellite. As you can see the signal is nice and strong and extremely clear. I did find that the output from the LNB was actually too much for the FCD SDR and so I reduced the LNA setting in GQRX to 0dB. This reduced the background noise level considerably as the receiver was no longer being overloaded and made the signals much more prevalent above the noise floor.
Short video clip showing signal clarity from the QO-100 Satellite
I’m really pleased at the performance of the receive path and have now ordered the 2.4Ghz hardware from DXPatrol and Nolle Engineering so that I can build the transmit path.
I have also made some improvements to my QO-100 Node Red Dashboard so that I can work split on the satellite using my IC-705 and FCD SDR.
QO-100 Node Red Dashboard with ‘Split’ capability
Once the 2.4Ghz hardware arrives I’ll update the blog with progress.
I’ve now completed the GQRX Receive and Icom IC-705 Transmit dashboard in Node Red. It was a fun project to put together and needed some javascript coding to get the functionality I wanted but, I got there in the end.
M0AWS QO-100 GQRX/IC-705 control dashboard
The dashboard looks fairly simple but, there is a lot behind the scenes to get it to this stage.
On the left is the Icom IC-705 transmit control panel. It shows the transmit frequency, power output and SWR reading. The SWR is so that I can check that the input into the 2.4Ghz transverter doesn’t have any connectivity issues. The “S0” will actually display the S Meter reading when the IC-705 is being used as a normal transceiver rather than being in QO-100 Duplex mode as shown above where the GQRX app and Funcube Dongle SDR are being used as the receiver.
The GQRX side of the dashboard shows the downlink frequency which tracks the uplink frequency of the VFO on the IC-705. This will ensure that the Funcube Dongle Pro+ SDR receiver will always be on the correct downlink frequency relative to the uplink frequency, thus I should always be able to hear my own signal coming from the QO-100 satellite.
Once taken out of QO-100 mode the two radios can be used independently on any of the HAM bands and can be switched using the buttons on the dashboard.
I also coded in a simple memory facility where a frequency can be stored in Node Red and recalled later on both the transmit and receive sides.
Looking at the dashboard it all looks simple and straight forward however, if you look at the Node Red flow it becomes obvious that this isn’t the case.
QO-100 Dashboard Flow in the Node Red Editor (Click for larger image)
There’s a lot to the flow to get the information from the receiver and transmitter so that it can be presented on the dashboard. There’s also some code to convert between Rigctl protocol used by the GQRX application and XMLRPC used by the IC-705 via FLRig and WFview. I had to also code around a bug in the Node Red XMLRPC node whereby you have to add 0.1 onto the VFO frequency for it to be passed onto the radio otherwise the information is never sent. This was a real pain of a bug to find but, with a little experimentation I found the problem and managed to code around it. The strange thing about this is that the 0.1 added onto the frequency isn’t actually passed onto the radio via the XMLRPC node, it just has to have that on input otherwise it doesn’t work at all. A very strange bug and hopefully one that will be fixed by the node developer in future releases.
All that is left to do now is add the temperature sensors dashboard to complete the dashboard. These haven’t arrived yet and so I’ve not been able to create the necessary flow to collect the data from them.
Hopefully this coming week the weather will improve and I’ll start getting the dish antenna up and the get the receive side working.
UPDATE: Further development of my QO-100 Dashboard has taken place, you can read all about it here.
Whilst I’ve been waiting for the weather to improve so that I can get my QO-100 dish antenna up I’ve been working on my QO-100 Node Red dashboard.
The idea of the dash board is to bring together the operating of the receiver and transmitter into one control centre so that the two separate devices are able to communicate and behave as if they were actually one device, like a transceiver rather than being individual components.
Ideally I would like to have the transmitter and receiver talking to each other such that when the VFO on the transmitter is incremented/decremented the receiver VFO also moves by the same amount.
By doing this the receiver VFO should always be in the right place on the 10Ghz band to hear my 2.4Ghz uplink signal and of course, any station coming back to my CQ calls.
So far I’ve only been working on the receive part of the Node Red flow, it’s certainly been a lot of fun getting it put together.
I control my Funcube Dongle Pro+ (FCD) using GQRX SDR on my Kubuntu PC. This software is working extremely well with the FCD and I’m happy with the level of functionality it offers.
GQRX SDR has the ability built in to control the SDR via remote TCP connection using RIGCTL protocol. Currently there isn’t a RIGCTL node available for Node Red so I have written a number of Javascript function nodes that provide the appropriate functionality in conjunction with a standard Node Red TCP node. This is working extremely well on the local LAN in the radio room and is proving to be very stable and responsive.
M0AWS QO-100 Node Red Flow – Receive Section
The flow for the receive section of the dashboard looks fairly complicated but, in reality it’s really not too difficult to get to grips with. The receive flow provides the facility to switch bands, switch modes, change receiver filter band width, display a realtime signal strength meter, receive +/- clarifier in 10/100/1000Hz increments and put the receiver into QO-100 mode where the SDR VFO is tuned to 739.550Mhz whilst the dashboard VFO shows the QO-100 downlink frequency in the 10Ghz band. This is all working very well and I’m happy with the initial result.
M0AWS QO-100 Receive Dashboard in QO-100 mode
I now need to start work on the transmit side of the QO-100 dashboard and get communications between my IC-705 transceiver and the FCD SDR working via Node Red. This could be a little more challenging as it will involve communicating with the IC-705 via WFView over wifi.
Following on from my initial article on plotting realtime WSJT-X decodes on a Node Red map I’ve made a few enhancements to the flow so that it includes even more data then before.
The additions to the flow now enables collection of status information from WSJT-X so that the flow is able to capture the frequency that the radio is tuned to and also the mode that WSJT-X set to. Neither of these two bits of data are in the decode message payload and so a separate mini-flow has to be created to collect the data from the status payload along side the other main flow.
Node Red flow showing additional sub flow in the top left corner of the flow editor screen
Since the status information needs to be available to all other flows I used flow variables to store the status information in so that it can be addressed directly from any of the other flows in the Node Red app.
If you’d like to use the flow in your radio room then I have put a download link below for a file that you can import into Node Red and build the flow in an instant.
Following on from my previous article on Enhancing Digital modes with Node Red I’ve now got to a point where I have realtime decode information from the WSJT-X digital application being plotted on a Node Redworld map not just for CQ calls but, for stations in conversation too.
The flow has become somewhat more complex than it was originally as more and more functionality has been added. I have deliberately split out the flow process into more nodes than are really necessary so that the flow is easier to understand. Anyone from a programming background like myself will soon realise that a lot of the nodes could actually be combined into one big node however, the overall flow process wouldn’t be so easy to understand for the Node Red newcomer and would possibly put people off from trying it out.
Current WSJT-X Node Red flow
Above is a screenshot of the flow as it currently stands. It’s pretty easy to understand what is happening in the flow due to the fact that the processes are broken out into small, easy to digest blocks.
From the top down we connect to WSJT-X via UDP port 2237 and listen for the data stream. As the data is received it’s passed directly into the WSJT-X-Decode node that converts the information into a Node Red compatible format. The data is then filtered with only the information required being passed onto the next node. There are two outputs from the filter node as we require two different streams of information, namely “CQ” and “TX1” data. All the rest of the data from WSJT-X is ignored as it’s not required at this time.
The “Get freq & SNR + Others” node builds a decode message payload with all the correct data, in the right format ready to be passed on along the flow. This node also sets a number of parameters required by the map node to be able to control the display of the data.
The next node along is “Set msg.payload”, this brings together all the necessary data into a single message payload that is then worked on by all the nodes further along the flow.
The next 3 nodes perform the simple task of moving some of the data into the objects defined by the world map node, if the data isn’t moved into these specific objects the map will not plot anything.
Now we get onto the slightly more difficult bit that might put off those who aren’t from a programming background. The next 7 nodes are all javascript functions which I have created to perform tasks that cannot be done via the standard Node Red pallet.
At this point it’s worth noting that I’m not a javascript programmer, I’ve used Python, Rust, Go, C and many other languages during my 40 plus year career but, javascript has never been one of them. I’m sure any seasoned javascript programmer will most likely raise an eyebrow at my attempt at javascript programming but, you need to remember that I’m doing this in my retirement and my enthusiasm for learning yet another programming language has wained somewhat!
So, getting back to the flow, each javascript function does just one task each of which is as follows:
Set rx_time – Sets the time the data was received/processed
Remove RR73 in tx1 – Remove decodes where RR73 is in TX1 instead of a valid callsign
Set Dynamic Icon Colour – Sets the icon colour depending on what type of call is decoded
Maidenhead to LON/LAT – Converts Maidenhead locator codes into LAT/LON Coordinates
Calc Distance – Calculates the distance between “My QTH” and the DX station
Calc Bearing – Calculates the bearing/beam heading to the DX Station from “My QTH”
Generate Search URLs – Generates the URLs for QRZ and my own online log lookups
Editing the Calc Distance function with debug info in the far right panel
Once all the functions have run the resultant data set is forwarded on to the WSJT-X Stations Map node where it is plotted real time on a world map.
To view the map point your web browser at your PC running Node Red as follows:
http://radiopc.your.domain:1880/worldmap/
Or if you haven’t got a DNS setup at home then just use the IP Address of the PC instead:
http://192.168.100.10:1880/worldmap/
Don’t forget that for all of this to work you must configure WSJT-X to send data via UDP on port 2237 otherwise the flow won’t be able to connect and listen for the decode data.
You may have noticed that there are 3 other nodes that I haven’t mentioned yet. The two green greyed out nodes are Debug nodes that can be enabled when required to help see what is going on in the flow. These debug nodes will display data in the debug panel on the right of the flow editor screen when they are enabled, they are extremely useful for debugging!
The third is the blue My QTH node, this contains data pertaining to my QTH that is plotted on the map using an orange icon. You can easily edit this node to point to your QTH instead.
WSJT-X Node Red map showing orange icon denoting my QTH
Once the flow is deployed you’ll be surprised how quickly the data starts to be plotted on the map. Stations calling “CQ” are shown by Green icons and stations that are in a QSO with another station are denoted by the Red icons.
Each icon is clickable and will present all the information collected by WSJT-X for each station viewed.
WSJT-X Node Red World Map showing FT8 stations realtime on the 12m Band
The popup also has two clickable entries, one will take you to the qrz.com page for the station being viewed and the other will search my logs to see if I have worked that station already and if so it will open a new tab showing the information.
Node Red Function Editor showing the Generate Search URLs function
You can edit the “Generate Search URLs” node so that it points to your online logs search engine so that you can view your own log data instead of mine.
Below is a close up of the popups that are displayed when each icon on the map is clicked. The popups show the information collected from WSJT-X for each station plotted on the map.
Left – Green “CQ” Popup and Right – Red “TX1” in QSO popup
If you fancy trying this out for yourself but, don’t fancy creating all the nodes in the flow manually then I have made an export of the flow available for download. All you have to do is download the file, unzip it and then import it to Node Red and you’ll have everything built ready to play with.
For a couple of weeks now I’ve been playing with Node Red to add functionality to my digital mode applications.
To get to know how it all works I initially used Node Red to create a series of dash boards for my servers and virtual machines to show realtime information on CPU temperature, CPU load, memory usage and storage etc.
Node Red Flow to collect information from a virtual machine (VM)
This worked very well and I was soon able to generate the information I needed in a palatable format. This was a great way to get to know Node Red flow building and introduced me to using gauge and graph nodes in flows.
The resultant Node Red Dashboard for one of my Virtual Machines
Once I had mastered creating dashboards for servers/virtual machines (VMs) I then started to investigate using Node Red to plot data from WSJT-X on a map.
I currently use the PSKReporter website to see stations that I hear on a map as WSJT-X sends the data to the site automatically however, this information is always 5mins or more old. For some time I’ve been wanting to see the information realtime as it is received and so I was hoping to be able to achieve this via Node Red.
Node Red has nodes available for a multitude of applications all easily installed via the Manage Palette menu in the flow editor.
I installed the WSJT-X Decode and World-Map nodes and set about building a flow to capture the data and plot it on a world map.
Building a Node Red Flow to decode WSJT-X data and plot it on a World Map
Putting the building blocks of the flow together is fairly straight forward and easily achieved using the excellent flow editor built into Node Red.
I configured WSJT-X to make the decode data available via UDP on port 2237 and then started the flow by creating a UDP node that connects to WSJT-X using the same port. The data immediately started flowing and I could see the information via a debug node.
I can’t stress enough how useful debug nodes are in Node Red. You can add debug nodes onto any output on any other node to capture the data as it flows. This gives you the ability to check what you’re getting is what you expected and also to see the format the data is in. The debug data is displayed in the debug panel on the right of the flow editor in realtime and gives you a great view of what is going on in your flow.
I decided to start with capturing the data for stations calling CQ as this was easily identifiable in the JSON object coming out from WSJT-X.
Passing the output from the WSJT-X-Decode node into a switch node I added a rule that filtered out data containing “type: “cq” and passed it onto the next switch node that created a payload consisting of the station callsign, maidenhead grid square and type so that it could be passed onto the next node for processing.
The next node in the flow is a function, this is where it gets a bit tricky. To be able to plot data on the map we need the Lat/Lon coordinates of the station making the CQ call. Since WSJT-X uses maidenhead locator data I needed to convert this to Lat/Lon coordinates before passing the data to the map node to be plotted.
Since Node Red is written in Java all the functions have to be written in javascript. The problem here is that I am not a javascript programmer and so this meant I’d need to learn yet another programming language. Unfortunately Node Red doesn’t allow functions to be written in C, Rust, Go or Python, all languages that I know well and after retiring from over 40 years in the UNIX/Linux/IT world my enthusiasm for learning yet another programming language has wained somewhat.
Being so close to having a working solution I pressed on and after much head scratching I finally put together some javascript that converts the maidenhead locator information in to good old fashioned Lat/Lon coordinates. I’m sure a seasoned Javascript developer wouldn’t be impressed with my code but, it works and does what I need and so I’m happy with it for the time being.
WSJT-X FT8 stations calling CQ on the 60m Band plotted on a Node Red World Map
Once I had the location information converted it was just a matter of passing the data to the world map node in the correct format for it to be plotted realtime.
As you can see on the screenshot of the map above, it worked extremely well with stations popping up as they were decoded by WSJT-X.
I now need to refine the data sent to the map so that it shows the frequency the station is calling on, the time they made the CQ call and the mode (FT8/FT4 etc) being used.. I would also like to add the distance from my QTH to the station calling CQ to round the information off however, this will mean writing another javascript function which, I’m not sure I want to dive into just yet.
I also need to add into the mix stations that aren’t calling CQ but, who’s callsign and grid square are passed on from WSJT-X. This will mean I will then be able to add to the map those stations that are actively working other stations and maybe I might even be able to show a line between the two stations that are in QSO.
This has been a fun but, steep learning curve however, it will certainly add some great functionality into my radio room and enhance my radio HAM addiction even further.
Many years ago I purchased a Funcube Dongle Pro+ (FCD) SDR. Since it’s arrival it has just been stored in my “Get round too it” drawer.
It’s been many years but, today is the day it comes out into the light and finally gets powered up.
Funcube Dongle Pro+ USB SDR
I’m hoping to be able to use the FCD as the receiver in my QO-100 satellite ground station setup.
The output from the 10Ghz dish mounted LNB is around 739Mhz, well within the FCD receiver range of 150khz to 2Ghz. This will save me from having to transvert from 739Mhz to 430Mhz (70cm band) on the receive path.
This will also give me full duplex operation as I will use my Icom IC-705 on the 2m band (144-146Mhz) to drive the 2.4Ghz transverter for the satellite uplink whilst listening to my own signal via the 10Ghz downlink fed into the FCD.
Before I can even start to build the QO-100 satellite ground station I need to get to grips with the FCD, get the software installed, configured, resolve audio routing via virtual audio cables and get it decoding FT8/JS8/WSPR etc.
Checking the Ubuntu repo’s I found that GQRX v2.12 is available for installation.
sudo apt install gqrx-sdr
Once installed I fired up GQRX and set about configuring it. Initially it appeared to have automatically detected and configured the FCD however, when I started the FCD the software ran for 5 seconds and then just hung.
Diving into the configuration settings I found that the FCD actually appears twice in the list of available devices and all I had to do was select the other one in the list and start the software again and all was well.
I connected my 20m Band EFHW Vertical antenna and trawled up and down the band. The receiver performed well even with fairly strong signals so, I spent some time listening to a few of the stations coming in from the USA.
Next I wanted to sort out the configuration for digital modes. I already have a couple of virtual audio cables in the form of loopback audio devices configured on my Kubuntu PC as this is how I connect the audio between WFView for the IC-705 and WSJT-X/JS8CALL.
Sadly, GQRX doesn’t recognise the loopback audio devices that already exist and so I had to do a little further research to get to the bottom of the issue.
Digging deeper I discovered that GQRX requires loopback audio devices created using Pulse Audio and not the kind I had already created at the O/S level. A quick read of the pactl man page and some further searching online I found all the info I needed to create the correct kind of loopback audio devices.
Two commands are required to create the pulse audio server audio loopback devices:
Once I’d created the loopback audio devices I was able to select the gq2jt devices in both GQRX and WSJT-X/JS8CALL so that the audio was routed correctly.
GQRX SDR and WSJT-X working with the Funcube Dongle Pro+
The overall solution works well and doesn’t put much load on the CPU of my Kubuntu PC, leaving plenty of horse power for me to do other things at the same time.
So I now have the Funcube Dongle Pro+ working perfectly on my Kubuntu PC, all I need now is a 1.2m dish, a 10Ghz LNB and some high quality coax cable.
UPDATE: I decided to leave the FCD connected to the 20m Band EFHW Vertical overnight and monitor FT8 on the 40m band. The EFHW antenna isn’t anywhere near resonant on the 40m band and so I thought it would be interesting to see how well the FCD performed on a completely non-resonant antenna.
To my surprise it did exceptionally well, stations from all over the world were heard with ease, the FCD really is an excellent little SDR receiver.
Map showing stations heard on 40m Band FT8 over night 16/17 Jan 2023
If you’re looking for a relatively cheap but, effective receiver for FT8/WSPR monitoring then I can highly recommend the FCD. If paired with a RaspberryPi then it would be a really cheap to purchase/operate solution for any HAM operator or short wave listener (SWL).
I’ve now added my JS8/JS8CALL logs to the website for both QRO (25w Max) and QRP (<10w) QSOs.
The JS8 logs are available from the Logs menu above.
I’ve updated the adi2html program to now be capable of processing the JS8CALL log file and will be releasing it into the public domain soon.
M0AWS QRP JS8 Online Log
More soon …
We use cookies to ensure that we give you the best experience on our website. If you continue to use this site we will assume that you are happy with it.Ok
