Wednesday, October 5, 2011

A video example of a JT65A QSO using JT65-HF Software

A video example of a JT65A QSO using JT65-HF Software

A video example of a JT65A QSO using JT65-HF Software

It should be noted that the worldwide reverse beacon network will only upload received messages if they're in standard pattern. Thus if you write "GUD LUK W6DTW" or "CQ EU W6DTW" the reverse beacon network will ignore the message and you won't see yourself on the spotting lists or maps.


Regarding the requirement to keep your PC clock synchronized: If your station is at home, and you have internet access, then you should use a time sync client such as Dimension4 or Symmtime. Both are free and readily available online. The reason you want this is that the built-in time-sync feature in Windows XP/Vista/7 is not accurate enough to allow proper JT65A operation; you should disable it and use a dedicated sync client.


Your PC clock MUST be set very accurately--and the built in PC synchronization is NOT accurate enough--in order for JT65A to correctly synch with other stations!

If you don't have internet access at home, or are working rover/portable, then you might consider using a GPS dongle together with a software package that locks the PC's clock with the time signals received via GPS. (Many GPS vendors provide a small software utility with the GPS which will do just that, but I've also used the UIView32 APRS software package which can link up with many GPS dongles and adjust your PC's clock.) If you're in a pinch, on a tight budget, and still want to work JT65A, you can try syncing to the WWV tones from NIST in Boulder, CO or other shortwave sources. F6CTE's MultiPSK package comes with a WWV clock receiver application (clock.exe), but bear in mind that PC clocks tend to drift a lot even during a short period of time, so you'll have to tune back to WWV and readjust your clock about every 30 minutes. For best performance you'll want a GPS dongle; these can be purchased online for about US$30.

Usage and Best Practices

Once you have your soundcard interfaced, your PC's clock accurately set, and understand the odd/even QSO pattern you're close to making your first QSO! Usage of JT65A on HF is fairly straightforward; it's very much like PSK31 in that there is a waterfall display of signals in the audio passband. Recall from earlier discussion that by default JT65A transmissions occur at a "DF" (differential frequency) of 1270.5 Hz above the rig's dial frequency; this point in the waterfall is referred to as "DF = 0". However the DF can be adjusted in software to zero-beat with signals above and below this frequency. So a station transmitting at 830 Hz above dial frequency would be said to be at "DF = -440". Transmission of the 65 JT65A tones occurs within a bandwidth of just under 175 Hz, but in practice ops will try to keep their DFs at multiples of 200 Hz to avoid overlapping interference. That being said multiples of 200 Hz isn't a hard and fast rule, and you will see QSOs at almost any point in the waterfall.

Unlike WSJT which (if set to wide decode) only decodes the strongest message, W4CQZ's JT65-HF software will decode all messages in the 2000 Hz receive bandwidth 'window' (which is shown on the 'waterfall').

When using the JT65-HF software, you'll need to adjust your thinking about the waterfall display. Clicking on the waterfall will adjust the TX and RX DF, and you can add the target's callsign and signal report manually into text fields, but there is another way. Let's say that I just decoded a CQ from Valery RW6BN in Russia at DF = -332, and want to respond. Rather than click the waterfall, write "RW6BN W6DTW CM97" in the random text field, select the proper even or odd period, and click "Enable TX" (all of which would be hard to do within the 10 or less seconds I have between decode and the start of the next period) I can simply double click on RW6BN's message in the decode window. This adjusts the TX and RX DF to match RW6BN's DF, generates a standard message, populates the signal report field, sets the even/odd period to be the opposite of RW6BN, and activates "Enable TX". My message back to Valery will begin automatically at the beginning of the next period. Valery will double-click my message to him, click "Answer Caller" and "Enable TX" which will generate his response to me with a signal report. I will then click "Send Report", Valery clicks "Send RRR", and I will either click "Send 73" or enter a message like "DPL50W W6DTW" field in place of a 73. For those of you who don't type very fast, this is a great mode!

Aside from standard amateur practices the use of JT65A on HF requires a few additional considerations for best practice operation. This is mostly due to the sensitivity of the JT65A decoder; excessive power, splatter, poorly filtered TX audio lines, etc can create interference for ops hundreds or even thousands of miles away! For example; in spring of 2010 I noticed that a station in Japan was generating harmonics at 100 Hz intervals above and below his DF. I contacted him and it turns out he had a noisy power supply and the noise (50 Hz line rectified) was mixing with his transmission. From across an ocean I and other JT65A ops could clearly see his problem, and it was generating strong enough harmonics to be decoded at various points in the waterfall.

