WSJT-x mobile set-up

Some people think that WSJT-x is not about hamradio, because it is internet related while hamradio is supposed to be independent radio for amateur use on designated frequencies. This article will show that they are wrong, you don’t need the internet, we just need GNSS (thus GPS and the rest) which is always there and free to receive.

The second misunderstanding is that you have to carry a windows laptop in the field to be able to do this easily. Also this is wrong, we are not depending on Microsoft Windows, instead we only use Raspberry Pi’s for controlling the radio and timekeeping. Access to the RPi’s is what you do with VNC, this is free software that runs everywhere, Ubuntu, Windows, Mac OS or even your tablet.

A Raspberry Pi (3B+) is fast enough to run FT4, the figure below is the evidence, it shows a FT4 session with the latest version WSJT-x 2.1.0 GA:


The radio that I use was designed 16 years ago (I found an introduction article in QST in 2004 mentioning that the reviewer got it in 2003); the FT857 is still sold today while we know that there are more modern transceivers with SDR technology, DSP and more of that:


The RPi that controls the FT-857 is also running the WSJT-x software, two radio dependent cables are required, an audio cable and a cat cable. I used the MFJ-1234:


FT8 and in particular FT4 require time synchronization, you can do this by hand if there is no internet (one of our requirements) but why can’t it be done by GNSS? So this is a task for a second RPi with a GPS hat which needs a GPS antenna currently mounted on a can of chewing gum on the window sill.



Everything that you carry with you in the field has to talk to one another, for this we have an unused netgear switch (if could also go via local wifi). I replaced this switch a few years ago when CAT6 gigabit lan was installed, for field LANs we can still use it, 100 MBps is fast enough.


For packet routing you could carry the router you have at home into the field, chances are that your wife and children don’t like you too much when you return home, so, either build your own router (I gave up), or find a mobile WiFi router, also called a travel router or a MiFi device, the one below is really good enough to do the job.


Two projects [here] and [here] came together for this article. Can it be done easier? Probably yes but this is what I ended up with for mobile WSJT-x.

Last update: 30-Jul-2019 17:46 (Fixed a few typos).

Time keeper and router

For digital modes on a field day you have to assume the worst, no internet, no local Ethernet, and therefore no time information. We need time with some accuracy, so a GPS (more accurately GNSS) hat on  a Raspberry Pi that controls a local NTP server and a travel router should be able to do the job.

Figure 1: Upper right is the GPS status window, below that is an existing NTP window, and on the left is a (pulse per second) PPS output window
Figure 2: The Raspberry Pi with the Dragino LORA/GPS hat.

The GPS hat comes from dragino, it also does LORA (the white stick) which I’m probably not going to use, the only hardware modification is a (blue) patch wire between the output of the GPS chip and a free gpio port on the Raspberry Pi. I used gpio 19 for this purpose (earlier I wrote 29 and this was pin 26 which is a software defined gpio pin while 19 is a hardware PWM pin, there is no difference for the RPi)

Setting up your gpsd server 

GPSD is a daemon, a process running in the background doing all the work for you, such as making the GPS information available on a port on the system. Step 1 is that the GPS has to show positions are time, and, PPS data which we need for the NTP server. The dragino board can be handled in the same way as the Adafruit Ultimate GPS hat for the Raspberry Pi, it is described here. The first time you run the dragino board (the LORA/GPS hat) on a Raspberry Pi no GPS data is shown on a serial port (it should be /dev/serial0), reason is that the console already claimed it, the adafruit article explains how to get the gpsd to work. If cgps -s -u m does not show you anything you then this part needs to be fixed. Debugging the gpsd daemon is explained here although it can quickly become rather technical.

Setting up your ntp server

You could in principle get the time directly from the NMEA strings of the GPS chip, but that procedure can introduce 1 second timing errors because of the baud rate at which the NMEA information is displayed. (see also what I described for the DIY GPS tracker, the article is: here) So there are better ways to do it, namely by using a separate pulse per second (PPS) line from the GPS chip which is unfortunately not wired on the dragino board to any Raspberry Pi gpio pin. So this is what you do yourself, good old-fashioned soldering solves this problem. Once ppstest works you can proceed, for the rest I did not have to do a lot, the procedure is described here. The result is that NTP on lorapi mostly listens to the GPS receiver, and that some internet infomation is used, but not too much.

Some clock and frequency offset results on my LAN

There are several things you can do to see how well time and frequency are now defined, ntp comes with various tools to generate loopstats and peerstats. The loopstats refer to the time and frequency definition of your own clock, and likewise, peerstats are the definitions of all other clocks that NTP synchronizes to while running.

