REMOTE operations over slow / vpn / wifi / LTE networks

Hi all

I am trying hard to get my new ICOM 7100 going and altough I have a issues with my ISP / Connectivity for some reasons my radio developed an USB Disconnect while TXing on HF (suspecting RF into USB). Question is why it wasnt there for 2-3 days and suddenly all above 40W triggers COMx port disconnect. Funny thing is only VCP Port, not an audio interface…I might opt fot using an SERIAL pur CI-V interface I have somewhere.

Anyway, on the server I was playing with settings like - QtAudio - works initially but after a minute or two, TX audio just gets garbled / slowed down / seems like its trying to correct timing but fails. Only disconnect and connect to radio works.
When Setup using PortAudio - it seems to work slighlty better but only in combination of - PortAudio server and QtAudio on client.
RT Audio doesnt work on server as it doesnt advertise CODEC voice interface. It only works on client. Can someone explain differences in Qt,RT and PortAudio on Windows Enviroment?

Now question is - I am lucky to have a spare Raspberry PI4 with 4GB RAM on the table plus I also have on in my remote shack (RPi 4 - 2GB RAM). Both are connected to 1gbps ethernet btw.
Question is - shall I move the WFVIEW onto linux / raspberry or having a windows server is the way to go? I am not sure I am only one on Windows 11, but since I do have a UDP loss , sometimes the SERVER side wfview instance just crashes and end itself up - hence the raspberry question.

I am familliar with networking and port FWD and also understand the principles of the ICOMs USB audio interfaces, I just cant get thing to set up right and when it occasionally works, i get complains on my TX Audio. Thanks a lot and 73

I have uploaded client side and server side LOGs with WAV to onedrive

and here is latest log from server side…interesting to see timestamps - same time multiple same messages?

Hi Jiri,

There’s a lot to unpack here, so let’s see…

Com port disconnects due to RF. That can happen. The radio probably has an internal USB hub between its audio and serial devices, and I guess one of the devices is more picky than the other. You can try a better-shielded USB cable and also adding a few laps around a clip-on ferrite bead at each end of the USB cable. I use these at my QTH. Also make sure the USB cable is routed as far away from the RF coax as possible. You may also want to inspect the antenna and coax and check the SWR while you’re at it.

I don’t know the reason for why the audio would garble after some amount of time. The differences between the audio systems? Phil could tell you more. Qt is our most “compatible” option, and I believe RT is the lowest latency. Each system is by a completely different programming team. We found, over time, that some people’s systems worked better with one or another, and ultimately Phil just decided to put all three systems in so that people can try each one out to see what works the best. I use Port Audio usually myself, but that is only because it seems to work very well for me.

I would definitely select linux over windows for wfview as a server, but that is mostly due to my own familiarity with linux. If you’re comfortable with linux then I say go for it. You may also find that the audio works better, but I can’t say for sure that you would. Your Pi is certainly sufficient for wfview.

UDP loss is an issue that is exasperated by poor wifi, VPNs, and cellular (LTE) networks. It’s difficult in these environments. I recommend that you use the Opus codec, which is available to you since you are running your own wfview server. The reduction in bandwidth can’t hurt, and I believe it was more tolerant of UDP mangling than the other options. uLaw 8-bit would be another good choice as the 8-bit packets don’t get mangled up like the 16 bit ones do, and uLaw gives you sufficient dynamic range despite being 8-bit (uLaw is also what IRLP and most Asterisk nodes default to). Remember, you must disconnect before changing the codec. You can verify the codec used for the connection in the Log window.

Your log shows evidence of network trouble, although I cannot say exactly what the issue is. All these retransmit messages are due to missing or mangled packets. Definitely see what you can do to get the best network connectivity possible, and make sure to try the Opus and 8-Bit uLaw codecs.

Yes, you need to port forward the UDP ports. Also, you must not change the port number – it must be the same port open to the world as wfview is listening on. This is because the protocol communicates about the port numbers and does not expect to be remapped.

You asked about timestamps. The time stamp is taken when the message arrives into the message handler and it is done do a precision of 1ms. I would not claim it is 1ms accurate though. But at any rate, it is certainly possible for modern hardware to do many things within the same 1ms time bin.

I hope this helps some and sorry if it was a bit rambling.

de W6EL


sorry for later delay - I have a newborn just a less than 48 hours old. All is good :slight_smile:

Anyway since we were expecting a familly I had to start setting up remote at my VHF/HF QTH which is about 40km west of Brno(City I currently live in) and I am mainly using SDR from HPSDR Project - Hermes Lite 2 with an PA for 50W and that worked reasonably well even with some UDP drops.
Unfortunate situation caused the ADC to go in smoke so I purchased a 2nd hand IC7100 - I was after 7300 but that was gone in minutes, but I thought, hey - I do 2m and 70cm a lot so why not, I can do panadapter using a RSP or simillar…
So I pretty much just took a beefy laptop I was using for the SDR and installed WFVIEW on WIN11 and connectd IC7100 to it. I had a few days od hell as I could not get the audio right at all. .Eventually I started to play with local SDR RX and IC7100 and with a USB TX set to 20percent or so all seems better. I also have a WIN4ICOM package installed and that works very well including CW and good audio, but from time to time the server app just dies and I have to reboot the server machine remotely.

I replaced USB cables, put icom and cables into RF Enclosure so bo RF can get in just to make sure.

My results are:
I can not use WFVIEW with a current setup with CODEC set to Opus. Whatwver I do, in a minute or so, TX Audio becoems a Robot and interestingly . once work with a lenght of 1 second takes about 3 seconds to transmit - seems like udp stream gets broken and it doesnt reset and drop but keeps retrying until it gets the packets in right sequence but timeout is so long that it sounds like if you put a 10mS pause between each voice frame.
Also rx latency: in right bottom corner goes to 4000ms and up if I leave Opus.
If I setup Opus for RX and uLAW PCM for TX, latency goes between 100 and 200mS and stays there. I still have few udp audio missing packets or out of sequence but it seems to work.

Any ideas?
Also, I am missing slightly more complex main screen where I could do a CW but mainly where I could set up Compressor on / off or compression level, where I could control output gain of the ICOMs receive codec(mic) as sometimes it is overdriven when I try RT Audio or Port Audio on the server side.

Thanks again for all help

Jiri OK2IT

Hi Jiri,

Congratulations on the newborn! Presumably you’re still in that brief pocket of time where they sleep mostly? I remember after a few weeks it was a 3-4 hour sleep-eat schedule.

I’m still not sure why your audio gets garbled after some period of time. I have not seen that happen with any of my setups. Opus is my preferred codec which I will use when I can. But uLaw 8-bit does produce good results too.

Interestingly I was experiencing an issue where, at 100W transmit, the serial port would sometimes reset. The issue seems mostly solved with a different USB cable and a ferrite clamp. But not perfectly, I still have an issue here and there with it. It’s annoying because when it happens, the rig remains transmitting and audio remains streaming, but there is no way to “stop” the transmit (except closing down wfview server and then opening it again). Perhaps future versions could include something to re-open the serial port if it goes away. I suppose using the graphical wfview as a server would allow one to press “Disconnect” and then “Connect” at the server to re-open the port. Hmm. I’ll have to try that.

Yes, we do need COMP control in wfview. I’ve been doing some remote work lately myself and PC microphones really do lack the proper “punch” for communications audio. And of course, it needs adjustment for each user. We will get to this eventually.

de W6EL