Using hamlib for CW keying

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Using hamlib for CW keying

Christian Treldal-2
Hi guys

First I want to thanks the developers for the new ver. 1.4.0

A year or something ago Ervin wrote a quick Python2 script for keying
via hamlib. It has n

been working flawlessly until now. I've upgraded to Fedora31 and Python2
has been depreciated. I am trying to convert it to python3;

  But I think it is a good time for a humble feature request for Tlf
1.x.x. A build in hamlib keyer, so at least I can avoid stressfull 
expiriences like this.

All modern rigs have keying via hamlib.


73 de OZ1GNN

--
Med venlig hilsen


Christian Treldal
"Remember Darwin; building a better mousetrap merely results in smarter mice."


Reply | Threaded
Open this post in threaded view
|

Re: Using hamlib for CW keying

Drew Arnett
When you ask for keying by hamlib, you are asking for keying via CAT,
correct?  (I would have to look to see if hamlib supports anything
besides the CAT port on rigs, like the key line.)

I wrote a python application that acts like cwdaemon listening on a
network socket, and drives a USB to key adapter (K1EL WinKeyer USB).
I need to push a python3 version of that to github.  (I plan to do
over next week's holiday.)  That works great, but I have been thinking
about trying keying from the CAT port.  It might work great
functionally.  Reducing cabling would be a benefit.  But, I'll
probably keep the ability to use a key line interface for playing with
HB or old rigs.  On my todo list was to look at the hamlib server
mode.  It will talk to a network server version of itself, no?  So,
that might be an interesting way for me to insert my own application.
Would still need to have TLF modified to use hamlib for keying,
though.  Alternatively, for fun, my application could use CAT for
keying, but it could present both a hamlib socket interface for CAT
and a cwdaemon interface for keying.  This could work with existing
TLF.

Please point me to Ervin's Python 2 script or send me a copy.  Chances
are good that I can port it to Python 3 for you.  (I routinely deal
with the socket and pyserial issues that 2to3 doesn't automagically
fix.)

Best regards,

Drew
n7da

On Thu, Nov 21, 2019 at 11:31 AM Christian Treldal
<[hidden email]> wrote:

>
> Hi guys
>
> First I want to thanks the developers for the new ver. 1.4.0
>
> A year or something ago Ervin wrote a quick Python2 script for keying
> via hamlib. It has n
>
> been working flawlessly until now. I've upgraded to Fedora31 and Python2
> has been depreciated. I am trying to convert it to python3;
>
>   But I think it is a good time for a humble feature request for Tlf
> 1.x.x. A build in hamlib keyer, so at least I can avoid stressfull
> expiriences like this.
>
> All modern rigs have keying via hamlib.
>
>
> 73 de OZ1GNN
>
> --
> Med venlig hilsen
>
>
> Christian Treldal
> "Remember Darwin; building a better mousetrap merely results in smarter mice."
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Using hamlib for CW keying

Ervin Hegedüs - HA2OS
In reply to this post by Christian Treldal-2
Hi Christian,

On Thu, Nov 21, 2019 at 12:29:38PM +0100, Christian Treldal wrote:
>
> A year or something ago Ervin wrote a quick Python2 script for keying via
> hamlib. It has n

I MADE A PYTHON SCRIPT? :D

Could share with me/us? :)

> been working flawlessly until now. I've upgraded to Fedora31 and Python2 has
> been depreciated. I am trying to convert it to python3;
>
>  But I think it is a good time for a humble feature request for Tlf 1.x.x. A
> build in hamlib keyer, so at least I can avoid stressfull  expiriences like
> this.
>
> All modern rigs have keying via hamlib.

you mean aboue like K3? Once I started to review how does it
works, but IMHO it's too difficult. We discussed about this topic with
Zoli HA5CQZ, but now I don't remember the results.


73, Ervin
HA2OS


Reply | Threaded
Open this post in threaded view
|

Re: Using hamlib for CW keying

Christian Treldal-2
Hi Ervin

Tnx fer your script it has been in good use until now.

Den 21.11.2019 kl. 14.58 skrev Ervin Hegedüs:
> Hi Christian,
>
> On Thu, Nov 21, 2019 at 12:29:38PM +0100, Christian Treldal wrote:
>> A year or something ago Ervin wrote a quick Python2 script for keying via
>> hamlib. It has n
> I MADE A PYTHON SCRIPT? :D
>
> Could share with me/us? :)
>
Yes Ervin  AND THE EVIDENCE!!!

