WSJT-X reports time difference > 2 seconds on Windows 10

All of the JT modes (JT65, JT9), and now the new mode FT8 are sensitive to correct system time within a couple of seconds. This is because the transmit/receive cycle starts and stops at a predetermined time, and the software of each transmitting station and each remote receiving station need to be in sync in order for each transmission to get successfully decoded.

FT8 seems to be forgiving within about 1.5 seconds of difference, but above this it flags the delta between stations in the DT column:

On a new laptop with Windows 10, even though the date and time is set to set automatically using a remote time server on the internet, almost every FT8 transmission received was consistenly > 1.5 seconds in difference.

To fix this I downloaded and installed Dimension 4 and set it to start automatically. Sync’d the time and now we’re all set – you can see the received calls below in the DT column are all now within a couple of 0.1s after the sync:

Configuring WSJT-X to log to N3FPJ for ARRL Field Day (part 1)

My amateur radio club (RCARCS) uses N3FPJ logger for Field Day (we run N3FPJ on one laptop and the log from each station over WiFi). This year I want to have a go at setting up a digital mode station to log automatically to N3FPJ from WSJT-X to run some FT8, and also from fldigi to work PSK and RTTY. First up, let’s look at getting WSJT-X working.

WSJT-X doesn’t log directly to N3FPJ (it does to N1NM though), but it does indirectly through the intermediate helper app JT-Alert. The setup we’re going to do then is:

WSJT-X -> JT-Alert -> N3FPJ Field Day logger.

Starting with N3FPJ, the first step is to enable the Server API from Settings / Application Programming Interface:

The next step after installing JT-Alert is to select ACLog (N3FPJ’s main logging app) in the settings. The options give you a setting to connect to a locally running ACLog, and while this works for a local N3FPJ’s ACLog app, it doesn’t for N3FJP’s Field Day logger. This part is not obvious, but to configure JT-Alert to log to the Field Day logger even if on the same PC you configure the remote connection settings and then also point it to the .mdb log file of the locally running N3FPJ:

Here you also select the log type is ‘Field Day’. This approach for the config is in the Help docs for JT-Alert here:

Next, configuring network options in WSJT to allow JT-Alert to connect. Without making any other changes, if you start JT-Alert and then start WSJT you’ll see these two dialogs which tell you what settings you need to change in WSJT:

In WSJT settings on the reporting tab, select all 3 checkboxes in the UDP section, and replace the default 127.0.0.1 with your current IP address, e.g.

To use FT8 for Field Day, WSJT has a setting to customize the exchange to include the required class and ARRL section:

To test out the config so far, start the apps in this order: N3FPJ, JT-Alert, WSJT. To test logging a QSO, enter a test call in the DX Call field and press the Log QSO button:

… note here when running Field Day mode you should enter the correct exchange sent and exchange received so the QSO is logged correctly in N3FPJ.

The log is automatically sent across to N3FPJ via JT-Alert:

I noticed if you don’t manually enter the exchange sent and received then it will populate just the callsign field with the sent and received still blank. If you complete both as you log from WSJT then the log entry is saved into N3FPJ automatically.

Note: in JTAlert v2.13.6 I noticed the above steps work fine on Windows 10 if you are logged in as an Admin user. If you log in as a regular user, JTAlert will not copy logs across to N3FPJ, unless you start JTAlert with ‘Run as Administrator’. Also, it will pop up the warning message saying that it failed to check if the log was successfully written, even though it is written to N3FPJ successfully. There is a timing setting in the JTAlert Performance settings to increase the length of time before the N3FPJ is checked for a successful log, but it doesn’t appear to make any difference for this issue.

Next up, I’ll look at getting fldigi setup to also log direct to N3FPJ.

Observing HF Propagation on 20m from US West Coast to East Coast

Spent a few mins operating FT8, and PSKReporter is showing 2 very distinct bands of reception reports, at approx 1200 miles and 2400 miles to the East from my location in Davis, CA:

I’m guessing the first band is propagation with 1 hop and the second band on the East coast is the second hop. It very distinctly shows how in between these two areas there’s noticeable dead zones where I’m not being heard at all. Very interesting!