Added RESENDCALL feature #322

airween · 2022-03-07T22:46:14Z

This PR adds a new feature for Tlf, which missing me a lot.

Consider that you are participating on a contest in RUN mode. A station comes back, you type his callsign, press the ENTER, you send his call and the report. Then the station corrects his callsign, and sends the exchange. Now you must confirm that you changed the modified callsign.

This patch does this feature.

There is a new keyword with two possible values:

RESENDCALL=FULL | PARTIAL

In case of FULL, the whole callsign will send again, with PARTIAL, Tlf calculates a shortest clear part of callsign.

Here are few examples:

First record	Corrected	Send Partial
WB6A	W6BA	W6B
HA2OH	HA2OS	OS
HA2MS	HA2OS	OS
HA2MH	HA2OS	OS
OK2FHI	OK1FHI	OK1
OK1FH	OK1FHI	FHI
OK2FH	OK1FHI	1FHI
WB6AB	WB6A	6A

airween · 2022-03-08T00:03:33Z

Okay, while I fixed the test issues, I realized that get_wpx_pfx() isn't the best choice, because if the OP in a foreign country, the prefix will completely different. I should rework that part, but we can start to discuss about this feature.

ha5se · 2022-03-08T00:05:35Z

I would like first to send some opinions, then a possible additional option.

I am afraid that the following shortest examples could cause more on-air repeats than the case for FULL at once:

WB6A W6BA W6B
IMHO, this is the worst example in the list, sparing only a single char -- while probably misleading to make him think I finally logged W6B,
AFAIK rather usual is correcting either full, or only prefix or country, or only suffix. No partial suffix for correction.
OK2FH OK1FHI 1FHI
well, personally I do not like it, but matter of taste, at least acceptable.
For your logic, my new example would be OK2FH OK1ABC 1ABC but no any resemblance in this case -- for me FULL would be obvious here
WB6AB WB6A 6A
well, not so much misleading, but still not obvious enough.
I'd rather use FULL for this.

The simpler possible suggestion from me is to try to keep everybody happy ;) , with at least introduce FULL, SHORTEST (as from Ervin), and SHORT (prefix or country or suffix for single error, otherwise full).

For one-char suffix, I would rather send FULL when correcting suffix...
For two errors, I would always resend FULL.
Never shorten 3-char calls.

Slightly more sophisticated version would be to configure with bitmap what you prefer to do... Tastes are different ;) ...

To my tastes, some more examples:

W1XX W1AW W1AW
W1AX W1AW AW
WB1A WD1A WD1 (up to you, perhaps WD)
N2A D2A D2A

N0NB · 2022-03-08T01:23:04Z

* On 2022 07 Mar 18:06 -0600, ha5se wrote:

I would like first to send some opinions, then a possible additional option.

Nice feature, Ervin. It will come in handy. I do share the concerns expressed. I suppose one consideration would be how do other loggers that have such a feature as this handle it? In other words, what are contest ops already used to? Perhaps a query to the mailing list might give more suggestions.

I am afraid that the following shortest examples could cause more on-air repeats than the case for FULL at once: 1) WB6A W6BA W6B

All three of these are valid US callsigns. Similar variations exist in all US call districts and it would be quite possible to work all three in a given contest. Under rare but possible circumstances this could get confusing! I think I would set the feature to FULL and leave it at that. 73, Nate

…

-- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819

airween · 2022-03-08T06:58:55Z

@ha5se hi Jeno,

thanks for feedback!

1. WB6A 	W6BA 	W6B
   IMHO, this is the worst example in the list, sparing only a single char -- while probably misleading to make him think I finally logged W6B,

the idea behind this implementation was I corrected the original prefix, which was WB6. Btw, if we ignore the prefix-suffix grouping, we should send only the B6, or the full callsign.

2. OK2FH 	OK1FHI 	1FHI
   well, personally I do not like it, but matter of taste, at least acceptable.
   For your logic, my new example would be OK2FH  OK1ABC  1ABC  but no any resemblance in this case -- for me FULL would be obvious here

Yes, that was the logic.

3. WB6AB 	WB6A 	6A
   well, not so much misleading, but still not obvious enough.
   I'd rather use FULL for this.
