I got the 23cm transverter from SG LAB last year, but did not find the time yet to get it to work, that is, it produces a 2W signal on a spectrum analyser and you can control it with a handheld radio, the next thing are the antenna and the mast.
In Friederichshafen I found a biquad antenna for the 23cm band, the maker provided unfortunately no mounting options, so I constructed a frame from PVC tubing to support it, drilled a few holes in the reflector (you can easily do this, it does not really hurt the SWR) and attach it with tie-wraps to the PVC frame. A single bracket mounts it to the mast, currently I apply Plasti-Dip (TM) everywhere where I suspect water can enter the cable or the antenna, it is by far the easiest method to make things somewhat weatherproof.
The mast can’t support a rotor (probably), one lightweight antenna and a long-wire for HF can do the job, if that needs to be changed then I probably need to move the antenna to the roof on a shorter steel mast etc.
The transverter itself is rather simple to operate, put it in VOX mode, set the jumpers for the correct repeater shift and off you go. Both input and output LEDs should turn green, the input LED indicates the input power and the output LED the reflected power from the antenna. If the second LED is not correct then start debugging the cable, connectors and antenna with a VNA. You can oftentimes tune the SWR (assuming that the second LED is orange but you want to have it green) by adding a short cable segment. Otherwise find a directional coupler and divert the reflected power to a dummy load.
Future for amateur use
For many years there is the claim of 1278.750 MHz for the E6 precise positioning service of Galileo. For this they need a wide bandwidth but it is a spread spectrum technique. So it remains to be seen what happens when Galileo (the European GPS) goes into full operational mode, and how the amateur band can be maintained. Also it is good to watch announcements on temporal frequency restrictions for higher frequency bands. Occasionally there are events in Rotterdam during which you can not use certain frequency segments above 1 GHz.
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.
I think this is one of the tools you want to have next to what you already have for the digital modes in hamradio. JTalert is available from https://hamapps.com/ It is helpful because it gives access to https://hamspots.net which is generally faster than https://pskreporter.info/ Also JTalert has automated the way you can log QSOs or query callsigns in various ways. The program can either update your own logbook or a webserver logbook, and it has a lot of filtering for wanted calls, grids, countries, continents, it allows to chat with online JTalert users (just right click on their name and it opens a message window), etc. Contrary to popular believe, JTalert is not a program to replace WSJT-X, instead it works as an overlay for logging and reporting and as far as I can judge, but it does not fundamentally change the way WSJT-X works. JTalert does not make you the superhuman that does not need sleep, or maybe a robot, referring to the talk of Joe Taylor #k1jt in Friedrichshafen.