Compile – M0AWS Amateur Radio

16 July 202518 July 2025

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)

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.

More soon…

29 June 20257 February 2026

Rescuing a Bricked Pluto+

I’ve not written an article on the blog for a while now mainly because I’ve not had anything interesting to write about.

Today that changed, as I had a fun little project to dive into.

Steve, M0XVT sent me his Pluto+ SDR transceiver after his rather unsuccessful attempt at updating the firmware. Long story short, he somehow managed to brick the Pluto+ rendering it completely useless.

Not having a Pluto+ myself I’ve never actually played with one before and so this was new and exciting. I have, however played with Steve’s LibreSDR which is a later iteration of the Pluto+ and so, I had an idea of what I was getting into.

Firstly, how do you know when you have bricked your Pluto+?

Fortunately the Pluto+ device is actually quite clever and will inform you when it is bricked. The first sign you will notice is that you can no longer connect to the device using a USB connection to the data socket. The second sign is that when you take the top off the case you’ll notice that the blue LED is off and the green LED is on constantly. These are both classic signs that the device is bricked and needs rescuing

So, how do we rescue a bricked Pluto+?

Firstly, disconnect all cables and power to the device, it needs to be in a powered down state. Next remove the top of the case completely.

Unlike the LibreSDR the Pluto+ doesn’t boot from SD card so, we have to tell it that we want to boot it from an SD card. This is done by shorting the 3v3 and SD-H pins together using a jumper as shown in the photo below. (Black Jumper)

Pluto+ 3v3 and SD-H pins shorted together by black jumper

I believe that the v1 version of the Pluto+ has 1.8v instead of 3.3v, if this is the case on your device just short the SD-H pin to the 1v8 pin instead.

Next we need to make sure that the URST pin is connected to the MIO46 pin as shown by the green jumper in the image above. I put the jumper into this position as I am going to be using firmware that has ethernet support built in. If you want to load the official firmware then you will need to connect the URST pin to the MIO52 pin instead.

Next we need to load the new firmware onto an appropriate SD card. I’m using the F5OEO firmware that has ethernet support with DHCP built in. You can get the firmware from this Github link.

Whilst the firmware is downloading, insert your SD card into your PC and format it using a FAT32 filesystem.

Once the firmware has downloaded, unzip the file and save the contents of the zip file to a directory. Using your favourite file manager or in the case of a Linux junkie like me, the command line, copy the contents of the sdimg folder into the root of the SD card.

Note: That’s copy of the contents of the sdimg folder, not the folder itself.

Make sure to eject your SD card safely before removing it from your PC to ensure you don’t corrupt the contents.

Insert the SD card into the Pluto+ (it’s still powered down at this point with the top off).

Plug the USB A end of the USB cable into your PC but, do not plug the micro USB end into the Pluto+ just yet!

Now this is the tricky part, you need to hold down the DFU Button on the Pluto+ PCB (It’s behind the professor image on the PCB) whilst inserting the micro-USB plug into the DATA port of the Pluto+.

Once you see that the green and blue LED lights come on permanently, let go of the DFU Button and let the Pluto+ boot from the SD card. A short while afterwards the green LED should start flashing, this means your Pluto+ is alive again and has booted from the SD card.

At this point it’s important not to unplug the USB cable and not to remove the SD card from the device, we’re only half way there!

After a little more time the Pluto+ will appear in your file manager as a drive called PlutoSDR, navigate to this drive using your favourite file manager.

At the same time, open another window in your file manager and navigate to the folder where you saved the files from the Zip file. In this directory you will see the following two files:

boot.frm
pluto.frm

Copy these two files from the directory where you saved them into the root of the PlutoSDR drive.

Once this is complete, eject the PlutoSDR drive safely.

The green LED will now start blinking, don’t do anything, just leave everything as it is and the device will now create a new boot image on it’s own built in storage.

This process will take about 5mins so, go grab a cold beer, glass of wine or anything else that takes your fancy, sit back and relax.

Eventually the green LED will stop flashing, wait another minute or so for the process to fully complete.

If the PlutoSDR drive has reappeared in your file manager, safely remove the drive from your file manager and unplug the micro USB connector from the Pluto+ powering it down.

It’s now important to remove the 3v3 to SD-H jumper as we no longer need to boot from SD card.

You can now refit the top cover and the 4 screws and put the case back together. Connect an ethernet cable and micro USB cable to the DATA port and wait.

