In search of remote control software to operate SSB and CW, I found wfview to be the best candidate to keep things simple in setup. Would it be possible to operate SSB and CW using a iambic paddle from the remote pc using wfview? If so, which icom is the most suitable to get this working?
As a sidenote, I had my eye on a Icom 718 and I can live with SSB using RTS an not having waterfall etc but will a paddle on the remote pc work? I have the feeling it can’t be done? Any icom able to have a paddle on the remote pc?
It’s possible to key modern Icom transceivers remotely via paddle / straight key / etc but requires a USB connection. The ‘modulation signal’ is then fed into the radio’s internal USB / serial port adapter chip using the emulated modem control lines.
I have such a program in use myself (I called it “Remote CW Keyer”, and it was just a proof of concept) but there needs to be a ‘server’ on the radio side with USB. For some reason, Icom decided not to support direct keying via LAN / WLAN - what a shame. What can be done is sending ASCII characters to the radio (also via LAN / WLAN) but the client side (PC, raspberry, or whatever) would need to translate the Morse code from the paddle into ASCII (text) for the remote radio - and that’s tricky, and as far as I know not possible with wfview yet.
It seems not to be possible have a system that copies your ‘fist’ from the client PC to the rig. Even if you could write the code to interpret a paddle or straight key on the client and code in the host PC to drive a key input to the rig, I think the variance in latency between the client and host would distort the sending.
That leaves the host PC sending CW strings to the radio. I know that IC7300 can be driven that way. And also the IC705 can be driven over the LAN by wfview on a client PC. I have done that using the CW input mechanism in wfview. But that is keyboard input of the text.
Wolf suggests having paddle or key input on the client PC. A club member has implemented an arduino solution that converts straight key to emulate a keyboard. We used it at JOTA last year to get the kids to send morse and see what they sent. I’ve also built an arduino based keyer/reader that allows me to duplex a paddle and straight key and displays the sent text on a 16*2 LCD screen, but this drives the Icom as a straight key.
So morse key driven text input is practicable, but you will need custom hardware to convert the morse to keyboard strokes. What I don’t think has been tested is whether you can connect both the kb emulator and a real kb to an app such as wfview.
Thank you very much for the info and suggested possibilities. As I understand and also saw on youtube, there are paddle solutions to connect to the pc using USB with teenty or arduino like prints. The program mentioned by Wolf triggers also my intrest. I have found and installed the software but need to read the extended documentation 1st before asking questions
I also saw some old school solutions using a mouse as interface to USB which is very cheap and easy. Without any form of knowledge in current wfview cw solutions, would this not be a possibility to get signals from the paddle into the pc, and translate that into text in the CW keyer?
Translate CW into text for transmission, and let the rig convert it back from ASCII (Text) to Morse is easy if the operator uses paddles, and a half-way “normal” timing. But inaccuracies or “special hand-writing” with a straight key won’t be much fun with such a system, beause the rig (e.g. IC-7300) can either send a character followed by a inter-word-space, or two characters spaced by exactly three dots. Nothing in between. So whatever happens, the actual transmitted signal will have a different timing than what the operator keys into the “client”-side. I tried to solve this using keying commands consisting of the “key up / key down” state in the upper bits of each byte in the keying bytestream, and the time duration (with a non-linear encoding) in the lower 7 bits. Then, at the “server” side, the program is aware of the network latency AND the jitter of the latency (for that purpose, it kind of “pings” the latency over the TCP/IP connection). Depending on the peak latency, the server keeps a few hundred milliseconds of keying commands in a FIFO, just long enough to prevent running out of data.
Lengthy details and test results (for the tech-minded) at https://www.qsl.net/dl4yhf/Remote_CW_Keyer/Remote_CW_Keyer.htm
During a few tests, using a DSL connection on one side (e.g. server in my shack) and a mobile internet connection for the ‘client’ PC, this worked reasonably well (but not perfect yet). For these tests, I use TCP/IP, not UDP, for a couple of reasons.
Thank you for your reply. I’m done playing with my mouse and started to think of a solution to get this remote idea to go. I have ordered 2x FDTI USB to TTL serial converters for the direct keying part. Looking for schematics, I have found a RCForb (which also has my interest and if possible combine both wfview and remotehams) document to wire paddles for direct keying. this states the following;
Dit → DSR
Dah → DCD
In your program these options are selectable for ‘dot’ and ‘dash’.
When reading your documentation I think the wiring for the radio will be the jack in the transceiver configured for straight key with pins DTR on tip and ground to sleeve? Not sure if RTS is needed here but by the looks of it, the program remote CW keyer has this default selected. Therefore selecting the COM from the usb-to-serial adapter will be sufficient?
