Unattended (somewhat) JT9 / JT65 on 40m and JT-Alert
2014-08-11 Leave a comment
Once I had my digital interface in place, I used my new FT817ND with great success for ragchewing using PSK31, several contest-style contacts with W1AW on RTTY, and then some WSPR propagation tests, before I stumbled upon the WSJT-X app by K1JT following some questions from a ham on a local amateur radio club forum.
The new WSJT-X application comes as an upgrade to the older WSJT JT65 app and comes with support for both old JT65 and the new JT9 mode. The new JT9 mode is claimed to be more effective than JT65, plus be using 10-times lesser bandwith, and producing not as profoundly depressive sound as JT65 does. Actually it sounds like a weak continuous wave tone but you can clearly identify it on the waterfall as a digital mode and not someone tuning the finals / antenna.
The both modes are designed for very low power transmissions – 5W being probably the maximum. Still, I heard folks saying they run 10-20W and some ran unnecessarily waaaaay more wiping out AGC and the waterfall as a result…
Power levels 1-5W seems to work best. 10W is probably QRO. What’s really critical is that the computer clock is accurate – within +/- 1 second accuracy. My Lenovo’s clock, for example, runs away 1-2 seconds a day easily.
To achieve that, the easiest is to sync clock with internet time servers – e.g. NIST servers. That can be done by right-clicking on the tray clock icon and then going to adjust date/time, internet time, etc.
The fastest way, is through the command line though:
I have it running in a loop (in background; using batch file) syncing time every 60 minutes.
Next, I read the WSJT-X user manual, then monitored the exchanges for some time to get a grip on best practices, and then ran CQ using JT65 mode for a few hours putting 5W out, and got more than a dozen responses into the log!
Then I tried CQ with JT9 and got just one reply. Seems as the folks are slow in adopting the new mode (app)?
Anyway, the modes appeared utterly boring to me as the exchange is fairly primitive as well as the operator’s involvement required.
There are three turns for each side – each TX/RX cycle takes 1 minute on each side of a QSO with transmission – 50 seconds to transmit (or receive and decode) the message, and then remaining 10 seconds to choose a tiny preset message to reply.
Example of a typical QSO:
- We start with sending CQ – e.g. CQ VA3PAW FN03 (FN03 is the grid locator)
- Another party sends a reply – e.g. W1AW VA3PAW FN31
- To acknowledge receipt – send RST (db power – e.g. -5 db): VA3PAW W1AW -5
- Another party acknowledges and sends their report: W1AW VA3PAW R-7
- We sign-off with RRR or 73: VA3PAW W1AW RRR
- The other party closes with: W1AW VA3PAW 73
Voila. Provided no re-submissions needed, the exchange takes 6 minutes end-to-end. Operator’s involvement is required every 2 minutes to check received messages and choose one of the three available predetermined responses:
There is some leeway with sending free-text messages (up to 13 characters) so some folks use it to send something like:
- TU PSE QSL 73
- 5W 1/4VRTCL
- 73 JIM IN NH
- and so on…
after they close on RST report. That adds 2 more minutes to the loop.
So it takes up to 6-8 minutes to just barely exchange reports…. Even CW is so much faster compared to this. The advantage though is that very faint signals get decoded. There are some rare/remote DX callers come up at times (like Australia, Israel, etc) which signals on CW would be lost in local city noise here anyway on my random wire antenna.
To ensure you don’t miss that DX, there is a nice freeware JT-Alert software that keeps an eye on the band traffic and provides audible alerts when your intervention is required – e.g. someone called us or interesting DX appeared. This way, you can run CQ somewhat unattended and if someone responds to our call – JT-Alert will sound an alert for you to take action and move on with a reply.
Another nice feature of JT-Alert is that all your logged contacts can be automatically added to your logbook (HRD, and other logging software is supported) so you won’t need to import wsjtx.adif every time.
The results after 2 shifts of operation are almost 100 Qs with a number of DXCCs – that probably explains why this mode has a number of followers and is quite popular: