CALLER disappears and another calls

[w7sst]

Description

This bug was reported by Mark, K5GQ, and started as an email conversation between Mike, W7SST, and Mark. I am pasting this email conversation below so we can move the discussion into this github issues so others can participate and provide feedback as well.

Copy of Mark's original email to me...
On Tue, Jun 4, 2024 at 5:54 AM Mark ... wrote:

Mike,

There are two items with version 1.84.

In this case I was using ARRL Field Day. I also saw it on WPX

The audio level of the caller varies from faint to very loud; the frequency of the audio level changing requires me to instantly be able >to adjust the level up or down. For me this is not enjoyable addition. Can it be switched OFF!
I am listening to morse runner over bluetooth headset. All band conditions are unchecked, activity is at 2.

I am having trouble documenting how to reproduce this annoyance.
The wrong call is entered and sent, if you did not correct it on the 2nd time a different callsign is heard.
If you do not get the call correct and send it - a different station is heard.

Mark

Steps To Reproduce

• As Mark describes through the email conversation below, this bug is hard to reproduce. Mike thinks it is related to partial callsign matches occurring when 2 stations are calling at the same time with similar callsigns (e.g. W7S and W7H). See the conversation below.
• Our initial goal is to reproduce this problem so it can be understood and fixed.

Expected behavior

Mark, do you want to add any additional detail here? If so, please edit this description.

Actual Behavior

Mark, do you want to add any additional detail here? If so, please edit this description.

Reproduces how often

Version information

• Morse Runner version: 1.84
• OS/Version: [e.g. Windows 10]

Additional context

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.
• Understand the problem
• code a fix
• test it
• release notes

[w7sst]

On Wed, Jun 5, 2024 at 7:39 PM Mike Brashler ... wrote:

Hi Mark,
Thank you for reaching out and reporting these two issues.

I will get back to you in the next day or two with a longer response.

In short, the first issue is fixed and will be available in the next release. The second issue is new, but I want to learn more from you. It seems you are the first to report an issue using bluetooth headphones. I will elaborate in a day or two.

73,
Mike W7SST

[w7sst]

On Wed, Jun 5, 2024 at 7:40 PM Mike Brashler <...> wrote:

I worded that wrong. The second issue if fixed; the first issue it not. sorry about that.

-Mike

[w7sst]

On 2024-06-08 12:51 am, Mike Brashler wrote:

Hi Mark,
Thanks again for your feedback.

Concerning the second item where the caller disappears... This has been a known problem for some time now. We have called this behavior "ghosting" where the caller disappears after starting the QSO. You can read more about this issue and solution here: #200. It turned out the root cause of this problem had been around since the original software was written. It turned out a random number generator was creating a situation where the caller would disappear almost immediately - this was occurring about 6% of the time. Many people have been seeing it.

Concerning the first item where the audio is getting louder and you find yourself adjusting volume control and tuning. At first, when you mentioned bluetooth headset, I immediately thought that MR was generating a clipped signal that was overloading your bluetooth device. After looking in the code, I don't think that is the case. I now think you are finding an annoyance of the software where the user has to tune RIT in order to copy a station in low-activity situations.

In a large pile-up situation with high activity, callers will be off frequency and the user will have to adjust RIT up/down to find/copy the caller. However, when there is low activity (e.g. your case w/ Activity=2), the callers will most likely be on frequency, so the need to adjust RIT up/down will be less. Perhaps you are seeing this up/down tuning as the annoyance you are reporting. Currently, the code is creating a station that is +/- 300Hz above/below your calling frequency. This is a 600 Hz window and with a 500Hz bandwidth receive window, you will have to adjust the RIT to receive some of the stations. A recent change was for Single Call mode, the created stations are within +/- 50Hz of your station. This results in not having to use the RIT to copy the station. Perhaps we need to do something similar for Pile-Up mode where we restrict calling stations to be near to the user's calling frequency.

Would you please consider reporting this problem as a new issue in github.com? I'd like to start a conversation with other MR advocates (and yourself) to see if we can find a solution. We are trying to balance usability with creating a realistic contest simulator.

You can report the new issue here, perhaps as a feature request: https://github.com/w7sst/MorseRunner/issues/new/choose

I would also encourage you to join our efforts on github.com? You do not need coding experience, only an interest in making MR better for the user community. I'd like to invite you to join us. We would appreciate your help and insight as a MR user. Please visit us at www.github.com/w7sst/MorseRunner/#readme. I think you only need to create a github user account.

If you join us, we will get you a copy of the engineering build with your second issue (call ghosting) fixed so you can help test it for us.

Thank you.

73,
Mike W7SST

[w7sst]

From Mark on June 11...

Mike,

I looked at #200.

That is not what happened to me.
I have not seen this in 1.83 (but may not have had enough samples) or in the earlier version.

Tom mention of " call changed slightly. " is the best description of the bug. No callers off frequency. The bug appears to have a slightly different last letter of the call.

Tom, KO4TCL in K5GQ CW Academy intermediate class stated:

I encountered it twice in one run, and no idea what would have triggered it. In one, I waited to hear the call again. The other I hit F8 for NIL. Both times they moved off frequency and the call changed slightly. For the latter, they never came back and I'm assuming perhaps they moved further off frequency. I just restarted the pass at that point.

I do plan to submit this as a new intermittent issue when I achieve details sufficient to reproduce or document better. Unfortunately it is random but using a small database appears to make it happen more often.

Mark
K5GQ

[w7sst]

From Mike to Mark on June 12...

Hi Mark,

Thanks for the detailed information regarding the station appearing off frequency...

I have a quick question... Is the LIDs button pushed in the Band Conditions section? If so, there is random behavior that occurs where the calling station will copy your call wrong. This code is used to compare call signs at the end of the QSO and could prevent the call from going in the log correctly. In 1.85, the code will report the callsign error and allow a new station to be created.

Also, if you are noticing a station moving to a new frequency, then this is a newly created station with a new callsign. If you are noticing a similar callsign from the prior caller, then the call history file may contain similar callsigns. If constructing a smaller call history file, be sure that all callsigns are sufficiently different from each other to stop confusion of callsign that are off by a letter or two.

Thank you.

73 Mike

[w7sst]

From Mike to Mark on June 12...

Hi Mark,

I should also reference two other issues related to caller ghosting that you may not have seen. These two issues, plus issue #20 mentioned earlier, have all been addressed since v1.84 was released. These issues, I'm hoping, will address the caller ghosting issue. Hopefully this will also address that you are seeing. If not, I'll work with you to try to get it resolved.

These other issues are:
#314
#315

Plus the original:
#200

Thank you.

73 Mike

[w7sst]

From Mark to Mike on June 12...

Mike,

1. NO unchecked ... Is the LIDs button pushed in the Band Conditions section?

2. Also, if you are noticing a station moving to a new frequency, then this is a newly created station with a new callsign.
   do not believe so. Seemed very close to my frequency ..

3. The smaller call history file, does have callsigns that are NOT sufficiently different from each. This database has improved mine and others ability get the call correct. Callsign can be off by a Dit or letter;

Mark

[w7sst]

From Mike to Mark on June 13...

Hi Mark,
Thank you for your continued comments.

Based on your comments on (2) and (3) below, you got me thinking about it and I think I might know what is happening here...

The MR logic will compare the call you enter against all stations that are actively calling you. It is possible to have both an "exact match" and a "partial match". If two stations are calling you with similar callsigns and you respond to one of them, both stations will try to finish the QSO with you. If one of those stations is off frequency, you may not know it is there. When you finish the QSO with the first one, the second one will continue to try to complete a QSO.

As a testing technique for you to try, create a database with 24 callsigns, each different by only the last letter (e.g. k5gqa k5gqb, k5gqc, ..., k5gqz). This will force the existing MR logic to always see the "partial callsign match". Using this database, you will see this partial match behavior occurring more frequently and this may help you reproduce the problem. Please let me know what happens.

Also, could you share your current database with me? I'd like to do some additional testing with it. When working on this ghosting call problem, I was worried about the use case of similar callsigns. I had assumed that with a large database of different calls, this would not be a problem. However, in your case, you have created a database with similar callsigns for training purposes.

Also, what Contest, Run mode and Activity settings are you running with?

Thank you,
Mike

[w7sst]

From Mark to Mike on June 13...

Mike,

Easy stuff first.
The data base - attached.
A text and the dta file.

Mark
remorserunner1_84callerdisappearsandanothercalls_.zip
_3 char_Callsigns _743.txt

[w7sst]

From Mark to Mike on June 13...

Mike attached is a 3 character call sign group of 33.

This random problem ran MR just 4 times 6 calls - and did not trigger the problem.

Contest, Run mode and Activity settings are you running with?
WPX SINGLE calls 02

Mark

_3 char_Callsigns _7-A-Z_33.txt
remorserunner1_84callerdisappearsandanothercalls_ (2).zip

[w7sst]

From Mike to Mark on June 13...

Thank you Mark. I will try to look at this over the weekend.

73, Mike

[w7sst]

From Mark to Mike on June 15...

Mike,

when it happens again -

Audio Recording Enabled - You can record yourself under "File" menu
"Audio Recording Enabled". When this menu option is checked, MR saves
the audio as "MorseRunner.wav" in the same folder. If this file already
exists, MR overwrites it

I will go look for the file and rename it.

Mark

[w7sst]

From Mark to Mike on June 25...

Mike,

so far this is what I have been able to reproduce.

Call time
N2S 0-16sec DID NOT ANSWER

W9A 17-21 THIS CALL is SENT just ONCE
I believe heard W9S maybe it was W9H
W9S 23 EXCHANGE SENT - but did not get TU

NIL SENT
w9a I verify W9A using F5 - get NR

program appears normal after this.

problem-morseRunner.txt
Problem-MorseRunner.wav

[w7sst]

From Mike to Mark on June 25...

Hi Mark,

Thank you for this extra information. I have not had a chance to look at this yet. You are giving me really good information here and I appreciate it. I'm sorry I don't have the bandwidth right now to look at it.

When I do get back to this issue, are you willing to take a debug executable from me that will generate a debug message file?

This file will contain debug messages from all the internal decisions made within the program, show all callers, show their transmissions and your transmissions, etc. I would still have to do some coding to get this to generate a separate file (currently it only generates debug output to my debugger). It might be a month out before I can get this to you. It would be based on the latest code base, which is post 1.84. This will still help with debugging of these similar 1x1 callsigns.

Thank you.
Mike

[w7sst]

From Mark to Mike on June 25...

yes Mike I will be glad to. (to take a debug executable from me that will generate a debug message file?)

after weeks of trying to get this bug to appear,
it did

debug executable
with multiple starts stop runs

with each new run, does it overwrite the previous run?

Mark

[w7sst]

with each new run, does it overwrite the previous run?

Yes, the file is overwritten with each new run. Issue #259 suggests that a Save Dialog be allowed to create a user-specified file. Another option is to automatically generate a unique file name (e.g. MorseRunner-nnn.wav, where nnn is a number which increases with each Run command).