Topics

Default Mode in Capture Window


Fred Kemmerer
 

Hello Dave,

I have been doing quite a bit of 2m EME using MAP65 (a version of WSJT that uses an external SDR receiver to do broadband decoding of JT65 signals reflected off the moon). I am also running DXkeeper and commander as part of my setup.  The MAP65 program does not have a direct logging interface so using JTalert to interface to DXkeeper is not an option. All of this works well except that I need to manually enter the QSO mode (which is always JT65B) for each contact. This is a contesting setup so the contacts come pretty rapid-fire (ex. I made almost 100 contacts on 2m EME this weekend during the ARRL EME contest).

Is there a way to set a default QSO mode, ideally per band, or could such an option be provided? This would be useful in any situation where QSOs are being logged without the availability of an automated radio or another interface which supplies the QSO mode. I encounter this same use case when operating MobileHF and in portable scenarios where a radio interface to my computer is not available.

Here's an image of my 2m EME setup which uses DXLab, MAP65 (the main app for contacts), and WSJT-X as a backup decoder -

AB1OC EME Software Setup

You can read more about the 2m EME Station that we have built here -

2m EME Station Series

Best and 73,

Fred, AB1OC
https://stationproject.blog
https://www.n1fd.org


Dave AA6YQ
 

+ AA6YQ comments below

I have been doing quite a bit of 2m EME using MAP65 (a version of WSJT that uses an external SDR receiver to do broadband decoding of JT65 signals reflected off the moon). I am also running DXkeeper and commander as part of my setup. The MAP65 program does not have a direct logging interface so using JTalert to interface to DXkeeper is not an option. All of this works well except that I need to manually enter the QSO mode (which is always JT65B) for each contact. This is a contesting setup so the contacts come pretty rapid-fire (ex. I made almost 100 contacts on 2m EME this weekend during the ARRL EME contest).

Is there a way to set a default QSO mode, ideally per band, or could such an option be provided? This would be useful in any situation where QSOs are being logged without the availability of an automated radio or another interface which supplies the QSO mode. I encounter this same use case when operating MobileHF and in portable scenarios where a radio interface to my computer is not available.

Here's an image of my 2m EME setup which uses DXLab, MAP65 (the main app for contacts), and WSJT-X as a backup decoder -

AB1OC EME Software Setup <https://stationproject.blog/wp-content/uploads/2020/10/3-EME-Software-Operating-Environment.jpg>

You can read more about the 2m EME Station that we have built here -

2m EME Station Series <https://stationproject.blog/2019/10/21/eme-part1-goals-station-design/>

+ Your screen shot shows Commander controlling an Icom transceiver whose mode is DataU. So in the Radio panel on the General tab of Commander's Configuration window, set the "Log Mode for Data-L or Data-U" selector to JT65B.

73,

Dave, AA6YQ


Fred Kemmerer
 

Thank you, Dave. Your suggestion works great for setting the default mode!

One more item. The default signal reports (599) for JT65x don't make any sense. It would be great if the defaults could be changed to OOO and RO. is there a way to do this with either DXkeeper or Commander? This would make logging much less error prone for EME contacts.

Thank you again!

Best and 73,

Fred, AB1OC
https://stationproject.blog
https://www.n1fd.org


Dave AA6YQ
 

+ AA6YQ comments below

One more item. The default signal reports (599) for JT65x don't make any sense. It would be great if the defaults could be changed to OOO and RO. is there a way to do this with either DXkeeper or Commander? This would make logging much less error prone for EME contacts.

+ At present, DXKeeper defaults the signal report to 599 unless the mode is SSB, FM, AM, or DIGIVOICE>

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

+ What about all the other K1JT modes; should DXKeeper provide different default signal reports for them?

73,

Dave, AA6YQ


Joe Subich, W4TV
 

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

+ What about all the other K1JT modes; should DXKeeper provide
different default signal reports for them?
K1JT modes are very resistant to default signal reports as the
typical report is a signal level between MDS for the submode
and somewhere up to +20 (representing the signal to noise level
in a 2500 Hz passband). When using WSJTX direct or with JTAlert
the signal report is transferred automatically eliminating the
need for default(s) - or using the Capture window.

73,

... Joe, W4TV


