I’ve recently built a new AllStarLink (ASL) node for my MB7IBW gateway that I have recently brought up on air on the 2m band.
AllStarLink 3 has a lot of changes in it when compared to the previous version and this of course impacts my Node-Red Control Dashboard that I’ve been using to manage my first ASL node for well over a year now.
To build the node I used the RaspberryPi imager and added the AllStarlink 3 image as detailed on the allstarlink.org website.
Installing the system this way makes it pretty easy compared to previous installs but, it comes with some quirks which cause issues with Node-Red.
From the outset the plan has always been to have AllStartLink 3 and Node-Red running on the same Pi4 to keep it totally self contained. This was easy enough to achieve and works without issue.
Node-Red Control Dashboard for AllStarLink 3
Installing Node-Red onto a Pi4 is really easy and is fully documented on the Node-Red Website.
Once the AllStarLink 3 operating system was installed on my SD card, booted and operational I installed Node-Red. I soon realised that there were a few things I had to do before loading the Node-Red flow.
AllStarLink 3 no longer logs connect and disconnect messages in the connectlog like it did in AllStarLink 2. To get logging working again I had to create two new BASH scripts as detailed below and put them into /etc/asterisk/myscripts.
For the connect information I created the BASH script as detailed below.
Next I disabled the temporary filesystems that are used by default for the apache and asterisk logging as it’s useful to keep the apache logs for debugging and I needed the asterisk logs for the Node-Red dashboard.
Disabling the temporary file system is very easy to do, just edit the /etc/fstab and comment out the two lines as shown below.
# Comment out the next line for persistent Apache logs
#tmpfs /var/log/apache2 tmpfs defaults,noatime,nosuid,nodev,noexec,mode=0775,size=32M 0 0
# Comment out the next line for persistent Asterisk logs
#tmpfs /var/log/asterisk tmpfs defaults,noatime,nosuid,nodev,noexec,mode=0775,size=32M,uid=102,gid=106 0 0
# Note: These lines are wrapped, should be on 1 line in the /etc/fstab
Once the entries in the /etc/fstab were commented out I rebooted the Pi4 to get persistent filesystems.
The final thing that had to be done was to allow user repeater to use sudo without a password so that it could be used to perform reboot/shutdown/process restart as user root from within the dashboard.
# /etc/sudoers
# Allow repeater sudo without password
repeater ALL=(ALL) NOPASSWD: ALL
Once this was all done I imported the Node-Red flow, configured the SSH nodes with login credentials for the Pi4 (important to use the user repeater for SSH), clicked deploy and the dashboard was ready for use.
Node Red AllStarLink3 Control Dashboard Flow
I’ve been using the dashboard for a few weeks now and it’s running perfectly, without error.
If you want to build your own Node-Red Control Dashboard for your AllStarLink 3 node then, just download the flow using the button below and import it into your flow editor.
I’ve spent some time this afternoon modifying my Node-Red Dashboard for controlling AllStarLink nodes to work with the new AllStarLink version 3.
My original AllStarLink Control Dashboard was designed to work with AllStarLink 2 which I have running on an old RaspberryPi 3b on the 70cm band. The dashboard has worked reliably ever since deployment and is in use daily.
With the release of AllStarLink 3 and all the changes that it entails I’ve had to make a few changes to the dashboard flows in order to make it compatible with AllStarLink 3 nodes.
This entails not only flow changes but also the addition of two new bash scripts that are called by Asterisk to log connect and disconnect messages as they are not logged by default any more. (Seems a bit of a step backwards)
Node-Red AllStarLink Control Dashboard v3.0 for ASL3
The changes also entail disabling the temporary filesystems used by default in the new ASL3 build so that log files etc become persistent.
I’ll spend some time using the new dashboard to ensure it’s working correctly and then will release it into the wild for all those that are brave enough to move over to AllStarLink 3.
The articles I write for the blog are mostly technical but, I thought it was about time that I wrote this article as it’s been buzzing around inside my head for some time now.
So, what are the 5 things that I have found revolutionary in my shack that have brought new, exciting ideas and projects to life making amateur radio more enjoyable.
1: A RaspberryPi Single Board Computer
RaspberryPi 5 Single Board Computer
Ever since the first RaspberryPi Single Board Computer (SBC) was released I’ve been a huge fan. This little credit card sized number cruncher has been the base for so many projects, it has to be the first on my list.
The RaspberryPi SBC has been through a few iterations since its initial conception and is now powerful enough to take on most tasks that any radio HAM is going to throw at it.
So, what have I done with them?
Well I’ve used them to run Node-Red services for my many web app dashboards that control things like my QO-100 Satellite Ground Station, UPS power monitoring, Internet speed graphs, server and virtual machine monitoring, AllStarLink nodes, hosting websites, building an SDR shortwave receiver, running HAM Clock / Open HAM Clock, developing my own software, hosting virtual machines and a whole host of other fun and interesting things. I’m even writing this article using my RaspberryPi 500+ computer that is my daily desktop PC.
There are an endless number of things you can do with a RaspberryPi to bring new life and functionality to your radio hobby.
Want to get into Amateur TV? Want to decode digital modes real time? Want to track aircraft in the sky real time on a virtual radar screen? Want to search the shortwave bands for stations of interest? Want to host your own blog and website?
All these things and a lot more are easily within reach with a RaspberryPi.
The RaspberryPi is only limited by your imagination, the more imaginative you are the more your number crunching little friend will do.
2: A 3D Printer
Bambu Lab A1 Combo 3D Printer
Every HAM should have a 3D printer. These manufacturing marvels bring a new level of quality, design and simplicity to your HAM radio projects. I’ve found it incredibly useful since venturing into the rabbit hole that is 3D printing. When I think back to the weeks and months of my life I’ve spent making cabinets and boxes out of sheet metal, aluminium or wood for the numerous projects I’ve built over the years, a 3D printer would had made my life so much easier. 3D printing has revolutionised the making of things for the Amateur Radio home brewer.
There’s a multitude of useful things on websites like Printables, Thingiverse , Makerworld and others where you can just download the files and print high quality designs for all those things you’ve wanted to do but, don’t have the time or inclination to craft by hand.
The real satisfaction with 3D printing comes from designing your own things and making them. My first project was to design and print a fan cooling system for my Xiegu XPA125B amplifier.
From the factory the amp is passively cooled and doesn’t take long for the heat-sink to become saturated resulting in a high operating temperature. I was never happy with this and so was determined to resolve the problem.
Getting to grips with TinkerCAD was a bit of a vertical learning curve but, after a few mistakes and design mishaps I soon had it under my belt and pressed on with designing the cooler unit.
Designing the Xiegu XPA125b cooling system using tinkerCAD.
It’s not until you start designing and manufacturing things that you suddenly realise how much effort goes into them but, I persevered and over the period of about a week or so I had a perfectly fitting, operational cooling system that kept the amp super cool regardless of how long I waffled on for on the HF bands.
Once you’ve got your first design made you suddenly find yourself wanting to improve it and add things. In my case this was adding a Hermes Lite 2 holder to the top of the amp cooler and then a top shelf to hold my cross needle SWR and power meter.
Since then I’ve progressed massively with my designs and have even designed and printed things for other HAMs and family members, it’s totally addictive!
I can highly recommend the Bambu Lab A1 Combo (As shown above). It’s a quality piece of equipment that has operated faultlessly since purchase. Right now it’s printing a case for my RaspberryPi 4, just one of the many projects I’ve used it for since becoming a happy owner.
RaspberryPi 4 case from printables.com
Go on, release your inner creativity and treat yourself to a 3D printer, you won’t regret it and it’ll help you bring to life all of those radio projects you’ve dreamt of doing but, never got round to starting.
3: An AllStarLink Node
M0AW AllStarLink Node 61928 sitting on the equipment rack
Many people say that using VOIP over the internet isn’t real radio, I know because I used to be one of those people however, it has become an invaluable resource for keeping in touch with people all over the world.
Being part of an online HAM Radio Community it’s important that as a group we are able to talk to each other regardless of where we live, what bands we have access to and whether there is any propagation.
The AllStarLink (ASL) network gives global FM quality audio no matter where you are in the world. We use it daily for our breakfast net, general chatter throughout the day and even hold a weekly Matrix ASL Net on a Thursday evening.
Using our VHF/UHF handhelds (Real Radios!) and an easy to make AllStarLink Node we’re able to join in with the conversation regardless of propagation, licence type or distance, it really is great for bringing people together.
With devices like the SHARI and AIOC board now being readily available for minimal cost it really is very easy to get onto the AllStarLink network and talk to people even if you live in an antenna restricted location.
Why be alone when you can use the Matrix ASL node ( 642332 ) and join in the conversation.
4: Node-Red
M0AWS – Updated NodeRed QO-100 Dashboard with PTT button
Node-Red is a low-code programming tool for event-driven applications.
Node-RED’s goal is to enable anyone to build applications that collect, transform and visualise their data; building flows that can automate their world. Its low-code nature makes it accessible to users of any background, whether for home automation, industrial control systems or anything in between.
I’ve been using Node-Red for a number of years now and have developed a suite of web app’s that control and monitor just about every aspect of my Amateur Radio hobby and IT infrastructure.
Node-Red forms an integral part of my QO-100 Satellite Ground Station providing control of both the uplink and down link radios whilst synchronising the VFO’s, controlling filter selection and more, all from one simple to use interface using nothing more than a web browser.
It doesn’t stop there, my AllStarLink (ASL) nodes are also managed through a user friendly Node-Red Dashboard that removes all the need for technical know how and makes ASL node management as simple as clicking on a button to connect or disconnect to the many global networks.
Much of this functionality is achieved without writing a single line of code. If you can use a mouse, drag and drop objects on the screen you can develop Node-Red web app’s, it really is that easy.
M0AWS Interactive Log Flow
It doesn’t end there, Node-Red is great for presenting data in easy to digest formats.
Whether it be HAM Radio Log data presented on an interactive world map or monitoring of your server, RaspberryPi, virtual machine or UPS using gauges and graphs, this can all be achieved easily with nothing more than a mouse. There’s no need to spend hours writing thousands of lines of code, just drag and drop a few nodes onto the screen and join them up. You’ll be amazed how easy it is.
I believe every Amateur Radio enthusiast should have Node-Red available in their radio shack. It’s easy to install on your RaspberryPi 4 or 5, Linux or Windows PC and Apple Mac with the same great functionality available on all platforms.
Once you’ve developed your first web app you’ll suddenly find a million more ideas will come into your head and before you know it, you’ll be where I am today with Node-Red at the centre of your radio hobby.
5: A Hermes Lite 2 HF SDR Transceiver
For years I used black box HF radios from the big 3 manufacturers along with the odd radio from the smaller enterprises like TenTec but, they all had their foibles and there was often nothing I could do about it.
My last acquisition from the big 3 was a Yaesu FTDX10, a competent hybrid SDR radio with a good receiver however, the menu system is terrible, the button layout not much better and the user experience not as good as it could be. Of course the software is closed source so there is nothing you can do about it. The radio did its job but, it wasn’t fun to use, it wasn’t what I really wanted and it didn’t put a smile on my face.
I looked at moving to software defined radios (SDR) but, with prices in the many thousands of pounds bracket and the software being closed source I came to the conclusion that they wouldn’t give me what I really wanted either.
So what was it that I was searching for?
Thinking long and hard about it I came to the conclusion that what I really wanted was a radio that gave me the same satisfaction that OpenSource software has given me for decades, namely an HF radio that I have complete control over, from the hardware through to the software and everything in between.
I wanted something that I could tailor to my exact needs. Something that was built using open hardware and open software, something where if I wasn’t happy with it I could change it, improve it and do the things I wanted with it.
At this point my search for the ideal radio headed in a completely different direction.
Xiegu XPA125b Cooler with Hermes Lite 2 cradle – front view
The Hermes Lite 2 SDR HF Transceiver (HL2) has been around for a number of years. I was first introduced to it by Michael, DK1MI and then Roger, G8VLR via the Matrix. Both Michael and Roger use the HL2 on a regular basis and have often waxed lyrical about how good it is.
Being designed by radio amateurs for radio amateurs it’s based on an open architecture from the ground up. Being an OpenSource junky this really appealed to me and as I looked deeper into it from both a hardware and software point of view I soon realised that it had the potential to be exactly what I was looking for.
It wasn’t long before I found myself on the Makerfabs website placing an order for the HL2 mainboard, filter board, I/O board and case. A couple of weeks later it arrived and I dived head first into the SDR rabbit hole.
2 years later and the HL2 has become my main HF radio in the shack. Partnered with a Xiegu XPA125B amplifier and PiHPSDR software running on my Kubuntu Linux PC it is everything I have been looking for in an HF radio.
I’ve made modifications to the software to suit my operating style and needs with the user interface being exactly how I want it, no unnecessary buttons or knobs, just the controls that I use on a daily basis cleanly placed in a logical, easy to use layout, the way I want it.
My understanding of software defined radio and how it works has improved a hundred fold. Having access to the software and being able to go through the code and understand the architecture has been an interesting journey and one that has enhanced my radio enjoyment considerably. I now have a smile on my face every time I go on air.
Do I miss the FTDX10?
No, not in the slightest!
So, those are the 5 things that I feel have revolutionised my radio amateur hobby and made it a more enjoyable experience. I’m sure over time I will add to this list as I venture down future rabbit holes in our wonderful radio hobby.
For some time I’ve wanted a full duplex 2m/70cm handheld so I could have a go at working the LEO FM satellites during the summer months from the garden.
Searching through all the handhelds available today I came across the Wouxun KG-UV9K dual band, full duplex VHF/UHF radio.
Since I already own a Wouxun KG-UV980PL Quad bander (6/4/2m & 70cm) I’m familiar with the menu system and the very good build quality so I decided to research it further.
Wouxun KG-UV9K Full Duplex Handheld
Looking at the spec for the handheld it does everything I want and more whilst being reasonably priced.
Jumping onto the Martin Lynch and Sons website I found there were two listings, the radio on its own or the “Pro Pack”.
The radio on its own was £79.00 but, the Pro Pack was only £20 more at £99.00 and came with every option available for the handheld including a programming cable, 2 batteries and a rather nice carry case.
Wouxun KG-UV9K Pro Pack
The full specification and other details for the “Pro Pack” can be found on the ML&S website but, here’s a brief summary:
Pro pack contains:
KG-UV9K Transceiver with 2 antennas
Two batteries Two belt-clips Software and transfer data Cable Fast charger dock and Power Supply Hand speaker mic Battery eliminator Manual Wrist strap Leather case In-car charger SMA-SO239 adaptor Hands-Free kit
Like my Wouxun quad bander the handheld can also be configured as a cross-band repeater, something I’ve not yet found a use for but an interesting feature. Of course being a full duplex radio with two receivers you can listen to signals on 2m and 70cm simultaneously or transmit on one and listen on the other, a feature I’ve wanted for LEO satellite operations.
The radio is really easy to programme using CHIRP and easy to setup via the very logical menu layout. The hand held has a good solid feel to it and I’ve found the battery lasts a good 3-4 days even though I use it to chat with other stations via my AllStarLink node most mornings and the radio is left monitoring all day.
The larger of the two supplied antennas works extremely well having a relatively good gain. I can now easily get into my two local repeaters on 2m & 70cm from within the house, something I’ve never been able to do with my old Retevis RT85 even with a high gain antenna on it.
The receivers in the UV9K are head and shoulders better than that of the Retevis RT85, I’m hearing signals much stronger now and can even get into repeaters that I’ve never even heard on the old Retevis handheld.
The display on the Wouxun is bright and easy to read, even in bright sunshine which is great as I plan to use it outside a lot during the summer months.
The supplied speaker mic gets good unsolicited audio reports on transmit and has clear audio on receive with plenty of volume. The speaker mic doesn’t have any radio control buttons on it sadly, something I really like about the Wouxun UV980PL quad bander as you can control every aspect of the radio without touching the front panel. Would be a nice upgrade for the handheld if it every became available.
Overall I’m really impressed with the Wouxun UV9K Pro Pack. The radio performs very well, comes with every optional extra available and is a bargain at just £99.00.
If you’re looking for a full duplex handheld radio then I recommend you grab the Pro Pack before the offer ends.
Following on from my previous article on using Node-Red to build interactive log maps I’ve now reworked the flow to make it more efficient with less Javascript.
The original flow had a function that handled the issue of FT4 contacts being recorded in two different ways depending on which app you use for your FT4/8 operations.
<mode:4>MFSK <submode:3>FT4
or
<mode:8>MFSK FT4
The code I wrote to handle this wasn’t particularly elegant and so I decided to remove the code entirely and just use a simple change node.
M0AWS New node to handle FT4 more efficiently
This is the great thing about Node-Red, there’s always more than one way to do something.
With this fix in place and the old code stripped out of the format generic payload function, the new flow is much tidier and easier to comprehend.
M0AWs Updated ADI Log Map flow
With testing complete and the two maps now live on my website the flow is finally ready for release into the wild.
If you fancy presenting your ADIF logs in a more visual, interactive format then just download the flow below and import it into your Node-Red flow editor.
Don’t forget that you will need to change the path to the log files in the file read nodes to suit your setup and change the location data in the My QTH trigger to match your callsign and location. Other than this the flow should just work.
I’ve not been on the radio much over the last few weeks as I’ve had my head down other radio related rabbit holes.
One of the rabbit holes is a Node-Red project to make my online logs a little more interactive. For sometime now my logs have been displayed on my website as nicely formatted, searchable HTML pages however, they don’t really allow the viewer (myself included) to see the global coverage of all the contacts so, I decided to write a Node-Red flow that would do just that.
M0AWS Interactive Log Flow
The flow itself isn’t too complicated and basically consists of reading in the individual ADIF formatted log files, processing the data and then sending the data in the correct format to the map node for display.
I’ve had to write a few functions to handle the processing of the ADIF formatted data but, these aren’t particularly complex and are fairly easy to understand even if like me, you’re not a Javascript programmer.
The flow is working perfectly however, I’m in the process of reworking the format generic payload function to reduce the amount of code and make it more efficient.
M0AWS SSB / CW / FreeDV Interactive Log World Map
M0AWS Interactive Log Map Layers Menu
The flow generates two maps, one for voice / CW /Satellite contacts and the other for WSJT-X FT4/8 contacts. Every pin on the map is colour coded by band with satellite contacts being denoted by a satellite icon.
Each pin / icon on the map is clickable and reveals the data of the QSO being displayed.
In the top right-hand corner of the map there is a drop down layermenu that allows the viewer to filter by band thus reducing the number of icons on the screen at any one time.
Seeing the data presented on a map really brings my logs alive. An example of this is that I had no idea I’d worked so many stations in India on the QO-100 Satellite.
The small icons in the pins show a microphone for SSB/FM/FreeDV contacts and a downwards pointing triangle in a box for CW contacts. Sadly I couldn’t find a Morse key icon in the collection available.
M0AWS filtered view of QO-100 Satellite contacts
I only use FT4/8 for testing new antenna designs however, it’s interesting to see the global coverage accomplished with this weak signal mode.
M0AWS WSJT-X FT4/8 Interactive Log World Map
Once I’ve finished rewriting the format generic payload function I will make the flow available for download here so that others can also create an interactive view of their radio logs.
If you want to have a look at the maps and try them out for yourself, they are available under the Logs menu above.
This Node-Red instance is running in a virtual machine (VM) on a 16GB RAM RaspberryPi 5 that is also running a number of other VMs at the same time so, it’s safe to say it’s not heavy on CPU and will run on the older Pi4 as well.
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)
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)
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.
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
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
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.
Over the last few weeks I’ve been working on my install-pihpsdr script to build a version of the DL1YCF PiHPSDR fork that will work with the Adalm Pluo, Pluto+ and LibreSDR transceivers.
Since I don’t own any of these devices, Steve M0XVT has loaned me his Adalm Pluto and LibreSDR devices to test with.
Initially neither of the devices would work with the PiHPSDR build that my script was creating. After some investigation I found this was due to the fact that the developer build script was only building the SOAPYSDR library, it wasn’t building the modules for each device type.
This was easily fixed by adding some extra code that would build the necessary SOAPYSDR modules so that the devices were discovered on the local LAN.
Since I had the devices to hand I took the opportunity to test the updated build script on a number of Linux Distro’s that I have to hand.
PiHPSDR running on Linuxmint 22.1 Cinnamon Edition using the LibreSDR transceiver
I tested the updated build script on Kubuntu 22.04LTS, Linuxmint 22.1 Cinnamon Edition and RaspberryPi 4/5 running the latest RaspberryPi OS 64bit version.
These all worked great with the transceivers and will now make a great platform for QO-100 stations that use either the Adalm Pluto, Pluto+ or LibreSDR devices.
Of course this build of PiHPSDR will also work with the Hermes Lite 2 and RadioBerry devices that I use most of the time in my own radio shack.
The updated PiHPSDR install script can be downloaded from my original blog article on the subject that is located here: https://m0aws.co.uk/?p=3686
The updated build script will most likely work on most Debian based Linux distro’s and build a working version of PiHPSDR. If you find a distro where you have problems please email me and let me know the details and I’ll happily look at the issue and try to resolve it.
Thanks to Steve for the loan of his precious SDR transceivers, I had a lot of fun with them!
Regular readers of my blog will already know that I am a huge fan of the Linux operating system, it’s clearly evident in most of the content on this website.
I am also a very enthusiastic user of one of the first credit card sized computers that came to be, namely the RaspberryPi. I own all the iterations of this wonderful little computer from the very first version to the latest and greatest, RaspberryPi 5.
This little computer has done more for computing in education than Microsoft and Apple will ever achieve and it’s done it at an incredibly low price making it more accessible to schools, colleges and students than any other platform.
The RaspberryPi has what most consider to be the best support on the planet when it comes to single board computers (SBCs). From the dedicated team that build Raspberry Pi OS, to all the amazing projects and forums that are available, for free on the internet today.
The RaspberryPi computer really has revolutionised computing for the masses.
My RaspberryPi 5 that I am using to write this article.
Raspberry Pi OS really is very good. It’s based on the great Debian distro’ that many of us seasoned Linux users dearly love. It’s light weight, fast and meets the needs of everyone that is venturing into the exciting world of Linux and SBCs for the first time.
Overtime as we all become more experienced with Linux on the RaspberryPi we become more demanding and start to find the Raspberry Pi OS desktop environment lacking. Sure it can be enhanced by adding more and more to it however, it never quite reaches the point of satisfaction and we are always wishing for something more.
With the Pi-5, the latest iteration of this great credit card sized computer, users are now able to seriously think about building a more powerful desktop environment for their little berry flavoured computers.
On my desktop PCs dotted around the house I have used Kubuntu for decades. It’s a slick and powerful desktop environment that has met my needs for many years and I love it more than any other Linux desktop. Sadly Kubuntu isn’t easily available out the box for the RaspberryPi and so I decided that it was time to replicate it as closely as possible on my new, super powerful RaspberryPi 5.
When I ordered my RaspberryPi 5 from Pimoroni I added the NVMe base and 250GB M.2 SSD drive to the order. Up until now I’d always used SD cards however, they are slow and unreliable and so I decided that since the Pi-5 has PCIe it was time to take the step away from SD cards and start using SSD technology.
Getting the OS onto the SSD is a two stage affair. First you have to create a bootable SD card to boot the Pi-5 from and then use it via the RaspberryPi Imager to install the OS onto the SSD. It’s a bit long winded but, easy enough.
Since I’m a huge Kubuntu fan I decided my desktop of choice for my new Pi-5 was going to be KDE-Plasma. I had tried to install this desktop before on older model Pi’s however, it ran so slow that it was unusable. With the new Pi-5’s increased computing power and the speed of the SSD I was confident that this was now possible.
I started out installing the Lite version of Raspberry Pi OS on the SSD. This is a command line only version of Linux that doesn’t include any desktop environment, a nice clean slate to start from.
RaspberryPi Imager showing Pi OS Lite (64bit)
Once the Lite version of the OS was installed on the SSD I shutdown the Pi-5 and removed the SD card and then powered the Pi-5 back up again so that it booted from the SSD.
Upon booting I was presented with the simple Linux Login prompt. After entering my username and password as setup during OS install I landed at the Linux command prompt.
sudo su -
I used sudo to become root user as shown above and then set about building my new KDE based super computer. First I needed to update the operating system with all the latest patches and security fixes.
apt update && apt dist-upgrade
The update and upgrade process ran for a while but, it was soon complete.
reboot
I issued the reboot command and then logged back in again, I was now ready to start building the KDE desktop environment.
sudo su -
apt install kde-plasma-desktop gldriver-test
Becoming root again I type the command to install the KDE-Plasma desktop and the graphics-related config services. There’s a lot of packages to download and install so, I left it to do its thing.
A little while later all the packages were installed and ready to go. I now needed to tell the system to boot into the new graphical user interface instead of the command prompt using systemctl.
systemctl set-default graphical.target
Once this was done I needed to make a change to the display settings using the raspi-config program.
raspi-config
Selecting No.2 on the menu, Display Options and then D2 Screen Blanking, I disabled screen blanking so that I got the full 4K support for my KDE Desktop.
Once the system had been configured for a graphical user interface there was only one thing left to do and that was to shutdown the RaspberryPi.
shutdown -h now
The beautiful KDE-Plasma Desktop on RaspberryPi 5
Powering the Pi-5 back up again I was greeted by the standard KDE Plasma login screen and then, after logging in I was transported to the beautiful KDE desktop. I was now smiling like a Cheshire cat!
The KDE desktop is incredibly snappy on the Pi-5 with an SSD, app’s open instantly and run with minimum CPU exertion. It was now time to load the rest of the KDE application suite to complete the build. Popping open a terminal I hit the command line once more.
sudo su -
apt install kde-full vim yakuake vlc firefox rsyslog
This loads the full set of KDE applications adding just about everything you’ll ever need to the desktop environment. It’s about 1GB of packages and so depending on your internet speed it could take a while but, it’s well worth the wait.
Once complete you are ready to go with a fully functional, snappy, powerful desktop.
I’m extremely pleased with the performance of the Pi-5. KDE is super fast, snappy and responsive. With 8GB of RAM on tap the RaspberryPi has no problem with performance. The Pi-5 and KDE-Plasma really do make a great desktop computer at an incredible cheap price.
Looking for a new computer?
Add a cheap USB sound card and a pair of speakers and this little setup will meet the needs of 90% of the population with ease and go on to satisfy the more seasoned, demanding Linux user or programmer without breaking the bank.
(This information is also for the Hermes Lite 2, Adalm Pluto, Pluto+ and LibreSDR)
During my RadioBerry build I started out using the version of PiHPSDR that was created just for the RadioBerry. The problem with this is that it is hard coded for a very small screen making it hard to use on a big screen since the user cannot resize the window dynamically.
I decided to look for a forked version of the PiHPSDR software that had the ability to change the window size to suit all use cases. During my search I stumbled across the DL1YCF fork of the source code that has some enhancements, one of which is the ability to change the display size.
In no time at all I had the source code downloaded and compiled only to find that it didn’t work with the RadioBerry. After some investigation I found that this was due to the fact that the RadioBerry software has compiled into it code that is used to access the GPIO pins on the RaspberryPi so that it can communicate with the RadioBerry HAT. This is fine except that the DL1YCF version of PiHPSDR also has code in it to use the GPIO pins. This of course causes a conflict and the net result is that nothing works.
Reading through the source code and Makefile I found that all I needed to do was to compile a version of PiHPSDR without GPIO support. This would then remove the conflict and allow the RadioBerry software to operate correctly.
To this end I put together a download/compile/install script for the DL1YCF version of PiHPSDR that will work on a RaspberryPi with a RadioBerry HAT and give the ability to resize the window to fit any size screen.
The script also works on a Linux Desktop PC running Ubuntu/Kubuntu/Linuxmint/Debian operating systems. (It will most likely work on other distro’s too but, these are all I have to hand currently). You can of course also use this software with a Hermes Lite 2 transceiver.
DL1YCF PiHPSDR running on RaspberryPi 4 with RadioBerry HAT on a large monitor
To install this enhanced version of PiHPSDR on your RaspberryPi/Desktop PC with GPIO support disabled, download the installation script below, unzip it and run it in a terminal on your RaspberryPi/Desktop PC in your home directory. (/home/<your-username>).
The script will download the latest source code from the DL1YCF github, disable the GPIO code and then compile and install it to your computer. If installing on a RaspberryPi it will create an icon on the desktop for you to use to start the software.
If installing on a PC then you will need to create your own desktop icon as the one created only works on a RaspberryPi. You can of course just start the software from the command line in a terminal. (My preferred method).
If you have a RaspberryPi 5 then I highly recommend that you run this version of PiHPSDR on it as it has a lot more computing power and handles using dual receive with ease. It will run on a Pi4 but, you will load the CPU more as it’s not as powerful as the later model Pi5.
The script will ask if you want to compile in SOAPYSDR support so that PiHPSDR will work with RTL-SDR, Adalm-Pluto, Pluto+ and LibreSDR. Enter Y to compile in support or N if you don’t need it.
I hope this proves useful to all the RadioBerry, Hermes Lite 2 and Pluto users out there who want to use PiHPSDR on a big screen.
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.