The simpler possible suggestion from me is to try to keep everybody happy ;) , with at least introduce FULL, SHORTEST (as from Ervin), and SHORT (prefix or country or suffix for single error, otherwise full).

Can you describe some pseudo algorithm for SHORTEST and for SHORT?

For one-char suffix, I would rather send FULL when correcting suffix... For two errors, I would always resend FULL. Never shorten 3-char calls.

So you mean if the callsign is shorter than 4 chars, then we have to send the full call?

Slightly more sophisticated version would be to configure with bitmap what you prefer to do... Tastes are different ;) ...

I do not see the point of bitmaps here. Sometimes I failed because I'm typing blindly and pressed wrong key :).

To my tastes, some more examples:

W1XX W1AW W1AW

I think this implementation now works as you expect.

W1AX W1AW AW

same here.

WB1A WD1A WD1 (up to you, perhaps WD)

the modification was in prefix, same result here as you expec

N2A D2A D2A

Well, this make sense.

I'm glad that the discussion has started. Thanks again.

airween · 2022-03-08T07:11:13Z

@N0NB

hi Nate, thanks for feedback!

Nice feature, Ervin. It will come in handy. I do share the concerns expressed. I suppose one consideration would be how do other loggers that have such a feature as this handle it? In other words, what are contest ops already used to? Perhaps a query to the mailing list might give more suggestions.

Ask the mailing list is a good idea, I'm going to write.

In last few months I usually used N1MM+. I have to tell you I have no idea how can I turn on/off this feature, or how can I configure it :). But the feature itself is very useful. In Tlf, I had to press F5 at the end of the QSO, which is uncomfortable. So, I do not know is there any good example what we should follow.

An example (assume from N1MM+): the other station hears me but records my callsign as HA2OH. I correct it, then finally he sends me only an S. Personally I do not like these "only-one-char-corrections".

I am afraid that the following shortest examples could cause more on-air repeats than the case for FULL at once: 1) WB6A W6BA W6B
All three of these are valid US callsigns. Similar variations exist in all US call districts and it would be quite possible to work all three in a given contest. Under rare but possible circumstances this could get confusing! I think I would set the feature to FULL and leave it at that.

I see your argument and partially I agree with it. As I wrote above, the logic was that the prefix has modified, so the logger sends only the length of the prefix. The main reason why I send this PR now that let's start the discussion, so thank you again.

df7cb · 2022-03-08T08:26:23Z

1. WB6A 	W6BA 	W6B
   IMHO, this is the worst example in the list, sparing only a single char -- while probably misleading to make him think I finally logged W6B,
the idea behind this implementation was I corrected the original prefix, which was WB6. Btw, if we ignore the prefix-suffix grouping, we should send only the B6, or the full callsign.

IMHO the logic should be "if the prefix changed, send it, if the suffix changed, send it". Since prefix WB -> W and suffix A -> BA, both need to be included.

airween · 2022-03-08T08:47:30Z

@df7cb, thanks Christoph,

IMHO the logic should be "if the prefix changed, send it, if the suffix changed, send it". Since prefix WB -> W and suffix A -> BA, both need to be included.

Actually I'm using prefix only to determine the length of it, but I'm not sure it's a good idea, see my comment. I mean what about E7/Z12A/8 (is it valid at all?) and the corrected call is E77/Z12A/8. May be we should drop the idea related to check the prefix and suffix.

ha5se · 2022-03-08T20:11:52Z

Hi Airween,

regarding SHORT vs SHORTEST,

your idea seems to be to spare as mach as can be (parm=SHORTEST) .

My taste is more conservative, repeating more often the full call (parm=SHORT), e.g. full call for:

for short callsign (3 char)
when only sparing a single char vs full
when more than one char corrected ( W1AB -> W1BA )
when the corrected part is only 1 char ( AA1A -> AA1B )

More sophisticated config could be a bitmap,

e.g. bit 02 -- always use full prefix:

K1AA -> N1AA

N1 (independent of bit 02 to let at least two chars)

WB1ZZZ -> WD1ZZZ

WD (w/o bit 02)
WD1 (with bit 02)