https://www.dropbox.com/s/ofn5p482dsf49tv/rigkeyer.py

I've been trying to convert it to Py3 , no capitals in socketserver and
remove .decode("utf8") and is seems to run; but it don't send anything
to the radio.

>> been working flawlessly until now. I've upgraded to Fedora31 and Python2 has
>> been depreciated. I am trying to convert it to python3;
>>
>>   But I think it is a good time for a humble feature request for Tlf 1.x.x. A
>> build in hamlib keyer, so at least I can avoid stressfull  expiriences like
>> this.
>>
>> All modern rigs have keying via hamlib.
> you mean aboue like K3? Once I started to review how does it
> works, but IMHO it's too difficult. We discussed about this topic with
> Zoli HA5CQZ, but now I don't remember the results.

I've been using it with my KX3 and no problems. In the beginning there
was a buffer overflow in hamlib; but it seems to be ok now

I tested today $echo "+\send_morse'test'" | nc -w 1 localhost 4532 to a
IC-7610 and it cw happily

> 73, Ervin
> HA2OS

73 Chris

OZ1GNN

--
Med venlig hilsen


Christian Treldal
"Remember Darwin; building a better mousetrap merely results in smarter mice."


Reply | Threaded
Open this post in threaded view
|

Re: Using hamlib for CW keying

Nate Bargmann-4
In reply to this post by Christian Treldal-2
It should be possible.  We've had a few threads on this topic:

https://lists.nongnu.org/archive/html/tlf-devel/2015-08/msg00000.html
https://lists.nongnu.org/archive/html/tlf-devel/2015-12/msg00001.html
https://lists.nongnu.org/archive/html/tlf-devel/2018-11/msg00027.html

I seem to recall trying to figure out how this might be done in Tlf and
got lost...

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


signature.asc (673 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Using hamlib for CW keying

Ervin Hegedüs - HA2OS
In reply to this post by Christian Treldal-2
Hi Christian,

On Fri, Nov 22, 2019 at 12:18:18AM +0100, Christian Treldal wrote:

>
> Den 21.11.2019 kl. 14.58 skrev Ervin Hegedüs:
> >Hi Christian,
> >
> >On Thu, Nov 21, 2019 at 12:29:38PM +0100, Christian Treldal wrote:
> >>A year or something ago Ervin wrote a quick Python2 script for keying via
> >>hamlib. It has n
> >I MADE A PYTHON SCRIPT? :D
> >
> >Could share with me/us? :)
> >
> Yes Ervin  AND THE EVIDENCE!!!
>
> https://www.dropbox.com/s/ofn5p482dsf49tv/rigkeyer.py

ohh... :)

I found it in my Dropbox :P
 
> I've been trying to convert it to Py3 , no capitals in socketserver and
> remove .decode("utf8") and is seems to run; but it don't send anything to
> the radio.

hmm, sounds interesting.

Anyway, I modified the code, it's avaliable here:

https://www.dropbox.com/s/4jiqdsesomcccio/rigkeyer.py

(the old link redirects to the rigkeyer2.py)

Note, that I've tested now with both Python version (2 and 3). My
TRX doesn't support the CW keying via Hamlib (TS850 still), but I
could test it with the DUMMY RIG. Now it works as well, there
were an another necessary modification in line 25 (in old code).

> >you mean aboue like K3? Once I started to review how does it
> >works, but IMHO it's too difficult. We discussed about this topic with
> >Zoli HA5CQZ, but now I don't remember the results.
>
> I've been using it with my KX3 and no problems. In the beginning there was a
> buffer overflow in hamlib; but it seems to be ok now

sure, then I assume you successfully installed the Hamlib Pythons
module for Python 3.
 
> I tested today $echo "+\send_morse'test'" | nc -w 1 localhost 4532 to a
> IC-7610 and it cw happily

please check it again with this new version above!

Anybody can use it with this way:

python2 rigkeyer.py

or

python3 rigkeyer.py


HTH,



73, Ervin
HA2OS
 

Reply | Threaded
Open this post in threaded view
|

