Other SOTA sites: SOTAwatch | SOTA Home | Database | Video | Photos | Shop | Mapping | FAQs | Facebook | Contact SOTA

Datamode - FT8 Part 2


Thanks Barry, that was helpfull.

That gave me a com port to use so BktTimeSync is now happy. Syncs OK at 1 min intervals. Time.is isnt happy though as it says the time is 1.4secs out.



Compton, how big are the corrections that you see each minute when it resyncs? Are they all close (<0.1sec) or are you seeing a lot of large corrections on syncs?



It is quite strange. Dimension 4 runs on the W10 laptop at start up and syncs at start up. Time.is is happy and reports time is exact. Then when I run the BktTimeSync with GPS it corrects by 0.5 to 1.4 seconds from what Dimension 4 has set it as. Time.is then reports that the clock is out by 0.5 or 1.4 or what ever seconds. I cant believe that the GPS clock is out by that much compared to a time server in my country plus I assume that Time.is is correct.

The 1 minute updates with BktTimeSync are around the 0.02 mark. Its just the first sync that seems very much out.



Its been quite some time since I transmitted in FT8 as my work load got crazy,

Is the propagation ok at the moment for QRP FT8 work? Only one guy in the Midlands heard me… (10W long wire on FishingPole)


I think it always is. Have a look at PSK Reporter to see. https://pskreporter.info/pskmap.html


This is where I realised that no station was coping me… :frowning:
Usually with 10w I hit EU well. (Thats months ago though)


A man with two watches… hahaha

Thanks all for this tread. It has been immensely helpful. I will likely try an FT-8 activation very soon. I am still not 100% clear on the “syntax” of an FT-8 SOTA QSO, but the ideas here have made things a lot better. I will give it a whirl.


FT8 Operating Procedures. I have been planning to do activations with the sensitive new FT8 mode in WSJT-X. With the compact and lightweight Microsoft Surface Pro computers, it should be quite possible to run my KX3 in VOX mode, per the arrangement used by ON7DQ and to use the single USB port for GPS time setting, Given the fact that this mode is more sensitive than CW, and may be easier for logging and sending CW during extreme cndx, I can’t help but think FT8 will become increasingly popular for SOTA.

I am curious how other people structure their standard FT8 messages. Certainly one could forego sending the grid locator and send a “random text message” such as “CQ W7GJ SOTA” (which is less than the maximum of 13 allowable characters). But a random text message is not decoded as readily as a “standard message” when signals are weak.

It also is possible call CQ as a standard message with a “directional CQ” using 2 letters between AA and ZZ. Using the standard messages provides more sensitivity and better reliable decoding. Since I figure I will be QRP anyway with my KX3 and battery power, it seems this might be the better option. Is there already an agreed-upon format for calling CQ SOTA in FT8? If not, I propose using “ST” as the directional CQ, so a standard CQ message would be “CQ ST W7GJ DN27”. I suppose that COULD be misinterpreted as a directional call for only stations in Sudan, but it seems that such instances would be rare, particularly if the ST were adopted by all SOTA users.

I have seen other comments about how to send the summit identifier and agree that it is best to send it at the end of the contact in a random text 73 message. An example would be “73 W7M/LM-099”, which meets the limit of 13 characters, and seems to be sent and decoded successfully with the current version of WSJT-X…

Does anybody have any comments of other ideas regarding the above and how we might go about setting an accepted standard to be used for FT8 during SOTA activations?


I think it would be good the have two letters to indicate that a CQ is for SOTA. I have activated 12 summits using JT-65 and two using FT8. Most of those were without posting alerts or spots. Even when spotted, few QSO have been entered in the database by chasers. I have found FT8 activations to be both fast and reliable, and not dependent on beeing spotted. I use a small ASUS transformer book laptop/tablet, running Linux. If I make sure the clock is in sinc, using ntp, when I leave home, the clock is ok on summit. When I did not do this, I was able to sync the clock using my phone to provide internet as a portable wifi hotspot, on the summit.



for information : the new version of WSJT-X 2.0.0 (GArelease) is now available for windows, linux and macOS
for FT8, JT4, 9 and 65, QRA64, ISCAT, MSK144, WSPR and Echo.
here : https://physics.princeton.edu/pulsar/k1jt/wsjtx.html
with documentation
good dx
de Bruno F6HHK

WSJT v2 beta releases and details (GA as of 10/12/18)

I have not had a chance to work with WSJT-X 2.0.0 yet, but I have heard that it has some additional features added to the communications protocol needed for the upcoming ARRL RTTY (really mixed-mode keyboard-to-keyboard) Round-up and also that it is backwards-incompatible with older WSJT-X versions. First, will these updates make it easier, or more straight-forward to use FT8 for a SOTA activation compared to previous versions? And second, if it is incompatible with older versions, will it be better to still with the older version in the short-term for contacts to maximize the chance of completing an activation until more people have had a chance to upgrade?


Hmm, there are a couple of interesting mentions of SOTA in the WSJT-X guide for 1.9.1:


However, it seems to indicate that FT8, at least prior to 2.0.0, does not have enough bits to store the SOTA reference in place of the existing grid square field used in the first two messages of an exchange. It’s specifically encoded with the limited alphabet needed for a 4-character maidenhead grid square, but a SOTA summit reference is a bit longer. The final 73 message exchange, however has a little more room since there’s not much information content like first several messages have.