An interesting example is E7/Z12A/8 .

Could be generalized by referring to "parts" instead of prefix/suffix.
E7/Z12A/8 -> E6/Z12A/8 E6
E7/Z12A/8 -> E7/Z14A/8 Z14
E7/Z12A/8 -> E7/Z12A/9 /9

However...

the last cases clearly show that the algorithm need not be too clever ;) .

In complicated cases, or when in doubt, better use full call.
One or more "/" could suffice for no shortening. Relatively rare calls, anyway.

So far, except of the E7/... , the examples were short, anyway, thus not much gain...
Where it is more important is to spare repeating full WB1JOY -- obviously we want to repeat only the changed halve when correcting a single char...
It also often happens by many (and unfortunately with my PA as well) that the leading dot is missing due to lazy PA relay
( SA5SE --> HA5SE ) -- to repeat the corrected prefix (or country) is just enough here...

src/logit.c

src/parse_logcfg.c

src/sendbuf.c

src/utils.c

zcsahok · 2022-03-09T19:51:13Z

I see practiacally 2 features here.

re-send as such (the FULL mode): this is practically an "auto-F5" functionality.
"optimized" re-send (SHORT mode): here the crucial point is the exact definition of the algorithm determining the text to be sent.

For 1) it would be good to have a temporary override: I usually use the keyer (Ctrl-K) to send such correction (or one could use an independent keyer). This gives the user complete freedom as to what and how to send. In such a case automatic re-sending shall be suppressible for that QSO.

For 2) we can start with a well defined (and tested) logic. This will surely not fit everybody, so once we have plugins available it would be up to the user to come up with their own way of re-sending. (e.g. send the whole call but faster)

airween · 2022-03-09T20:37:24Z

Hi Jenő,

your idea seems to be to spare as mach as can be (parm=SHORTEST) .

yes, that was,

My taste is more conservative, repeating more often the full call (parm=SHORT), e.g. full call for:
* for short callsign (3 char)
* when only sparing a single char vs full
* when more than one char corrected  ( W1AB -> W1BA )
* when the corrected part is only 1 char  ( AA1A -> AA1B )

right, now I got it.

e.g. bit 02 -- always use full prefix:

K1AA -> N1AA
* **N1**   (independent of bit 02 to let at least two chars)
WB1ZZZ -> WD1ZZZ
* **WD**   (w/o bit 02)
* **WD1**  (with bit 02)

I think using of any bitmap would make it more complicated the setup - or I miss something. Could you give an example for the settings with bitmap?

An interesting example is E7/Z12A/8 .

I'm not sure that this is a valid example, but I hope the main argument is visible.

Could be generalized by referring to "parts" instead of prefix/suffix. E7/Z12A/8 -> E6/Z12A/8 E6 E7/Z12A/8 -> E7/Z14A/8 Z14 E7/Z12A/8 -> E7/Z12A/9 /9
However...

the last cases clearly show that the algorithm need not be too clever ;) .

yes, definitely.

For the help, I've created a repository that anybody can play with:

https://github.com/airween/tlfresend

If you want to test/try, do that.

In complicated cases, or when in doubt, better use full call. One or more "/" could suffice for no shortening. Relatively rare calls, anyway.

Would make sense.

So far, except of the E7/... , the examples were short, anyway, thus not much gain... Where it is more important is to spare repeating full WB1JOY -- obviously we want to repeat only the changed halve when correcting a single char... It also often happens by many (and unfortunately with my PA as well) that the leading dot is missing due to lazy PA relay ( SA5SE --> HA5SE ) -- to repeat the corrected prefix (or country) is just enough here...

Correcting a single char is very strange IMHO. I think N1MM+ follows that, sometimes I get a singe S when the station corrects my call, but I do not like that, personally. But it's my own problem :).

airween · 2022-03-09T20:45:14Z

Hi Zoli,

I see practiacally 2 features here.

1. re-send as such (the FULL mode): this is practically an "auto-F5" functionality.
2. "optimized" re-send (SHORT mode): here the crucial point is the exact definition of the algorithm determining the text to be sent.

yes, when I started to implement this, I thought this will be the neuralgic point of the whole feature. I'm glad that conversation has started.

For 1) it would be good to have a temporary override: I usually use the keyer (Ctrl-K) to send such correction (or one could use an independent keyer). This gives the user complete freedom as to what and how to send. In such a case automatic re-sending shall be suppressible for that QSO.

A good point, thanks for the idea.

For 2) we can start with a well defined (and tested) logic. This will surely not fit everybody, so once we have plugins available it would be up to the user to come up with their own way of re-sending. (e.g. send the whole call but faster)

Agree.

Defining the logic is the most important task now. We can add later the plugins, or any modifications. Practical use will show the experiences, and we can go away.

Note, that as I wrote above, I've created a repository to play with this feature:

https://github.com/airween/tlfresend

Any patch are welcome.

Also thanks for your comments next to patch. I'm going to review them soon.

ha5se · 2022-03-09T22:07:27Z

Hi Ervin,

your idea seems to be to spare as mach as can be (parm=SHORTEST) .

yes, that was,

Well, exactly my point. If you acknowledge a too short piece of the corrected call, then you will get it sent again, and must confirm again. Of course, everybody has somewhat different personal experience and feeling about this. Surely no exact rules.

`I think using of any bitmap would make it more complicated the setup - or I miss something. Could you give an example for the settings with bitmap?

Well, it was only an example how to try to satisfy everybody's taste. Do not want to take more bitmap examples, nor config keywords, since I do not think this is a way to go: much too complex for end user, and during the contest not so relevant anyway. Personally I also think bitmaps (or according keyword lists) as over-complicated: only few people would use it, and still unsatisfied sometimes ;) . Better keep by FULL SHORT SHORTEST ;)

So far, except of the E7/... , the examples were short, anyway, thus not much gain... Where it is more important is to spare repeating full WB1JOY -- obviously we want to repeat only the changed halve when correcting a single char... It also often happens by many (and unfortunately with my PA as well) that the leading dot is missing due to lazy PA relay ( SA5SE --> HA5SE ) -- to repeat the corrected prefix (or country) is just enough here...

Correcting a single char is very strange IMHO. I think N1MM+ follows that, sometimes I get a singe S when the station corrects my call, but I do not like that, personally. But it's my own problem :).

Well, in this matter, I think it is not just a matter of taste. Sending a single char as correction is ... hmmmm... This is no verification at all... I think a partial call as verification should at least 50% matching the originally transmitted mistyped part.

After all, still I think best is to keep the logic and conf simple, and still maintaining my view that I would not like yours SHORTEST... However, three options could satisfy most of us, at least I hope ;) .

airween · 2022-03-10T19:28:46Z

Guys,

as I posted yesterday, I made a separated repository help to play with the code which gives back the partial callsign in case of wrong record (for the first time in QSO).

@zcsahok Zoli has made a pull request, with awesome results. In this table below, you can see the received callsign at 1st and 2nd case, then the calculated partial call from me, and from Zoli:

 CALL 1st    | CALL 2nd    | Res HA2OS   | Res HA5CQZ 
-------------+-------------+-------------+------------
 WB6A        | W6BA        | W6B         | W6BA       
 HA2OH       | HA2OS       | OS          | OS         
 HA2MS       | HA2OS       | OS          | OS         
 HA2MH       | HA2OS       | OS          | OS         
 HA2MH       | S52OS       | S52OS       | S52OS      
 S2MH        | S52OS       | 52OS        | S52OS      
 S2MH        | S52MH       | 52MH        | S5         
 OK2FHI      | OK1FHI      | OK1         | OK1        
 OK1FH       | OK1FHI      | FHI         | FHI        
 OK2FH       | OK1FHI      | 1FHI        | 1FHI       
 WB6AB       | WB6A        | 6A          | 6A         
 HG5N        | HA5N        | HA5         | HA         
 HG5N        | HG55N       | 5N          | 55         
 HG5N        | HG6N        | HG6         | HG6        
 HG5N        | HG5D        | 5D          | 5D         
 PA1234X     | PA1834X     | PA1834      | 1834       
 PA1234X     | PA1834K     | 834K        | 1834K      
 PA1234X     | PA1234K     | 4K          | 4K         
 PA1234X     | RA1234X     | RA1234      | RA         
 F1234X      | R1234X      | R1234       | R1         
 F1234X      | R1234C      | R1234C      | R1234C     
 K1A         | K1W         | 1W          | 1W         
 K1A         | W1A         | W1          | W1         
 K1A         | K2A         | K2          | K2         
 DL1ABC      | DL1ADC      | DC          | ADC        
 R1ABC/2     | R1ABC/3     | /3          | /3         
 R1ABC/2     | R1ADC/2     | DC/2        | ADC        
 R1ABC/2     | R4ADC/2     | 4ADC/2      | 4ADC       
 R1ABC/2     | R1ADC/3     | DC/3        | ADC/3      
 R1A/2       | R1W/2       | W/2         | 1W         
 EA8/HB9ABC  | EA8/HB9ANC  | NC          | ANC        
 EA8/HB9ABC  | EA6/HB9ABC  | EA6         | EA6/       
 EA8/HB9ABC  | EA6/HB9ANC  | 6/HB9ANC    | EA6/HB9ANC 
 EA8/DL1ABC  | EA8/DK1ABC  | K1ABC       | DK         
 EA8/DL1ABC  | EA6/DK1ABC  | 6/DK1ABC    | EA6/DK     
 G/DF1ABC    | F/DF1ABC    | F/          | F/         
 LA/DF1ABC   | PA/DF1ABC   | PA/         | PA/        
 HA5ABC/P    | HA5ABC      | 5ABC        | ABC        
 HA5ABC      | HA5ABC/P    | ABC/P       | /P         
 HB9/OK1ABC  | OK1ABC      | OK1ABC      | OK         
 OK1ABC      | HB9/OK1ABC  | HB9/OK1ABC  | HB9/       
 HA5ABE      | HA5AB       | 5AB         | AB         
 HA5ABE      | HW5AB       | W5AB        | HW5AB

Zoli's algorithm is here. He splits the callsign into multiple parts, as alt prefix (before the leading /), prefix (without area), area, suffix, alt area after the suffix, like /1. The function compares these parts from both callsign, then produces the result as you can see.

Of course, his solution is more complex than mine, ergo this is much better than mine :), so I assume there is no question, which one should we use.

But I just wanted to show you - any ideas are welcome.

And TNX Zoli!

zcsahok · 2022-03-10T19:45:09Z

For the case of removal of XX/ or /X

HA5ABC/P    | HA5ABC          
HB9/OK1ABC  | OK1ABC

maybe sending full call could be better (=more clear on the other end). Not sure, though.

ha5se · 2022-03-11T19:18:11Z

Agree, surprising how different tastes are regarding this ;) .
Perhaps let us give bitmaps another chance now, for further discussion...

Example flags, version 01:

hex	desc
:800	Force FULL always (obvious, not included in examples)
:400	Force FULL for more than one correction
:200	Force FULL when "/" present
:100	Force FULL for short calls (3 chars)
:080	Force FULL if only sparing single char
:040	Force FULL if the corrected part is only a single char long
:020	--- unused ---
:010	--- unused ---
:008	Allow full suffix or full prefix
:004	Allow full suffix or full prefix, or country if two char
:002	Allow minimal, at least two chars
:001	Allow minimal, even if part is single char
:000	never auto-resend, default for backward compatibility

Some but not all possible combinations are listed, assumed to produce the associated calculated resent part. N/A is not available using the current flags.
For HA5SE, I only filled the example when calculated part significantly differs from at least one of the other examples.
Hope there are not too much typos left...

	CALL wrong	CALL corr	Res HA2OS	flg	Res HA5CQZ	flg	Res HA5SE	flg
1.	WB6A	W6BA	W6B	:001	W6BA	:004	W6BA	:004
				:002		:008		:008
2.	HA2OH	HA2OS	OS	:004	OS	:004
				:008		:008
3.	HA2MS	HA2OS	OS	:004	OS	:004
				:008		:008
4.	HA2MH	HA2OS	OS	:001	OS	:001
				:002		:002
				:004		:004
				:008		:008
5.	HA2MH	S52OS	S52OS	:001	S52OS	:001
				:002		:002
				:004		:004
				:008		:008
				:400		:400
6.	S2MH	S52OS	52OS	:001	S52OS	same	S52OS
				:002		:002		:088
7.	S2MH	S52MH	52MH	-N/A	S5	:004	S52	:008
8.	OK2FHI	OK1FHI	OK1	:004	OK1	:004
				:008		:008
9.	OK1FH	OK1FHI	FHI	:004	FHI	:004
10.	OK2FH	OK1FHI	1FHI	:001	1FHI	:001	OK1FHI	:008
				:002		:002		:400
11.	WB6AB	WB6A	6A	:002	6A	:002	WB6A	:084
								:088
								:040
12.	HG5N	HA5N	HA5	:008	HA	:004
13.	HG5N	HG55N	5N	:002	55	:002	HG55N	:084
				???		???		:088
14.	HG5N	HG6N	HG6	:004	HG6	:004	HG6N	:084
				:008		:008		:088
15.	HG5N	HG5D	5D	:001	5D	:001	HG5N	:084
								:088
								:040
16.	PA1234X	PA1834X	PA1834	:004	1834	-N/A	PA1834X	:084
				:008				:088
								:040
17.	PA1234X	PA1834K	834K	-N/A	1834K	-N/A	PA1834K	:084
								:088
								:040
18.	PA1234X	PA1234K	4K	-N/A	4K	-N/A
19.	PA1234X	RA1234X	RA1234	:008	RA	:004
20.	F1234X	R1234X	R1234	:004	R1	-N/A	R1234
				:008
21.	F1234X	R1234C	R1234C	:001	R1234C	same
				:004
				:008
				:400		:400
22.	K1A	K1W	1W	:002	1W	:002	K1W	:100
								:040
23.	K1A	W1A	W1	:004	W1	:004	W1A	:100
				:008		:008
24.	K1A	K2A	K2	:004	K2	:004	K2A	:100
				:008		:008
25.	DL1ABC	DL1ADC	DC	:002	ADC	:004	ADC
						:008
26.	R1ABC/2	R1ABC/3	/3	:002	/3	:002
27.	R1ABC/2	R1ADC/2	DC/2	-N/A	ADC	:004	R1ADC/2	:200
						:008
28.	R1ABC/2	R4ADC/2	4ADC/2	-N/A	4ADC	:001	R4ADC/2	:200
						:002
29.	R1ABC/2	R1ADC/3	DC/3	-N/A	ADC/3	:001	R1ADC/3	:200
						:002
30.	R1A/2	R1W/2	W/2	-N/A	1W	:001	R1W/2	:200
						:002
31.	EA8/HB9ABC	EA8/HB9ANC	NC	:002	ANC	:004	EA8/HB9ABC	:200
						:008	just compat
32.	EA8/HB9ABC	EA6/HB9ABC	EA6	:004	EA6/	-N/A	EA6/HB9ABC	:200
				:008
33.	EA8/HB9ABC	EA6/HB9ANC	6/HB9ANC	-N/A	EA6/HB9ANC	:400	EA6/HB9ABC	:200
34.	EA8/DL1ABC	EA8/DK1ABC	K1ABC	N/A	DK	:004
35.	EA8/DL1ABC	EA6/DK1ABC	6/DK1ABC	N/A	EA6/DK	:004
36.	G/DF1ABC	F/DF1ABC	F/	:002	F/	:002	F/DF1ABC
37.	LA/DF1ABC	PA/DF1ABC	PA/	N/A	PA/	N/A	PA/DF1ABC
38.	HA5ABC/P	HA5ABC	5ABC	N/A	ABC	:004	HA5ABC/P
39.	HA5ABC	HA5ABC/P	ABC/P	N/A	/P	:002
40.	HB9/OK1ABC	OK1ABC	OK1ABC	N/A	OK	N/A	OK1ABC	:200
41.	OK1ABC	HB9/OK1ABC	HB9/OK1ABC	:200	HB9/	N/A
42.	HA5ABE	HA5AB	5AB	N/A	AB	:004	AB	:004
						:008		:008
43.	HA5ABE	HW5AB	W5AB	:001	HW5AB	:004	HW5AB	:004
				:002		:008		:008

Notes about HA2OS cases, IMHO

case 1 vs 2 or 3 are incompatible in logical sense
case 7 is absolutely illogical, far from other minimal examples
cases with last number(s) from prefix + full suffix come sometimes, maybe a new flag could be introduced
case 13 is similar length to HA5CQZ, still different -- should be better defined
generally, I think similar inputs produce too different outputs, rather hectic, ad-hoc

Other notes:

For cases 26 and above, with "/" by HA5SE, in some cases I like full suffix, however, generally I find it better to use full.
Unfortunately, it cannot be decided case by case, cases should rather be consistently categorized.
I think this is what you manually can do, but not programmatically ;) .
for case 40 to work by HA5SE, "/" must also be checked in the wrong call.

Conclusion V01:

for HA5OS, i do not see enough consistency to combine flags to get a final mask that would cover most of his examples.
for HA5CQZ, :006 would be a good start.
for HA5SE, obviously :7C6

Note that when any flag is on but still no match, then an implicit FULL should be applied as last resort.

…syntax

airween · 2022-03-12T14:56:59Z

Guys, I changed the main algorithm in this PR (see above). Today the Tesla Memorial Contest will be a good chance to test is :).

airween · 2022-03-12T15:24:37Z

For 1) it would be good to have a temporary override: I usually use the keyer (Ctrl-K) to send such correction (or one could use an independent keyer). This gives the user complete freedom as to what and how to send. In such a case automatic re-sending shall be suppressible for that QSO.

I reviewed the logic, and realized that after pressing CTRL-K the KEYER window opens, and:

it possible to use F-n keys, like F5 (which sends the modified call, **if the uses sets the F5 as @); btw pressing the F5 is handled, re-send won't activate
if user replaces the F5=@ with something other, then this logic will fail
KEYER sends the message char by char. I can imagine that we follow the content of keyerstring, and if it's equal with hiscall, we replace the sentcall value.

Thoughts?

airween · 2022-03-12T15:27:50Z

@ha5se thanks for the explanation, but I think it's a bit more complex to implement, but even more complex to set up for a user :).

At first, we should finish this feature, then we can see what requests are received.

zcsahok · 2022-03-12T15:56:32Z

I will add some minor fixes.

zcsahok · 2022-03-12T20:27:43Z

(let resend_callsign() decide what to send, this work for NOT_SET too. check for CQ is not needed as it done the line above.)

airween · 2022-03-12T20:37:02Z

(let resend_callsign() decide what to send, this work for NOT_SET too. check for CQ is not needed as it done the line above.)

Right, thanks Zoli.

If you think your reviews are finished, please resolve them.

Please see my comment above.

If there is no other modification, we can merge it soon.

zcsahok

Added some more comments, sri.

test/test_adif.c

test/test_cabrillo.c

test/data.c

… RESEND_CALL to init_variables()

…call

ha5se · 2022-04-05T21:30:43Z

@ha5se thanks for the explanation, but I think it's a bit more complex to implement, but even more complex to set up for a user :).

At first, we should finish this feature, then we can see what requests are received.

Hi Airween, while I agree about the complexity, still I have prepared a more versatile demo concept with more functions and options to better suit to the very different tastes. Hopefully it can at least serve as a base for discussion. A readme file and a demo test script has been included in my repo https://github.com/ha5se/resendcall2 .

airween · 2022-04-10T17:04:40Z

Hi Jenő,

sorry, I almost forgot this comment from you (perhaps you should open a new issue next time - it's no problem that we already discussed about the topic).

To review the introduced test I need few days.

Btw, thank you for your efforts.

ha5se · 2022-04-11T21:47:06Z

Hi Airween,

I am really very grateful for your note. Frankly, I was just about to start missing at least a simple note to my work -- however critic ;) .

My mistake, sorry, still I do not know git enough: still I do not know how to and when to open new topic... Anyway, I did not want to overwhelm this #322, nor do I know how to open an issue to a non-closed one. Mine was my best effort, please be assured... Poor learning curve from me, from a poor old citizen, just the age retiring from work... ;)

Anyways, I am still planning to send very minor changes, as well as a bulk test, to my repo tomorrow. Hope that you will at last find my concept of some use...

airween added 2 commits March 7, 2022 23:43

Added RESENDCALL feature

2686da5

Fix make check issues

66391a7

airween requested review from dl1jbe and zcsahok March 8, 2022 00:01

zcsahok requested changes Mar 9, 2022

View reviewed changes

src/logit.c Outdated Show resolved Hide resolved

src/parse_logcfg.c Outdated Show resolved Hide resolved

src/sendbuf.c Show resolved Hide resolved

src/utils.c Show resolved Hide resolved

airween mentioned this pull request Mar 12, 2022

add an alternative logic airween/tlfresend#1

Merged

airween added 3 commits March 12, 2022 15:36

Replace get_partial_callsign() by @zcshok's solution; applied astyle …

461398e

…syntax

Added resend_callsign() to keep the code more readable

44e73c7

Changed RESENDCALL to RESEND_CALL

4f777a0

zcsahok added 2 commits March 12, 2022 20:08

minor RESEND_CALL doc update

c7cc01f

minor resend_callsign upd

8220d5a

minor resend_callsign upd2

1fbdedd

zcsahok reviewed Mar 12, 2022

View reviewed changes

test/test_adif.c Outdated Show resolved Hide resolved

test/test_cabrillo.c Outdated Show resolved Hide resolved

test/data.c Outdated Show resolved Hide resolved

airween and others added 3 commits March 13, 2022 01:15

Remove unnecessary headers and objects from test; move initial set of…

971a01d

… RESEND_CALL to init_variables()

Merge branch 'resendhiscall' of github.com:airween/tlf into resendhis…

21de89d

…call

add test for get_partial_callsign

079d6cd

zcsahok approved these changes Mar 13, 2022

View reviewed changes

zcsahok merged commit 71908f1 into Tlf:master Mar 16, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Added RESENDCALL feature #322

Added RESENDCALL feature #322

airween commented Mar 7, 2022

airween commented Mar 8, 2022

ha5se commented Mar 8, 2022

N0NB commented Mar 8, 2022 via email

airween commented Mar 8, 2022

airween commented Mar 8, 2022

df7cb commented Mar 8, 2022

airween commented Mar 8, 2022

ha5se commented Mar 8, 2022

zcsahok commented Mar 9, 2022

airween commented Mar 9, 2022

airween commented Mar 9, 2022

ha5se commented Mar 9, 2022

airween commented Mar 10, 2022

zcsahok commented Mar 10, 2022

ha5se commented Mar 11, 2022

airween commented Mar 12, 2022

airween commented Mar 12, 2022

airween commented Mar 12, 2022

zcsahok commented Mar 12, 2022

zcsahok commented Mar 12, 2022

airween commented Mar 12, 2022

zcsahok left a comment

ha5se commented Apr 5, 2022

airween commented Apr 10, 2022

ha5se commented Apr 11, 2022

Added RESENDCALL feature #322

Added RESENDCALL feature #322

Conversation

airween commented Mar 7, 2022

airween commented Mar 8, 2022

ha5se commented Mar 8, 2022

N0NB commented Mar 8, 2022 via email

airween commented Mar 8, 2022

airween commented Mar 8, 2022

df7cb commented Mar 8, 2022

airween commented Mar 8, 2022

ha5se commented Mar 8, 2022

regarding SHORT vs SHORTEST,

More sophisticated config could be a bitmap,

An interesting example is E7/Z12A/8 .

However...

zcsahok commented Mar 9, 2022

airween commented Mar 9, 2022

airween commented Mar 9, 2022

ha5se commented Mar 9, 2022

airween commented Mar 10, 2022

zcsahok commented Mar 10, 2022

ha5se commented Mar 11, 2022

airween commented Mar 12, 2022

airween commented Mar 12, 2022

airween commented Mar 12, 2022

zcsahok commented Mar 12, 2022

zcsahok commented Mar 12, 2022

airween commented Mar 12, 2022

zcsahok left a comment

Choose a reason for hiding this comment

ha5se commented Apr 5, 2022

airween commented Apr 10, 2022

ha5se commented Apr 11, 2022