Skip to content

Conversation

@zcsahok
Copy link
Member

@zcsahok zcsahok commented Nov 7, 2025

Auto CQ came up in two issues recently (#463 and #466).

Let's see if we can improve here.

Stop auto CQ on callsign grab (from #463): normally the callsign field is empty during CQ, so check if it has been set by a grab (clicking on Fldigi RX window). In addition to key presses consider such events also as CQ-stopper, but don't report them to the caller.

@zcsahok zcsahok marked this pull request as draft November 7, 2025 21:35
@zcsahok
Copy link
Member Author

zcsahok commented Nov 7, 2025

Handle PgUp/Dn (keyer speed up/dn) internally (from #466): make use of handle_common_key() after filtering.
UI experience is not the best due to the delayed update, but one can live with it.

@df7cb
Copy link
Contributor

df7cb commented Nov 8, 2025

I confirm fldigi grabbing stops autocq with this patch. Thanks!

these are special terminal-specific keys not known to curses,
so had to map them to internal key values.

moved Ctrl/Alt-PgUp/Dn handling to handle_common_key()
@zcsahok
Copy link
Member Author

zcsahok commented Nov 8, 2025

Added handling of Ctrl/Alt-PgUp/Dn (CQ delay control), so #466 is fully covered IMO.

Due the specific nature of these key had to restructure key handling a bit: mapping to non-curses keys happens in `onechar()'.

@zcsahok zcsahok marked this pull request as ready for review November 8, 2025 20:21
@zcsahok zcsahok requested a review from dl1jbe November 8, 2025 20:22
@zcsahok
Copy link
Member Author

zcsahok commented Nov 8, 2025

Changing CQ delay has only an immediate effect when shortening it. Lengthening will be effective at the next CQ round. I think this is tolerable.

@zcsahok zcsahok linked an issue Nov 8, 2025 that may be closed by this pull request
@dl1jbe
Copy link
Member

dl1jbe commented Nov 10, 2025

Changing the keying speed results in CQ delay starting early or late depending on the direction of change.
'message_time' should be recalculated at every start of the while() loop. So both will get in sync again after the next round.

Better yet would be to recalculate the remaining time as soon as the CW speed got changed.

@zcsahok
Copy link
Member Author

zcsahok commented Nov 10, 2025

Moved message length calculation into the loop.

We have no definite info how much of the message is left when speed changes. It could be possible to estimate it, but it's not worth the effort IMO. For small speed changes (+/- 2 wpm) the difference is hard to notice.

@dl1jbe
Copy link
Member

dl1jbe commented Nov 11, 2025

Moved message length calculation into the loop.

Thanks. Looks good now.

We have no definite info how much of the message is left when speed changes. It could be possible to estimate it,

Yes if first calculation is correct we could estimate based on the percentage of time already spent.

but it's not worth the effort IMO. For small speed changes (+/- 2 wpm) the difference is hard to notice.

True. It only matters for bigger changes.

@zcsahok zcsahok merged commit 44a1f47 into Tlf:master Nov 11, 2025
2 checks passed
@zcsahok zcsahok deleted the improve_autocq branch November 11, 2025 19:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

AUTO CQ msg modification

3 participants