Re: Using hamlib for CW keying
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
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
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
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
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
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
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
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
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
* 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
* 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
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
* 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
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
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
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
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
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
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
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
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." > >
Using hamlib for CW keying
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."