After about 10-15 seconds the green LED should flash and your Pluto+ is now no longer bricked and ready for use once more.

You can SSH to your Pluto+ using the normal Linux SSH command logging in as root with a password of analog.

If you have PiHPSDR installed and compiled with the SOAPYSDR library and modules (See my article on how to do this easily) you can now start it and connect to your Pluto+ device as normal.

Steve's rescued Pluto+ receiving a signal from my AllStarLink node in PiHPSDR — Steve’s rescued Pluto+ receiving a signal on the 70cm band

This same procedure can be used on Linux, Mac, Windows and RaspberryPi, it is not platform dependent.

If you want your Pluto+ to always boot from the SD card, you can leave the 3v3 pin connected to the SD-H pin permanently.

More soon ….

5 March 2025

Signal on RaspberryPi without Snap!

Let me start this article by confessing that I hate Snap on Linux!

The whole idea that you’d need a container type environment to install an application on a Unix system is very far from where I want to be.

It annoys me that snaps are updated automatically too. I know you can disable this but, I shouldn’t have too. App’s should only get updated when I want to update them, not before.

What I really hate is the fact that the Snap back end system is proprietary and owned solely by Canonical, the Ubuntu people. This goes against my OpenSource ethos.

Sadly I had to install Snap to get the Signal messenger app installed on my RaspberryPi 5 desktop computer. App’s installed via Snap are extremely slow to start, run slow and are heavy on resources. Snap also mounts a whole bunch of dependency Snaps via loop devices to make the app work. Snaps make a real mess of your system.

The final straw that broke the camel’s back for me was when Snap did an automatic upgrade to Signal to a version that has a serious bug in it causing it to crash a minute or so after startup. I initially reverted to the previous version to get it working again but, sure enough Snap did another auto-update and broke it again.

This time I couldn’t revert back to the previous version as Canonical, in their infinite wisdom decided to remove the previous version of Signal from their Snap store!

At this point I removed the Signal Snap from my computer, along with all the “hanger on” snap packages that were clogging up the RaspberyyPi 5 and finally did a complete purge of snapd using dpkg to get rid of all the horrendous snap mount points on the file system.

After a reboot I then went hunting for the Signal messenger app source code. Looking through the code it’s not a 5min job to get it compiled on a RaspberryPi and so I followed a few of the forked versions to see if someone had already done all the hard work for me.

After disappearing down a few Rabbit Holes I eventually stumbled into the world of Pi Apps.

Pi Apps is a neat little app that provides access to the “most popular app store for RaspberryPi computers”. It’s 100% free, OpenSource and written in shell scripts. Perfect!

Installing the “Pi Apps” app is straight forward and only takes a few moments.

Pi-Apps - App store for RaspberryPi — Pi-Apps – App store for RaspberryPi

Opening Pi-Apps I found a multitude of OpenSource apps all ready to be installed at the click of a button. In no time at all I’d found Signal and had it installed without getting anywhere near the dreaded Snap.

The version of Signal available at the time of writing this article is v7.39.0 which is fine as this is a stable, bug free version that works reliably.

If you’re using a RaspberryPi computer I can highly recommend you install the Pi-Apps app to enhance your collection of great OpenSource programmes to make your little raspberry flavoured buddy even more useful.

More soon …

10 December 202413 May 2025

Using the DL1YCF version of PiHPSDR with the RadioBerry

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

install-pihpsdr-v22-update Download

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 …

10 December 202415 April 2025

RadioBerry Software Install

For the last week or so I’ve been playing with a RadioBerry HAT for my RaspberryPi computer. The RadioBerry is a cut down version of the Hermes Lite 2 with just 20mW output power and separate TX and RX antenna ports. It’s a really neat little package that sits on top of a RaspberryPi4/5 and creates a neat little HF transceiver.

I initially started with the RadioBerry HAT on my Pi5 but, I soon realised that the software really doesn’t work well at all on the Pi5. I’m not 100% sure as to why but, for some reason it holds one core at 100% continuously. It seems that the RadioBerry software is single threaded. The end result is that on the Pi5 you cannot use a sample rate above 9600 before the IQ stream starts to stutter.

By contrast, installing the RadioBerry software onto a Pi4 it performs perfectly upto the maximum sample rate of 384000 without any stuttering. I’ll need to spend some time going through the source code to try and determine why it doesn’t work correctly on a Pi5.