On 2020-10-14 1:53 PM, Dave AA6YQ wrote:
+ AA6YQ comments below
One more item. The default signal reports (599) for JT65x don't make any sense. It would be great if the defaults could be changed to OOO and RO. is there a way to do this with either DXkeeper or Commander? This would make logging much less error prone for EME contacts.
+ At present, DXKeeper defaults the signal report to 599 unless the mode is SSB, FM, AM, or DIGIVOICE>
+ Are "OOO and RO" appropriate for JT65 in all cases, or only when the propagation mode is set to EME?
+ What about all the other K1JT modes; should DXKeeper provide different default signal reports for them?
73,
Dave, AA6YQ


Dave AA6YQ
 

* 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?

         73,

             Dave, AA6YQ


iain macdonnell - N6ML
 

On Wed, Oct 14, 2020 at 1:13 PM Dave AA6YQ <@AA6YQ> wrote:

* 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?
It's OOO (Oscar's), not 000 (zeroes) (similarly RO, not R0). Somewhat
described here:

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

73,

~iain / N6ML


Dave AA6YQ
 

# AA6YQ comments below

On Wed, Oct 14, 2020 at 1:13 PM Dave AA6YQ <@AA6YQ> wrote:

* 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?
It's OOO (Oscar's), not 000 (zeroes) (similarly RO, not R0). Somewhat described here:

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

# Thanks, Iain!

73,

Dave, AA6YQ


g4wjs
 

On 14/10/2020 21:12, Dave AA6YQ wrote:
* 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?

         73,

             Dave, AA6YQ

Hi Dave,

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.

73
Bill
G4WJS.


--
73

Bill

G4WJS.


Dave AA6YQ
 

# 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


g4wjs
 

On 14/10/2020 23:00, 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
Hi Dave,

I am not convinced, short codes do get used for EME on some bands but I would not necessarily say it is the default position.

Also the only report is O, there is no report of RO as that is a combination of "roger I have your report, and my report is O", so you would no more log RO as a report than you would log R-13 as a report, i.e. you would log -13 only.

I think that all that is necessary is to be able to log 'O' or 'OOO' as a report, either sent or received. It hardly seems worth logging such reports anyway as merely logging the QSO is evidence that the operator has confirmed that a QSO was completed, i.e. callsigns and one other QSO specific piece of information (gridsquares) have been sent *and* acknowledged both ways.

73
Bill
G4WJS.



--
73

Bill

G4WJS.


iain macdonnell - N6ML
 

On Wed, Oct 14, 2020 at 3:00 PM Dave AA6YQ <@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?
I think it should be for JT65 EME only, if anything. MS and Tropo
these days would be using modes that do not use that form of shorthand
(MSK144, etc).

Where does this "default" come into play anyway? I missed that part of
the thread. Are we talking about manually entered QSOs (e.g. capture
window), or imports that don't specify signal reports, or... ?

73,

~iain / N6ML


Joe Subich, W4TV
 

# 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


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.


Dave AA6YQ
 

+ AA6YQ comments AA6YQ

I think it should be for JT65 EME only, if anything. MS and Tropo these days would be using modes that do not use that form of shorthand (MSK144, etc).

+ My DXing has been limited to the F2, ES, and BS propagation modes, which is why I'm seeking guidance.


Where does this "default" come into play anyway?

+ In his original post, Fred AB1OC stated that he is using MAP65 (a version of WSJT) for 2m EME QSOs, and that "The MAP65 program does not have a direct logging interface so using JTalert to interface to DXkeeper is not an option."

<https://groups.io/g/DXLab/message/196716>

+ I assume that he is using DXKeeper's Capture window to record these QSOs.

I missed that part of the thread. Are we talking about manually entered QSOs (e.g. capture window), or imports that don't specify signal reports, or... ?

+ the SENT and RCVD items are populated with default signal reports when

- you have the "Initialize RST items to 59/599" option enabled on the Configuration window's General tab

- you have Contest mode enabled on the Configuration window's Contest tab

- you double-click the SENT or RCVD item in the QSO panel on the Main window's "Log QSOs" tab

+ There is no option to include default signal reports in imported QSOs.

73,

Dave, AA6YQ


Dave AA6YQ
 

+ AA6YQ comments below

