Hello!
I upgraded to v2.5.1 from Ubuntu 21.04 (I couldn't use the hirsute ppa due to missing deps). I experimented with CW macros (using Hamlib) before, but with this upgraded version I notice that there are additional pauses between each character. E.g., instead of "cq cq" it's more like "c q c q".
In addition, the wpm increase by +5 after the first character. Repeatedly triggering macros adds +5 wpm with each turn.
Is this something I could fix locally?
tnx es vy 73
Stephan, oe3spr
Hi Stephan!
How big step it was to move to 2.5.1?
git log | grep -i -B2 -e "version changed" -e "hamlib keyer"
Date: Fri Feb 12 17:24:42 2021 +0100
version changed to 2.5.2
--
Date: Sun Jan 24 16:48:04 2021 +0100
version changed to 2.5.1
--
Date: Sat Jan 16 09:19:17 2021 +0100
version changed to 2.5.0
--
Merge pull request #336 from OH1KH/squash_hamlib_speed
CW macro speed changes with Hamlib keyer
--
Date: Fri Oct 23 09:50:28 2020 +0300
CW macro speed changes with Hamlib keyer
Added limited support for speed changes in middle of macro text when using Hamlib keyer.
--
CW macro speed changes
Added limited support for speed changes in middle of macro text when using Hamlib keyer.
--
Source code is cleaned up (removed duplicate blocks, etc.)
HamLib keyer:
Tried to make Hamlib keyer handshake better. Now messages up tp 10 characters are sent by one hamlib command,
longer messages are sent letter by letter.
Tested with WinKeyer and Hamlib keyer (Icom IC7300) modes. (I have no other keyers)
--
Date: Thu Apr 4 17:00:00 2019 +0300
Fixed every second press of empty cwkey sends 'b' with hamlib keyer
--
Date: Sun Jun 17 13:49:12 2018 +0200
version changed to 2.3.0
--
Date: Sat Dec 30 06:53:49 2017 +0100
version changed to 2.2.0
If you have stepped from 2.3.0 to 2.5.1 then there is difference in the way Hamlib keyer is feed. Short messages are sent letter by letter, but this should not increase the value of CW speed during macro, or when triggering them again.
This fix was done because Hamlib keyer does not have proper "rig cw buffer full" indication and there is no way to know how many letters from macro rig has already sent.
With very low speed rig connection you perhaps may notice caps between letters. I have tested this with my icom ic7300 usb connection with CI-V speed of 19200 and it works perfectly at least up to 32WPM
You can try it by making a long macro to send (over 10 characters) and then shor macro (below 10 characters). If you notice differences between letter spacing then it might be because of new way of feeding Hamlib keyer.
Bug sending "c q c q" instead of "cqcq" (using CW type) should also be fixed in 2.5.1
Be sure that you have Hamlib version is 4.0 or better. There has been tons of fixes for Hamlib lately.
You can upgrade your 2.5.1 to 2.5.2 by this way without outdated repositories (but there are no changes in Hamlib keying):
Open command console and then:
change to /tmp directory
cd /tmp
Download cqrlog (Complete application directory for other distributions) from downlaod page link using wget:
wget https://github.com/ok2cqr/cqrlog/releases/download/v2.5.2/cqrlog_2.5.2_a...
Then extracted the file (that installs cqrlog):
sudo tar -vxf cqrlog_2.5.2_amd64.tar.gz --strip-components=1 -C /
Always when doing upgrade remember to backup your logs. Either with full adif export or by copying whole directory in console(when cqrlog is closed):
cp -a ~/.config/cqrlog ~/.config/cqrlog_back
If you have to restore just do the copy opposite direction
--
Saku
OH1KH
Hi Saku!
That explains a lot, thanks! I was upgrading from 2.4.0, Hamlib is 4.0 now. I already noticed that in 2.4.0 there was a delay between characters as soon as the message gets over 10 characters (what makes it pretty unusable, to be honest). This is still the case. I can split "cq" and "%mc" for our SES into two different messages, though, that's no problem and even adds some flexibility. Serial speed is set to the maximum of 115200, btw.
The odd +5 wpm increase was coming from the `+` character that I wanted to use as "end of message" prosign. Previously, this was output as the prosign [ar]. This is no longer the case, it appears this character is now interpreted as a command to increase speed. I couldn't figure out, though, how to actually increase/decrease speed. Can you tell me how it's done?
Could I also output [ar] as a prosign somehow? I found a forum posting that ^ar should do it, but it doesn't (anymore).
tnx
Steve
HI Steve!
You say " This is still the case. I can split "cq" and "%mc" for our SES into two different messages," Can yo clear this out a bit more, please.
Does it happen 2.5.1 (or 2.5.2). I would like to have an example as I do not find any problem there.
The message, speed used, rig used. I can only test hamlib cw with Icom 7300, so my view is quite limited here.
The increase + and decrease - has always been there with winkey. Just lately I was able to add it to Hamlib cw keying with help from Mike W9MDB who has been very active for Hamlib fixes lately.
How ever as the cqrlog help (operation/CW memory keys) says:
+ or - in macro text will increase/decrease CW speed by 5WPM/one mark.
"TU +++599--- 001" will send 599 with 15WPM higer speed.
Hamlib keyer has some limitations with this:
1) Version of Hamlib must be at least Hamlib 4.1~git Last commit 2020-10-20 03:22:59 2020 +0000 SHA=8a769c
2) Do not use space(s) between text and +(or -) rigctld will add them I.E. "TU+++599---001"
3) Speed change works only with BKIN mode (not F-BKIN) and at the moment new Icom rigs (tested only ic7300)
I also remembered there once was a question about AR. It seems to be message https://www.cqrlog.com/node/2192
It is a rig depended feature as you can see from picture of manual page that is included in message chain.
At bottom of picture there is a line that tells ^ must be added as prefix for combined characters.
But is is only case with Icom (7300 and perhaps other models), it is not a cqrlog feature. Cqrlog just passes by the ^ as is.
I made quick test and macro CQ cq de %mc %mc ^ar k works as expected with ic7300.
Wit other rig brands and models it may differ.
--
Saku
OH1KH