The JT65 decoder also expects to see the received signal level remain within a fairly narrow range of +/- 5 as viewed on the audio input level meter. Sometimes we see new ops getting started with JT65A who think that to work DX they need to run QRO, which is simply not true, and in fact does this creates havoc for other users because the QRO signal will often overload the decoders of everyone within 1,000 miles. 50 watts ERP is usually more than enough to work anywhere, presuming that propagation exists. WY5R has a confirmed contact with ZS2ACP (South Africa) back in February 2010 from Amarillo TX on 40 meters using 5 watts. ZS2ACP gave WY5R an initial signal report of -10 dB, which means that WY5R could have reduced his power by 10x or more and still remained well within the margin for a reliable decode. Texas to South Africa using 500 milliwatts on 40m - talk about QRP! Stories like this are fairly common in the JT65A community.

Hardware settings are largely similar to other digimodes like PSK31: Set the rig to max power, upper sideband, no compression or equalization, and then adjust the audio levels from the PC during transmit to control RF power out. Adjust the audio levels to control and not the rig's RF power control, because at lower RF power levels the ALC is more likely to kick in and you'll start splattering. Owners of the Elecraft K3 should note that when running digimodes the first five bars on the LCD scale labeled "ALC" are technically just an indication of audio drive level, like a VU meter. The bars after the first five do indicate ALC. So K3 owners should ensure that you're showing no more than 4 or 5 bars on the ALC meter during JT65A transmit.

Be sure to check the manufacturer's rating for your rig's recommended duty cycle; JT65A transmissions are a continuous sinusoid which lasts for about 48 seconds. Most rigs are rated for 50% duty cycle which means if it's rated for 100 watts SSB you should keep the RF power out to 50 watts or below.

On the receive side some care should be taken to maintain an audio level that's as close to zero on the audio input level meter as possible. This is usually set on a quiet channel, or during the 10 second pause between periods presuming no other signals such as Olivia, RTTY, etc are present. If you've set your receive audio level to zero and then find that the level exceeds +5 during someone's transmission you'll probably be OK, but if the signal gets over +10 the decoder will start having trouble and so you'll want to consider adjusting the receiver gain or even activating some attenuation.

While this article is focused mainly on W4CQZ's JT65-HF I wanted to offer a suggestion to users in general, and especially those who choose to operate with WSJT. Both JT65-HF and WSJT support the use of EME "shorthand" sequences for "OOO", "RRR", and "73". These were created for use in extreme cases (such as the 250 dB path loss during a signal's round trip to the Moon and back) and are strongly discouraged on HF. It's really not necessary, because if you've made contact and exchanged calls you almost certainly will be able to send standard messages containing signal reports and your 73. Besides Part 97.119(a) requires that you identify at the end of a QSO, and a "shorthand 73" doesn't meet that requirement. To that end you should note that WSJT offers a feature for sending your callsign in CW, as does JT65-HF with the latest public version (version 1.0.6 at press time).

An other video example of a JT65A QSO using JT65-HF Software

The video author uses TWO videos, one video embedded inside the other, to demonstrate the sending and receiving of JT65A digital signal. He also demonstrates proper sound levels, and so forth. Good demonstration...

Regarding the use of Prefix and Suffix callsigns (DX entities),
As much as I have come to love JT65 it has one huge flaw and that is its handling of prefixed call signs. The JT65 protocol, in my opinion, was originally designed with no thought as to need for prefixed call signs, then, at some point, this need to realized and added. The JT65 protocol - how it structures the bits it sends - is quite elegant, efficient and straight forward when dealing with regular calls, but, the moment you add a prefix or suffix all that simplicity and elegance is lost. The available prefix or suffix values are hard coded and defined from the master source - that being WSJT. In your specific case of PJ4 that is not a defined prefix value so you can't properly use it. The prefix available for PJ are PJ2 and PJ7. For HH the only prefix available is HH, HH7 is not "in the list".

It is not a trivial matter to add/edit the prefix list as it breaks compatibility with previous versions of WSJT... for example, say I added PJ4 to the list as number (a made up number) 350 in the list of prefix values... when you set JT65hf to use PJ4/W6CQZ it would send W6CQZ as usual then send a value of 350 to indicate PJ4 prefix. Any past versions of JT65hf (or any other program that implements JT65) would have a 'old' prefix list ending at 349 and would have no idea what 350 should indicate. It's convoluted, but, sadly the way it works.

So. The unfortunate answer is that if you're going on a DX expedition and won't have a 'real' local to the DX call JT65 is in my opinion totally unsuitable for use. I wish this was not so, but, I'm a slave to the protocol as defined as much as anyone else.

No comments: