Hi Greg,
I think I forgot to add that! You should be able to switch inputs physically at the radio – wfview does not attempt to “restore” the input selection or anything like that.
I’ll add that input next time I’m working on that part of the code.
–E
de W6EL
To be clear, set the input at the physical radio to USB, and ignore and do not change whatever is in wfview.
Quick update….got remote working. V1.2d on both Linux server, and win10 client. Old Linux laptop server, netbook client. Low spec machines. 2.4Ghz WiFi on both ends. Opus codec ch1. Notes…keep in mind, first run!: RX audio stutters, even with latency slider maxed out. Reports of similar broken audio on TX. Frequency often gets random incorrect values in it…like VHF frequencies….on a 7410, I doubt it, lol. Whole interface feels laggy….should I increase or decrease polling rate to help?….or will it help?
Anyhoo….THANKS! it’s off to a good start now!!!
Greg, KC8HXO
More notes….the lagging’s, and strange freq display happened on local WFview client before remote setup, too. Also….this rig maxes out at 19200 baud….it is set there.
Hi Greg,
I would decrease the polling as much as you can on the server side – take it out to 200ms or so. On the client, you can decrease it to a number that yeilds acceptable refresh rates on the s-meter. We do occasionally get bad reads, collisions, etc on the older radios, and that’s something we’re working on. I think the safest configuration is to use the highest baud rate supported and then the lowest polling rate (highest polling number) you can stand. That way the transactions are quick and with plenty of room between them.
As for the codec (Opus), on the client, select the codec, press “Save Settings” and then re-launch wfview client. This is because we send the codec information at the start of a session. Opus is definitely the best choice when you are connecting between wfview instances as it is more tolerant of errors and also significantly lower bandwidth is required.
The latency can be adjusted any time, and I recommend starting with the sliders in the middle. If you’re using wifi, any brief interruptions in signal (such as scanning for wifi access points, microwave ovens, etc) can dramatically lower performance. I would start with purely ethernet if that is an option. UDP without significant FEC is quite susceptible to dropouts. You can look on this forum for examples where people had issues; it was almost always due to unexpectedly-poor wifi performance. For example, you may have no trouble streaming HD from Netflix over wifi, but when you try wfview, any kind of packet loss will be very apparent.
Let us know if any of this helps,
–E
de W6EL
Yes…did not realize changing to Opus codec required save and restart. Setting polling to around 100ms helps, but odd it is not recalled correctly on client side…defaults back to 25ms every time. Also think part of the audio dropouts I hear are due to my long-time habit of turning UP the volume, and “riding” the RF gain to maximize S/N ratio. Seems between signals on RX, when noise is low, it’s almost as if there is a noise gate cutting off audio entirely for short periods. Turn up RF gain a bit, and solid band noise with no stutters. Is this possible? If so, some of my issues appear to certainly be " the nut behind the wheel".
Thanks again!
Greg, KC8HXO
Hi Greg,
Polling: The server and client have independent polling. The initial polling value is determined from the baud rate of the serial connection (which is communicated to the client version as well). That is what we consider a “safe” and nominal value. I recommend setting the server polling to the highest value (200ms) as you don’t really need much polling at all on the server side since the client side will also poll. When either side polls, the results are shared. At the client side, you can adjust the polling value to suit the S-Meter refresh rate desired. The s-meter is refreshed every other poll period (alternating with a list of parameters we track). We don’t currently save the user-specified polling rate, but perhaps we should be! The only complication is if a user switches to different radios without specifying a different settings file and ends up polling at an inappropriate rate.
Audio quality: You might want to check to see that the USB audio gain is set for a good nominal value. You could, at the server side, try something like closing wfview and running audiacity to capture some audio and just check that there’s a good amount of signal level. I like to see things at least half-scale and ideally at around -12dBfs RMS when there’s a signal present. If the audio is too low coming in, the conversion could be noisy and dominated with artifacts. I ride my RF gain as well, I think it’s a fine habit. USB audio levels can probably be set in two places: The radio’s menu (I don’t have a 7410 but I imagine there’s an adjustment), and possibly within the operating system as a sort of standard audio control that most USB audio devices have. In Linux Mint, I use the audio control panel to adjust the level on an input source, which actually sends adjustment commands to the USB hardware, which in theory adjusts the analog gain prior to conversion.
Let me know if that helps,
–E
de W6EL
Yes…taking these instructions, things are getting much better! Apparently, checking in to a local 75M net, they couldn’t tell I was remote!!! Winning!!! Back to work tomorrow, so I will probably be absent again a while…but I read every post to the forum, and have sent multiple people to the web site.
Kudos…again.
Greg, KC8HXO
Hi Greg,
Fantastic, glad to hear it’s working!
–E
de W6EL