Re: Using hamlib for CW keying

Christian Treldal-2
Hi Ervin

Den 22.11.2019 kl. 09.49 skrev Ervin Hegedüs:
> <snip>

> ohh... :)
>
> I found it in my Dropbox :P
A memoryleak;-)

>  
>> I've been trying to convert it to Py3 , no capitals in socketserver and
>> remove .decode("utf8") and is seems to run; but it don't send anything to
>> the radio.
> hmm, sounds interesting.
>
> Anyway, I modified the code, it's avaliable here:
>
> https://www.dropbox.com/s/4jiqdsesomcccio/rigkeyer.py
>
> (the old link redirects to the rigkeyer2.py)
>
> Note, that I've tested now with both Python version (2 and 3). My
> TRX doesn't support the CW keying via Hamlib (TS850 still), but I
> could test it with the DUMMY RIG. Now it works as well, there
> were an another necessary modification in line 25 (in old code).


I just made a quick test with my KX3 and we are back in business!!!!

>>> you mean aboue like K3? Once I started to review how does it
>>> works, but IMHO it's too difficult. We discussed about this topic with
>>> Zoli HA5CQZ, but now I don't remember the results.
>> I've been using it with my KX3 and no problems. In the beginning there was a
>> buffer overflow in hamlib; but it seems to be ok now
> sure, then I assume you successfully installed the Hamlib Pythons
> module for Python 3.
>  
>> I tested today $echo "+\send_morse'test'" | nc -w 1 localhost 4532 to a
>> IC-7610 and it cw happily
> please check it again with this new version above!
>
> Anybody can use it with this way:
>
> python2 rigkeyer.py
>
> or
>
> python3 rigkeyer.py
>
>
> HTH,
>
>
>
> 73, Ervin
> HA2OS
>  

Again thanks a lot Ervin, see you in the test

73, Chris

--
Med venlig hilsen


Christian Treldal
"Remember Darwin; building a better mousetrap merely results in smarter mice."


Reply | Threaded
Open this post in threaded view
|

Re: Using hamlib for CW keying

Ervin Hegedüs - HA2OS
hi Christian,

On Fri, Nov 22, 2019 at 12:19:29PM +0100, Christian Treldal wrote:
> Hi Ervin
>
> Den 22.11.2019 kl. 09.49 skrev Ervin Hegedüs:
> ><snip>
>
> >ohh... :)
> >
> >I found it in my Dropbox :P
> A memoryleak;-)

perfect description :)

> >Note, that I've tested now with both Python version (2 and 3). My
> >TRX doesn't support the CW keying via Hamlib (TS850 still), but I
> >could test it with the DUMMY RIG. Now it works as well, there
> >were an another necessary modification in line 25 (in old code).
>
>
> I just made a quick test with my KX3 and we are back in business!!!!

good to read :)
 
> Again thanks a lot Ervin, see you in the test

you're welcome,

I'll participate from our club station with call HG5C - see you
there! :)


73, Ervin


Reply | Threaded
Open this post in threaded view
|

Re: Using hamlib for CW keying

Csahok Zoltan
In reply to this post by Christian Treldal-2
Hi Christian,

Yes, keying does work with the script. But as far I can see
there are two issues with hamlib keying:

- in-band speed changes are not supported. one can't send "+++TEST---"

- sending a large message could block rig interface until it gets queued.

Given the rig protocol (KY command) and the way hamlib supports it
I see no option to circumvent these.

WinKeyer on the other hand offers in-band speed change and winkeyerdaemon
provides the buffering for a cwdaemon compatible UDP interface.

Correct me if I'm wrong here.


73,
Zoli


On Fri, Nov 22, 2019 at 12:18:18AM +0100, Christian Treldal wrote:
>
> I tested today $echo "+\send_morse'test'" | nc -w 1 localhost 4532 to a
> IC-7610 and it cw happily
>

Reply | Threaded
Open this post in threaded view
|

Re: Using hamlib for CW keying

Nate Bargmann-4
* On 2019 22 Nov 14:31 -0600, Csahok Zoltan wrote:

