my main idea is that if the rig supports CW CAT (several do) we definitely should do it that way to prevent latency/jitter etc.
my radios supports voice and cw buttons to send (“the parrot function”) so I’m missing the “radio does not provide a button for cw” part here
Yep, CW or SSB “parrot” is a CW keyer memory or VOICE keyer memory.
It is “memory”.
And what I’ve said is that in my opinion (which probalby is not so relevant here) this “is a part of FACE of radio” while possibility to send CW like via CAT and giving text to send is not.
I am a real old time high speed cw op and contester. Only real live time cw operation with human brain decoding would work for a real cw operator in contest. The ability to move quickly with a reply which might not be cooked with software is not tolerable for us. I would not use the cw program w/o live manual keying ability, to hell with remote decoding or macros. Sorry, learning code is as much as a challenge as learning how to use remote forwarding in my estimation.
Just a thought,for it to be effective and appeal for a real cw op, manual control via WFView is a default must. Learn Morse, use it. It is like programming, to learn it , you must use it.
Gary,
we’re not talking about decoding here though – we’re talking about remotely being able to send the dits and dashes. Manual keying is probably totally out of the question to have it work in high speed situations (for me that’s around 28…30wpm) – except the cq’s and replies etc via correctly spaced cw done via the built-in keyer.
(Or did I misread you?)
I would say most contesting is in the range of 20-30 wpm(or below for many). If implemented, I would think allowing for non-perfect timing human keying with an old time" bug" semi-automatic would lend individuality to the code, a “fist” as it is called. This is lost wth “perfect” code protocols.
Individual ops have individual “fists”. Oh well…An old amateur extra like myself was 20 WPM, with generals at 13 wpm. fine for contests by humans.
little bit OT here but if I hear the imperfect fist I generally skip them because of the fact that you will get many errors out of it.
I mean if someone from Slovenia sends a call and like S55G or S51DX you will see that improper timing will and in fact generally does cause issues when writing down details. Not a real problem when you are ragchewing but…
I have heard calls where you read “-…-…-” or “-.-.–.-” etc where you know what it probably should be but…
Hence the desire to have a perfectly spaced cw. And latency will not help…
Ha Ha…Imperfection is the spice of life. Some stroke victims use bugs or hand keys as post human stroke therapy. Allowing for it is inclusive. Just a thought. Much like a large screen being a God send with WFView for the visually impaired ham.
Hi Gary,
One trick would be to take a practice oscillator code key setup, and just patch the audio into the computer’s line input, and transmit this over sideband. wfview supports that right now. But I know, this isn’t as pure as truly rapidly keying the transmitter on and off.
I could certainly see how a real hardware code key could be remoted, but it’s definitely a large project in and of itself to really get right. I suppose I would quantize the analog signal to something like the nearest 1ms, buffer about 50ms, and send out where the dits and dahs are, letting the remote side key accordingly. It’s an extremely small amount of data, so there could be redundancy in the protocol for sure.
Does anyone know of any open-source software with similar capabilities?
–E
de W6EL
Wow, can of worms opened, sorry! Everybody answered most of the questions, but I’ll clarify, RTS/DTR based keying is exactly like a “PTT” signal, where as CI-V can pass an ASCII string over serial and the radio will key it (modulate it) on it’s own. It works quite well and isn’t sensitive to timing. In the example rigctl command I included, “b” sends the following string (“CQ”) to the radio to key.
To appeal to a real CW op, contest or no contests, it would be a real plus in my opinion to allow real (fake ) keying , a “fist” so to speak in some manner. I understand that since CW is no longer a licensing US requirement, it may be a dying communications form (but NASA still requires astronauts , at least to know how to do it minimally I have been told…you may be able to confirm this,). It is still used in aviation for VOR navigation recognition at present (Voice Omni Range ) . VOR is being phased out, albeit slowly but is still b/u to GPS for pilots. CW is an old art / skill/mode, another language so to speak that will be around in some form. Just listen to the CW sections, it aint dead yet!
It would be a plus for WFView if it were implemented I think. (maybe I would be the only one to use it…HI HI !!! Just MHO.
Thanks for the fine work all you linux./apple/windows mcoders / network folks are doing BTW…
Workaround:
use model IC-7300 (3073) instead of IC7610 (3078) with CI-V address of the 7610 (152 dec):
rigctl -m 3073 -r /home/9v1kg/rig-pty1 -c 152
then cmd: b + cw text to send
9V1KG
Hi Jason,
No need to appoligize! I’m glad you opened the can, I need to know what kinds of ways people use or envision using wfview.
I think we will look at ways to do the remote RTS from a genuine morse code key at the remote location. This would be a somewhat unique feature, and it fits well with wfview providing a control interface like the radio does.
I feel like sending the ASCII over CI-V is somewhat already taken care of by the apps mentioned here used for contesting and logging, plus there is always the rigctl method, which could easily be wrapped into a stand-alone application, even one written in javascript or python. So I don’t see wfview gaining a CW “text input” window (although if someone wants to contribute one, that would be just fine and we’d do it if it works well).
Keep the ideas flowing,
–E
de W6EL
Hi Arthur,
I think CW is a great mode, and I do plan to learn it soon. For now though, I just need folks like you to chime in here and let me know what you think about plans for remote CW. I’m beginning to warm up to the idea of a method to interface hardware keys and paddles. I feel like the “type the text” methods of CW are basically already covered anyway through existing technologies.
–E
de W6EL
ALL:
CW is the original DATA mode , and it is only unique to the “younger and older” generations of radio amateurs who no longer have to use it for licensing, but it would be a fun implementation as an area to learn the mode for those who wish to. It would be an attraction point for some perhaps. Remote data control via a hand key to a a server / high tech SDR,how unique.
Amateur Radio is a wonderful School of Technology, from Marconi to Torvalds. I love learning more Linux , others perhaps might like to try the archaic mode of CW. HI HI!
Thank you…I am reading on how to connect my newly created L305D Toshiba WFView 7300 Icom server to my new “client” private network computer (ASUS)via my LAN private network in some manner (client being via a wifi connect to my LAN) with WFView.! Will keep reading to attempt to communicate before I dare go Internet ! Have rarely done network things before,probing my gateway/router is fascinating, fortunately, there is that reset button on the back! HI HI!
Hi Gary,
You’ll enjoy this, my son did a science fair project on digital modes. We ran a bunch of digital modes at one watt into a dummy load, and then received them on a radio at the other side of the room, also using a dummy load. We’d do the test at three power levels into the dummy load and then rate the percent of words that came out correctly. It may not have been perfectly scientific, but it was definitely fine for his 5th grade science project.
5 WPM CW was the most resilient mode (software decode). THOR was one of the better ones too.
RTTY was the worse digital mode, and of course we tried voice using a recording and it was abysmal at any power level!
–E
de W6EL
would be an excellent feature. Then I could do my operation completely from my desktop. Sidetone is important too.
9V1KG
Hi All
I will try to describe how I use remote CW and how I would like things to work. This will be a long one so grab a cup of coffee or some popcorn.
Today when operating remote I send all my cw from the logging program. I would very much be able to also use paddles. My setup is like this:
On the radio side I use RCforb server, connected to the IC-7300 with USB cable. Setup in radio and rcforb software is to use keying with DTR. Same setup on another radio , IC-7400, A USB cable to computer and a simple keying interface to radio.
On the client side I use RCforb client. The Client software emulates a K3 so in the logging software I set up radio as a K3. This gives two options for keying cw. Either to use DTR keying all the way from log to radio or keying vith cat commands.
The first option works sometimes when on the same lan but very sensitive to interference. Useless when I remote to my summerhouse with radio on a 4G connection.
When using keying via cat ( all letters sent to radio server as commands) keying works almost perfect. Also on the 4G connection. The logging software is UCXlog and this is the only one I found that can send cw as cat from the logging software. I can use both macros and type free text in the cw window.
The macros of cource uses all info in the log to populate with correct info.
RCforb also has the possibility to build a small interface and connect a paddle or keyer at the client. Have tried but it is extremely difficult to send good cw and affected by CPU, Jitter, latency and you name it.
I have also played with wkremote and Remote CW from DF3CB to connect two winkeyers. This works reasonabley well for sending with paddles. But also means that the com-port to the winkeyer is used by this software and not available to the logging software so not possible to use macros. Have tried with com port splitters but does not work very well when cw is involved.
In a perfect world I would want a winkeyer in both ends and wfview transfer info from client to radio side as caracters. And also that the winkeyer is available to the logging software on the client side. Probably impossible to solve.
Or that there is a small log module in wfview that sends log info to a true logging software but then we are building a totally different beast.
The first option works sometimes when on the same lan but very sensitive to interference. Useless >when I remote to my summerhouse with radio on a 4G connection.
When using keying via cat ( all letters sent to radio server as commands) keying works almost perfect.
I tested this with macros and break-in at the lowest possible break-in time which was very good. Used a connection that has a low latency. I again need to test over LTE and see what happens if connections get congested.
We also need to be sure that it works across all operating systems, ruling out specific tricks.
My personal (not the team’s one) opinion:
At the end you face either almost perfect CW from rigs that support it and have a text-input box / macros and low latency good for a contest and bk-in, at say 30wpm
have a hit and miss, with latency issues, hard to read CW from the other end with a straight key/paddles, no useable bk-in
have a solid, high latency, ragchew-grade, no useable bk-in , not suited for contests
or maybe a way to to choose from some of these input methods
Sorry to revive this thread but I needed to remote CW for a contest today (which I am missing right now 
btw) If I read this lengthy thread correctly, a WFView IP solution is in the works once latency and jitter issues are addressed.
I went “out of band” and use a Bluetooth Low Energy 5 BLE5 (better range and faster than BT4) link to key the radio only. Essentially I went “around” WFView directly to the radio’s CW key input jack.
In my use case, the Icom radio and antenna coax are in the garage and the operating position is in the house. About 20 feet away through dry wall. The video shows testing with the radio only a few feet apart from WFView and the winkeyer USB. Antenna is a dummy load. Not shown, the N1MM+ contest software and its USB connection to WinKeyer USB. The paddles are for fills and chit chat. An antenna switch is also BLE controlled.
I kind of doubt anyone else would need a setup like this. But it is cold in the garage.
In the video I turn off the radio to show that the radio sidetone and the winkeyer monitor were in perfect sync–the volume is lower with the radio off. Although I haven’t measured the latency (from paddle contact on the client to server keyline assert over the BLE5 link) with a scope.
gud luck in the contest om,
bob
wm6h