JTTY on an Android phone: an example QSO and a crib sheet

Updated 5 October: a POTA mode that sends your park reference, a QTH setting, transmitting on the station you tap, and why some messages take more frames than others.

JTTY is the new keyboard mode in WSJT-X 3.2. It works like RTTY: there are no timed sequences, you type, and the other station answers when they like. But it is far better at weak signals and makes far fewer errors. A signal is about 127 Hz wide, and text arrives in frames of 1.9 seconds.

I’ve been writing an Android app for it, jtty-android. It runs the IC-705 over WiFi through wfview, so the phone is the whole station: waterfall, decoder, macros and log. It has three sets of F-keys: Contest (WSJT-X’s own), Casual and POTA. This post is the crib sheet I wish I’d had for the first few QSOs.

Setting it up

The phone talks to wfview over the network: CAT through wfview’s rigctld server (port 4533) and audio through its TCI server (port 50001). Two settings caught me out, and neither one shows an error when it’s wrong:

• wfview: Settings → Radio Access → Audio System must be TCI Audio. Otherwise the TCI connection succeeds, and wfview even sends S-meter readings, but no audio. The app’s waterfall stays black while wfview’s own waterfall runs happily, because wfview’s comes from the radio’s scope, not from the audio. The app now says “wfview is connected but sending no audio (is its Audio System set to TCI Audio?)”.
• IC-705: the DATA MOD input must be WLAN, not USB. Otherwise PTT keys the radio, but it transmits nothing.

In the app’s Settings, fill in your call, grid, name, QTH and rig once. The macros use them, so you don’t have to type them during a QSO.

Reading a line

112649 -12 1496   JR1NHD DE OK2WO

A trailing … means more frames are still arriving. x ... y means a frame was lost in the middle (fading). A fragment such as KON means the start was missed.

Tap a line to reply. That fills in His call and moves both your RX (green) and TX (red) frequencies onto the station.

That TX move matters. The station you call only decodes its own RX window (its frequency ± 50 Hz) and WSJT-X’s fixed 1200–1800 Hz search, so a call from anywhere else may never be seen. When you’re the one calling CQ, callers come to you instead: Hold TX frequency in Settings keeps your TX still while tapping callers moves only RX.

An example casual QSO

With the mode chip (next to Message) on Casual, the eight F-keys run in the order a QSO uses them. Here I answer W9XYZ’s CQ:

When I’m the one calling CQ, it’s F1, then F3 (W9XYZ 599 IO70) to whoever answers, then F5, F6 and F7 the same way. Turn on Hold TX frequency for that, so tapping a caller doesn’t move your TX.

While His call is filled in, the app decodes only my RX window, so the transcript stays quiet during the QSO. Pressing Log saves the QSO, clears His call and goes back to searching the whole band.

An example contest QSO

With the chip on Contest, the keys are WSJT-X’s own JTTY defaults: 599 plus a serial number.

Send your own call to answer a CQ (F4). F5 sends only his call: he won’t know who’s calling, and you’ll get a QRZ?. I learned that on air.

An example POTA activation

With the chip on POTA, a My park field appears next to His call (GB-0123, or GB-0123,GB-0456 for a two-fer). FT8 can only say “POTA” in a CQ; JTTY sends free text, so the park reference itself goes over the air.

Between QSOs, F6 is a one-frame CQ G8GDS CQ: anyone tuning in has had the park from F1. When a hunter asks PARK?, F5 sends it again. An activator runs a CQ, so Hold TX frequency is worth turning on here.

Hunting works in any mode. Tap an activator’s CQ W9XYZ CQ POTA US-0005 and the log form picks up his park. In POTA mode, F8 calls another activator with your own park for a park-to-park: W9XYZ G8GDS GB-0123.

Crib sheet

Words you’ll see

Casual F-keys

POTA F-keys

Contest F-keys (WSJT-X 3.2 defaults)

Placeholders

A key whose placeholder is empty is greyed out. Pressing it says what’s missing, for example “F5 needs My name in Settings”.

Frames cost time

Each frame takes 1.9 seconds and carries one of two things: a compact atom the protocol knows (a call, a whole CQ G8GDS CQ, 599 IO70, a Field Day class), or up to 5 characters of free text. Calls, grids, reports and serials are cheap; anything else is spelled out 5 characters at a time.

That explains the odd costs. A park reference isn’t an atom, so GB-0123 is always 2 frames (GB-01 + 23). Worse, a word inside a CQ breaks the atom, and the whole message falls back to free text, callsign and all:

So the POTA keys keep the CQ whole and put POTA and the park after it. Some more costs:

That’s why the casual keys send 599 rather than a real SNR: -12 costs a frame more. %R is there if you want it.

Logging

Log, next to Send, opens a form filled in from the transcript:

• the start time, from his first message or my first call to him
• the frequency, from the dial plus my TX offset
• the report I sent
• his report and grid, or his serial in a contest
• his park, if he sent one, and mine in POTA mode

Anything can be corrected before saving. Log in the top bar lists the QSOs, and Export ADIF shares the log file.

Parks go in the standard ADIF fields: mine as MY_SIG POTA / MY_SIG_INFO, his as SIG POTA / SIG_INFO. After an activation, Export POTA shares the day’s QSOs from my park in the file pota.app expects, named like G8GDS@GB-0123-20261005.adi (one file per park for a two-fer).

ADIF has no JTTY mode yet, so QSOs are written as MODE MFSK, SUBMODE JTTY, which is what WSJT-X 3.2 does too. QRZ and desktop loggers take them, but LoTW won’t until TQSL learns the submode.

Links

• WSJT-X 3.2 User Guide, which covers JTTY
• My earlier post on wfview audio switching