After installing the latest WIN10 build I’m having issues with audio drive. Before the 5/18 release I was running FT8 on my 705 using Wfview, DXLab, and WSJT on my laptop connected to the 705 via WiFi without any issues. the setup would stay up all day, I would occasionally make FT8 contacts while in the shack. After the 5/18 WIN10 update I’m seeing the audio drive disappear after a transmission or two. I tried reloading everything, rebooting the laptop, etc , no joy. It would run for a few cycles then no drive. The WiFi connection is solid, laptop is about 10 feet from the WiFi source before and after. The only thing changed is the 5/18 version. Anything you want me to try?
wfview should certainly work OK in debug mode so i’m really not sure why it isn’t?
The command is:
wfview.exe --debug
There are also no significant changes in TX audio since the 05/15 version. The main changes are relating to send buffers and retransmit code. We haven’t had any other reports but it is early days so I will try to reproduce the issue here.
Even without debug mode, wfview will create a log (just with less information in) but any critical problems should be logged in there anyway so worth having a look.
OK. I will load up the 5/18 ver and try the debug mode again in the morning. 5/15 has been stable for 4 hours now, after 100 or so tx/rx cycles, 5/18 ver failed consistently after 1 or 2 tx cycles.
I tried WSJT-X direct to wfview (05/18) for around an 30 minutes and about 20-30 TX cycles and it worked fine.
I have noticed though that using WSJT-X via DX commander may be causing an issue as Commander does create lots to additional serial commands which are forwarded to the rig. It also seems to request settings that wfview doesn’t understand.
I saw lots of lines like this in my wfview.log
2021-05-20 00:58:45.026 INF rig: Unknown control level (0x14) received at register with level 128
It didn’t fail though but I was connected to a 7610 via LAN, I will try the same tomorrow on a 705.
It might be interesting to try bypassing DX Commander and connect wsjt-x directly to wfview. This will at least isolate the issue as it is possible that the rig is receiving too many commands this way. After the first release, we plan to add some form of caching to minimize this issue.
I left wfview, DX Commander and wsjt-x running overnight and have made about 30 QSOs without incident.
I did have an issue a few minutes ago when calling another station where the rig went into TX but there was no audio. I have had this before and a restart of wsjt-x cured the problem. I have seen other reports of this issue (not using wfview) and it seems to be a problem with wsjt-x losing access to the sound card. I don’t think this is your issue though as from what you said, it happens almost immediately?
Hi Phil. I’m aware of that issue with WSJT, this appears to be different, especially since I drop back to the 5/15 release and the problem goes completely away. I’m in the middle of moving north for the summer, sometime today I will find the time to install the 5/18 release and run debug, and also test without DXLab. Right now I’m running ver 5/15 and it’s working 100% with DXLab in the mix…
Ok I just got debug to run, wfview ran about 3 tx/rx cycles on 12m then tx stayed on, and no audio on carrier. Shutdown wfview tx went off. I then tried to run this…
Get-Content $env:TEMP\wfview.log -Wait -Tail 30
WIN10 said Get-Content not recognized as an internal or external command. Where is that other log file you mentioned?
but unfortunately it’s too big to upload here…