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:
My amateur radio club (RCARCS) uses N3FJP logger for Field Day (we run N3FJP 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 N3FJP 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 N3FJP (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 -> N3FJP Field Day logger.
Starting with N3FJP, 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 (N3FJP’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 N3FJP’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 N3FJP:
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: N3FJP, 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 N3FJP.
The log is automatically sent across to N3FJP 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 N3FJP 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 N3FJP, 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 N3FJP successfully. There is a timing setting in the JTAlert Performance settings to increase the length of time before the N3FJP 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 N3FJP.
I’d come across this handy AppleScript before and had it setup and working, but since I’ve been recently re-installing on a new SSD, I’d forgot where I found this. It’s a a script that runs from one of the macro buttons in Fldigi to send contact details to RumLogNG.
Setup instructions are here, and the script and be downloaded from here. Works perfectly.
