It sounds like to use winkeyer locally is solved. To use it remotely, if I am understanding correctly, one needs to forward serial traffic from a “server” computer (could be as simple as a Raspberry Pi) with the winkeyer, to the remote user location. You can forward serial traffic very easily with linux using socat. On windows it can be significantly more involved I believe.
I’m not sure if we need to do anything with wfview. But we can add a how-to if anyone has a good workflow for CW.
So if I read you right we’d have the winkeyer connected to the server side which is also running this socat program (which I will have to google real soon now).
and on the local computer run wfview and fldigi with fldigi configured to talk to the winkeyer but point to a local instance of this socat program and have the traffic go thru this networked virtual serial port pipeline.
That very well could work.
There will probably be some problem with linux socat talking the same language as some windows equivalent. They may do the same thing but the packet structure used bny both may not be compatible.
“In theory” the wfview server could forward the winkeyer data to a remote wfview, it is also possible for us to emulate a winkeyer at the wfview client end (there are a few open source implementations of winkeyer available) and ‘for example’ the wfview server could ‘key’ the rig using GPIO (assuming the server is a Raspberry Pi).
This would remove a lot of the potential timing issues and we could even send timing information with the data to the remote wfview.
I like the ideas! A Pi can also do PTT, TUNE, and S-Meter (or power or SWR) for older rigs that lack those commands. We’ll have to at least add a mechanism to read/write to the GPIO on the Pi. So many possibilities.
I could not agree more about the socat documentation. Also, it seems like there is some inconsistency in how command-line arguments are interpreted. Sometimes, if they are in the wrong order, you get an error that implies you have specified bad arguments. It’s frustrating.
There are some examples on the old wiki for how to do this, which worked for me with some success. This is how I forwarded CI-V traffic prior to Phil’s magical server/client work, which is now integrated into wfview. And for what it’s worth, I think you and I have quite similar commands.
Don’t read into it much, just use the socat examples. In both cases, I wrote a while loop in a bash shell script to keep the socat running should it happen to exit. I still have issues sometimes where I cannot re-connect until I recycle the socat server side. But overall, it is a useful swiss army knife tool for sure.
Hi Phil, I found that the supporting radio control for Fldigi, flrig, can support CW keying using CAT commands. Using Winkeyer, requiring additional hardware, just seems an outdated approach. Now waiting for a Winkeyer software emulator to hook up with my logger…
73, W6WYN
The way I transmit “good CW” is with FLDIGI 4.19 using the DTR-RTS keying on the (USB) COM-port to the rig (7300). True, there are very slight dependencies on PCs cpu load variations. Advantage is that the FLDIGI DTR rig cw keying also handles north European accented characters and Prosigns. Config settings are above CAT Keying in W6WYN’s posting above.
If the COM-port signals RTS and DTR are stably communicated from a remote wfview, CW keying from remote could be possible. I may be able to test this tomorrow, unless anyone else has verified it.
At the moment, the DTR/RTS signals aren’t transferred between wfview client/server. We are looking at a couple of methods of doing this while retaining compatibility with rig based servers but it is quite complex as it would need to take into account latency/jitter of the connection.
direct USB connected CW works fine with n1mm+ as well if you use DTR or RTS for keying.
Some rigs handle CIV commands to send CW but the issue obviously is that you need to feed the text
instead of the generated CW.
I have been thinking of how to reliably send cw messages for the rigs that support it. Meaning that all the timing will be taken care of the rig instead of “local” at n1mm+/wfview/etc. The reason why local does not work well is that - if we talk about remote operations - jitter, latency and missing signals may cause your cw writing to become unbearably useless.
We’d like to know what’s needed to be sent and send over in CI-V the text and the rig will use it’s internal logic to send away the text.
Same as for M1…8 – thinking baout ways to be able to use them via a working solution as you cannot say to the rig “send the M1 contents”.
FYI, CI-V on many radios permits sending CW with the rig’s keyer. This is good because it doesn’t rely on good timing by the computer, doesn’t tie up the serial port for more than a few milliseconds, and uses the rig’s keyer speed setting. Hamlib does this, but the "RigCtld emulation function of WFView does not appear to do this yet.
However, it works fine if you use hamlib with wfview’s virtual serial port. I am able to send CW on my IC-7300 with the following command:
Note that “port number” there is for CQRLog’s version of rigctld, so can’t be the same as the rigctld port wfview is listening on.
In my view, keying CW should be the responsibility of the logger anyway, so this works fine. Hopefully wfview’s rigctld will eventually get the option of sending cw, but this alternative works fine for now. A keyer-speed knob would be nice though! Thanks devs, this is fantastic software. Just thought I would share these options for anyone trying to set computer keying up. No need for external keyers or any of that jazz for the 7300 and siblings.
This is very interesting indeed! I’m not a CW op (yet?), so let me see if I understand the mode of operation correctly: You send CQ (or other CW traffic) by sending the characters to the radio over CI-V, and then the radio keys the characters at the prescribed rate? Is this correct? I’m sorry to be so uninformed about it. Is sending CW via typing in CQRLog a fairly common thing people do? How does the experience compare to sending via fldigi’s modulated CW?
Your screenshot is good, this will be helpful to others trying to make this connection. Our implementation of rigctld is interesting, we’re trying to support common commands although there are many (such as thins one) that we hadn’t encountered yet. wfview’s rigctld server (thank you Phil!!!) is a more advanced method of control compared to the pseudo-term, because we can properly rate-limit traffic to the radio and cache recent results (recent being a few ms). So I rather like the idea of supporting commands that we see in the wild. This command though, this would definitely be a special case as it allows for long arguments.
there are a few ways to send cw. One is to form local the characters and toggle RTS or DTR depending on the rig settings. That looks fine and it is if you are local, over USB for instance. With WFview that’s going to be a disaster.
Quite a few new rigs have the ability to just send a string of text like “CQ TEST de PA3MET TEST” and with the right prefix CI-V commands it will tell the rig to output with the internal keyers the above mentioned text. As the timing is done local, it will be just fine and dandy.
Now N1MM+ does the toggling of the RTS or DTR. Others may do different.
RSBA1 has 8 memories that can be filled with information and it will, if the remote rig supports this, send it via their internal keyer.
7300, 7610, 785x, 9700, 705 all can do this.
Re rigctld – we can see what we can do but need to be sure that it does not break the standard hamlib stuff so must keep that compatible too.
With the CW Memory… do people really use that? I just can’t see carrying on a QSO using 8 memory buttons. I’ve always ignored this feature on my 7300.
For RTS and DTR signaling, is it that the computer program toggles these lines on and off to send the dits and dahs? Like a PTT basically? Are you concerned that the relative “jitter” in the connection timing would mess up the precision of the operator’s CW keying?
If I’m reading this all correctly, the preference of modern CW operators is to type the CW characters, have the characters sent to the radio (as text), and then have the radio create and send out the pulses. Is that correct?
Not entirely. Most contest keying is generated by the logging program. But sometimes you have to resend a part of the exchange. You could do that via keyboard or most often by manual keying. For normal QSOs, you might get by with keyboard but most do manual keying.
Gary
W9TD
So it would seem in the context of CW contesting, it’s done with macros. This is similar to how I do some operation of other digital modes in fldigi, where I program macros to reply and CQ, and the macro generally picks up on the other party’s call sign and fills in some details.
I suppose where I was hung up on all this was imaging having a normal (non-contest) QSO. That I can’t see doing via macros. But I guess typing out the CW and having the rig key it in isn’t so bad at all. Or use modulated CW like me from fldigi :). Hehe.
If I can put few words here…
Based on what wfview is (from my perspective) a remote FACE of my radio…
I’d say that sending CW is a CAT feature available via CAT and to be used with dedicated software.
Radio does not provide a button to send “any” cw… while it provides “a button” to send “any audio” … and this is implemented;)
Pressing the button with CW or VOICE memory is something different… and this I’d like to see in wfview.
Of course as with everything there is no clear border between what is FACE of radio and what is not as usually all features of FACE are available via CAT… and there is also a question how deep inside menu it is still a FACE
