I have tried to find out if there is a solution to connect an external button for PTT preferably using the side channel signals in a USB serial adapter. I have used that with other remote PTT program remaudio but cannot use it any more as I’m now on linux on the remote end and remaudio is windows only.
What I would like is possibility to set up a serial port and decide which pin is used, CTS or DSR, for PTT and what polarity is PTT active.
Have I missed something that is already there or shall I add this as a feature request/whish for future releases?
I used a CD4528, a CD4066, R’s, C’s and an old USB-keyboard-PCB to
create Ctrl+T on the falling edge and Ctrl+R on the rising edge when
switching the PTT input.
You’ll need to sign in first (and possibly create a developer account, it is free).
Once you create an issue, we get emails about it automatically :-). It’s just a way for us to track things people are asking about. We can create the issue for you if you like.
Thank you both.
I think it would be a better solution to support the relatively standard solution among SDR rigs which is the USB sideband signals CTS or DSR instead of having to slaughter a keyboard, even if that was a very creative solution.
Now I have created a new issue with the same headline as this thread.
Personally, I think Phil’s work on using the ShuttleXPress and ShuttleX Pro is going to be the best solution, as you then get several buttons and a tuning dial. I tried this out recently and it really is a very nice way to use a radio remotely.
But I am open to other ideas. There are also special “small” macro keyboards you can get with just a few buttons on them, and you can program those buttons to send custom key commands.
I understand what you mean. The ShuttleExpress is an interesting solution but it does not give me a foot pedal and it goes a bit against my idea of keeping the cost down of my remote working.
If I pay some $ to remote control my rig I could easily buy Win4Icom or BA1. Both are good solutions for remoteing an Icom rig.
Personally I’m against using these alternative programs is mainly because I truly like the idea of cooperative work on open source solutions even if I have actually bought a license for Win4Icom. I don’t use it mainly because it requires a Windows computer on the other side and it was difficult to connect DXLabs suite to it to get my preferred suite of support programs to help.
Using an old ‘slaughtered’ keyboard also requires the wfview program to be in focus to actually toggle PTT I understand? This is really annoying when using support programs on a small screen. I have solved it by using AutoHotKey to quickly switch between programs. wfview has a long path to become a full remote solution but it is now my main choice. In wfview I do lack support for split operation, control of filters and such but I can manage that using DXLabs on the back for now even if it is a bit tricky. And I’m pretty sure it will be implemented eventually…
The main issue by using CTS or DSR (if using e.g. QT) is that you must poll the CTS and DSR. There is no automatic function to connect them as triggering signals I have found. I use this type of serial connection in a QT client for remote straight key CW even though I’m not a programming guru.
Please, don’t read my comments here as criticism or anything like. I have understood by experience I sometimes argue in a way that offend people and that is NOT my intention. I just want to explain why I think it would be a good idea to have a really simple interface for external PTT which is common with other SDR programs such as Quisk. It should not be a big issue to implement either but it is of course a question of prioritize what benefits most people first, which is important too.
You know, one way to quickly hack that idea together is to write some python that polls the serial port status constantly, and sends transmit commands over the rigctld connection that wfview supports. I do something similar right now to make gqrx follow wfview.
Then you could take the result of the query and send the appropriate command to wfview’s built-in rigctld-compatible server. Which, by the way, can accept more than one connection at the same time.
Don’t forget to turn on rigctld under External Control in settings.
For example, I can telnet in and set and query PTT:
$ telnet localhost 4532
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
t
0
T 1
RPRT 0
t
1
T 0
RPRT 0
t
0
^]
telnet> quit
Connection closed.
You see? Not too difficult to script things up using this connection.
Thank you
I think you have given me the missing tool
I think I can relativrly easily modify my CW-client to connect using rigctl as of your example and the problem should be solved for me.
I’ll get back if I encounter problems I think you might be able to help me with…
Really thank you Elliot!
I did a quick and dirty change of my CW client/server to send “T 1\n” and “T 0\n” when I push and release my CW key, connected to the rigctl port of wfview over raw TCP and it works perfect! Now I have a PTT-over-serial-adapter working for me and I will clean up the code from everything CW-ish and offer it to others. I only run Windows on the client side so I don’t know if it works under Linux but it is QT so it is fully possible…
That is correct but my code to interpret the PTT button might not be that well written and maybe not so portable :o) Even though I guess it might really be.
Remember I have only tested it on my windows10 64 bit.
The Readme file should be populated with instructions.
There is a zip-file with what is neede by me to run the program stand-alone and should work for others if unpacked somewhere and run the program PTT-rigctl.exe
Keep me posted if you try with or without success anyone!
I hope you got my latest updates which make it easier to debug problems. I.e. when PTT is pushed the GUI PTT button turns red so it is possible to divide possible problems in serial-port or TCP connection problems…
