Recently I purchased a Hermes Lite 2 SDR receiver (HL2 for short), and I am very impressed with it. One of the very nice features is that it lets you receive several chunks of spectrum (“slices” in SDR parlance) at once.
I also found an excellent piece of software for the digital-mode enthusiast called SparkSDR. SparkSDR can make use of the multiple slices offered by HL2, and thus allows for an infinite number of digital mode receivers to be operated using the HL2 slices. SparkSDR also offers the ability to transmit these modes, but for the purposes of this article, I am only concerned with FT8 reception.
Since FT8 came about, the use of WSPR for making test transmissions and observing receiving locations has pretty much died. However, with the widespread update of FT8 (and similar modes such as FT4, etc.) these transmissions may instead be used as transmitting beacons – when a station calls ‘CQ’ (makes a general call soliciting someone to reply), the software sending the FT8 call encodes the senders location (as a QRA locator) into the sent message. A typical CQ may look something like this:
CQ M1GEO JO02
Similarly, the system of another person responding to my CQ call will also encode the distant station’s location, resulting in a response which may look something like this:
M1GEO ZL1A RF72
Here “M1GEO” is my callsign, “ZL1A” is a DX (distant) station and “JO02” (and “RF72”) is the first part of the maidenhead locator, covering a 100km square, which looks something like this:
It is possible to use a 6-digit locator, for example JO02HG, which takes the accuracy down to a 10km square (see below). Although there are higher resolution locators than this, they are not often used.
Since we know (at least to within 10km) where a transmitting station is, it becomes possible to plot the stations on a map. You’ve probably seen this done before. Websites like PSKReporter and WSPRnet have been doing this for some time now.
The image above use different coloured markers for different bands:
40m (7074 kHz)
30m (10136 kHz)
20m (14070 kHz)
15m (21074 kHz)
I have been recently enjoying the ability to use the same untuned vertical antenna with the same radio on different bands simultaneously (the HL2 lets you remove any band-pass filtering). This allows you to see, for example, that while 40m was good for working Germany, 30m had good propagation into Australia.
PSKReporter lets you filter by mode, band, and time, so you can see what times a given band is open to a specific location. Excellent for helping to fill those missing DXCC slots you may have.
It was interesting for me to see that much of the more remote stations were received on the lower bands, 40 and 30m, and not 20m as I would have expected:
VK7BO at 6:06 UTC on 30m
VK3ZH at 6:33 UTC on 30m
K6SY at 5:28 UTC on 30m
LU1WFU at 1:50 UTC on 40m
YE8QR at 14:46 UTC on 40m
Although at the time of writing (August 2020), HF conditions are quite poor, not all of the lack of performance on 20m can be explained due to the band conditions, since 20m is still open to South America and into Asia.
Animating the propagation
After looking at these static images, I wanted to see how things changed with time. Could I, for example, see when the best time to work the west cost of the USA would be? I decided to make a time-lapse animation. The animation runs for approximately 3 days, and includes the following FT8 decodes:
40m (7074 kHz)
30m (10136 kHz)
20m (14070 kHz)
15m (21074 kHz)
It is clear to see sudden bursts of colour when a band opens, and to watch conditions change throughout the day. The dates here were for a Friday to Monday, so, there’s plenty of weekend activity.
I’m keen to further explore the possibilities of this.
I noticed after a while, that my BER percentage of my MMDVM_HS_Hat and Pi-Star setup was significantly higher than other users, at around 3.5%. I know from setting up GB7KH that getting this correct takes patience. I also happen to know that the design of the MMDVM_HS_Hat uses inexpensive TCXOs to provide frequency and timing references. As such, some calibration can do wonders for the BER on DMR.
For this mini-guide, I shall use my TYT MD-380 handheld DMR radio. My hotspot is set to use a nominal frequency of 434.250 MHz as the carrier frequency.
Using the DMR handheld as a transmitter on low power, it should be possible to better match the frequency of the receiver to the transmitter – this process isn’t ideal, because it could equally be the handheld frequency which is incorrect – but at least they’ll match.
We’ll need to get SSH access to the underlying Linux system on the Pi-Star. You can either use the “SSH Access” tab from the Pi-Star Expert menu, as below:
Or you may prefer to SSH into the Pi-Star with your preferred SSH client – I use PuTTY. Either option will work here.
The program we need is called MMDVMCal. Fortunately, there’s a version compiled for us already in Pi-Star. From the Pi-Star console terminal, the following command will start the MMDVMCal program where we’ll do our testing:
$ sudo pistar-mmdvmcal
When the program starts, you’re greeted with the following command line instructions. You may also see some debug/warnings about
Starting Calibration… Version: 1, description: MMDVM_HS_Hat-v1.4.17 20190529 14.7456MHz ADF7021 FW by CA6JAU GitID #cc451c4 The commands are: H/h Display help Q/q Quit W/w Enable/disable modem debug messages E/e Enter frequency (current: 433000000 Hz) F Increase frequency f Decrease frequency Z/z Enter frequency step T Increase deviation t Decrease deviation P Increase RF power p Decrease RF power C/c Carrier Only Mode K/k Set FM Deviation Modes D/d DMR Deviation Mode (Adjust for 2.75Khz Deviation) M/m DMR Simplex 1031 Hz Test Pattern (CC1 ID1 TG9) K/k BER Test Mode (FEC) for D-Star b BER Test Mode (FEC) for DMR Simplex (CC1) B BER Test Mode (1031 Hz Test Pattern) for DMR Simplex (CC1 ID1 TG9) J BER Test Mode (FEC) for YSF j BER Test Mode (FEC) for P25 n BER Test Mode (FEC) for NXDN g POCSAG 600Hz Test Pattern S/s RSSI Mode I/i Interrupt Counter Mode V/v Display version of MMDVMCal <space> Toggle transmit
The first thing to do is to set the MMDVMCal frequency. I did this by pressing “E” followed by the frequency of my radio (434.250 MHz) in Hz.
You should see this frequency echoed back in brackets once the menu is reprinted to the screen. If you look at the example above, you’ll see that the frequency is 433000000 Hz (or 433.000 MHz). Pressing “b” will enter “BER Test Mode (FEC) for DMR Simplex” mode:
At this point, a quick transmission will show the exact BER:
DMR voice header received DMR voice header received DMR voice header received DMR audio seq. 0, FEC BER % (errs): 2.837% (4/141) DMR audio seq. 1, FEC BER % (errs): 2.837% (4/141) DMR audio seq. 2, FEC BER % (errs): 3.546% (5/141) DMR audio seq. 3, FEC BER % (errs): 1.418% (2/141) DMR audio seq. 4, FEC BER % (errs): 0.709% (1/141) DMR audio seq. 5, FEC BER % (errs): 2.128% (3/141) DMR voice end received, total frames: 6, bits: 846, errors: 19, BER: 2.2459%
My BER is showing as 2.5%. Not awful, but with some room for improvement.
The process of finding the ‘perfect’ value is twofold. The first is to find the approximate frequency, and then dial in the exact value. Here, we’re trying to find out the difference between the nominal frequency (in my case 434.250 MHz) and the optimal working frequency.
From the menu above, you’ll note that both “F” and “f” (both upper and lower case) increase and decrease the frequency respectively. By holding your radio in transmit, repeatedly press the F key until you the MMDVM_HS_Hat looses the transmission from your handheld. You’ll see the TX frequency announced with each change of frequency – allow time between each step (around 10 seconds on each frequency).
Keep going in one direction until the software reports “Transmission Lost” – note the final frequency down. You can see this by pressing “H” or “h” to reprint the menu. For me, the first limit I reached was 434249800 Hz by repeatedly pressing “f” to lower the frequency.
From here, you can find the mean (centre) frequency: (434249800 + 434250800)/2 = 434250300 Hz (300Hz higher than the nominal).
Use the “E” command once again and enter your new mean frequency – for me, this was 434250300 Hz.
You can then either enter frequencies yourself stepping 10 Hz at a time until you find the frequency yielding the best BER, or you can use the “Z” and “z” commands to increase or decrease the steps, and continue using the “F” and “f” commands to ‘home in’ on the value. I tabulated my results to give me a clear understanding of what was going on. I first went with 25 Hz steps (half the default 50 Hz steps) and found the following values for a 15 second transmission on each frequency. At the end of each transmission, status (including BER) are reported. You can see that the optimum value was very close to my mean value.
You can see that the optimum value was very close to my mean value. I experimented with even smaller steps, but didn’t really improve much on the 0.1% BER. This value is definitely good enough, and is an order of magnitude better than what I had previously!
Since I also use D-STAR, I quickly pressed “K” to enter D-STAR BER test mode, and, with the best settings from DMR, I keyed my Kenwood TH-D74 handheld – everything was fine here, too:
D-Star audio FEC BER % (errs): 0.000% (0/48) D-Star audio FEC BER % (errs): 0.000% (0/48) D-Star audio FEC BER % (errs): 0.000% (0/48) D-Star audio FEC BER % (errs): 0.000% (0/48) D-Star audio FEC BER % (errs): 0.000% (0/48) D-Star audio FEC BER % (errs): 0.000% (0/48) D-Star voice end received, total frames: 214, bits: 10272, errors: 0, BER: 0.00000%
Taking the frequency for your lowest BER (in my case 434250275 Hz), the offset is easy to calculate: Simply subtract the best BER frequency from the nominal frequency to find the offset: 434250275 – 434250000 = 275 Hz (note, this can be negative).
Applying the Offset
We next need to apply our offset (in my case +275 Hz) to the main MMDVMHost application running on the Pi-Star. This is done through the expert configuration.
Inside the Pi-Star configuration, head to the Admin Expert menu once again and select MMDVMHost.
Inserting our calculated offset (in Hertz) from the above.
This page assumes some basic familiarity with Linux. It assumes a clean install of Ubuntu 18.04 and installs Eclipse Photon. I install the CPP version, but you’re free to choose when the option presents itself!
Update the OS
First thing to do is to update the operating system. This is easily achieved by running the following two commands:
sudo apt update
sudo apt upgrade
These commands may take a while to complete, depending on what there is to update and how fast your internet connection is.
Installing Java Development Kit (JDK) 8
Since Eclipse is written in Java, we will need the latest version. I’m not sure if the Java Runtime Environment (JRE) alone is enough, but I have installed the full JDK anyway.
Firstly we add the third party JDK PPA repository and update the package manger index
sudo add-apt-repository ppa:webupd8team/java
sudo apt update
Next we must actually install the JDK:
sudo apt install oracle-java8-installer
This will pull in a few extra packages, such as java-common, oracle-java8-set-default (which makes sure that this installed version of Java is the system default), font packages and so on. You’ll be guided through the Java 8 installation with an ncurses based installer:
You must accept the Oracle Binary Code licence. The download for Java 8-1u171 was 182 MB. To confirm the installer completed correctly, scroll up in the terminal window. You should see something explaining that the installation finished successfully. To confirm this, and check the version installed, you can run the following from the terminal:
javac 1.8.0_171 [or similar result expected]
The Eclipse installer can be found on the Eclipse project download page: https://www.eclipse.org/downloads/. At the time of writing, the Eclipse Photon installer was 45.9 MB. I downloaded it using the Mozilla Firefox browser, and saved the installer into my user’s download folder (/home/geosma01/Downloads/).
Once downloaded, switch back to your terminal program, and change directory into the downloads folder and extract the downloaded TAR/GZIP archive and change directory into it:
tar xvfz eclipse-inst-linux64.tar.gz
We’re now ready to run the installer. If we change into the newly extracted folder and then run the installer, we should be good to go:
I ran into trouble installing Eclipse as root, so I install it into my own user space: ~/eclipse/cpp-photon
Accept any licences it prompts for:
Once the installer has finished, you can start Eclipse by pressing Launch. We’ll make a desktop shortcut in a few moments…
Now we have Eclipse running, we should get ourselves an icon to easily start it.
Creating a Menu Icon
Next we will create a menu shortcut. We will create this using a basic terminal-based text editor (nano). Running the following will open the file:
Then, copy and paste the following, as you see appropriate – you should change my username (geosma01) to your own at the very least:
If all has gone well, you’ll see something like the following inside the menu:
PyDev can be easily installed through the Eclipse Marketplace. From inside Eclipse, click Help on the menu, and select Eclipse Marketplace. You should be presented with the following window. You can then enter “pydev” into the search, and then click Install on the entry shown below:
Confirm your selections, accept the licence conditions, and you’re good to go! Once installed, click on Restart Now and you’re done!
Once restarted, you can open a PyDev Perspective by selecting Window from the menu, selecting Perspective > Open Perspective > Other and selecting PyDev:
You’re ready to go!
An online scrapbook full of half-baked projects and silly ideas.