New user here. Delightful program, I’m running it on Windows 10 and a Mac laptop. Thank you for creating WfView!
I’m wondering if you plan to add CW operation to the program, or if someone has thoughts on how to accomplish it.
Thanks & 73,
Warren
KC9IL
Hi Warren,
Welcome to wfview
We have a number of plans for CW operation, most are fairly long-term though. A simple keyboard based TX will likely be first, but we are also looking at the possibility of straight key/paddle interfaces as well.
There are a number of timing issues with straight key/paddle operation though, which we have a few ideas how to fix.
Watch this space!
73 Phil M0VSE
Hi,
the integration of Winkey would be fine!?
73 de Uwe, DL4AC
if the keyer is connected remotely to the rig, it would have the same timing issues Uwe.
Now I have to say that I don’t use a winkeyer so not sure.
Rigctl can key the rig remotely via wfview’s virtual serial port using the rig’s built-in keyer. For example, the following shell command uses the virtual serial port to send the CQ string to the rig and the rig’s built-in keyer takes care of the sending the whole thing, so you could have terrible network latency and still get perfect timing:
rigctl -m 3073 -r /home/pi/rig-pty1 -s 115200 b ‘CQ CQ DE VE3MAL’
(note that in my case,
it’s a 7300,
/home/pi/rig-pty1 is the virtual serial port,
my rig is set to have a baud rate of 115200)
Unfortunately, most loggers don’t support hamlib keying yet, but if you really needed remote keying via wfview, it can be done like this in a pinch while you wait for more features to be implemented. You could even have a keyer type interface in one line of bash:
while true; do read text; rigctl -m 3073 -r /home/pi/rig-pty1 -s 115200 b “$text”; done
I added a more fulsome ( though still extremely minimalist) implementation in clogger that includes speed control and the ability to stop the keyer, etc. (https://github.com/etamme/clogger)
Good luck! Sorry it’s a cludge of an answer, but it might get you started.
Jason, thanks for the ideas. I wonder if anyone has tried your approach to interface N1MM+. That would be a great start.
73, Warren, KC9IL
Hi Phil,
I’ve been enjoying wfview, but this does seem to be the biggest gap. One way to get 80% of the way there (at least for certain use cases) with what I expect would be limited effort would be to add a set of ~8 user programmable buttons on the interface. These could be programmed to send an arbitrary CAT command to the rig; for CW, this would allow a user to take advantage of the rig’s internal memory keyer, or to send an arbitrary set of characters over CW. This would allow most of the control to be done through wfview directly, only jumping over to other avenues in unusual cases.
It would also be useful for users in other modes (e.g. internal voice keyer), as well as users who really want a function that’s further down your roadmap (e.g. NB or NR).
73, Scott KF3CP
Hi there
so far so good, CW CQ WW This weekend and I am stuck at location far away - familly issues - but i can listen in using IC7100 and all my big antennas. I would love to CW TX. So far - WinKey or more like remote VNC to a PC with a Winkey keyer + CW Keyboard was the only option, no delays , no jitter issues. It would be great for newer ICOMs to use their internal keyer if they support.
tnx for the hard work!
Jiri OK2IT
Hi Jiri,
It’s definitely on the list. Icom does gives us a command we can use, so it’s just a matter of writing all the code to support it.
–E
de W6EL
There’s a bunch of IC-705-only CAT things I’d use customizable buttons for.
Hey All – Gerry, W1VE here.
I’m the NCJ columnist for Remote Contesting. I know many of you are doing remote for your own stations. I am involved in many stations that are typically quite far away and in other countries.
I’m an avid CW Contester, and professionally, I’m a software engineer.
I’ve used an earlier version of wfview, and am coming back for another look. Yes, CW operation remotely, especially with a requirement for paddles, is difficult. I understand why the team is taking it’s time. The only way to do it right is to generate the CW on the station end, which takes latency out of the picture. As the developers have stated, keyboard CW is pretty easy (just generate Winkey protocol and send it to the other end), but with paddle CW, you would have to interpret the key closures on the paddle, encode the CW as Winkey protolcol, and send it. Easy on an arduino, but much more difficult with a PC operating system (though not impossible, for sure.)
I am not a 7610 owner, but WANT to use one at a remote station. Here’s the rub: Can you get the radio to come on if there is an AC Power failure? I thought the rig has to be “standby mode” to be able to be commanded remotely. Perhaps there is a setting when AC is restored to make that work?
Now, about CW. There are many ways to solve this. What I typicaly do is NOT run wfview over the
Internet. Not a good idea. I run it on a PC at the remote QTH, and use a Winkeyer locally. This gives you excellent Keyboard CW, no latency, and is very easy to use. Then, use Anydesk or TeamViewer to access the station remotely.
I use Mumble for remote audio. I host many free Amateur Radio Mumble servers. Mumble has better audio quality, and incredible ease of use than any other solution I’ve used for remote. If Interested, email me and I’ll send you a document describing usage and the addresses of my servers.
If you want CW paddles, life gets more complex. However, the simple way do do this is with the VSPE
Serial emulator:
(Station-Side) Rig ->Winkey → VSPE Serial Port In → TCPIP Server ==> Network <=== TCPIP Client ->Serial Port-> Winkey on station side.
This works beautifully over the Internet or locally. Of course, for Internet connections you’ll have to do port forwarding. However, sign up for a free edition of TailScale (tailscale.com), and you can connect PC-to-PC any port using any network topology (ipv4, ipv6, dynamic ip, CGNAT such as cellular or Starlink_, and no port forwarding. Once each PC on the TailScale VPN, just bind VSPE to the 100.X.X.X Tailscale IP and you are all set.
Just getting an IC-705 for Christmas … excited to play with wfview and get remote CW working on it.
de W1VE
Hi Gerry,
I have over 8700 FT8 contacts made remotely, but I want to expand my modes to CW and SSB again running remote.
Because my CW skills are very rusty and I lack experience and confidence, I am planning to use CWTY to decode CW as a backup to my ear. I am communicating with Grant the developer of CWTY to potentially add another output to his SW to send CW commands and characters to a serial port, which can then be connected to Wfview’s serial port via COM0COM which get forwarded to the IC-7610 remotely running semi break-in. Because the IC-7610 sends the CW via command stream, there will be no chopping or strange effects.The command is x’71’ followed by the chars followed by x’FF’ Check you IC-705 to ensure it will accept the x’71’ CW command.
I concluded there was no way to use paddles remotely because of the network latency.
I have a Web Power Switch to cycle my radio and other devices.
I am using PortAudio for now on my Dell Lattitude 7480 Windows 10 laptop. Yes, the radio comes back up if there is a power failure, or if I power it off and on using the Web Power Switch.
Merry Christmas!
Hi Gerry,
Lot to unpack here, so let’s go paragraph by paragraph.
Sounds fun!
We currently don’t support CW, but it is on our list. 3 our of 4 of the developers are avid CW ops, and we are definitely looking at the best way to do it.
If I am not mistaken, the 7610 will come back on if it was on prior to power being abruptly removed. With that said, even when off, and yes, even if not in standby, a special command sent over the serial port can wake it up. A Raspberry Pi or really any computer with a serial port could be programmed to offer this command to the radio over USB. Perhaps someone here can verify this for me.
This is interesting but perhaps a bit misguided. There is most certainly latency when you use a remote keyboard. Plus of course the massive bandwidth required for streaming remote desktop and screen controls this way. I know it was once popular to do this sort of thing, but wfview has a low-latency and low-bandwidth control protocol built-in. This protocol is significantly more responsive than sharing a display remotely. Plus you gain the advantage of a genuine application running on your local machine, which opens yourself up to a lot of interesting possibilities and better integration. The latency for CI-V commands (and serial traffic in general) is on the order of the ping time between two stations (ie, a few tens of ms). Audio latency is typically 70-150ms, but again, it will depend on the connection.
We use wfview for remote audio, and it really is excellent. Like mumble, wfview can use the Open Source OPUS codec, which provides about 4:1 data compression with hardly any loss in quality when connecting to a genuine wfview server. When connecting directly to the radio’s built-in server, wfview can use either lossless 16-bit linear PCM, 8-bit linear PCM, or 8-bit uLaw (logarithmic). This is simply what the radio supports, we can’t make the radio use Opus, but you can run a local wfview copy to stream the audio using Opus if you need the extra bandwidth. Even a machine like a Raspberry Pi can run the wfview server with ease. 8-bit uLaw is almost as good sounding as Opus and uses about twice the network bandwidth.
wfview has support for virtual serial ports built-in. You can use the virtual port just like a real serial port, even with remote wfview copies running over the internet. Thus, any kind of command the 7610 supports can be sent via these means.
For other pieces of hardware (like winkeyer) that you might need to control, yes, third party solutions are an option. netcat and socat are great options for linux users.
See, now you’re talking! I don’t have a 705 (yet) but it sure seems like a great radio!
But really, in summary, wfview has built-in full-duplex remote audio, CI-V, and serial support. There’s really no need to run additional programs to do these things. And once you try running it natively like this, you’ll get the best and most fluid user experience.
Yes, there are edge cases such as operating a remote rotor or a winkeyer or something where you may need an extra serial port, but overall, most users should really shoot for using wfview just as it’s designed to be used – because it works, and it works nicely!
73,
–E
de W6EL