CW memories from Hamlib keyer

6 posts / 0 new
Last post
oh1kh
CW memories from Hamlib keyer

After upgrading my rig to ic7300 I can now do all controlling of rig via usb cable. No need any more for separate arduino keyer.

Just selected Preferences/CW interface/ Interfaces type: Hamlib

How ever this has one bug. Or should I say property.
When you press CW memory key the corresponding text to send is delivered to rig with next rig polling sequence.
If your poll rate (Preferences/TRXControl) is set to, lets say 1500 (that is fast enough if you just need to know your frequency), then in worst case your CW memory goes out after 1,5sec from pressing the memory key.

At the moment I have poll rate of 700 but it is still too slow for pileups. At least it feels like nothing is happening for long (0,7sec !) time after pressing a memory key.

This affects also to CW typing from keyboard, I think (not tested).

At least the memory keys operation should be fixed. I think I have an idea for it.
When CW memory key is pressed we should check that radio polling is not just running and if not, then reset the timer so that new poll will happen immediately.

I will test that (also that) when I'm again in "programming shape".

oh1kh
CW memories from Hamlib keyer

Wrong guess. Again....

With more testing it shows up that rig polling rate has nothing to do with CW start delay after pressing CW memory key.

My previous keyer was arduino based K3NG connected to usb port as "WinKeyer". No delay with that.
Now using HamLib (rigctld) keyer with IC7300 and it has delay.

It seems to be caused by serial speed. There is no speed setting for Winkeyer. Assuming it uses very high speed as default.
When using IC7300 rig remote via usb the speed maximum is tied to remote socket max. that is 19200. (CI-V Usb port link to REMOTE).
If the link is released USB speed can be set up to 115200 but then hamlib is not getting any control of rig. Even when rigctld speed parameter is set to corresponding USB baudrate (any over 19200 , equal or less).

So the problem is not in cqrlog, but in icom itself.

No can do....

--
Saku
OH1KH

oh1kh
CW memories from Hamlib keyer

FYI

With IC7300 if " link to remote" is set OFF then "echo back" must be set ON.
That way rigctld can get control of rig if rig's USB baudrate is set to 115200 and rigctld has parameter "-s 115200".
(Rigctld needs to " see" command issued and "link to remote" does it at hardware level. When unlinked needs it to be done with software "echo back")

It might have reduced gap from releasing CW memory key to CW rf output start. But just few milliseconds, if any.
How ever speeds over 30wpm it is a long time :-)

--
Saku
OH1KH

DL3LAR
CW memories from Hamlib keyer

I'm looking for a solution for the IC-7610. Like the 7300, it has also an USB Hub, afaik.
Did you try to set "USB SEND/Keying" to "USB1 (B)" in the rig and use driver cwdaemon instead of hamlib ?
cwdaemon port should be then ttyUSB1, if rigctld is linked to ttyUSB0.

CW memories transmit latency should be then much reduced, I guess.

Actually I'm still struggeling with cwdaemon setup for serial port.

73 de Rolf, DL3LAR

oh1kh
CW memories from Hamlib keyer

Hi Rolf!

No, I did not try it. My experiences of cwdaemon (several years ago) are quite bad. At that time it did not work properly and I have not tested it afterwards.
I think I'm quite happy with this current setup. Delay between releasing CW memory button (mouse buttons) and actual CW start is very small now.
It really does not matter speeds below 30wpm.

My advice is to forget cwdaemon and try hamlib instead as keyer.

--
Saku
OH1KH

oh1kh
CW memories from Hamlib keyer

Start delay problems with HamLib keyer seems to be resolved.

It was in cqrlog's CWkeying procedure that sends text to rig with hamlib's b-command.

Usage was "b "+"text to send". How ever command b expects text right after "b". Now an additional space was between "b" and text to send causing one space long delay for start.
Depending on WPM this delay was different length.

In beta-212 this is fixed and is now under testing. Sounds good now.

After testing it will be pull requested to official source.

--
Saku
OH1KH