> # 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 request came from Fred AB1OC, who reports that he is using MAP65, a version of WSJT that uses an external SDR receiver to do broadband decoding of JT65 signals reflected off the moon. I assume that Fred would have switched to the current version of WSJT-X if were possible to do so.

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.

+ When WSJT-X is directly interoperating with DXLab, the Propagation Mode specified on the Defaults tab of DXKeeper's Configuration window is logged with each QSO.

+ It seems like we're down to adding an option that when enabled will use default signal reports of O and O if the Propagation Mode is EME.

73,

Dave, AA6YQ


Joe Subich, W4TV
 

+ It seems like we're down to adding an option that when enabled will
use default signal reports of O and O if the Propagation Mode is
EME.
However, according to G4WJS, O and O is not even a signal report in
WSJT:

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.
It would seem that there is no "default" signal report for JT65/WSJT.
Instead O/O simply indicates "signals copied at both ends" (or QSO
complete).

I understand Fred's request for a default but unchecking "Initialize
RST items to 59/599" and leaving those fields blank would be just as
valid as O/O - ie. logging the QSO as complete is equivalent to O/O.

73,

... Joe, W4TV


On 2020-10-14 8:37 PM, Dave AA6YQ wrote:
+ AA6YQ comments below

> # 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 request came from Fred AB1OC, who reports that he is using MAP65, a version of WSJT that uses an external SDR receiver to do broadband decoding of JT65 signals reflected off the moon. I assume that Fred would have switched to the current version of WSJT-X if were possible to do so.
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.
+ When WSJT-X is directly interoperating with DXLab, the Propagation Mode specified on the Defaults tab of DXKeeper's Configuration window is logged with each QSO.
+ It seems like we're down to adding an option that when enabled will use default signal reports of O and O if the Propagation Mode is EME.
73,
Dave, AA6YQ


Dave AA6YQ
 

+ aa6yq COMMENTS BELOW

It would seem that there is no "default" signal report for JT65/WSJT.
Instead O/O simply indicates "signals copied at both ends" (or QSO complete).

I understand Fred's request for a default but unchecking "Initialize RST items to 59/599" and leaving those fields blank would be just as valid as O/O - ie. logging the QSO as complete is equivalent to O/O.

+ Fred AB1OC, are you comfortable with using blank signal reports as defaults instead of O and O (or O and RO)?

73,

Dave, AA6YQ


Fred Kemmerer
 

Thank you for considering supporting default modes. For JT65 EME, RO, and O reports are used almost exclusively. There is basically no use of the -xx signal reports common with FT8/FT8 and some other WSJT-X modes. It might be best if the end-user could set their defaults for at least any modes that are used in EME (ex JT65, QRA64, JT9, etc). If these modes are used for terrestrial contacts, then the -xxx format would be appropriate but when these modes are used for EME (moon bounce), it would need to be RO and O to be useful. I really would like to see the RO and O reports to be available as an option for these modes as it's easy to forget to include them when making contacts rapidly such as during the various EME contests such as ARRL EME. Maybe blank unless an RO, O option is set and one of the EME modes is in set via Commander?
--
Best and 73,

Fred, AB1OC
https://stationproject.blog
https://www.n1fd.org


iain macdonnell - N6ML
 

On Sat, Oct 17, 2020 at 12:12 PM Fred Kemmerer <fkemmerer@...> wrote:

Thank you for considering supporting default modes. For JT65 EME, RO, and O reports are used almost exclusively. There is basically no use of the -xx signal reports common with FT8/FT8 and some other WSJT-X modes. It might be best if the end-user could set their defaults for at least any modes that are used in EME (ex JT65, QRA64, JT9, etc). If these modes are used for terrestrial contacts, then the -xxx format would be appropriate but when these modes are used for EME (moon bounce), it would need to be RO and O to be useful. I really would like to see the RO and O reports to be available as an option for these modes as it's easy to forget to include them when making contacts rapidly such as during the various EME contests such as ARRL EME. Maybe blank unless an RO, O option is set and one of the EME modes is in set via Commander?
As pointed out by someone else in this discussion, the "report" is (if
anything) just "O". "RO" means "[R]oger (I received my report), and
yours is (also) [O]".

73,

~iain / N6ML