Introduction to a weak-signal digital mode
Have you ever wondered how much of the noise you hear on the HF bands is actually comprised of signals too weak to be copied? JT65A is a weak-signal digital mode that allows you to pull great DX out from under the noise on the high frequency spectrum. The JT65A communications protocol was conceived and first implemented by Joe Taylor, K1JT. Joe, a Professor Emeritus of physics at Princeton University, shares a Nobel Prize with Russell Alan Hulse (ex-WB2LAV) for the discovery of the first pulsar in a binary system as well as the first confirmation of the existence of gravitational radiation in the amount and with the properties first predicted by Albert Einstein. Joe has contributed to the amateur radio community in much the same way, changing the playing field for weak-signal operation.
JT65A is actually a "sub-mode" of Joe's original JT65 protocol, which he designed to optimize EME contacts on the HF and VHF bands. JT65 includes error-correcting features that make it very robust, even with signals much too weak to be heard. It was later realized that this protocol, with some adaptation, would also be very usable for terrestrial HF communications.
Join the Facebook community for JT65A here: https://www.facebook.com/jt65mode
This is a WEAK-SIGNAL digital mode! - You should not run much power, at all. Many amateur radio operators have worked the world with a simple dipole antenna and 20 watts. Some have done it with less power. You simply should NOT be running 100 watts, UNLESS YOU ABSOLUTELY HAVE TO! By running at 100 or greater power, you MAY cause intense interference to all of the other stations on the same frequency, countering any possible benefit of using this mode! DO NOT RUN HIGH POWER UNLESS YOU KNOW FOR CERTAIN THAT YOU CANNOT COMPLETE THE TWO-WAY CONTACT WITHOUT LOWER POWER! USE ONLY THE POWER NECESSARY TO COMPLETE THE CONTACT! The method suggested is to start all calls with lower power, and only increase the power if you must. Most operators start with 5 to 20 watts. They only increase the power if no contact is made!
It is true that on some bands, under certain propagation conditions, the contact can only be accomplished with 100 watts of power. However, it is also true that under many conditions on most HF bands, it is often demonstrated that lower power has been sufficient to accomplish amazing results. THIS MODE IS DESIGNED FOR WEAK-SIGNAL DETECTION AND SUCCESSFUL TWO-WAY COMMUNICATION!
How much power do you really need to transmit, with JT65A? Here is a calculator to help you figure that out, based on the reports you receive from other JT65A stations.
Here is a list of common JT65A frequencies:
Freq kHz / Sideband / Note 28076.0 / USB 24920.0 / USB * note 3 * 21076.0 / USB 18102.0 / USB 14076.0 / USB 10139.0 / USB * see note 1,2 * 7036.0 / USB (International) 7039.0 / USB (Typically Europe) 7076.0 / USB (USA) 3576.0 / USB 1838.0 / USB 1805.0 / USB
* Note 1 * Do not use 10145-10150kHz because JT65A is NOT COMPATIBLE with PSK31, MFSK, or RTTY and the other fast time-sharing modes such as PACTOR, ALE, PSKmail, and APRS.
* Note 2 * It is becoming a standard practice on 30m to actually use 101378 kHz as the window frequency (USB), to play 'nice' with WSPR stations. This, of course, is an issue with certain countries/regions where digital operation is not allowed below 10140 kHz. However, most JT65A appears to be shifting to 101378 for a window (dial) frequency. This issue with the frequency problem between IARU regions needs to be resolved. I will update this when new information is available.
- NOTE 3: Per discussion amongst the JT65A crowd on the reflectors: There is discussion about moving the 12-meter window frequency, USB to 24927. THIS IS A PENDING ISSUE: Those amateur radio operations in Region 3 must operate at 24920 to 24929. Discussion is currently underway to resolve an issue with using 24920 KHz (PSK-31 since 1999). I will update this list as soon as a new concensus is reached. (last updated October 1, 2011)
Special Two-Part Article Published in CQ Amateur Radio Magazine
David Witkowski (W6DTW) and Tomas Hood (NW7US) co-authored a two-part article that was published in CQ Amateur Radio Magazine in October and Novemember 2010 that explored JT65A and the JT65-HF Software. You may download the two PDF files, below.
From the article, here are some excerpts about JT65A... some "basics":
Installing the JT65-HF Software
The older JT65-HF software installation package is found at http://sourceforge.net/projects/jt65-hf/. NOTE: JT65-HF-Comfort is a new branch of development of JT65-HF. Joe is not sure that he will continue with JT65-HF, and so someone has stepped up to start moving forward with a branch of development code-named "Comfort". See: the general site for the JT65-HF Comfort branch of software. Here is the download page -- look toward the bottom of the page for the Installer. Currently, the latest version, 3.3, is here via this link. Execute the installation file, after you download the most recent version. If you receive a Security Warning box, be sure to 'allow' the installation to proceed. Follow the 'Setup - JT65-HF' installation wizard prompts (accepting the License Agreement, and all defaults), until the software is fully installed.
After installation is complete, start JT65-HF and click on 'Station Setup'. The 'Configuration' dialog appears, defaulting to the first tab, 'Station Setup'. Be sure to configure each setting and field with the appropriate information (callsign, Grid Square, and so forth). When these fields are properly completed, click on the second tab, 'RB/PSK Reporter/Rig Control'. This tab allows you to select from several rig control options, including Ham Radio Delux software (which must be running if you select this option). Also on this tab are the options to report stations 'decoded' by JT65-HF to the PSK Reporter web server, and the reverse beacon server.
When you have configured your station settings and operating preferences, click the 'Save Settings and Close Window' button.
The JT65A QSO
The JT65 protocol makes use of compression to pack as much info into the period as possible, but even with compression the maximum of 13 characters can be sent in a random-text message. Supported characters are limited to 0-9, A-Z (caps only), space, and some punctuation. This is NOT a rag-chewing mode!
0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ +-./? (Note: space is between Z and +)
A standard JT65 QSO contains everything necessary for a valid QSO: callsigns, grid squares, and signal reports. The standard QSO requires 6 periods (i.e. 6 minutes) and proceeds like this:
CQ K1JT FN20 (First station calls CQ) K1JT W6DTW CM97 (A second station answers CQ w/ grid square) W6DTW K1JT -18 (CQ station sends signal report) K1JT W6DTW R-16 (Answering station sends "R" + sig report) W6DTW K1JT RRR (RRR indicates that the R+signal was received OK) K1JT W6DTW 73 (RRR was received OK) W6DTW K1JT 73 (The end of the QSO, K1JT signs '73')
You may have noticed that some of these messages contain more than 13 characters. This is because the JT65 protocol uses a few clever tricks to increase the data compression efficiency, but only if the message is written in a standard pattern, such as those shown above. The 13 character per message limit applies only to random text. Some JT65A ops have taken to using their 73 sequence to offer info on their setup, so it's not uncommon to see "K1JT W6DTW 73" replaced with "VERT25W W6DTW" (indicating 25W on a vertical) or "DPL10W W6DTW" (indicating 10 watts on a dipole). Sometimes when people are having trouble you will see messages such as "CHECK CLOCK" or "NO COPY QRZ?" The use of "TU7" (short for "thank you and 73") has been gaining popularity.
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.
YOU MUST SET YOUR PC CLOCK TO THE EXACT TIME
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.
THIS CANNOT BE STRESSED ENOUGH
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), from Joe (W6CQZ):
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.
73 - Joe - W6CQZ