1. DXLab@groups.io

Re: Default Mode in Capture Window

g4wjs
 

Joe,

WSJT-X supports short-codes and in modes like JT65 they are not merely historical artefacts, they are a very efficient mechanism of passing a 3-bit binary piece of information (RO, RRR, or 73), i.e. a confirmation of receipt or signoff. Short-codes are detected by the decoder with enhanced sensitivity, not just used visually on the waterfall, although as they have no FEC other than repetition, they may be interpreted visually by the operator even if the decoder fails to recognize them. To that end markers are drawn on the waterfall to aid visual detection, each short-code consists of an alternating tone between the lowest sync tone and another frequency denoting which short-code it is.

A QSO might go like this (repetition and message averaging elided), meanings of messages exchanged appended:

CQ G4WJS IO91                  # G4WJS makes a general call
         G4WJS K1JT FN20       # K1JT replies
K1JT G4WJS OOO                 # G4WJS acknowledges the K1JT call
         RO                    # K1JT acknowledges (short-code)
RRR                            # G4WJS acknowledges (short code
         73                    # K1JT signs off (short-code)
Note that even though 'OOO' is printed nothing is sent in the message meaning 'OOO', instead any message of the form "<DX-call> <DE-call> <grid-square>" (where <grid-square> is optional) is simply printed, when short-codes are enabled, as an 'OOO' message. I.e. the 'OOO' is not a short-code message, it is just a decoration at the Rx end on a normal 72-bit payload JT65 message.

MSK144, commonly used for meteor-scatter QSOs below 2m, uses a different type of short-codes which are full fledged messages which are shortened by various reduced sensitivity encoding techniques in order to increase the message repeat rate. The intent is to utilize shorter duration meteor trails to complete a QSO in progress quickly, with some sacrifice of sensitivity and decoding robustness. These are not human readable other than that there is a clear audible difference between a normal MSK144 message and a MSK144 short-code message, determining which particular short-code message has been received requires systematic decoding by software.

73
Bill
G4WJS.

On 14/10/2020 23:23, Joe Subich, W4TV wrote:
> # Any objections to this proposed enhancement to DXKeeper?

The "shorthand" reports are becoming less frequently used as
more users adopt WSJTX to replace the older WSJT due to the
automation built into WSJT.  As Bill points out the shorthand
reports are an artifact of CW (where they were easier to
recognize by ear) and the original WSJT (where they were easy
to "see" in the waterfall).  The shorthand reports have little
if any advantage given the improved decoding in the most recent
versions of WSJTX.  Logging the actual receive levels is just
as common as the shorthand reports.

I don't see the need for unique defaults - at least for those
using WSJTX or WSJTX/JTAlert given their integration with
DXLab Suite.  The bigger issue with WSJTX/JTAlert is entering
propagation mode on a QSO by QSO basis - particularly if one
is running the K1JT modes on a second rig not controlled by
Commander at the same time as "traditional modes" on a rig
connected to Commander.

73,

   ... Joe, W4TV


On 2020-10-14 6:00 PM, Dave AA6YQ wrote:
# even more AA6YQ comments below

    * more AA6YQ comments below
    
            + Are "OOO and RO" appropriate for JT65 in all cases, or only when
            the propagation mode is set to EME?

        Only for EME

    * Thanks, Joe. With the propagation mode set to EME, are "OOO and RO" appropriate as default signal reports for all K1JT modes, or just JT65?

    * 000 is the default "RST sent" and "R0" is the default "RST Rcvd" - correct?


those types of reports are optional even in JT65 mode. In general they are used when fixed dual alternating tones are used instead of encoded messages for the acknowledgement and sign off stages of QSOs. These so-called short codes have increased sensitivity allowing QSOs to be completed with marginal propagation and station equipment. They hark back to CW EME operating where repeated single charcters or pairs of characters are sent for a complete period, i.e. OOOOOOO..., RORORORO..., RRRRRRR..., 737373737373... . They are used, by prior agreement, after callsigns are exchanged using regular messages.

# Thanks Bill! Based on your comments above and the "EME QSOs" section of the document Iain N6ML recommended:

<http://www.arrl.org/files/file/18JT65.pdf>

# it would seem appropriate for DXKeeper to use OOO and RO as the default signal reports when the Propagation Mode implies very weak signals: EME,  Meteor Scatter (MS), and Tropospheric Ducting (TR).

# Any objections to this proposed enhancement to DXKeeper?

             73,

                     Dave, AA6YQ



--
73

Bill

G4WJS.
Join DXLab@groups.io to automatically receive all group messages.