Re: Using hamlib for CW keying

2019-12-05 Thread Nate Bargmann
I've just finished setting up for ARRL 160 and am using cwdaemon with
the same port as Hamlib.  In logcfg.dat I added the following line:

RIGCONF=rts_state=OFF,dtr_state=OFF

Then I set the K3's PTT-KEY menu to OFF-DTR and the keying was working
fine with one port as I tested it.  The proof will be in the 'test this
weekend!

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
Description: PGP signature


Re: Using hamlib for CW keying

2019-11-29 Thread Csahok Zoltan
Now I remember that actually our FD is setup is just like this:
using a single USB-serial converter with RX/TX controlling the rig via hamlib
and DTR doing keying via cwdaemon. We had no issues with it. 
The only thing is that at Tlf start-up the key is down for a second.
I'll check hamlib config to see if this behaviour can be cured.
Thanks Nate for the pointer.

73,
Zoli

On Fri, Nov 29, 2019 at 12:51:59PM -0600, Nate Bargmann wrote:
> 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.
> 



Re: Using hamlib for CW keying

2019-11-29 Thread Nate Bargmann
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
Description: PGP signature


Re: Using hamlib for CW keying

2019-11-29 Thread Nate Bargmann
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
Description: PGP signature


Re: Using hamlib for CW keying

2019-11-29 Thread Olaf Devik
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





Re: Using hamlib for CW keying

2019-11-27 Thread 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  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
>



Re: Using hamlib for CW keying

2019-11-27 Thread Nate Bargmann
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
Description: PGP signature


Re: Using hamlib for CW keying

2019-11-26 Thread Olaf Devik

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




Re: Using hamlib for CW keying

2019-11-26 Thread Christian Treldal

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."




Re: Using hamlib for CW keying

2019-11-25 Thread 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

-- 

"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
Description: PGP signature


Re: Using hamlib for CW keying

2019-11-23 Thread Nate Bargmann
* 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
Description: PGP signature


Re: Using hamlib for CW keying

2019-11-23 Thread 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  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
>



Re: Using hamlib for CW keying

2019-11-22 Thread Nate Bargmann
* 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
Description: PGP signature


Re: Using hamlib for CW keying

2019-11-22 Thread Csahok Zoltan
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
> 



Re: Using hamlib for CW keying

2019-11-22 Thread Ervin Hegedüs
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:
> >
> 
> >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




Re: Using hamlib for CW keying

2019-11-22 Thread Christian Treldal

Hi Ervin

Den 22.11.2019 kl. 09.49 skrev Ervin Hegedüs:





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."




Re: Using hamlib for CW keying

2019-11-22 Thread Ervin Hegedüs
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
 



Re: Using hamlib for CW keying

2019-11-21 Thread Nate Bargmann
It should be possible.  We've had a few threads on this topic:

https://lists.nongnu.org/archive/html/tlf-devel/2015-08/msg0.html
https://lists.nongnu.org/archive/html/tlf-devel/2015-12/msg1.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
Description: PGP signature


Re: Using hamlib for CW keying

2019-11-21 Thread Christian Treldal

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."




Re: Using hamlib for CW keying

2019-11-21 Thread 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? :)

> 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




Re: Using hamlib for CW keying

2019-11-21 Thread 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
 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."
>
>