Thursday, March 3, 2022

The Amusing Side of FT8 Slowness

Recently I wrote about my perspective versus others on the slowness of FT8. I would rather use the faster FT4 but since few bother I am stuck with the slower digital mode. A recent experience demonstrates a peculiar advantage of its slow speed. I relate the story so that you can laugh along with me. (I know that I need a distraction, if only briefly, from world events.)

I was monitoring FT8 activity on 160 meters (1.840 MHz) one evening while I was busy with other tasks in the shack. My interest was to monitor the activity for interesting DX. I would occasionally glance at the monitor to see what was coming through. Perhaps something rare would pop up to incite me to transmit.

Nothing terribly exciting was heard other than some countries to the south. One of these had a compound call sign of the form XX/YYYYY. I could see about 6 or 7 stations vying for his attention. On a whim I called and he came back to me.

We exchanged reports and he sent RRR. Before my 73 message could be sent, WSJT-X crashed.

The error message meant nothing to me so I closed the Windows info boxes that popped up and tried to restart WSJT-X. Nothing happened. I opened the Windows Task Manager and paged through the active processes and found an orphaned process belonging to the app. I clicked the process, pressed End Task and exited the Task Manager. WSJT-X started successfully this time.

I expected to find that the other station had abandoned our QSO and gone on to work one of the other callers. But when the decoded messages scrolled past there he was still sending me RRR. Surely at least 2 minutes had passed! I'm surprised that he stuck with me through at least 4 transmit periods.

Since WSJT-X lost its state data in the crash I had to jump into the QSO manually. I clicked on the RRR message, selected a clear frequency to transmit and clicked Enable Tx to send 73. I don't know how fast I did all this since it worked and the QSO was completed. My reflexes are fast since I am a contester. Luckily I remembered the sent and received signal reports so that could I manually entered them in the log window.

As soon as I did that and breathed a sigh of relief WSJT-X crashed again.

I went back into the Task Manager and killed the orphan process. Then I checked the log to confirm that the QSO was saved. Before restarting the app I went to the WSJT-X web site to see if this was a known bug. It was and it was fixed in the latest release (2.5.4), which I had not yet installed. The text of the bug fix was perfectly descriptive of what had occurred:

WSJTX: - Repair a defect that caused occasional crashes when in QSO with stations using nonstandard callsigns.

I have a habit of delaying installation of software updates since they can introduce new bugs, I may not use the features that have been fixed, and I am in no rush to explore new features. This is a case where I should have updated sooner.

Completing a CW or SSB QSO with such a long period of silence would never have happened. The slowness of FT8 came to my rescue. Sometimes slow can be good.

No comments:

Post a Comment

All comments are moderated, and should appear within one day of submission.