I wonder exactly how this’ll change with the newest release.


Hi Loren,
This has all been discussed on other threads on this reflector at length. A method of using the earlier FT8 was worked out but was not perfect. Your assumption is correct that with the extensions in version 2.00 which was officially relweased yesterday, there is now support for various contest exchanges, which could probably be used for SOTA as well. We do need the community to agree a model for SOTA for WSJT-x v 2.00 FT-8 communications however, otherwise it will get somewhat confusing if the format varies between Ops.

We also need to decide a few points about which mode should be used etc. this is being discussed at present on a different thread. 20m FT8 DX S2S event / attempt ? (which you are already part of I think).

73 Ed.


The WSJT Development Group is pleased to announce the general availability (GA)

release of WSJT-X Version 2.0.0.

If you have been using version 1.9.1 or earlier, or one of the candidate releases

v2.0.0-rc#, it’s important to upgrade now. The original protocols for FT8 and MSK144

are no longer supported. With v1.9.1 and earlier you cannot communicate with WSJT-X

2.0 using these modes.

We now recommend using WSJT-X 2.0 anywhere in the conventional FT8 and MSK144

sub-bands. Everyone should upgrade to v2.0 by no later than January 1, 2019.


  1. Compound and nonstandard callsigns are automatically recognized and handled using

new FT8 and MSK144 message formats.

  1. The new FT8 protocol provides optimized message formats for North American VHF

contests, European VHF contests, ARRL Field Day, and ARRL RTTY Roundup. Similarly,

the new MSK144 protocol provides optimized message formats for North American VHF and

European VHF contests. Full support is provided for “/R” and “/P” calls in the

relevant contests.

  1. The new protocols provide nearly equal (or better) sensitivity compared to the old

ones, and lower false decode rates.

  1. New logging features are provided for contesting and for “Fox” (DXpedition) mode.

Logging is optionally integrated with N1MM Logger+ and WriteLog.

  1. Color highlighting of decoded messages provides worked-before status for

callsigns, grid locators, DXCC entities, continents, CQ Zones, and ITU zones on a

“by band� and “by mode� basis, and for stations that have uploaded their logs

to Logbook of the World (LoTW) within a specified time interval.

  1. The WSPR decoder now achieves decodes down to S/N = -31 dB. For the particular

benefit of LF/MF users, an option “No own call decodes” has been added.

  1. The UDP messages sent to companion programs have been expanded and improved.

A more detailed list of program changes can be found in the cumulative Release Notes:


Upgrading from earlier versions of WSJT-X should be seamless. There is no need to

uninstall a previous version or move any files.

Please do not continue to use any release candidate – that is, any beta release with

“-rc#” in the version name.

Links to installation packages for Windows, Linux, and Macintosh are available here:


You can also download the packages from our SourceForge site:


It may take a short time for the SourceForge site to be updated.

We hope you will enjoy using WSJT-X Version 2.0.0.

– 73, Joe, K1JT, for the WSJT Development Group


I’m hoping to give this a go today.


The uptake of Ver 2.0.0 seems to have been much faster in North America than in Europe. However on 40m and 20m yesterday it looked like there had been about a 40% changeover to the new version amongst European stations. If you are running Ver 2.0.0 you can see all signals as tracks on the waterfall, but only Ver 2.0.0 signals will decode.

Walt (G3NYY)


Friday 14th December 2018 - The Cloud G/SP-015

Gig: Joe Longthorne
Venue: Shaftesbury Casino, West Bromwich

It was a case of “spot the difference” from my point of view with my first activation using WSJT-X 2.0. Everything seemed to be exactly the same, initially at least.

I soon worked out that I could call CQ SOTA M1EYP/P IO83 - which I definitely couldn’t before. I couldn’t get the ‘SOTA’ bit to stick and had to keep putting it back in manually. I didn’t get round to experimenting if the IO83 could be replaced with a version of the SOTA reference, so I continued to use my free text line at the end of the QSO for that.

6 QSOs made on 20m FT8, including one into the USA, followed by a couple on 2m FM, including S2S with GW4HQB/P on Foel Fenlli GW/NW-051.

And of course, another gig. My first ever in a casino, and preceded by the promoter taking us to a nearby Indian restaurant and treating all the band and sound crew to a very good curry.


Wonder if that was the Vine in Roebuck Street. If not go there next time you’re in West Brom… Not for everybody, but it’s an experience anyone who likes curry and decent beer should try at least once :slight_smile:


No, it was Akash Balti on the High Street.


Hi Walt,
Monitoring the WSJTx Groups.io list there are now people reporting that they can no longer get any (or only very few) decodes with their 1.9x versions of WSJTx - so (at least in the US it seems) most people have moved to v 2.00 as request by JT. I’m actually seeing lots of traffic when using WSJTx v2.00 where a couple of weeks ago that was not the case, so it looks like also here in Europe people are moving over.
My previous thought that JT may have changed the defualt frequency on 20m for FT8 was a red herring - the frequency I came up with on first start was one I had entered for a DXpedition.

By the way if anyone is getting the error panel related to accessing LOTW coming up with v 2.00 GA (even if you don’t use LOTW!) it is due to a problem with SSL verification - the solution is documented in the V2.00 quick guide document. There’s a pre-prepared package to download and install, after that all is fine.