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

Do not get an R from dx station after correcting a bad call #370

Closed
1 task done
w7sst opened this issue Oct 9, 2024 · 15 comments · Fixed by #371
Closed
1 task done

Do not get an R from dx station after correcting a bad call #370

w7sst opened this issue Oct 9, 2024 · 15 comments · Fixed by #371
Assignees
Labels
bug Something isn't working verified Bug is fixed and verified

Comments

@w7sst
Copy link
Owner

w7sst commented Oct 9, 2024

Description

As reported by Bob, @WR7Q

Hi Mike,

I am using Windows 11 and CQ WPX.

I have been playing with this a bit and found the following:

When I put in the incorrect callsign and it sends it again, then I put the correct one in, I just get his exchange. I do not get an 'R' which is necessary to receive before I go on.

73,
Bob WR7Q
CWA Admin

Steps To Reproduce

Expected behavior

Actual Behavior

Reproduces how often

Version information

  • Morse Runner version: 1.85
  • OS/Version: Windows 11

Additional context

Can you help?

Please let us know if you are available to help. (replace '[ ]' with '[x]' to affirm)

  • Yes, I'm available to help test a solution to this problem.
@w7sst w7sst added the bug Something isn't working label Oct 9, 2024
@w7sst
Copy link
Owner Author

w7sst commented Oct 9, 2024

Hi Bob,
I have tried to reproduce this, but I am missing some information from you. Are you using function keys to send your actions, or the ENTER key? Can you provide extra details on how you are sending each message.

Thank you,
Mike

@WR7Q
Copy link
Collaborator

WR7Q commented Oct 9, 2024 via email

@w7sst
Copy link
Owner Author

w7sst commented Oct 9, 2024

Hi Bob,
One more question... Are you able to reproduce this problem on the prior release 1.84? Or on the original 1.68?

Thank you,
Mike

@WR7Q
Copy link
Collaborator

WR7Q commented Oct 9, 2024 via email

@WR7Q
Copy link
Collaborator

WR7Q commented Oct 9, 2024 via email

@w7sst
Copy link
Owner Author

w7sst commented Oct 9, 2024

Hi Bob,

  1. Are you running in Single Call mode or Pile-Up mode?
  2. When the DxStation responds each time, are they sending their exchange and are you entering it along with their corrected callsign.

Thanks,
Mike

@w7sst
Copy link
Owner Author

w7sst commented Oct 10, 2024

Hi Bob @WR7Q ,

I have been trying to reproduce and I don't think I am able to reliably reproduce the problem. My testing is showing the same behavior on both 1.84 and 1.85. I know some logic has changed in 1.85, especially in the fixes for the ghosting issue.

To help reproduce this issue, can you help provide...

  1. Are you running in Single Call mode or in Pile-Up mode? I have been running Single Call mode.

  2. What have you entered in the various exchange fields before you send? When you send your information, what are you using (either function keys or Enter). You have already told me you are sending the callsign with the Enter key, but I also need to know the contents of the Number field (i.e. have you entered their serial numbers).

  3. Next, what does the DX Station send back to you after you send the corrected callsign. I think you have said they send the callsign only.

Please let me know these details for both 1.84 and 1.85. The bug is deep inside the state machine of the DX Station and the state of each field is used in determining the next state of the state machine and thus what the DX Station will send next.

I have studied and compared the code between 1.84 and 1.85 and cannot see any obvious changes. I have instrumented my code to help the debugging process, but I am lacking the extra detail of what is being sent by you (the field contents), how you send it (which key or Enter) and finally what the DX Station is sending back. This extra information will really help.

Thank you for your help.
Mike

Adding @scotthibbs

@WR7Q
Copy link
Collaborator

WR7Q commented Oct 10, 2024 via email

@w7sst
Copy link
Owner Author

w7sst commented Oct 10, 2024

okay. I'm guessing that you have only entered the callsign, and not their serial number exchange.

@WR7Q
Copy link
Collaborator

WR7Q commented Oct 10, 2024 via email

@WR7Q
Copy link
Collaborator

WR7Q commented Oct 10, 2024 via email

@w7sst w7sst added the confirmed This bug has been confirmed label Oct 10, 2024
@w7sst w7sst self-assigned this Oct 10, 2024
@w7sst
Copy link
Owner Author

w7sst commented Oct 10, 2024

Hi Bob,
I was able to reproduce the issue you are reporting. Thank you for the extra information.

I have also found the problem in the code and will get a fix ready. We can consider a 1.85.1 bug-fix release in another month or so. We would want to see if any other bugs are reported.

73, Mike

@WR7Q
Copy link
Collaborator

WR7Q commented Oct 11, 2024 via email

@w7sst
Copy link
Owner Author

w7sst commented Oct 11, 2024

Hi Bob,

Here is a build containing a fix to this issue. Do you have time to give it a spin and verify the fix for us?

Thank you and 73,
Mike W7SST

w7sst added a commit that referenced this issue Oct 11, 2024
- this problem was introduced in 1.85
- Note: When MorePatience was introduced in May 2024, a bug (Issue #370) was
  introduced causing the DxStation to not send an 'R' after the user corrected
  a callsign. The case involved the user sending a corrected callsign using
  the Enter key while leaving the exchange fields blank (user sends
  '<his incorrect call> ?'. In this case, the DxOperator.MsgReceived function
  would call MorePatience for the '?' and the Patience value was set to 4.
  This caused DxOperator.GetReply() to send the wrong response:
      DxOperator.GetReply(osNeedEnd, Patience=5) --> 'R <HisCall>'
      DxOperator.GetReply(osNeedEnd, Patience=4) --> '<HisCall>'
  To fix this problem, MorePatience will maintain an existing Patience value
  of 5 (FULL_PATIENCE) and not set it to 4. Resolved in October 2024.
@w7sst w7sst linked a pull request Oct 11, 2024 that will close this issue
@w7sst w7sst added fixed - ready for validation bug is fixed; ready for validation and removed confirmed This bug has been confirmed labels Oct 11, 2024
@w7sst w7sst added this to the v1.85.1 - Bug fix release milestone Oct 11, 2024
@WR7Q
Copy link
Collaborator

WR7Q commented Oct 11, 2024 via email

@w7sst w7sst added verified Bug is fixed and verified and removed fixed - ready for validation bug is fixed; ready for validation labels Oct 11, 2024
w7sst added a commit that referenced this issue Oct 14, 2024
- this problem was introduced in 1.85
- Note: When MorePatience was introduced in May 2024, a bug (Issue #370)
was introduced causing the DxStation to not send an 'R' after the user
corrected a callsign. The case involved the user sending a corrected
callsign using the Enter key while leaving the exchange fields blank
(user sends '<his incorrect call> ?'. In this case, the
DxOperator.MsgReceived function would call MorePatience for the '?' and
the Patience value was set to 4. This caused DxOperator.GetReply() to
send the wrong response: DxOperator.GetReply(osNeedEnd, Patience=5) -->
'R <HisCall>' DxOperator.GetReply(osNeedEnd, Patience=4) --> '<HisCall>'
To fix this problem, MorePatience will maintain an existing Patience
value of 5 (FULL_PATIENCE) and not set it to 4. Resolved in October
2024.
- Issue #370
w7sst added a commit that referenced this issue Oct 24, 2024
Minor change mentioning removal of 100-person subscription limit on
groups.io. This is in addition to prior changes relating to Issue #370.

Also updates version number to v1.85.1 for release.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working verified Bug is fixed and verified
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants