Replace the Check column content by the correct data

[f6fvy]

Summary

Currently, the Chk column indicates in red the kind of data that was incorrectly copied (ZN or whatever). I'd find much more useful to display the correct data I was supposed to copy instead (did I miss an 'E', or I mixed up an 'S' with an 'H' ?).

Can you help?

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

• Yes, I'm available to discuss possible solutions and alternatives to this problem.
• Yes, I'd like to review and provide feedback on the proposed solution.
• Yes, I'm available to help test a solution to this problem.

[w7sst]

@f6fvy @scotthibbs @K6OK @WR7Q

I have been working on a prototype for replacing the Check column with corrected data. I like Laurent's suggestion.

Below are three options showing what/where to display the red font. I'd like your feedback on which is easier to read and usable. Thank you, Mike

a) the user-entered data in red

b) the corrected data in red

c) both user-entered and corrected data in red.

I think the column heading should be changed to Corrected not Check.

I also found it interesting that I was unable to log an incorrect callsign. The DxStation would always send their correct call until I either responded with the correct call or hit "NIL".

Any thoughts on the three choices above? Tnx and 73, Mike

[f6fvy]

Thanks Mike for the 3 suggestions. As we've been used to the Check column being in red for years, I'd be more in favor of proposal B, or C.

[scotthibbs]

Hi Mike, I like C myself because it shows what is incorrect and the check in red to show what it should have been. It seems intuitive. As for the column name. I like Corrected better than Check. I don't like the past tense though so "correct" would be better. Maybe "Answer" here. Right Answer, Correct Answer... Nice work! 73 KD4SIR Scott Hibbs 812-581-0631

…

On Mon, Apr 8, 2024 at 6:50 PM Laurent Haas - F6FVY < ***@***.***> wrote: Thanks Mike for the 3 suggestions. As we've been used to the Check column being in red for years, I'd be more in favor of proposal B, or C. — Reply to this email directly, view it on GitHub <#266 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADEITRORZDVM5Q5XJR4MUQDY4MUNBAVCNFSM6AAAAABDTO6SK6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBTHA4DCNJXGQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[f6fvy]

Correct Exchange (or Exch. for short) seems more appropriate

[K6OK]

Please use any column heading other than "Check." That will conflict with ARRL Sweepstakes if that contest is supported. Otherwise you'll have two columns that are called "Check." I think "Correct" is good.

I prefer A -- use red to show only what's in error. Ha, when I was in school the teacher used a red pen to circle what I got wrong :-) Everything in the check column is never wrong by definition so it should never be red.... IMHO.

73 Jim K6OK

[w7sst]

I also just noticed that the existing Chk column also renders the NIL and DUP errors. These two errors are not exchange errors. So renaming the Chk Column to Correct and displaying NIL or DUP may also lead to confusion. We certainly don't want two columns, one for the original error and one for the correction data. Perhaps call this revised column Error?

Using option A, where the user-entered data is colored Red, we can display any NIL and DUP errors in Red in the Correct column. This would let the user's eye go to the error information whether it be an error in the exchange copy or a NIL/DUP error. They would see their errors in either exchange column (Exch1 or Exch2) and any NIL/DUP errors in the Correct column. The correct data (for exchange errors) would be rendered Black in the Correct column.

I think for me I've ruled out Option C where Red is used in both the exchange column and the Correct column. I'm leaning towards Option A and will wait till I have something running to see what looks better. I'll put an option in the INI file so we can play with it for a while.

[K6OK]

Regarding NIL and DUP:

In contesting today "B4" and "DUP" has largely fallen out of favor. The majority of contesters, including myself, simply work the dupe station a second time for zero points. It's faster and more efficient that way than getting into a discussion and scrolling though the log. Just work them and move on. I'd suggest showing DUP in black in the Error column an an information item. It's not an error and contests do not penalize participants for dupes.

NIL -- If the Error column shows the correct call or exchange in red then there's no need to MRCE to say "NIL." It's redundant. If I miscopy the other station's call and it's shown in red, then by definition I know it's not in the other station's log.

73 Jim K6OK

[w7sst]

I will display the DUP in black in the Chk/Correct/Errata/Erratum column. You're right, this should not be treated as an error. I will also try to display other exchange copy errors in the same field for this QSO (i.e. the call is a DUP, but also had an exchange copy error).

Relating to B4, #274 is recommending a replacement for B4.

[w7sst]

NIL -- If the Error column shows the correct call or exchange in red then there's no need to MRCE to say "NIL." It's redundant. If I miscopy the other station's call and it's shown in red, then by definition I know it's not in the other station's log.

I agree with this idea to show the correct call in red and eliminate the NIL due to the redundancy. I'll move in this direction. This change will be under a separate issue due to the additional logic changes required.

[w7sst]

So what do you think of the column name Erratum for the existing Chk column?

[f6fvy]

For me, "Mistakes" or "Errors" are more comprehensible for non-native English speakers but in any case, it's not a big deal.

[w7sst]

For me, "Mistakes" or "Errors" are more comprehensible for non-native English speakers but in any case, it's not a big deal.

Good point.

[w7sst]

I have been thinking about using the column heading "Corrections". This Err column is showing the corrected data. The actual mistake is in the various exchange columns.

Here is option A showing Red user-entered data...

This option shows the "DUP" in black, so not rendered in Red as an error (as recommended by @K6OK).

Here is option B with the Correction column in Red...

The disadvantage of this option is the "DUP" condition is now rendered in Red. Perhaps not a big deal during a simulation because with 1000's of callsigns in the history file, it is unlikely to get a duplicate.

Thoughts???

Note: I am running with 4 calls in my call history file. This helps force the DUP error.

[scotthibbs]

I like A with red user-entered data and the DUP in black. 73 KD4SIR Scott Hibbs 812-581-0631

…

On Sun, Apr 14, 2024 at 7:59 PM Mike Brashler ***@***.***> wrote: I have been thinking about using the column heading "Corrections". This Err column is showing the corrected data. The actual mistake is in the various exchange columns. Here is option A showing Red user-entered data... image.png (view on web) <https://github.com/w7sst/MorseRunner/assets/106113737/bcfbd0bd-ae20-4e7b-81e2-24f3543dc092> This option shows the "DUP" in black, so not rendered in Red as an error (as recommended by @K6OK <https://github.com/K6OK>). Here is option B with the Correction column in Red... image.png (view on web) <https://github.com/w7sst/MorseRunner/assets/106113737/50b98d63-e2d0-46b1-9795-c68417560c55> The disadvantage of this option is the "DUP" condition is now rendered in Red. Perhaps not a big deal during a simulation because with 1000's of callsigns in the history file, it is unlikely to get a duplicate. Thoughts??? *Note: I am running with 4 calls in my call history file. This helps force the DUP error.* — Reply to this email directly, view it on GitHub <#266 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADEITRNKEYTQOH5NOHVM4VLY5MQ75AVCNFSM6AAAAABDTO6SK6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANJUGI2TONRVGU> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[w7sst]

IARU HF Contest changes...

Having the Red in each column is beginning to look busy to me. Perhaps leaving the Red in the Corrections column would help. We would leave the DUP error rendered in Black.

[K6OK]

Having the Red in each column is beginning to look busy to me.

I think it looks perfect just the way as shown. It only looks busy because you are making lots of intentional mistakes.
In 2023 CQ WW CW the median error rate was only 2.9%. And so for the median user it'll never be as busy as shown.
For the new CW student if it does get full of red, that's a useful message to either practice more or slow down or both.
In general only apply red to items that are wrong, so red belongs in the call/RST/Zone columns, not under Corrections, except perhaps the red "NIL" (which puzzles me... how can it be NIL if the call, RST and Zone are all correct?) 73 Jim K6OK

[w7sst]

And the JARL ACAG Contests...

Here is the JARL All Japan Contest...

@jr8ppg We are adding the Corrections column to all reports and dropping the Sent Column. Please let me know if you have any concerns. I will include you in the code review after I convert all contests to use the new Corrections column.

Thank you.
Best regards and 73,
Mike W7SST

[w7sst]

Here is the NAQP Contest change...

I decided to leave the Pref Column in the report. For the NAQP contest, the Pref column is used as the multiplier. I'm not sure what value it adds to the user. I guess the Pref column was part of the original 1.68 WPX/HST contest and we have kept it for most of the subsequent contests.

What do you think, does the Pref column add any value? I suppose it only adds value if we are showing the Score/Mult per qso as a separate column. This Pref column is simply the extracted prefix from the entered callsign.

Note - I'm not sure how I got the NIL error. I think I hit my enter key too soon and the program logic got into a weird state. I'm still trying to figure this one out.

[w7sst]

And finally the CQ WPX ...

The remaining Contest is the HST Contest (which is a variation of the CQ WPX).

[w7sst]

I have a question regarding how to handle the HST Competition Mode. When running HST Competition, there is a Score column. Both the Sent and Received exchanges are included.

To change the log for this contest, I see a couple of options:

A) Replace the Chk column with the new Corrections column. Leave the Sent and Received columns as is. If an error occurs, show the whole field in Red. This will not fit in the current space. However, if the GUI changes increases the width of this window, we would have room.

B) Drop the Sent column, split the Recv column into RST and NR columns. Change the Chk column to Corrections or Correct.

With Option B, I'm wondering if the existing Sent Column is important for the HST contest?

Any suggestions on which way to go here?

Thank you,
Mike

@K6OK @f6fvy @scotthibbs @jr8ppg @WR7Q

[scotthibbs]

Not sure if this applies, but if they ghost BEFORE you correctly enter to post into the log, it is NIL. There is an issue open to correct this since it would be counted (use. I'll leave the design of the results to those actually working the contests. I think it's cool we will get to know what we didn't get correct. 73 KD4SIR Scott Hibbs 812-581-0631

…

On Wed, Apr 17, 2024 at 2:23 AM Mike Brashler ***@***.***> wrote: I have a question regarding how to handle the HST Competition Mode. When running HST Competition, there is a Score column. Both the Sent and Received exchanges are included. image.png (view on web) <https://github.com/w7sst/MorseRunner/assets/106113737/9d78d2c0-bb67-4c9e-9cdd-9a5eb8d0d134> To change the log for this contest, I see a couple of options: A) Replace the Chk column with the new Corrections column. Leave the Sent and Received columns as is. If an error occurs, show the whole field in Red. This will not fit in the current space. However, if the GUI changes increases the width of this window, we would have room. B) Drop the Sent column, split the Recv column into RST and NR columns. Change the Chk column to Corrections or Correct. With Option B, I'm wondering if the existing Sent Column is important for the HST contest? Any suggestions on which way to go here? Thank you, Mike @K6OK <https://github.com/K6OK> @f6fvy <https://github.com/f6fvy> @scotthibbs <https://github.com/scotthibbs> @jr8ppg <https://github.com/jr8ppg> @WR7Q <https://github.com/WR7Q> — Reply to this email directly, view it on GitHub <#266 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADEITRKI3EPK6EJ7OGNIIITY5YPPTAVCNFSM6AAAAABDTO6SK6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANRQGU2TQMJTGY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[w7sst]

Here is one option for the HST Competition...

It keeps the original Recv and Sent columns and replaces the Chk column with a Correct column. I forced two errors, one RST and one NR error. Once I fix the callsign partial match bug, we would also see the callsign correction in the Correct column.

Also, several contest logs have been modified by replacing the Recv and Sent Columns with Exch1 and Exch2 columns. Each of these columns can show a Red error (as seen in all the examples above. However, doing so drops the Sent Column which is a copy of what the operator has sent. This adds no value to the user other than showing them a growing sequence number providing an easy QSO Count. The contests impacted by this change include These contests include CQ WW, ARRL DX, JARL ACAG and IARU HF.

Does this matter?

Can anyone think of any reason why we need to keep the original Sent Column as we go forward?

Do we need to keep the original Sent Column in the HST Competition contest?

@K6OK @f6fvy @scotthibbs @WR7Q @jr8ppg

[f6fvy]

IMHO, no reason to keep the Sent column for contests. No opinion on HST competition I don't use.

[w7sst]

I decided to drop the Sent column from the HST Contest log report. This seems to look good now...

I am noticing that I prefer "Correct" over "Corrections". I will probably change the other reports to use simply "Correct".

I also decided that a "contest" also decides what is displayed on the Qso Log report (e.g. RunMode="HST Competition" would show the Score column. This scoring is determined by the contest rule makers (IARU) and should be displayed regardless of the selected Run Mode. Thus, this score column will now show up for the HST Contest for all Run Modes. The total score will show up in the lower-right corner of the app. I will file a separate Issue for this.

[scotthibbs]

Looks good!! Great work!