Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve QSO exchanges after entering partial callsign #315

Closed
4 tasks done
Tracked by #350
w7sst opened this issue May 31, 2024 · 3 comments · Fixed by #317
Closed
4 tasks done
Tracked by #350

Improve QSO exchanges after entering partial callsign #315

w7sst opened this issue May 31, 2024 · 3 comments · Fixed by #317
Labels
enhancement New feature or request fixed - ready for validation bug is fixed; ready for validation

Comments

@w7sst
Copy link
Owner

w7sst commented May 31, 2024

Summary

When the user has copied only part of the simulated callsign, the station will respond by repeating its callsign and sometimes its exchange. When doing so, there are currently limited messages being returned. Actual contests use different and shorter messages as compared to the MRCE simulation. This change is related to Issue #314.

Motivation

Improved realism. One of the goals of MRCE is to create a realistic contest simulation. This change will improve the realism of the contest exchange when partial callsigns are entered.

Detailed Description

After the user enters a partially-correct callsign, the existing simulation will return the following messages:

DE <call> <exch>
DE <call> <call> <exch>
<call> <call> <exch>

Seasoned contesters will minimize the length of messages being sent by eliminating the DE and sending both corrected call and exchange information. To that end, we will add the following (shorter) messages:

<call> <call> <exch>
<call> <exch>
<call> <call>

Both sets of response messages should be sent in a random manner with priority given to the shorter messages.

Additional context

I found this paper, Do's and Don'ts of CW Contesting and More Do’s and Don’ts in CW Contesting, written by Rob Brownstein, K6RB. It discusses recommended practices for CW Contesting. It was posted by the K1USN group who sponsor the weekly CWOPS SST Contest. I thought it was a good read.

On page 2 of the second article in the above link, it mentioned:

Some people will hold off sending an exchange if a runner sends the wrong call. For example, if I sent K4PP 5nn ca to K3PP, he may send K3PP K3PP and pause without sending an exchange. I would then send K3PP 5nn ca. Then, he would send tu 5nn pa. However, doing this delays both the runner and pouncer, and only the runner is at risk of losing points. So, why not be a good citizen and send K3PP 5nn pa rather than holding off the exchange. If the runner gets it, and fixes it, then great. If not, you’ve done your job without delaying either of you.

Based on the above, we should keep the exchange after the corrected callsign and increase the frequency of responses of this type. We also want to shorten the responses as mentioned in the article.

Tasks

  • Coding
  • Code Review and integration
  • Testing
  • Release Note
@w7sst w7sst added the enhancement New feature or request label May 31, 2024
@w7sst w7sst added this to the v1.85 - next release milestone May 31, 2024
@w7sst w7sst self-assigned this May 31, 2024
@w7sst w7sst changed the title Improve QSO exchanges during partial callsign Improve QSO exchanges after entering partial callsign May 31, 2024
@w7sst
Copy link
Owner Author

w7sst commented May 31, 2024

Here is the link to build v1.85-dev.3 which includes this change.

@w7sst
Copy link
Owner Author

w7sst commented Jun 1, 2024

The comment below is copied from the Pull Request/Review...

When running a simulation, sometimes a callsign is copied incorrectly and entered into the Callsign exchange entry field. After hitting Enter, the partial callsign is sent. The calling station will respond with a corrected callsign and optionally the exchange information.

There are two scenarios.

1 - User sends partial call only (using F5 function key)

This condition can easily be created by following these steps:

  1. start a simulation in Single Call mode.
  2. Enter the calling callsign, but change the last letter.
  3. Hit F5 to send the partial callsign.
  4. This will now enter the osNeedCallNr state.
  5. The calling station will send a response with the corrected callsign and optional exchange.

State osNeedCallNr

The following messages are sent after receiving a partially-correct callsign from the user without an exchange.
The first column shows the original messages and the second column shows the revised messages.

Original Freq Revised (v1.85) Freq
DE <call> 50% DE <call> 16.7% (1/6)
DE <call> <call> 50% DE <call> <call> 16.7% (1/6)
. . <call> <call> 16.7% (1/6)
. . <call> <call> <exch> 16.7% (1/6)
. . <call> <exch> 33.3% (1/3)

The following is the new code showing the responses for this case (osNeedCallNr).

    // osNeedCallNr - They have sent an almost-correct callsign.
     osNeedCallNr:
      if (RunMode = rmHst) then
        Result := msgDeMyCall1
      else
        case Trunc(R2*6) of
          0: Result := msgDeMyCall1;    // DE <my>
          1: Result := msgDeMyCall2;    // DE <my> <my>
          2: Result := msgMyCall2;      // <my> <my>
          3: Result := msgMyCallNr2;    // <my> <my> <exch>
          4,5: Result := msgMyCallNr1;  // <my> <exch>
        end;

2 - User sends partial call and their exchange (using Enter key)

This condition can easily be created by following these steps:

  1. start a simulation in Single Call mode.
  2. Enter the calling callsign, but change the last letter.
  3. Hit Enter to send the partial callsign and exchange
  4. This will now enter the osNeedCall state.
  5. The calling station will send a response with the corrected callsign and exchange.

State osNeedCall

The following messages are sent after receiving a partially-correct callsign and exchange information from the user.
The first column shows the original messages and the second column shows the revised messages.
Notice the revised messages are now always sending the exchange. I suppose I should leave out the exchange on one of these.

Original Freq Revised (v1.85) Freq
DE <call> <exch> 50% DE <call> <exch> 16.7% (1/6)
DE <call> <call> <exch> 25% DE <call> <call> <exch> 16.7% (1/6)
<call> <call> <exch> 25% <call> <call> <exch> 33.3% (1/3)
. . <call> <exch> 33.3% (1/3)

The following is the new code showing the responses for this case (osNeedCall).

    // osNeedCall - I have their Exch (NR), but need user to correct my call.
    osNeedCall:
      if (RunMode = rmHst) then
        Result := msgDeMyCallNr1
      else
        case Trunc(R2*6) of
          0: Result := msgDeMyCallNr1;  // DE <my> <exch>
          1: Result := msgDeMyCallNr2;  // DE <my> <my> <exch>
          2,3: Result := msgMyCallNr2;  // <my> <my> <exch>
          4,5: Result := msgMyCallNr1;  // <my> <exch>
        end;

w7sst added a commit that referenced this issue Jun 9, 2024
After entering a partial callsign and exchange information, the user
will hit `Enter` to finish the QSO and log the QSO. The QSO is not
logged.

This was caused by the logging module only comparing for a perfect match
against the caller callsign and not considering the common occurrence of
a partially-correct callsign. Code was changed to allow a
partially-correct callsign. This allows these QSO to be included in the
log as expected.

Checkin notes:
```
Improve handling of partial callsign matches

- Report both callsign and exchange errors in QSO log.
- Add argument to IsMyCall to enable random result for lids.
```

Issue #315 will add improved messages for the partially-correct callsign
case. This next review will be posted soon.

Once the second pull request/review is submitted, I will post an
engineering build for testing. Stay tuned...
@w7sst w7sst linked a pull request Jun 9, 2024 that will close this issue
@w7sst w7sst removed their assignment Jun 9, 2024
@w7sst w7sst added the fixed - ready for validation bug is fixed; ready for validation label Jun 9, 2024
@w7sst w7sst mentioned this issue Sep 10, 2024
24 tasks
@w7sst
Copy link
Owner Author

w7sst commented Oct 7, 2024

Closing this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request fixed - ready for validation bug is fixed; ready for validation
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant