Firstly thankyou Elliot and Phil and the rest of the team for the fantastic job you have done to produce WFview.
I have just put together a “new” computer for the shack running the recently released Debian 12 “Bookworm” and the first application I installed was the just released WFview 1.64
This is just a couple of “issues” I had and how I worked around them. I am not a programmer and this post is just what I experienced and how I got around it - there will no doubt be a better way to do things.
The installation:
I used the Debian install script fullbuild-wfview.sh · master · Elliott Liggett / scripts · GitLab
It would run through to a point where a message was displayed “Preparing for WFView 1.64” and it would appear to hang at this point. Hitting “Ctrl C” terminated the sticking point and the build continued on and successfully completed.
Audio:
I am running WFView in server mode connected to the 7300 and listen from my office in the house with WFview connecting to the server and for life of me I couldn’t get the audio to work right on RX (I havent tried TX yet) what Audio I could here was choppy - you could follow a conversation but it was not suitable. I had thought it was an issue with my network as the link to the shack is a wifi bridge rated at 1GB and has full signal strength and line of site between the nodes. And I had been using an old 32 bit bow running Raspberry PI OS and it worked fine, but the much newer 64 bit core I5 was not playing the game. Thanks to the comments I found on this forum I discovered the Audio system setting QT RT and Port Audio. I am yet to educate myself as to what they mean but selecting RT solved the RX audio issues.
An Issue I am yet to resolve relates Im yet to work out if its a radio or WFview issue.
If I am controlling the Radio with WFview and shut wfview down and then start up WSJTX. WSJTX fails with a configuration error. Rebooting the PC does not help, WSJTX will receive the audio from the 7300 but will not control it. To get it to work requires turning the radio on and off again WSJTX will then happily start up and control the radio.
I will investigate this further and look at using WSJTX in conjunction with WFview.
I think I have resolved the install issue you had. I believe it was showing you the log of development commits and for whatever reason pausing there. No need to reinstall, it’s a minor issue that should not have impacted your install.
Different Audio Systems (libraries for handling audio that we did not develop ourselves) seem to work better for different systems, we don’t really know why exactly, but that is indeed why Phil has maintained three audio backends for each of the three operating systems that we support.
How are you connecting wfview to WSJT? Did you look at our manual on this topic? wfview has a built-in rigctl-compatible server which is the recommended method.
Maybe this is my misunderstanding of the opperation of the applications.
What Ive done is started WFview and used it to control the radio for some voice work. Then closed WFview then open WSJT. This is when WSJT fails to connect to the radio.
Im treating WFview and WSJT as independent applications.
If I reboot the computer WSJT will return a rig control error
If I power cycle the radio WSJT will work happily.
Im not enabling rigctdl simply because in this instance I am using the applications independent of one another. Ill have a play with running them together with rigctl.
Given that this issue persists with computer reboot and requires a reboot of the radio that the issue lies in the radio.
Being looking into this some more and noted the issue doesn’t occur If I turn off the water fall display before exiting WFView. Which is a work around at least.
Ive made some packet captures of the data on the USB port and will take a closer look.
This also occurs running widows 10.
I should add that I do have WSJTx running with WFview using rigctl and that is great this issue ive mentioned is just when trying to use the applications independent of one another.