[Tlf-devel] Cluster sound
Hi there. I finally got everything ready for the cqww; but is there a clever way to get rid of the 'boiing' which comes with every new spot. You can always turn down the volume; but it doesn't prevent the 'boiing' from being re transmitted when using the PC as cq-machine. Any useful hints?? 73's de OZ1GNN -- Med venlig hilsen Christian Treldal "Remember Darwin; building a better mousetrap merely results in smarter mice." ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] Cluster sound
Hi Tnx. Open a packet terminal ":pac", writing "set/nobell", close it with ":" did the trick. Den 27-10-2016 kl. 20:57 skrev Fabian Kurz: > On Thu, Oct 27, 2016 at 08:42:44PM +0200, Christian Treldal wrote: >> I finally got everything ready for the cqww; but is there a clever way >> to get rid of the 'boiing' which comes with every new spot. You can >> always turn down the volume; but it doesn't prevent the 'boiing' from >> being re transmitted when using the PC as cq-machine. > On DXSpider clusters (and probably others) you can disable the > bell at the end of each spot (0x07) by the command "set/nobell". > > 73 > Fabian 73 de OZ1GNN -- Med venlig hilsen Christian Treldal "Remember Darwin; building a better mousetrap merely results in smarter mice." ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
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."
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 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
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."
