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).
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.
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:
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.
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+
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.
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:
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.
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.
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.
This is a fairly new product from MJF, it is the MFJ-1234 also known as a RigPi Station Server (RSS) which uses a Raspberry Pi 3 for controlling radios, it has a CW keyer and it can control antenna rotors. The RigPi includes add-on boards for audio and Morse code keying. The project website is: https://rigpi.net/
Running WSJT-X on the RigPi
Three weeks later after I announced the RSS I received my RigPi and I was able to work on it. My primary interest would be to use it for WSJT-x and derivatives such as JS8call on field days. So the requirements are that the RigPi should take control of my Yaesu FT-857 running on batteries. Also the RigPi should run on batteries etc. Audio from the FT-857 goes to the sound card controllable via alsamixer on the Raspberry Pi, also audio from the RigPi has to go to the FT-857, and we need full CAT control over the transmitter. For this rest in this article I want to explain what you need to get everything up and running besides the RigPi and a 5V USB to USB-C power supply.
You need a RJ-45 to a 6-pin DIN cable for the FT-857, this is the same cable that you
need for the MFJ-1204. It comes with a patch (schematic C) as shown in figure 2.
You need a UTP patch cable to a nearby router, all could also be done via wifi if it is fast enough, I preferred the UTP patch cable set-up.
A HDMI cable for connecting the RigPi to a monitor, this is what you need to configure the Raspberry Pi.
A USB mouse and a USB keyboard for the Raspberry Pi, also required for setting it up.
A CAT-6 to USB cable for a FT-857, this is the CT62-U from Yaesu to the 6-pin CAT interface on the FT-857.
With this all you get a wired-box on top of the transceiver, this is what the MFJ-1234 does, it is a hub and a processor at the same time:
WSJT-x was already installed on the RigPi, so we start it up and configure it in the
best possible way.
Due to the audio routing in this experiment and the capabilities of the FT-857 select
data/pkt mode in the radio tab under settings in WSJT-x, USB does not work there unless you modify somewhere the FT-857 on the front MIC connector. I didn’t do this (yet) because you can live without it with WSJT-x.
At the end of the day I was able to send and receive some FT8 data, and also to make some QSOs. The ALC indicator on the FT-857 should be visible, and also you need an external PWR/SWR meter to see whether something is transmitted and that nothing is reflected towards the radio. This is no problem on a field day.
If WSJT-x works the way you like it then configure VNC on your laptap, tablet or whatever you had in mind, and demonstrate that you can control the RigPi. From this point on you only control your RigPi via the laptop, this is the point where you can remove the HDMI table, the USB mouse and the USB keyboard. Screen resolution and so on should be adjusted under Raspberry Pi settings so that it is acceptable for the external laptop display. So this is what I got in the end, as is shown in figure 4.
There are few todo’s with this project:
Is there need for an audio in on the microphone of the FT857, seems only possible with an extra cable, currently I do this in the data (or digi) mode of the FT857,
How do I update the WSJT-x software on the RigPi without affecting the rest of the software, it came with WSJT-x 2.0.1 GA
Is the RigPi fast enough to run JT-4? Also, is it fast enough when there is a lot of band activity. Still have to find out.
Find out whether a crossover cable works to any laptop, in other words, can I avoid to carry a router intp the field.
A holiday activity, build your own CW decoder that can handle up to 40 WPM including logic control to determine the CW code speed. There is a 567 tone decoder chip and some signal pre-processing, 8 ohm stereo audio goes in, next you print the decoded text on the serial output and on the LCD screen.
Version 2.4 has a status bar, most left number counts frames, then WPM guess followed by quality parameters.
This is version 2.3 that includes a quality of code filter.
This is version 2 that clearly had some bugs that were fixed
Note: I’m not sharing too much details yet because I’m still working on the software which is roughly 1000 lines in C/C++ Arduino style, still it compiles to 11k of code and less than 1 k of variables. The hardware resembles the design made by WB7FHC Budd but I’ve changed some stuff before it goes in the 567 tone decoder IC. The magazine Electron Dec 2018 jaargang 73 discusses a similar project.
In wsjt-x there is a save directory, like c:\users\admin\appdata\local\wsjt-x\save which started to collect some 30Gb of data and something line 38+ thousand wav and C2 files in the 2,5 years that I used wsjt-x. The 30 Gb is not really a problem, but I don’t like the 38+ thousand files because it slows down windows 7, for instance because of backups and virus scanners checking the system. So why is this happening? The answer is that the developers and testers use the save directory files but it is probably not helping the average user. Also, my impression is that “save everything” was a default setting in the past. If you are not a developer then:
clear everything in the save directory, you don’t need it.
go to menu -> save and select none
You will still see that wsjt-x writes files in the save directory, but it also removes the files when the program is properly closed. Occasionally you can clear the save directory (under file -> delete all *.wav & *.c2 files in SaveDir) because there will probably be unattended wsjt-x occasions with a PC restarting after a windows update (for instance). So repeat the clean procedure once per month.
After running in this way for a day I still found files in the save directory. This sounds more like a bug in WSJT-x, in actually all versions.
At this moment (12-dec-2018) you should consider an update to WSJT-X V2.0.0 GA which clearly has several advantages as the release notes and the user guide explain. At the same time install NTP and openssh. Installing NTP makes a significant difference because WSJT-X depends on accurate timing. If you are more than 2.5 seconds off then your transmissions simply fail. (The 2.5 seconds is a guess). Windows is by itself sloppy on internet time synchronisation and a separate NTP from Meinberg does a better job. The openssh package (you only need the DLL actually) is required because of LOTW access by the software. This transition period may take a while, either because people are late with their updates, either because it is not always an easy job on each operating system.
Last update: 12-dec-2018
FT8 different versions, 80 and 40m bands, last 24 hours (now:13-12-2018 13:12 CET)