NTP is presently running on rwo Raspberry Pi’s and a PC on my LAN. Lorapi is the RPi equipped with the GPS hat and the wired PPS line,  Adsbpi is its neighbor listening all day to aircraft ADSB data, and the PC is a windows 7 system using the Meinberg ntp implementation. Here are some time and frequency offset estimates for all RPi systems:

Figure 3: Red orange line refers to lorapi, and the blue line is adsbpi. The clock offset is shown in milliseconds and the time runs in hours (its offset is not too relevant)

Figure 4: modelling results of the clock frequency. This is what NTP extracts for your system. Color coding is the same, red is lorapi and blue is adsbpi.

So what do you learn? Adding a GPS time synchronization improves the definition of time considerably, better than 50 microseconds is easily achieved unless there are a lot of antenna changes and temperature changes of your RPi. Without the GPS time synchronization we see that the time offset can easily reach +/-200 microseconds  in steady state but this depends on the quality of the internet and the availability of stratum 2 NTP servers in your neighborhood. If they are not there then things become rapidly more troublesome, a few milliseconds (up to 10) is what my PC shows, my PC does not listen to any stratum 2 server. The relaxation time to reach steady state can be as much as 1 or 2 hours for the tested systems, except when you carry your own GPS, in that case the steady state is reached in less than 30 minutes. The frequency plots show that we are dealing with non stabilized (no voltage or temperature stabilization) oscillators. So this is what quartz does for you. At night the temperature does not change too much and the oscillator frequency variations are small, during the day this is a different story. For the intended digital modes application any definition of time is good enough (100 milliseconds would already be satisfactory). If there is no internet to synchronize to during a field day then the GPS solution should work. For time of arrival applications the reported 50 microseconds would result in 1.5 km type of ranging errors.


This is something I tried on lorapi, but it is too complicated, so what I will do is to carry a travel router with me in the field, a travel router is able to create its own LAN and from there you connect to any internet if needed, if you not matter if the internet is not there, if we ran WSJT-x on a field day.

Last update 28-Jul-2019 11:34

WSJT-X spectrum produced by a FT991 transceiver

My working hypothesis was that the ALC meter value is relevant for digital modes, the input audio signal should be at a level where you have a small ALC meter value, but where you reach on an external power meter the commanded power of the FT991. The question is whether a higher audio input signal with a increased ALC meter value will cause more splatter in the WSJT-x transmit signal of the FT991.

Setup: FT991 and PC in the configuration the way it is used on the HF bands, both are connected via a microham keyer II. The commanded output power levels on the FT991 are 10, 25, 50 and 80 Watt. (See the discussion below under advisory note discussing the attenuators and the SDR.) Measured are: the peak level in dB of the WSJT-X generated tune signal and the signal level of highest parasitic frequency seen by the sdrplay duo, and also the noise floor in the waterfall graph produced by the SDR. The external power meter is that of a Palstar tuner put in bypass mode.

The following values show the dB difference between the signal peak and the parasitic frequency signal level for the lowest audio input level generated by the PC resulting in a near zero ALC indication and a power on an external power meter equal to the commanded level on the FT991:

  • 80W 25.6 dB
  • 50W 24.2 dB
  • 25W 27.2 dB
  • 10W 26.0 dB

There is an uncertainty of approximately 2dB in the reported values depending on the indicated ALC meter value in relation to the level of the audio input signal send by the PC to the FT991, whereby it should be remarked that the signal level of the parasitic signals relative to the central frequency deteriorate up to 2dB for larger ALC meter values.

Conclusion: there is no indication that a high or a low power level matters in the discussion. High audio levels will increase the level of parasitic frequencies by approximately 2dB, the parasitic frequencies are approximately 26dB below the central peak in the WSJT-x tune signal produced by the transmitter.

Example FT8 spectra made by FT991 measured with SDR console and an airspy HF+

50W zero ALC center part
Figure 1: Center of FT8 spectrum, zero ALC 50W, the level of the parasitic frequencies is some 26dB below the central peak, I suspect that the sound card of my PC is causing this. The width of the green region is 50 Hz. This graph explains why nearby transmitters running FT8 appear several times in the decoded call sign window. The FT8 demodulator would first find the strongest signal, and the successively find in the residuals all parasitic frequencies which can arrive above the noise floor of the used receiver. SNR measurements for nearby transmitters are therefore unreliable in WSJT-x
50W max alc
Figure 2: Zoom out, 50W max ALC, there is no evidence of excessive splatter, the width of the green region is 3200 Hz.
50W zero ALC
Figure 3: Zoom out 50W zero ALC, and to my surprise nothing changed compared to the max ALC version about which has maybe a few more dB  on the parasitic frequencies, the width of the green region is 3200 Hz.

