ARRL SS - display missing/invalid exchange when incomplete

[w7sst]

Description

When running ARRL SS, if the Precedence is copied incorrectly (148 C 72 OR instead of 148 B 72 OR), MRCE will send ? until the user corrects the exchange. The user may not understand why their entered exchange is invalid. By displaying the error, the user can correct it.

Steps To Reproduce

1. Start ARRL SS Contest
2. Copy a QSO and enter an invalid Precedence value (e.g. enter C instead of the correct Precedence value)
3. Press Enter
4. The simulation will send ? and the calling station will repeat the exchange.

Expected behavior

The user should see an error that the Precedence value is wrong. This will help newer users to this contest learn to copy the Precedence portion of the exchange correctly.

Actual Behavior

MRCE sends ? and calling station repeats the exchange. The user may not know or recognize what is wrong.

Reproduces how often

100%

Version information

• Morse Runner version: v1.85-rc1

Additional context

• This problem is new for ARRL SS Contest given its complex exchange. With other contests, it has not been necessary to display an error when sending the ? after pushing Enter.
• For me, it took me a while to realize that the Precedence was wrong because I had entered what I thought was a valid exchange (e.g. 157 A 72 OR vs 157 C 72 OR).
• When only a part of the exchange is entered, e.g. 157 A 72, then an error is not necessary because the user can plainly see that they have entered only 3 of the required 4 parts of the exchange.

Tasks

• Fix the bug
• testing and validation
• code review and integration
• release notes

[w7sst]

Hi Jim,

I wanted to get your opinion on this one. You can read the first part of this Issue above.

Secondly, I was wondering if this ARRL SS Exchange Parser is being too strict? The current parser rules are expecting a valid Precedence character to be entered (e.g. must be one of Q, A, B, U, M, or S); otherwise the parser will skip this token. When the user has entered 4 tokens, they may think it is correct.

The alternative would be to log the invalid character and display the error. Perhaps I am suggesting that any 1-character token can be considered a Precedence value since any 2 or 3 character values are being treated as a Section.

Thoughts?

Thank you,
Mike W7SST

@K6OK

[K6OK]

Hi Mike. I think sending the ? over-the-air is the correct behavior along with strictly requiring the Prec in [QABUMS] condition. If there's a wrong Prec, it should be shown in the entry field, but upon Enter the program should send the "?" but not log it until corrected. Same goes for a typo in the Section.

I've had the displeasure of experiencing this myself in the actual SS. I copy the exchange, slap the Enter key thinking it's good in the log, but instead of hearing my CQ go out I hear me transmit the ? and the other guy is re-sending the exchange to me. A little embarrassing because my typo error caused us both to waste contest time. I see it as valuable for the MRCE user to practice this ahead of time, so if they do make a typo, the user will know what to look for and to listen for the exchange again. ARRL SS is not a beginner's CW contest so I don't believe the program should provide extra "help" in guiding them what to fix. -- Jim K6OK

[w7sst]

Hi Jim. I agree with what you are saying above. I will make sure that '?' is sent when the exchange is not correctly copied by the user.

However, I do notice a possible exception. The keys ('.', '+', '[', ',') are documented as "send TU and save the QSO". In this case, MRCE should follow the user's command by sending TU and saving the QSO. Current code is sending TU but not saving the QSO because the QSO is not complete.

For this case, I'll change the code to allow the QSO to be saved, even in the case where the data is not complete.
-Mike

[w7sst]

Also, Shift-Enter, Alt-Enter and Cntl-Enter are documented as "Save QSO without sending anything." In this case, we should save the QSO as is without any error display. Currently the code is not saving the QSO.

[K6OK]

Agree, "forced logging" should be supported. -- Jim

[w7sst]

Verified per prior conversations with Jim.

Jim, do you agree this can be marked as verified and closed?

@K6OK

[K6OK]

Mike -- I agree, verify and close.