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

New release of WSJT-x software V1.91 for FT8 etc


#1

The latest v 1.90 RC2 version of WSJT-x has just been released and is available for diownload from Sourceforge here - https://sourceforge.net/projects/wsjt/files/wsjtx-1.9.0-rc2/wsjtx-1.9.0-rc2-win32.exe/download

(that’s the windows version - Linux etc. versions are also available from Sourceforge).

I’ll let you know what’s new / different when I find out.

73 Ed.

Here we go - from the Doco: (https://master.dl.sourceforge.net/project/wsjt/wsjtx-1.9.0-rc2/wsjtx-main-1.9.0_en.pdf )

WSJT-X Version 1.9 offers nine different protocols or modes: FT8, JT4, JT9, JT65, QRA64, ISCAT,
MSK144, WSPR, and Echo.

New in Version 1.9
For quick reference, here’s a short list of features and capabilities added to WSJT-X since Version 1.8.0:
• New FT8 DXpedition Mode to facilitate high QSO rates in pileup situations
• Decoding improvements for JT65 mode, including a priori (AP) decoding when VHF/UHF/Microwave
features are enabled
• Optional Auto-Sequencing in JT4, JT9, and JT65 when VHF/UHF/Microwave features are enabled
• Better suppression of low-confidence false decodes generated by AP decoding in FT8 mode
• Improved decoding performance for WSPR mode, especially effective at LF and MF
• Minor adjustments to auto-sequencing behavior
• More flexible Doppler control features for EME
• Improved waterfall sensitivity for very weak signals
• Automatic real-time forwarding of logged information to N1MM Logger+
• Expanded and improved UDP messages sent to companion programs
• Bug fixes and other minor tweaks to user interface

So this is the 2nd. release candidate (not yet 100% stable) version that has the extensions for use on DXPeditions and includes a varriety of performance and reliability improvements.

FT8 DXpedition Mode (Advanced tab in settings).

• Check Fox if you are a DXpedition station operating in FT8 DXpedition Mode. Check Hound if you wish
to make QSOs with such a Fox. Be sure to read the operating instructions for FT8 DXpedition Mode.

(Document here: physics.princeton.edu/pulsar/k1jt/FT8_DXpedition_Mode.pdf )

System Requirements
• SSB transceiver and antenna
• Computer running Windows (XP or later), Linux, or OS X
• 1.5 GHz or faster CPU and 200 MB of available memory; faster machines are better
• Monitor with at least 1024 x 780 resolution
• Computer-to-radio interface using a serial port or equivalent USB device for T/R switching, or CAT
control, or VOX, as required for your radio-to-computer connections
• Audio input and output devices supported by the operating system and configured for sample rate 48000
Hz, 16 bits
• Audio or equivalent USB connections between transceiver and computer
• A means for synchronizing the computer clock to UTC within ±1 second

FT8 DXpedition Mode:
• This special operating mode enables DXpeditions to make FT8 QSOs at very high rates. Both stations
must use WSJT-X Version 1.9 or later. Detailed operating instructions for FT8 DXpedition Mode are
available online. Do not try to use DXpedition mode without reading these instructions carefully!
FT8 DXpedition mode is suitable for use only by legitimate DXpeditions and those
attempting to work them. Do not try to use DXpedition mode for normal FT8 operation.
1 http://www.physics.princeton.edu/pulsar/K1JT/FT8_Operating_Tips.pdf
2 http://physics.princeton.edu/pulsar/k1jt/FT8_DXpedition_Mode.pdf


#2

Checking the WSJT Yahoogroup, there is discussion on how the features in WSJT-x could be used for SOTA and it seems someone has worked it out.

This is from the list - so in reverse sequence - newest at the top.

Black Michael Feb 15 9:14 AM

I’ve got macro expansions working. Starting list is this…suggestions welcomed. I’ll note that using “FD” was discussed before and discounted as few would know what it means and I wonder how many would be trying to figure out a state that beings with “F” :slight_smile:
The restriction on these macros is it needs to be after your callsign otherwise the other side can’t quite handle the format. On older versions they will just see the short macro instead of the expansion.

So like this:
CQ W9MDB /1

msg.replace(" /0"," 1010");

msg.replace(" /1"," SPLIT UP");

msg.replace(" /2"," SPLIT DOWN");

msg.replace(" /C"," CONTEST");

msg.replace(" /E"," EMAILME");

msg.replace(" /F"," FIELDDAY");

msg.replace(" /S"," SOTA");

msg.replace(" /T"," TEST");

msg.replace(" /X"," DXPEDITION");

de Mike W9MDB

Show message history

Hi Mike,

As I understand it, you can already send 2 letter directional CQ’s, so this is already possible:

CQ FD W9MDB EM49, or CQ SS W9MDB EM49
We would only need the macro codes for things longer than 2 characters (perhaps such as SOTA, CONTEST, 1010, QRP, EME*, DXPED MODE, VHF TEST MODE, etc.) Being able to have 36 potential macros sounds like it could really cover a lot of potential phrases! It almost sounds too good to be true!

I am not that familiar with the way WSJT-X is structured, but if the macro file could be accessed as a text file stored in the default WSJT-X folder, then it would be easy for users to download updated macro files as they became available.

You also might be able to use such a macro to identify something like the length of the sequence being used, provided there was a compatibility in the decoding between 15 second and other longer (but potentially more sensitive sequences). However, there may be easier ways to determine this automatically.

Very interesting possibilities :wink: VY 73, Lance

  • I know FT8 was not developed as an EME mode, so I initially added this to the list sort of tougue-in-cheek. However, now that I think about it, most of my recent 2m EME contacts have been stronger than -22 dB, so I wonder if maybe there would be some interest in using FT8 on EME :wink: I don’t know that the stability would be good enough for most stations to use such a narrow bandwidth mode on EME, though. I know on 6m EME, it often seems like JT65A in Deep Search mode often could still stand another dB or two of sensitivity…

On 2/14/2018 16:49, Black Michael wrote:

I wonder if we could implement some 2-char macros for that kind of thing?

Something like:
/S - SOTA
/0 - TEST
/F - FIELD DAY

If first char of token is “/” then it’s a macro that gets expanded.

Sounds pretty simple…old versions would see the macro…current ones the expansion. Could have 36 macros.

So you could do
CQ W9MDB /F

de Mike W9MDB

On Wednesday, February 14, 2018, 10:41:33 AM CST, ‘Lance Collister, W7GJ’ w7gj@… [wsjtgroup] wsjtgroup-noreply@yahoogroups.com wrote:

I understand the required protocol, but it sure would be nice to be able to use some
of the extra characters in the message to add something like “SOTA” (or possibly some
other standard acronyms like “TEST” or “CQWW”) onto the end of the CQ message… VY
73, Lance


#3

And Now V 1.9RC3 has been released.

The version for Windows is downloadable from here:

http://physics.princeton.edu/pulsar/K1JT/wsjtx-1.9.0-rc3-win32.exe

What I have found so far is a new selection on the main screen “CQ Only” so I presume that then only displays CQ calls on receive.

Here’s the release summary:

	Release: WSJT-X Version 1.9.0-rc3
	         March 18, 2018
	---------------------------------

Changes from WSJT-X Version 1.9.0-rc2 include the following:

  • Corrected a number of flaws in Fox behavior, FT8 DXpedition Mode

  • Allow Hounds to use compound callsigns

  • Write debugging information to FoxQSO.txt.

  • Fix the “Blue Decode Button” bug

  • Allow partial processing of incoming UDP Reply messages so that
    non-CQ/QRZ decodes can be processed. The processing is the same as
    double-clicking the same decoded message within WSJT-X except that
    "Enable Tx" will not be enabled.

  • Send DX grid locator to wsjt_status.txt, for use by applications like
    PstRotatorAZ

  • Correct the display of DXCC status of KG4 calls

  • Updated copy of cty.dat

  • Updates to documentation

  • Other minor bug fixes

  • This release contains updated Hamlib functionality including changes
    to the Yaesu FT-817 back end that allows the uBITx kit transceiver
    to be CAT controlled by WSJT-X.


#4

Good news, Michael!
That would be great to see one day time adjustment out of other stations’ signals. Looks easy to implement, but fixed stations don’t need it. Not as accurate as gps sync, but vital for remote portables.

Another issue is the fox restriction as “only for dx-peditions”. Activators are not equal to dxpeditioners, but the principle may save battery life very much.

Free frequency choice for foxes is a big step forward for dx-peditions, but portable station may miss many correspondents in case of using alternative freq.

Finally non-Windows tablet support would push the mode to the mountains.
Maybe goat-sloath mode will be developed soon…


#5

Hi Sergey,
The concept that the “DX Pedition mode” was brought in for is a station running a pile-up. This is the same as we often have as SOTA activators, so in principal we should be able to work the software in the same way.

WSJT-x is available not only for the Windows platform but also for a few different distributions of Linux (even Rasbian for the Raspberry Pi), MAC OS X and the source code is freely available for anyone to compile to their own platform of choice.

While in theory, it should be possible to find a smart phone with enough power to run the code, the screen size can be a problem. Perhaps the newest “Phab-lets” with their 6.5 and 7" screens might suffice, but in my opinion a 10" tablet is really the minium size I would run the program on.

73 Ed.


#6

Hi Ed
Im sure I have read that the DXpedition foxnhound mode is only to be used for big rare dxpeditions and not any common portable mode. It uses frequencies outside the FT8 allocation.

Do the special callsign features in dxpedition mode carry over to normal operation?

73
Ron
VK3AFW


#7

Ron

I believe F&H might be available to the general public with a cap of 2 simultaneous QSOs (or some very low number) as it is as you point out currently intended for DxPeditions.

Choice of frequency while somewhat “fixed” by convention doesn’t necessarily preclude us operating somewhere close but different. If FT8 ever took off for SOTA then we might benefit from operating near the current FT8 frequencies to avoid being lost in the crowd.

A recent test was conducted of F&H which attracted 100s of hounds.


#8

Hi Ron,
The DXpedition mode needs to be enabled by the DXpedition station and the chaser stations in WSJT-x and they need to be on the same version. If this is not done, the software works with the longer sequence as it did two versions ago.

As for “whether” we should use the DXPedition mode for SOTA and whether the developers would object is one question - the capabilities of the DXPedition mode “may” be extended later specifically for SOTA but as it currently is - it would IMHO technically work - just how the SOTA reference is sent needs to be agreed.

While the software is still in Release candidate (RC) mode, out for testing, now could be a good time to approach the developers about use of DXP mode for SOTA.

Paul, Agreed we shouldn’t use the multi-signal mode.

73 Ed.

P.S. there is a new version of the separate PDF describing how the DXPedition mode works:

physics.princeton.edu/pulsar/k1jt/FT8_DXpedition_Mode.pdf


#9

IMHO FT8 operation on all bands has turned into a rat-race, and this new DXpedition mode is only going to make things worse. Already, people are running more and more power, split frequency operation has become the norm (using two 50 Hz band-slots for each QSO), and it is already a case of “survival of the fittest” - trampling rough-shod over lower-powered stations and calling on top of existing QSOs. I will not be using FT8 for SOTA.

73,
Walt (G3NYY)


#10

Hi Walt,
On the split frequency point, I believe that is the preferred mode as otherwise caller number 2 & 3 etc. are transmitting on top of the station responsing to caller 1.

I have to agree, the norm now appears to be to use high power, which not only flattens low power stations if it happens to be calling back on the same frequency but the wide signal also desenses EVERYONEs receivers, even if they are not involved in or listening to that QSO !

Ed.


#11

Yep, I’ve gone off it already! It’s a victim of its own success. I too won’t be using it for SOTA or indeed at home. I will stick to PSK31, PSK63 and JT-65, assuming there will be someone left to work on these modes. Maybe it’s time to see whether I can raise anyone - hoping they have not all gone over the FT8 like Lemmings over a cliff.

73, Gerald G4OIG


#12

Hi Gerald,
It is what it is - some people like it but I can’t help thinking that now that the “only show stations calling CQ” function has been added we’re only a few lines of code away from fully automated mode. Switch it on and stand back and wait for your log to fill up!

That’s not Amateur Radio.

Ed.


#13

So instead of that, callers 2 & 3 etc respond on random frequencies, flattening other QSOs that are already in progress.
I have lost count of the number of times that I have exchanged just a single over with a station, only to be wiped out by another QRO station replying, split frequency, to someone’s CQ call elsewhere in the band. It is thoroughly antisocial.

73,
Walt (G3NYY)


#14

Just to be clear, this “band” that we refer to is actualy just one frequency on the amateur band and at different points within the audio bandwidth of the rig - which is usually 2.4 or 2.8KHz wide as the SSB mode is used.
As you say in split mode the AUDIO frequency chosen by a responding station (QRO or QRP) is random and therefore a percentage of the times the frequencies used by stations could (and do) clash.

I think the developers have realised this and the data exchange has been changed in the DX mode - the way that works part of the audio range is reserved for executing the QSO and another (higher) part of the audio spectrum is used for the initial call from chasers (sorry hounds).
The DX calls in the bottom part of the audio range but the “hounds” (chasers) have to call in a different (higher) part of the audio-band to be heard.
Once the DX station latches on to one of the callers, it is sent a code to come down into the bottom part of the audio spectrum to complete the QSO. In this way all the interfering “rabble” stay up in the upper part of the audio band and cannot interfere with the DX station.

If this same logic were to be implemented in normal operation, and people used different frequencies, not all sit on one frequency, many of the problems we are talking about would go away.

At present we might have 50 stations operating at the same time in the space normally taken by 1 SSB station (2.4KHz) this has advantages in good use of the spectrum but disadvantages as that small block gets conjested.

Let’s hope the deveopers see this the same way and implement the needed changes in a later version of WSJT-x and the FT-8 protocol so that “normal” CQs also filter into the two parts of the audio spectrum.

73 Ed.


#15

Hi Walt
Maybe you werent heard and “your” frequency looked clear. QRO?
73
Ron
VK3AFW


#16

Hi Ed
That would be just like WSPR but at higher power.
73
Ron
VK3AFW


#17

The non-release candidate 1.90 version of WSJT-x has been released today 29/05/2018.
It is recommended that anyone using a release candidate (RC) version of WS-JTx upgrade to this version (in fact one of the conditions of trying any RC version of software is that you upgrade once the relaese (supported) version is available).

73 Ed.


#18

I shall be sticking with Ver 1.8.0 which suits me just fine.

I neither need nor want the new, antisocial features which have been added in Ver 1.9.0

73,
Walt (G3NYY)


#19

Hi Walt, I’m genuinely interested which do you think at the antisocial ones?
Compton

New Features and Enhancements in WSJT-X Version 1.9.0
-----------------------------------------------------

  • New FT8 DXpedition Mode to facilitate high QSO rates in pileup
    situations: for details see
    http://physics.princeton.edu/pulsar/k1jt/FT8_DXpedition_Mode.pdf

  • Decoding improvements for JT65 mode, including a priori (AP)
    decoding when VHF/UHF/Microwave features are enabled

  • More flexible Doppler control features for EME

  • Improved AFC capability for the wider JT65 sub-modes to help with
    drifting signals

  • Optional Auto-Sequencing in JT4, JT9, and JT65 when
    VHF/UHF/Microwave features are enabled

  • Corrected S/N measurements for the JT9 slow/wide submodes

  • DX grid locator sent to wsjt_status.txt, for use by applications
    like PstRotatorAZ

  • Improved decoding performance for WSPR mode, especially effective at
    LF and MF

  • Improved waterfall sensitivity for very weak signals

  • Optional forwarding of logged information to N1MM Logger+

  • Expanded and improved UDP messages sent to companion programs

  • Allow partial processing of incoming UDP Reply messages so that
    non-CQ/QRZ decodes can be processed. The processing is the same as
    double-clicking the same decoded message within WSJT-X except that
    "Enable Tx" will not be enabled.

  • Adjustable main-window geometry with a “splitter” between the two
    text panels.

  • Better support for macOS using hi-DPI Retina displays

  • Updated Hamlib functionality including changes to the Yaesu FT-817
    back end that allows the uBITx kit transceiver to be CAT controlled
    by WSJT-X.

  • Correct the display of DXCC status of KG4 calls

  • Decoded CQ calls where a prefix has been used as a suffix should
    have the DXCC entity name assigned correctly in almost all cases

  • Hamlib, support for TRX-Manager added.

  • Hamlib, improved support for FLRIG.

  • Updated copy of cty.dat


#20

All of them.

The only feature which really was in need of addressing was the program’s inability to handle non-standard callsigns properly (e.g. GB60OT, OT70WRA, etc). There has been no progress in this respect.

73,
Walt (G3NYY)