A second hour-long FT4 “practice contest” set for May 14 UTC has been cancelled, following the success of an initial mock contest held on May 9 UTC (the evening of Wednesday, May 8, in continental US time zones). The event followed ARRL RTTY Roundup rules, with everyone working everyone. WSJT-X program suite developer Joe Taylor, K1JT, was among those jumping into the fray. He called the exercise “very useful” and has drawn some preliminary conclusions as to how the FT4 protocol functions in a contest setting.

“FT4 works well, but — as implemented WSJT-X 2.1.0-rc5 — it has some rough spots and performance issues,” Taylor said in a post to the Yahoo WSJT Meteor Scatter and Weak Signal Group. “Many of these have been fixed already during this beta-testing period, and more improvements are still to come.”

Taylor said a second mock contest session using the current -rc5 “release candidate” (beta version) would not be helpful, and it’s not convenient for the developers to build and distribute -rc6 in time for a session early next week, a few days before the Dayton Hamvention. “Instead, we are aiming now to release WSJT-X 2.1.0-rc6 about 2 weeks later — probably in the last week of May or the first week of June,” Taylor said. “Another mock contest practice session will be scheduled soon after that release.” The current -rc5 beta version will expire automatically on June 7.

Taylor said he used a program build that was probably closer to the pending WSJT-X 2.1.0-rc6 beta version than to -rc5. “With my dial set at 7.090 and a 4 kHz displayed spectral window, my waterfall was mostly filled with FT4 signals from well before 0000 UTC to well after 0100,” he said. Taylor managed some 60 stations in 22 states, four Canadian provinces, and in two DXCC entities.

“Generally I found WSJT-X to work well in FT4 contesting mode, but I noted several behavioral oddities that still require attention,” Taylor continued. For example, he said the “TU” message need only be sent once, and if the new station needs to be called again, the leading “TU” should be stripped. He also noted that the “Call 1st” check box becomes unchecked in certain circumstances. “This was intentional, part of an attempt to defeat robo-QSOs; but there may be a better way to address this issue,” he remarked. He said the “Best S+P” button was effective, but feels its behavior can be improved. “Its selection of a ‘best’ caller should favor new multipliers, and perhaps also stronger signals,” he said. “Currently, the button only functions as desired during a reception interval.”

In a post to the Yahoo WSJT Group, Rich Ferch, VE3KI, described the mock contest in one word: “chaotic.” He requested eliminating the “feature” that lets the operator continue to call a CQ-ing station, even after the station has come back to someone else. “At the very least, make it wait until the other QSO is over before calling,” he said.

Before the practice event, Taylor said the developers were “looking for feedback on what works well, what does not, and what an FT4-enabled contest might be like.”

If you took part, post your observations and comments to the Yahoo WSJT Group reflector, the WSJT Development Group Mailing List, or the RTTYDigital list.

The WSJT-X Development Group reports that it’s aware of several other anomalies in the -rc5 version of WSJT-X 2.1.0. In addition to unexpected program crashes, the program will reset itself to FT8 protocol after the operator accesses the Settings screen. The current build of WSJT-X 2.1.0-rc5 does not run correctly under macOS.

Installation packages for Windows and Linux are on the WSJT-X page. A full release of WSJT-X version 2.1 is targeted for release in July 2019.