What is causing the spectrum we see in figure 1?

In my opinion the spectrum is not caused by the SDR, it is also not caused by the PC generating the WSJT-x signal, instead this is what the FT991 produces. For comparison, in figure 4 you find the spectrum of the transmitter in CW mode, this signal has nothing to do with the WSJT-x program or the PC, it is directly generated by the FT991 in CW mode. We see the same features as in figure 1.

Figure 4: A 30W CW signal generated by the FT991

I can also rule out the airspy HF+ and the SDRconsole software because a signal generator (for details see this article) is able to create a 25 Hz wide signal with a carrier to noise ratio of at least 100 dB on the waterfall plot. The spectral width is related to the sampling rate of the used software, in reality the bandwidth of the test signal is less than 25 Hz. In the SDRplay directory you find an spectrum analyzer for a SDRplay duo and it offers some more flexibility for sampling the signal, see figure 5:

Figure 5: single CW tone, this is what you get, around -26 dB intermodulation distortion is found by taking the differences of the four markers.

I also tested a FT990 transceiver, same set-up but with the SDRconsole software, the FT990 performs somewhat better than the FT991, it suggests that a TX IMD of -40 dB can be achieved.

Figure 6: The intermodulation of the FT990 is more around -40dB, this is what you find with 5W and a CW tone signal.

Advisory note with regard to attenuators and SDR

Your SDR is already a fairly good spectral analyser, but it is way to sensitive because it lacks the ability to attenuate transmit signals from a FT991.

Do not try to feed anything more than about 1 mW into any SDR because you will kill it (it has protection diodes but I don’t insist on the challenge) For this experiment you need a high power rating attenuator, so the first one on the chain of attenuators should be able to handle at least the power you transmit, the big black body in the figure below can handle up to 100W with an attenuation of 20dB. Even that is not good enough, you need to go down to 130 dB attenuation (in total) to get a signal close to the noise floor of your SDR, so this is where the rest of the attenuators play a role. (The four BNC to BNC attenuators were not used, also the SMA attenuators were not used) Used were as said the 20dB big black block, the 10dB N-N attenuator, and the HP-335C/D stepper attenuators. The last one becomes useful to tune the signal level close to the noise floor of your SDR and of course within its dynamic range.

An n-bit SDR will have a dynamic range of 10log10(4^n) dB, so 8 bit is 48dB, 12 bit is 72 dB and 16 bit is 96 dB, the airspy HF+ has 18 bit ADC, so its theoretical dynamic range is 108 dB. With for instance 100 Watt of transmit power you want the signal to arrive at some 60 dB  (well within the dynamic range of the SDR) above its noise floor which is approximately -140 dBm, so you need a signal level of -140 + 60 = -80 dBm. To reach -80dBm starting from 100W = 10*log10(100*1e3) = 50dBm you need 130 dB attenuation. The BBB plus the N-N connector give me 30dB; the extra required 100 dB comes from the HP335C/D.

Figure 7: My army of attenuators, without these I can not measure any spectrum with a SDR.


There are quality differences between the transmitter intermodulation distortions (TX IMDs). ARRL test reports take a test range of -20 to -35dB, the lower the number the better it is, our FT991 TX IMD measurement is confirmed in the ARRL test report described in QST November 2015, page 45 to 51. The measurement itself is relatively easy to do with a set of attenuators and software, to validate the quality of the SDR spectrum analyzer I used various test signals of around 1dBm to see whether the bandwidth and the obtained carrier to noise ratio are acceptable. Very narrow signals of better than 5 Hz bandwidth and 100dB difference between carrier and surrounding noise can be obtained with the SDRplay frequency analyzer.

The consequence of TX IMD is that any transmitter will always cause some splatter in the spectrum, it will also happen in the FT8 output signal. The consequence is that a receiver can pick up the TX IMD, strong FT8 signals may therefore cause duplicates at nearby frequencies, duplicates of the FT8 signal can picked up by the decoder.

Examples of duplicate FT8 signals occur in my option rather often, at least, I see them every day. In figure 8 there is an example at 947 Hz offset with a nearly duplicate found by the decoder. I could not eliminate this signal in the receiver, reducing the audio signal did not help, what will help is to attenuate the overall signal, but then you will also lose the weaker FT8 signals. The station from Croatia was the only one that was causing this problem and everything suggests that it is caused by the station itself and not the receiver that I used, nor the ALC behavior, nor the audio level. The observed TX IMD may very well explain why we see this in the WSJT-x band activity window.

Figure 8: At 947 Hz offset you see the main signal with a SNR of 13 dB, and a duplicate at -23 dB at 797 Hz, the distance is 150 Hz.

Last update: 15-Jul-2019 6:56