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

Hello there!
Lomg time no hear from me, sorry , my mum passed away so radio was on back burner.

I am running now WFVIEW / IC7100 and use server on RPi4b and works very well! Even running old serverf app. 1.5 or 1.6 and newest client, CW Works fine etc. As you mentioned I do get often 100W EMC issues when /dev/ttyUSB1 disconnects briefly. I set up TOT to 3 minutes so after 3 minutes MAX the TX dies due to TTL. I am about to go there today and change USB cable to my own made, 5cm long only with huuuge ferrite bead on it.

BTW Issues I had with audio - I dont have those with Linux / Raspberry!

73 and looking fwd for ALC/AGC and COMP!

Jiri OK2IT

Jiri, I’m sorry for your loss. That’s tough. We have dedicated several versions of wfview to the ones we lost (in the about box). Sometimes working on code really is our temporary escape from things.

I had EMC issues with a few SBCs and I found that some USB cables were definitely better than others.

Nice that the audio is working well for you.

de W6EL

Hi Elliot,

yes it was / still is tough going but she would have wnted me to carry on. We have a 4 months old baby girl and I am glad she managed to spend her last month seeing her…I am pretty sure that was the last bit she was holding to. Just had a look at my Mac/OSX 1.50 version About Box and indeed found the dedicated part info. Havent spoted it before!

Now to the WFVIEW - I am glad to see CW now being implemented. We had a Subregional VHF/UHF/SHF Contest last weekend and I couldnt stay at my VHF Remote QTH so I was running home remote. I have to say I was a bit nervous leaving wfview running on RPI4 into IC7100 with a GS35b 1500W PA ffor 2m, 1100W for 70cm and transverters for 23,13,9,6 cm but thanks to wfview and CW I managed to work every sked I was asked for. I also improved connectivity - I moved the wireless link to be my backup and finally I got FTTH - inly about 150mbps but very little jitter so all seems to work as it suppose to.
I spent lot of time debugging the config / setup I had with Windows server running and OSX or Windows client and it just seems that once sound is being done both ways using Windows, it doesnt like it at all. Once I moved it to same machine but running Ubuntu - everything was resolved. At the end I had to keep Windows so I used Virtualbox with USB ICOMs interface assigned direct to VM and VM Runing Debian. Now I use original RPi4 and tested also Orange PI2 Zero and that works also.
BananaPI I cant compile - seems QT isnt available in version we need.

I am looking forward to future builds and if I find something interesting I willl post on it.

73 Jiri OK2IT

Hi Jiri,

I’m glad it worked out for your scheduled contacts. CW is a rather new feature, so it’s nice to have some testing.

Please let us know how we can improve it.

de W6EL

Hi Elliott

Yes CW seems to work most of the time, at least on my setup.

I like waterfalls, click-n-tune I am usually running a remote of OpenHPSDR hardware along with whatever SDR TRX package I use at the moment, but since my 100W PA failed and I needed 100W HF/6m and something for V/UHF I installed again ICOM 7100 on my hilltop location and if other are interested this is my setup, which works excellent:

Server Side:

  1. Raspberry PI4b running Raspbian
  2. ICOM 7100 via USB 19,200 - Port Audio or Qt Audio.
  3. Separate ESP32 HTTPS IOT Board running 2 x 8 ports ON/OFF - driving 6:2 antenna switch, PAs, Transporters etc.
  4. AlfaSpid RAU - to USB of RPi4

On client I use Win or Mac with WFVIEW 1.6 or higher.
I tested CW in both HF and VHF Contests and it works well. Sometimes what happens it if I hit memory button right when it is about to finish sending previous one, it plays the CW locally (local side tone) but no RF.

But that happens less frequently and seems to relate to quality of internet connection at given time.

I have to say that running sampling at 9000 Hz or 16kHz and Opus all is cool even over LTE!

BR Jiri

Hi Jiri,

I am intrigued by your setup. I asked questions here last year about using an IC7100 with remote waterfall with an IF tap using an AirSpy, but I never got anything working. I use HPSDR for click and tune locally but couldn’t get the waterfall sent remotely.
To read your onedrive folder needs a log in - I don’t know whether you have placed the details there.


Hi Tony,

You can use a Pi with an RTL-SDR and the rtl_tcp program to create a tcp/ip stream of the RTL-SDR data. You can then use a program like gqrx to display (and demodulate) the stream on the remote computer.

I’m not sure about click to tune, but I suspect it can be done with some smart rigctl scripts.

de W6EL

Hi Elliot

Thanks for your thoughts. A bit of web searching has found some interesting ideas like using a cheap router to serve an RTL-SDR :
Musn’t get too distracted :wink:

Hello folks. Sorry I’ve been away. Elliot is correct. I am using rsp1 in exactly the same remote and I use hdsdr to perform the click and tune.