Trialing DeskHPSDR

For sometime I’ve been using PiHPSDR software to drive my Hermes Lite 2 (HL2) SDR transceiver. It’s a great piece of OpenSource software for SDR transceivers and has the best documentation that I have ever seen from an OpenSource project.

I must admit, I’ve had to make a few changes to get the software how I like it but, that’s the great thing about OpenSource software, you get the source code and can do what you like to it.

Following in this thread I recently decided to give DeskHPSDR a try.
DeskHPSDR is a fork of the original PiHPSDR but, with some changes mainly aimed at larger display computers.

After compiling DeskHPSDR on my Kubuntu Linux PC in the radio shack, I found there were a few issues, mainly the colours were hard on the eyes and band/channel markers wrong/missing on a few of bands.

DeskHPSDR default colour scheme on Kubuntu 22.04LTS (KDE-Plasma)
DeskHPSDR default colour scheme on Kubuntu 22.04LTS (KDE-Plasma)

I decided to dive in and take a look at the source code and try and sort out the colour issues as blue writing on dark buttons made them almost impossible to read under a KDE-Plasma desktop.

Delving through the appearance.c and css.c files I found that there were many changes required to get the end result I wanted. The biggest pain is that you have to recompile the source code after each change to see if the code change had worked, this results in many recompiles, a tedious task.

After spending many hours making changes I decided to email Heiko, DL1BZ who is the developer of DeskHPSDR. Over a number of emails we discussed getting the colour management code changed such that it was read in at start time from a separate css file rather than having to be compiled into the main program.

After a few emails back and forth, Heiko changed the code so that a separate CSS file could be read in at start up instead of the hard coded CSS in the C code files, this worked great and made it much easier to make colour changes without constant compilations of the code.

Next I needed to edit the bands.c file to change some of the band edge markers to show the UK band plan as, by default they are incorrect even though I have the region set to UK.

Editing the appearance.c file once more I was able to change the colour of the rather bright green panadapter signal display to a much more pleasing blue fading to red as the signal gets stronger.

One thing I really like about PiHPSDR was the channel markers on the 60m band. Anyone that uses the 60m band will know that the UK allocation is split into 11 different channels separated by spaces used by the primary user of the band. The channel markers make it just that bit easier to ensure you don’t stray out of the allocated channels however, this code had been removed from DeskHPSDR as Heiko didn’t consider it necessary.

Once again I pinged an email over to Heiko explaining how useful it is to UK HAMs and he very kindly put the code back into DeskHPSDR so that the 60m channels are once more clearly visible on the panadapter.

DeskHPSDR modified colour scheme on Kubuntu 22.04LTS (KDE-Plasma)
DeskHPSDR modified colour scheme on Kubuntu 22.04LTS (KDE-Plasma)

Feeling happy with the new colour configuration I decided to test it out on Linuxmint Cinnamon. Sadly the scheme that looked so nice under Kubuntu 22.04LTS didn’t look the same under Linuxmint and so I had to set about coming up with a version of the CSS file for this platform too.

After quite a few hours tinkering with CSS code I found it to be impossible to get the colour scheme on Linuxmint Cinnamon Edition identical to that I’d created under Kubuntu KDE-Plasma so, I settled for a look that was as close as possible.

DeskHPSDR on Linuxmint Cinnamon Edition with colour modifications.
DeskHPSDR on Linuxmint Cinnamon Edition with colour modifications.

Chatting with Steve, M0XVT we thought it would be a good idea to test it on his Kubuntu Linux and Linuxmint PCs. He is using a later version of Kubuntu than I am (24.04LTS) and so, it would be a good test to see if the colour scheme looked the same.

Sadly it turns out that for some bizarre reason the colours come out different in the later version of Kubuntu. This is a real nuisance as it means we’d need a separate colour scheme defining for each version of the O/S. Perhaps using CSS isn’t the best way to define a colour scheme in applications.

For some very strange reason the colours were also rendered differently on his Linuxmint PC even though he was using the same version of the O/S as I am.

DeskHPSDR running on Kubuntu 24.04LTS with colour scheme not rendering correctly
DeskHPSDR running on Kubuntu 24.04LTS with colour scheme not rendering correctly

Another issue was found whilst testing on Steve’s computers which seems to be caused by the fact he uses an Anan 200D SDR.

Looking at the documentation on github in theory DeskHPSDR should support the Anan range of SDR transceivers however, we found that it’s impossible to select the sample rate as the drop down selection list is completely missing from the Radio menu with the radio defaulting to its lowest sample rate of 48k resulting in not being able to see the full spectrum of frequency ranges on the bands.

DeskHPSDR Sample Rate drop down missing when using an Anan SDR
DeskHPSDR Sample Rate drop down missing when using an Anan SDR

The other thing to note is that the Remote Server functionality has also been removed from the code by Heiko as he feels it’s not necessary. This may be a deal breaker for some and so they may choose not to use DeskHPSDR and to continue using PiHPSDR instead.

I will at some point make the O/S specific CSS files and source code available for download for those that want to use DeskHPSDR with my colour scheme changes.

I’m not sure at the moment whether I will continue using DeskHPSDR or go back to PiHPSDR, time will tell.

More soon…

Realtime WSJT-X decode data map

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 Red world 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.


I’ll probably be adding more functionality to this flow as time goes on and will post further articles about it in the future.

More soon …