Whilst going through the source I discovered that the developer has put some code in that collects data from the running computer and sends it to the developer’s website. Some of this data is then made public via his website, http://www.pa3gsb.nl/radioberry/api/read.php

One of the things displayed on the website is the Mac address of the RaspberryPi on which the RadioBerry is running. This is a security risk and should never be done!

The most annoying thing is that this is done without authorisation. The installation doesn’t state that it’s going to collect data every time you start your RaspberryPi computer nor does it offer the ability to opt out. It also doesn’t inform the user that it’s going to pass the data on to a third party. In some cases it even collects HAM Radio Callsign and location data and displays it on a public website, a clear breach of the UK/European Data Protection Law.

Finding spyware in open source software is really poor and something most open source developers would never consider doing.

To this end I have disabled the spyware in the version of the RadioBerry software that I am using and am making it available to everyone else to use via this blog.

So, to install the RadioBerry software you just need to download the installation script and run it in a terminal on your RaspberryPi computer.

The script will download the modified source code, compile it and install it on your RaspberryPi ready for you to use.

RadioBerry installation Script Download

I encourage everyone that downloads the script and the source code to take a look at it and ensure you are happy with it. It’s important to know what you are running on your computer and what it does.

You can find the spyware code in the register.c file (It’s all commented out with “//” marks). The function now doesn’t pass any data at all to the public website.

I hope some of my readers who are experimenting with the RadioBerry transceiver find this useful.

I will soon be publishing an article on an enhanced version of PiHPSDR from DL1YCF to use with the the RadioBerry to complete the project.

Important Update:

There is an issue with the RadioBerry code that renders it useless if you use a kernel later than the version shown below:

Linux Radioberry 6.6.51+rpt-rpi-v8 #1 SMP PREEMPT Debian 1:6.6.51-1+rpt3 (2024-10-08) aarch64 GNU/Linux

Updating the O/S Kernel to any version later than the version shown above will stop the RadioBerry software from working. Recompiling of the code also fails due to the Kernel update and at the time of writing this cannot be fixed without a code rewrite by the original developer.

I also recommend that once you have built a working RadioBerry on a RaspberryPi 4 you should disable the automatic updates of the O/S to stop the system from failing in the future.

You can disable the automatic updates by entering the following commands into a terminal:

sudo systemctl disable apt-daily.service
sudo systemctl disable apt-daily.timer

sudo systemctl disable apt-daily-upgrade.timer
sudo systemctl disable apt-daily-upgrade.service

You can check the version of the kernel you have installed using the following command in a terminal:

uname -a

Hopefully this will help anyone that is having issues with their RadioBerry after an O/S update.

More soon …

19 November 202429 November 2024

Another new radio!

Many years ago when I lived in France I had a Flex-3000 transceiver, one of the first fully SDR transceivers on the market. It was paired with a proprietary Windows XP application called PowerSDR (now Opensource and called Thetis) and connected via a firewire connection.

17 years later I am once again venturing into the world of SDR transceivers in the form of a Hermes Lite 2. (HL2)

The HL2 hardware is available via the Makerfabs website in kit form. I ordered the HL2 motherboard, the N2ADR Filter Board to ensure a clean signal from the transceiver and the enclosure. Total cost for all the parts and shipping was £288.00 including all taxes.

The kit took about 10 or so days to arrive and was very easy to put together making sure to fit the PA transistor heat sink the right way round so that it doesn’t short out the main board. (There are many videos about this on YouTube)

Once the hardware was put together I needed to install some software to control/drive the HL2. Being a heavy weight Linux user my software choice had to come from the Opensource world.

M0AWS Hermes Lite 2 SDR Trasnceiver and Xiegu XPA125B Amplifier

After much research and chatting with other HAMs on the Matrix who have the HL2 I found that most people use the closed source SDR Console software to control the transceiver. Since this software is for Windows it’s not something I can use as I don’t have any Windows PCs, they’re all Linux only.

To this end I started researching Linux SDR software for the HL2 and decided that PiHPSDR was the one I was going to try first.

PiHPSDR was originally written for the RaspberryPi 3/4/5 single board computers (SBCs) but, I wanted to have a go at compiling it on my Kubunu Linux desktop PC. I found it straight forward to follow the instructions in the pihpsdr-install.pdf file and in no time at all I had the software compiled and running.

PiHPSDT running on Kubuntu Linux 22.04LTS — PiHPSDR running on Kubuntu Linux 22.04LTS

PiHPSDR is infinitely configurable and thus it feels like it has an infinite number of menus and options. Since the HL2 has two separate receivers, it’s possible to listen to two bands at the same time. This is the one feature I really missed more than anything with my FTDX10 so, I’m glad to have dual receive capability back once more!

Going through all the settings I realised that the A and B VFOs have individual settings. Initially I setup the software using just VFO A but, when I switched over to VFO B none of my settings were there. I then had the realisation that the settings apply only to the active VFO. I quickly went through all the settings again for VFO B and all was well.

In no time at all I was on the air with just 5w as my Xiegu amp hadn’t arrived. Not being perturbed I tuned up on the 15m band and started searching for stations. Interestingly it was CQWW SSB weekend and the band was full of contest stations. Working my way along the spectrum I found I was able to work quite a few stations with ease using my vertical and inverted-L antennas.

Contacts of note were VE3KG at 3406 Miles, VE3JM at 3382 Miles, RW9DX at 2380 Miles, KC1XX at 3331 Miles and N1DE at 3600 Miles. I also worked a bunch of European stations and had a great time giving away points with my little QRP rig.

Contests are a good time to try out new radios as all the big stations with good ears are on the bands and make the effort to get us QRP guys in their logs.

I have been extremely impressed with the receivers in the HL2 radio. It handles both strong and weak stations exceptionally well. PiHPSDR really does have brick-wall filtering and I was able to work the weaker stations right next to large contest stations with ease. At no time did the front-end of the receiver get overloaded.

Below is a short video clip of a conversation on the 80m band. The band was quite noisy however, with a reduction of the AGC gain and the 2700Hz filter it’s possible to remove almost all the noise.

Hermes Lite 2 SSB reception on the 80m Band

On CW the radio is a real delight. With the filtering and AGC gain control I am able to use extremely narrow receive filters without any ringing whatsoever. I would say that on CW the HL2 is as good as my FTDX10 when it comes to receiving even the weakest of stations.

I’m sure on paper the FTDX10 receiver has better numbers however, to the ear there really is no discernible difference.

Below is a short video clip of D4DX on CW on the 80m band. The band was noisy but, with the 100Hz filter enabled and clever use of the AGC Gain I was able to remove almost all the noise completely, reducing fatigue on the ears and making reception very easy even though there was some fairly deep QSB at times.

Receiving D4DX on CW on the 80m band using 100Hz filter and reduced AGC gain

A few days later my Xiegu XPA125B amplifier arrived. Unfortunately the amp didn’t come with the normal PTT lead that comes from the factory and is detailed in the user manual. For some bizarre reason this is a chargeable option when you buy the amp from Martin Lynch and Sons even though it is included from the factory.

This meant I had to make a lead which was a problem as I didn’t have one of the mini DIN plugs required for the connection to the amplifier. Jumping onto Amazon I ordered a packet of two and sat back and waited for their arrival.

A couple of days later the DIN plugs arrived and I quickly made up the necessary phono/RCA to mini DIN lead and got the amp operational.

The Xiegu XPA125B isn’t cheap but, it’s a really nice bit of kit. The neat little LCD display keeps you informed of power O/P, I/P and O/P SWR, voltage, current draw, temperature and band selected.

With just 0.7w of input from the HL2 I’m able to get a full 100w O/P from the amp. On the lower bands I have to reduce the O/P from the Hermes Lite 2 even further so that I don’t over drive the amp.

Being an avid Short Wave Listener (SWL) I wanted to see how the HL2 performed when listening to the big AM broadcast stations. To my surprise it makes an excellent SWL receiver with better AM demodulation than many of the more expensive radios. Having the option to select receive filters up to 16Khz wide I found I was able to get the best audio possible from many of the broadcast stations including Radio Caroline on 648Khz. It’s quite an improvement over the 12Khz maximum on the FTDX10.

Listening to AM Broadcast stations

What makes this project even more exciting is that both the hardware and software are from the OpenHardware/OpenSource world. The complete circuit diagram, PCB layout and information is available for all to download, something you don’t often see these days!

PiHPSDR is one of the nicest SDR applications I’ve seen in the Linux world and even comes with a 200 page downloadable user manual. Something you don’t see in many Opensource projects. The source code for the application is downloadable and you are able to make your own changes to it without restriction.

Overall I am really pleased with the Hermes Lite 2 SDR transceiver.
It has two excellent receivers, is infinitely configurable via the PiHPSDR software and performs extremely well under all conditions. Since getting the radio I haven’t even switched on the FTDX10.

More soon …

10 April 202411 April 2024

Building HAM Clock on an old RaspberryPi

I’ve got a couple of old RaspberryPi computers on the shelf in the shack and so decided it was time for me to put one of them to good use. The first model on the shelf is the oldest and is one of the very first RaspberryPi 1 computers that was released. (It’s the one with the yellow analog video signal output on the board!). This particular model is extremely slow but, I hang onto it just as a reminder of the first SBC in the line.

The second one is a RaspberryPi 2, a quad core machine that is only slightly faster than the first model but, it’s powerful enough to run HAM Clock.

It didn’t take long to install a vanilla Raspbian Desktop O/S and get it configured on the local LAN. I installed a few packages that I like to have available on all my Linux machines and then started on the HAM Clock install.

The first thing I needed to do was install the X11 development library that is required to compile the HAM Clock binary. To do this, open a terminal and enter the command below to install the package.

sudo apt install libx11-dev

You will need to type in your password to obtain root privileges to complete the installation process and then wait for the package to be installed.

The HAM Clock source code is available from the HAM Clock Website under the Download tab in .zip format. Once downloaded unzip the file and change directory into the ESPHamClock folder ready to compile the code.

cd ~/Downloads/ESPHamClock

Once in the ESPHamClock directory you can run a command to get details on how to compile the source code.

make help

This will check your system to see what screen resolutions are available and then list out the options available to you for compiling the code as shown below.

The following targets are available (as appropriate for your system)

    hamclock-800x480          X11 GUI desktop version, AKA hamclock
    hamclock-1600x960         X11 GUI desktop version, larger, AKA hamclock-big
    hamclock-2400x1440        X11 GUI desktop version, larger yet
    hamclock-3200x1920        X11 GUI desktop version, huge

    hamclock-web-800x480      web server only (no display)
    hamclock-web-1600x960     web server only (no display), larger
    hamclock-web-2400x1440    web server only (no display), larger yet
    hamclock-web-3200x1920    web server only (no display), huge

    hamclock-fb0-800x480      RPi stand-alone /dev/fb0, AKA hamclock-fb0-small
    hamclock-fb0-1600x960     RPi stand-alone /dev/fb0, larger, AKA hamclock-fb0
    hamclock-fb0-2400x1440    RPi stand-alone /dev/fb0, larger yet
    hamclock-fb0-3200x1920    RPi stand-alone /dev/fb0, huge

For my system 1600×960 was the best option and so I compiled the code using the command as follows.

make hamclock-1600x960

It’s no surprise that it takes a while to compile the code on such a low powered device. I can’t tell you how long exactly as I went and made a brew and did a few other things whilst it was running but, it took a while!

Once the compilation was complete you then need to install the application to your desktop environment and move the binary to the correct directory.

make install

Once the install is complete there should be an icon on the GUI desktop to start the app. If like mine it didn’t create the icon then you can start the HAM Clock by using the following command in the terminal.

/usr/local/bin/hamclock &

The first time you start the app you’ll need to enter your station information, callsign, location etc and then select the settings you want to use. There are 4 pages of options for configuring the app all of which are described in the user documentation.

M0AWS - HAM Clock running on RaspberryPi Computer — M0AWS – HAM Clock running on RaspberryPi Computer

Once the configuration is complete the map will populate with the default panels and data. I tailored my panels to show the items of interest to me namely, POTA, SOTA, International Beacon Project and the ISS space station track. I was hoping to be able to display more than one satellite at a time on the map however, the interface only allows for one bird to be tracked at a time.

You can access the HAM Clock from another computer using a web browser pointed at your RaspberryPi on your local LAN using either the IP address or the hostname of the device.

http://<hostname>:8081/live.html

or

http://<ip-address>:8081/live.html

You can also control the HAM Clock remotely via web browser using a set of web commands that are detailed on port 8080 of the device.

http://<hostname or ip-address>:8080/

M0AWS - HAM Clock remote command set — M0AWS – HAM Clock remote command set

This is a great addition to any HAM shack especially if, like me you have an old HDTV on the wall of the shack that is crying out to display something useful.

More soon …