Using WFView v 2.24 on my Windows 11 PC and the standard (old) WFServer version built into the radio, thanks to work done by Romas LY4PR, who found that changing a setting in wfview server .ini file from QtAudio to Port audio according to Headless Server | wfview stops the audio dropout problem.
Method he documented:
Stop wfserver in X6200 menu , via terminal access edit wfserver.ini with nano /etc/xgradio/wfserver.ini and change the second line from
[General]
AudioSystem=0
to
[General]
AudioSystem=1
then restart wfserver via and connect to the X6200 via the wfview client on windows 10 (or 11)..
After listening and transmitting for more than an hour, there was no audio disconnect or audio drops.
In WFClient the audio has to be set to Port audio, and I set the sample rate to the lowest available, 8000. These settings are only visible under the settings/radio access page when you are disconnected from the radio. Full or half duplex does not appear to make any difference. Rx and Tx codecs are set to Opus 1ch and Rx & Tx latency is set to 150ms (these could be default settings).
Hopefully this will help others as it has helped me with the annoying problem.
Hi Elliot, yes, the information is from the groups.io site (I am one of its moderators).
Such a small change - I’m kicking myself that I didn’t find it a year ago when I reported the issue here. I’m grateful that Romas LY4PR dug deeper and found it. The information has also been passed on to Xiegu, hopefully, they will include the minor config change in a future update.
I was not aware that there might be issues with TX audio. I was of the understanding that this was a receive audio issue. I have not transmitted from the PC back through the X6200 via the WiFi - i don’t have a suitable mic. set up on the PC at the moment - that will go on my “to do” list.
Thus far, we have not received a report of successful network audio transmission. This doesn’t mean it’s broken necessarily, but we haven’t heard anyone mention doing it yet.
Let us know how your testing goes. I don’t have this rig personally, so I will rely on your report
The trick is that before TX audio will work, the radio needs to be set to one of its digital modes LSB-D or USB-D as the WFServer supplies the audio as if it were coming in down a USB or ACC port connection.
Until Xiegu update the WFSERVER.INI file in their base configuration (they have acknowledged my request to make the change), avoid pressing the “Default” button in the WFServer panel on the X6200, as this appears to simply copy an original stored version of wfserver.ini over our updated one! Resetting not only what is displayed on the panel, but also the AudioSystem value. When this happens, the audio dropout problem returns, and you have to terminal-in again and edit the file.
With the configuration fix in WFSERVER.INI, exactly what level of “fixed” is attained? How good is the receive and transmit audio?
Genuinely curious.
Also, you could probably come up with a one-line ssh-with-command to fix that file for people. Linux has lots of neat text-altering utilities for this sort of thing.
The audio is stable - an occasional blip, but then again - take a look at this:
where Vlodomir has actually updated the version of WFServer running in the X6200 if I understand correctly.
P.S. I’m making progress with a specific wfview rig file for the X6200 with the IC705 functions that are not supported, removed. there are a couple of instances where the X6200 uses a different CAT command that i need to sort out.
I have concentrated on the Rig file and now have one for the X6200 radio specifically. Here is the file for others to test it by putting it in their C:\Users\username]\appdata\roaming\wfview\wfview\rigs directory (Windows).
Please report results back in this thread - good luck.
(In wfview settings, set the CiV address to A4 and click on Manual Radio CiV address).
Do not use this file if you also have an ICOM IC-705 on your network, as it also uses A4.
(Configure the X6200 with a static IP address and ensure the WiFi is running on the radio before starting WFView).
URL to the list in your well-written X6100/6200 changes page, thanks.
I haven’t seen any responses on this list regarding testing the X6200.rig file which I posted here. I’m not sure whether to interpret that as it has been tested and no issues were found, or (more likely) no one has tested it yet. Given that the CiV code used by Xiegu clashes with the IC705, this rig file can never be included in the main WFClient image.