> Hi Christian,
>
> Yes, keying does work with the script. But as far I can see
> there are two issues with hamlib keying:
>
> - in-band speed changes are not supported. one can't send "+++TEST---"
>
> - sending a large message could block rig interface until it gets queued.
>
> Given the rig protocol (KY command) and the way hamlib supports it
> I see no option to circumvent these.
>
> WinKeyer on the other hand offers in-band speed change and winkeyerdaemon
> provides the buffering for a cwdaemon compatible UDP interface.
>
> Correct me if I'm wrong here.
You may well be correct, Zoli.  As I recall, a speed change would
require sending the proper CAT command each time the change is made.
It's possible this could be done in a manner that doesn't mess up the
timing of the sent Morse, I think it would likely be very rig specific.

One thing the K3 and the later models can do is be keyed via the RTS/DTR
line and N1MM+ takes full advantage of that, speed changes and all.
Problem is whether more rigs support that and whether Hamlib supports
it.  Even though I've been a part of the Hamlib project for quite some
time, I'm not sure!  There may be some provision but probably needs some
debugging.  Again, this is a feature that is rig specific.

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


signature.asc (673 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Using hamlib for CW keying

Drew Arnett
Portable is good.  So I'd ask if hamlib found it possible to support
speed changes.

KX3 is only 3 wire serial CAT interface, so no RTS/DTR style keying
possible.  In that case, I suppose a Y cable could be fabricated that
fans out RTS/DTR to a separate key plug.  That's a bit tidier perhaps.

Another difference between rigs.  Some have a jack for paddles and a
jack for key.  KX3 doesn't, so I like using the external WinKeyer box
to let logging software and paddles key the rig.  Using the WinKeyer
box means I'll have a common solution regardless of which rig I end up
using.  (Operating at home, operating at someone else's station, FD
and other situations where the gear is an assortment from all the
participants, etc.)

Another bonus using a WinKer (or equivalent) is that the paddle input
then pauses any sending, too.  However, recently during contests, I've
been better about using CTRL-K to do fills instead of reaching for the
paddles. I'm still too green to know which method of keying for fills
I will ultimately end up preferring.

Best regards,

Drew
n7da

On Fri, Nov 22, 2019 at 10:19 PM Nate Bargmann <[hidden email]> wrote:

>
> * On 2019 22 Nov 14:31 -0600, Csahok Zoltan wrote:
> > Hi Christian,
> >
> > Yes, keying does work with the script. But as far I can see
> > there are two issues with hamlib keying:
> >
> > - in-band speed changes are not supported. one can't send "+++TEST---"
> >
> > - sending a large message could block rig interface until it gets queued.
> >
> > Given the rig protocol (KY command) and the way hamlib supports it
> > I see no option to circumvent these.
> >
> > WinKeyer on the other hand offers in-band speed change and winkeyerdaemon
> > provides the buffering for a cwdaemon compatible UDP interface.
> >
> > Correct me if I'm wrong here.
>
> You may well be correct, Zoli.  As I recall, a speed change would
> require sending the proper CAT command each time the change is made.
> It's possible this could be done in a manner that doesn't mess up the
> timing of the sent Morse, I think it would likely be very rig specific.
>
> One thing the K3 and the later models can do is be keyed via the RTS/DTR
> line and N1MM+ takes full advantage of that, speed changes and all.
> Problem is whether more rigs support that and whether Hamlib supports
> it.  Even though I've been a part of the Hamlib project for quite some
> time, I'm not sure!  There may be some provision but probably needs some
> debugging.  Again, this is a feature that is rig specific.
>
> 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
>

Reply | Threaded
Open this post in threaded view
|

Re: Using hamlib for CW keying

Nate Bargmann-4
* On 2019 23 Nov 08:26 -0600, Drew Arnett wrote:
> Portable is good.  So I'd ask if hamlib found it possible to support
> speed changes.

Yes.  It is done through the set/get_level functions in rigctl with the
KEYSPD token:

$ rigctl -m 229 -r /dev/rig

Rig command: l
Level: KEYSPD
Level Value: 22

Rig command: L
Level: KEYSPD
Level Value: 18

Rig command: l KEYSPD
Level Value: 18

Rig command: b N0NB

Rig command: L KEYSPD 22

Rig command: b N0NB

Rig command: l
Level: KEYSPD
Level Value: 22

Rig command:



Works on my K3.

> KX3 is only 3 wire serial CAT interface, so no RTS/DTR style keying
> possible.  In that case, I suppose a Y cable could be fabricated that
> fans out RTS/DTR to a separate key plug.  That's a bit tidier perhaps.
>
> Another difference between rigs.  Some have a jack for paddles and a
> jack for key.  KX3 doesn't, so I like using the external WinKeyer box
> to let logging software and paddles key the rig.  Using the WinKeyer
> box means I'll have a common solution regardless of which rig I end up
> using.  (Operating at home, operating at someone else's station, FD
> and other situations where the gear is an assortment from all the
> participants, etc.)
This is one of those "wishlist" items that understandably will not work
with every radio.  For those it does, it can be quite useful.

> Another bonus using a WinKer (or equivalent) is that the paddle input
> then pauses any sending, too.  However, recently during contests, I've
> been better about using CTRL-K to do fills instead of reaching for the
> paddles. I'm still too green to know which method of keying for fills
> I will ultimately end up preferring.

All of these approaches have tradeoffs, no surprise there.  Everyone has
their preferred approach.

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


signature.asc (673 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Using hamlib for CW keying

Nate Bargmann-4
In reply to this post by Christian Treldal-2
* On 2019 21 Nov 05:32 -0600, Christian Treldal wrote:
> All modern rigs have keying via hamlib.

I would caution, that is possible with varying degrees of support and
capability.

On the N1MM+ mailing list there is this recent thread that asks about a
warning when CAT keying is used:

https://groups.io/g/N1MMLoggerPlus/message/45927

Rich, VE3KI, weighs in later with:

https://groups.io/g/N1MMLoggerPlus/message/45930

where he states:

        Which rig? The KY command works differently in Elecraft vs.
        Kenwood vs. Yaesu. The examples that have been posted in various
        places were for Elecraft radios. IIRC, the KY command for
        Kenwood radios requires a fixed-length argument (padded with
        blanks), which makes it essentially impossible to use
        substitution macros. Also as I recall, the Yaesu KY command does
        not send text, it selects one of the radio's own CW memories and
        sends that.

I've not seen the code, of course, but I presume that N1MM+ is handling
all of the rig control stuff internally.  For Tlf and other programs
using Hamlib, the rig capabilities would be queried and if
rig_send_morse() is supported, it can be used, however, things like the
speed up/down characters in the keying macro would need to be handled by
the calling program and speed changes sent to the rig interspersed with
the message text.   I can see this becoming very clunky very quickly!

Any given Hamlib backend will probably be coded so as to perform needed
work-arounds as best as possible.  Again, this is very rig specific and
even Hamlib likely cannot hide certain differences.

I only have access to a K3 these days.  I've not seen much mention of
anyone using the Hamlib send_morse function for any serious CW keying.

If I could offer a wishlist item to the manufacturers, it would be for
those radios incorporating a USB connector for rig control and sound
card IO that a second virtual serial port be available to expose a K1EL
compatible keyer.

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


signature.asc (673 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Using hamlib for CW keying

Christian Treldal-2
Hi Nate

Den 25.11.2019 kl. 09.18 skrev Nate Bargmann:

> * On 2019 21 Nov 05:32 -0600, Christian Treldal wrote:
>> All modern rigs have keying via hamlib.
> I would caution, that is possible with varying degrees of support and
> capability.
>
> On the N1MM+ mailing list there is this recent thread that asks about a
> warning when CAT keying is used:
>
> https://groups.io/g/N1MMLoggerPlus/message/45927
>
> Rich, VE3KI, weighs in later with:
>
> https://groups.io/g/N1MMLoggerPlus/message/45930
>
> where he states:
>
> Which rig? The KY command works differently in Elecraft vs.
> Kenwood vs. Yaesu. The examples that have been posted in various
> places were for Elecraft radios. IIRC, the KY command for
> Kenwood radios requires a fixed-length argument (padded with
> blanks), which makes it essentially impossible to use
> substitution macros. Also as I recall, the Yaesu KY command does
> not send text, it selects one of the radio's own CW memories and
> sends that.
>
> I've not seen the code, of course, but I presume that N1MM+ is handling
> all of the rig control stuff internally.  For Tlf and other programs
> using Hamlib, the rig capabilities would be queried and if
> rig_send_morse() is supported, it can be used, however, things like the
> speed up/down characters in the keying macro would need to be handled by
> the calling program and speed changes sent to the rig interspersed with
> the message text.   I can see this becoming very clunky very quickly!
>
> Any given Hamlib backend will probably be coded so as to perform needed
> work-arounds as best as possible.  Again, this is very rig specific and
> even Hamlib likely cannot hide certain differences.
>
> I only have access to a K3 these days.  I've not seen much mention of
> anyone using the Hamlib send_morse function for any serious CW keying.
>
> If I could offer a wishlist item to the manufacturers, it would be for
> those radios incorporating a USB connector for rig control and sound
> card IO that a second virtual serial port be available to expose a K1EL
> compatible keyer.
>
> 73, Nate
>
My intention in this was only ,as a casual contester, to create a easy
way to do CW on my rig using a logprogram.

It don't need to be the perfect solution, and if there are some timing
issues, who cares in a contest anyway. I have a K1EL keyer myself; but
then I have to bring another gizmo almost as big as my KX3 when I go to
DU-land. That doesn't make sense to me, when I already has a keyer in
the radio.

Ervin and I will continue to work on our rigkeyer daemon who listens on
a port, parses it and sends it to 4532 for handeling by rigctld.

--
Med venlig hilsen


Christian Treldal
"Remember Darwin; building a better mousetrap merely results in smarter mice."


Reply | Threaded
Open this post in threaded view
|

Re: Using hamlib for CW keying

Olaf Devik
In reply to this post by Christian Treldal-2
Keying my K3 via hamlib works nicely.

But there are some problems, one is that Hamlib used a simplified
control setup based on Kenwood protocol and not fully includes all
possibilities in the Elecraft protocol.

By checking the actual commands between pc and rig it is apparent that
keying is done by KY command, not the Elecraft KYW command. The
difference between the two is that KYW blocks further commands while
buffer is emptied, fine if you want to change key speed at a certain
point. To enable speed changes in text would then necessitate changes in
the backend hamlib and as someone pointed out solution will probably
differ from rig to rig.

Therefore implementing speed changes within a cw string will be
difficult using hamlib. However, for simple cases like just sending text
strings, use of hamlib would make life simpler. Ie not another box with
associated cables. Fine for the casual contester.

Keying of a string from the pc can be stopped by sending ^D (pg 15 in
K3/KX3 programmers reference) character or just pushing a paddle lever
assuming paddle is connected to rig.

I would welcome such addition to tlf. Alternative would be to set up
nanokeyer, winkeyer or similar, but again, this is basically a box that
is unneeded with my K3 or for that matter my KX3.

73 de Olaf - LA3RK


Reply | Threaded
Open this post in threaded view
|

Re: Using hamlib for CW keying

Nate Bargmann-4
Thanks for that, Olaf.

Here is a crazy idea I had that someone might like to experiment with.
I thought of using a serial port multiplexer, assuming such a thing
exists and I found https://github.com/danielinux/ttybus as one of the
first hits, to have Hamlib and cwdaemon share the same port.  For the K3
and other radios that don't use hardware handshaking, this may work
well.  cwdaemon keys CW via the DTR pin and the K3 can be configured to
key CW via DTR or RTS.  In theory, since Hamlib and cwdaemon use
different pins, this should work.

Another idea is to not bother with a multiplexer and just direct Hamlib
and cwdaemon to the same port and see what happens!  So far I've not
tried this hare-brained idea myself...

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


signature.asc (673 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Using hamlib for CW keying

Drew Arnett
Hamlib is great and really achieved a lot.  Very neat what clients can
do with that library for sure.

But, all in one solutions sometimes get, um, interesting.  cwdaemon
defined a protocol.  So, anyone can write a replacement, that tlf and
others, can use.  And they have.  cwdaemon itself doesn't support
every type of keying hardware.  Nor did some of the alternatives that
implemented the protocol.

On my todo list is to read the hamlib rigctld protocol to see if it is
a candidate for the same approach.  No, I don't think hamlib should go
away or anything like that.  But, to do something custom, like have an
application listed to the cwdaemon and rigctld ports and wring what it
can from the KX3 or K3 CAT protocol might be interesting.  Or
something along those lines.  Sounds like someone has already tried
something along these lines.

Interesting stuff.

Drew
n7da

ps.  A couple of years ago, when I looked at the cwdaemon protocol, I
also looked at the packets generated by several different client
applications.  Some send more data than the protocol requires, and
cwdaemon doesn't complain.  IIRC, all had trailing nulls, some a
single null byte and some several.  So, I reported that in debug mode:
 https://github.com/drewarnett/pywinkeyerdaemon/blob/master/pywinkeyerdaemon.py#L126

On Wed, Nov 27, 2019 at 8:45 AM Nate Bargmann <[hidden email]> wrote:

>
> Thanks for that, Olaf.
>
> Here is a crazy idea I had that someone might like to experiment with.
> I thought of using a serial port multiplexer, assuming such a thing
> exists and I found https://github.com/danielinux/ttybus as one of the
> first hits, to have Hamlib and cwdaemon share the same port.  For the K3
> and other radios that don't use hardware handshaking, this may work
> well.  cwdaemon keys CW via the DTR pin and the K3 can be configured to
> key CW via DTR or RTS.  In theory, since Hamlib and cwdaemon use
> different pins, this should work.
>
> Another idea is to not bother with a multiplexer and just direct Hamlib
> and cwdaemon to the same port and see what happens!  So far I've not
> tried this hare-brained idea myself...
>
> 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
>

Reply | Threaded
Open this post in threaded view
|

Re: Using hamlib for CW keying

Olaf Devik
In reply to this post by Christian Treldal-2
I now have my K3 working with keying without any additional boxes like
netkeyer, winkeyer or similar.

Solution is fairly simple;

1. Install cwdaemon. Standard install uses parallell port for keying so
to use eg a serial port you have to modify cwdaemon config file (resided
in /etc/default). Had to set ttyS0 instead of parport0. cwdaemon seems
to start on boot with the standard debian install. So to get cwdaemon to
use serial port you need to restart; sudo service cwdaemon restart

2. Rig is controlled over same serial port. This seems to work fine as
the rig communication only uses txd and rxd lines. But there is a catch.
My standard install of hamlib triggered both dtr and rts lines and keyed
the rig unless rigctld command was changed. To avoid this you need to
ask hamlib to clear both the dtr and the rts lines. This can be done by
giving rigctld the following options in addition; -C rts_state=OFF -C
dtr_state=OFF.

3. On the K3 you need to enter the config menu and set the PTT-KEY entry
to OFF-dtr. It seems the cwdaemon keying goes over the dtr line. If you
want cwdaemon to control the ptt line, you would probably set this to
rts-dtr. Not necessary with a K3 as it provides full break-in.

The above works both with tlf and with cqrlog which is used for my main
logging. And this solution fully accepts all speed change commands and
tx stops from keyboard as it does not utilize the K3 internal keyer.

So by this I have no need for tlf (or cqrlog) to use keying via hamlib
as long as I use my K3.

But my KX3 does not allow for keying via the dtr line so the solution
will not work unless the dtr signal is routed via a transistor to the
KX3 key input. A solution which can be used for most rigs I assume.

So all in all, I do not have to prepare a nanokeyer/winkeyer or similar
extra box.

Thanks for responses which triggered me into finding a practical solution.

PS: Have not tried this on a usb-serial converter, my serial port is a
"real" serial port based on an UART 16550. But I note some usb-serial
devices has brought out the dtr line, and I would assume that this can
be made to work also on these.

73 de Olaf - LA3RK



Reply | Threaded
Open this post in threaded view
|

Re: Using hamlib for CW keying

Nate Bargmann-4
That's cool, Olaf.

It stands to reason that the DTR and RTS lines would explicitly need to
be turned off as I think the kernel automatically enables them when an
application initializes the port.

This was a more or less silly idea I had and I'm glad to see it will
work!  I'll have to try it too.  I'll have to look at the Tlf code to
see if config parameters can be passed to the library without going
through tigctld.

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


signature.asc (673 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Using hamlib for CW keying

Nate Bargmann-4
D'oh!  Read the man page, Nate!

       RIGCONF=rig_configuration_parameters
              Send rig configuration parameters to Hamlib.
              e.g. RIGCONF=civaddr=0x40,retry=3,rig_pathname=/dev/ttyS0

I plan to try this.

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


signature.asc (673 bytes) Download Attachment
12