Tried the new version and in this manner it behaves more or less the same as v1 in our situation. We are running the server on a W10 machine which is connected to via usb to the IC-7300 and tested it on W10 as client. CIV-Transceive is ON now on the 7300.
On the first run, the server managed to see the TRX automatically, then nerver again, only connects when I set to manual and in our case default address 94, even when I reboot everything.
The client side connects fine, but also after the first run, I can not get waterfall, and all the other controls, ptt also doesn’t work.
I currently also use win4icom, but i am sure closing it before using wfview. When the radio is in standby because win4icom setting is checked to put it in standby when closing the application, wfview can not wake up the radio. Even when I restart everything. I need to wake up the radio with win4icom and then close it, then wfview can connect to the radio. If I don’t restart the server pc, win4icom needs very long to connect to the serial of the radio, being then able to wake it up.
On the client side i can only hear audio, see the frequency and s-meter.
seems like we have a too high audio level, but i can adjust that.
On the server side I can not change the audio codec for streaming, is that don on the client side where I have the ability to choose?
I tried using omnirig with the virtual serial port and com0com where it seems to poll the radio once then get not updated anymore. What is the correct baudrate 115200? 8N1?
Hope you can find something in the log files… I like wfview a lot, but having troubles to get it working properly via remote connection and as said, no wakeup of the radio.
THX
Rainer
If you are also using win4icom, I suspect that it is disabling CI-V Transceive. Firstly I recommend ONLY using wfview, verify that CI-V Transceive is enabled and then try connecting. It is also worth ensuring the OmniRig isn’t running in the background as that will take control of the rig serial port if it can.
On the wfview server, the audio input/output MUST be the USB audio codec of your rig.
Once wfview is reliably connecting to the rig, you should then be able to use the virtual serial port (com0com) to connect to win4icom. The virtual serial port will filter-out any attempts to disable CI-V transceive but if other software is able to connect directly to the rig then it will likely disable it.
Thanks a lot for clarification. Forgot it that win4icom switches civ transceive off even when it was switched on on the trx, and next time I will test it locally when I am at the remote site and if it is then working fine will not activate win4icom again.
Regarding audio codec it is clear that the USB-Audiocodec is coming and going to to the trx on the server side, but I ment the codec which is streamed over the internet. it is ylaw or pcm, but i can only switch that on the client side. Is the client telling the server which codec to stream? I can not change that on the server side, hope you get me.
I only want to connect via the virtual serial port at the client to omnirig, because LOG4OM, WSJTX and N1MM is using it, so I can connect via one serial connection from the virtual serial port from wfview over com0com to omnirig and omnirig connects to all other softwares. Or at least it is my impression it would work so. Just wanted to be sure that also the speed and settings are correct with 115200 baud and 8N1. As win4icom garbled the wfview setup I could not tested it.
Thanks a lot for your efforts to make a great software!
73s
Rainer, OE1KFR
Yes the client decides what the tx/rx audio codecs will be so there is no way to configure that on the server. Incidentally, as wfview allows ‘receive only’ clients, the first client to connect to a server will determine which codecs are used, any subsequent clients must use the same receive codec.
Yes 115200 8N1 should be fine, by default I think that baud rate emulation is disabled in com0com so this setting shouldn’t matter.
Thanks a lot!
I asked Tom from win4icom about the CIV-Transceive setting and he said, that his sw is not changing the setting and should remain as it was set on trx. As I am not at the remote site I can’t confirm that, but when I left it was set to on, so there could be probably another issue why wfview is only connecting via manual address and the client has the issues mentioned above.
win4icom gives btw a udp socket error when wfview was used before… so probably a communication error on the ip side?
73
Rainer
From what I understand, win4icom uses the same UDP ports as the Icom radios for its remote protocol (50001-50003) although the protocol is not compatible with wfview. This is likely what is causing the problem, so you are probably best to change this in win4icom (if you can) or use different UDP ports in wfview.
Hi Phil!
I was at our remote site and used the latest 1.1 version, set all settings according your ppt and wfview worked as expected
But there are a few things I want to point out please:
Audio connection sounds only good if I am in the local LAN with 16 bit PCM. 8 bit sounds distorted with lots of clicks. The level looks fine, reduced it also a bit more, but no improvement. When I use mumble as audio connection it sounds totally fine, also over the internet. When I use wfview audio connection over the internet then I hear the distortions also in 16 bit PCM. ylaw is not usable either. I have a recording uploaded that you can hear what I mean. You can get it under this link: Audiofile
Second thing is regarding the virtual com port. At my tests I was using windows 10 on both sides. When I use a single SW like wsjt-x for example and connect it via com0com directly with the IC-7300 preset all is fine. Really problematic was to use the combination Omnirig connected via com0com and having wsjt-x and Log4OM connected to omnirig. This completely garbled the TRX settings and also switched off CIV-Transceive and wfview could not connect anymore to the TRX. Having Omnirig working would be great to be able to use multiple SW syncing with the TRX as this is my straight forward workflow. In contests I also use N1MM contest logger but without wsjt-x and without log4om over omnirig, but did not test that.
I saw you are working on implementing rigctld which looks very promising to control via TCP. Would it then possible to use hamlib over TCP? Would be great!
best 73s
Rainer
Yes I discovered an issue with 8bit audio in v1.1 which is fixed in the master branch (it was actually decoding PCM audio as uLaw) but to be honest the quality of 8bit really isn’t very good anyway. uLaw should work much better and uses the same bandwidth.
I have used all available codecs both over LAN and WAN connections and they work fine as long as there is sufficient bandwidth.
Mumble uses the Opus codec which can compress audio as much as 10:1. I have been testing using Opus for wfview-wfview audio and it seems to work very well so this will be added to a future version of wfview (it will only work with wfview-wfview though as when connected directly to LAN based rigs (7610, 9700 etc.) we are limited by what codecs are available on the rig.
I suspect that your WAN connection doesn’t have sufficient bandwidth. Realistically, you need around 1Mb/s bandwidth available in both directions (a single channel of 48K 16bit audio requires 768Kb/s) but by the time you have added overhead and waterfall data etc. it will be closer to 1Mb. You can also try reducing the sample rate as 48K is likely to be higher than you need. I have found that 24K is perfectly usable for most applications and will ½ the bandwidth required. This means that a 24K uLaw signal will only require around 192Kb/s with minimal loss of audio quality compared to 48K 16bit.
That’s weird, I seem to have lost the last paragraph! Anyway it was:
From my understanding of OmniRig, it doesn’t do any caching so each client that is polling the rig will use significant resources on the USB conection. With the Rigctld that we have developed, that uses cached versions of data so will significantly reduce the load on the rig. I have successfully had 4 different programs connected to Rigctld (Log4OM, WSJT-X, GRIG and Minos) with no noticeable problems.
Great! Thanks a lot for your detailed information and reply, much appreciated!
Do you think it would be possible to compile an alpha built of the current master branch? I can not do it currently. If I compile it on Ubuntu, I would not get the windows and Mac version right? Have no toolchain for that.
Would be great to test rigctld and the improved audio streaming as well the new meters for swr.
Thx 73s
Rainer
We will probably do a new build with rigctld soon as that is looking quite stable in testing so far. Unfortunately the other features are currently being developed in other branches which we will merge when we are happy that they are stable enough, so it is tricky to produce a build with all of these features.
Hi Phil!
Thanks a lot for your help and efforts, much appreciated!
Will test the new release then. Currently the setup with win4icom/omnirig/wsjtx/log4om/jttalert chenaged somewhow the settings again and can not use wfview. If the new version is out I will have a visit at the remote site.
I am also thinking on placing a RPi4 there as wfview server. Let’s see.
73s
Rainer
In the next few days, we will hopefully be releasing v1.2. This has a number of improvements but two of the main new features are emulation of rigctld and support for the Opus codec.
The rigctld emulation allows wsjtx, log4om and various other programs to connect to wfview simultaneously and by using a caching mechanism there is no extra load on the CI-V bus.
The addition of the Opus codec is only useful when connecting wfview-wfview but it results in around 80-90% bandwidth reduction compared to LPCM16 codec with no noticeable loss of audio quality. I have used wsjt-x over Opus and it works very well in my testing.
As both the client & server must support the same codecs, Opus cannot be used when wfview is connecting directly to a radio over LAN/WAN though as wfview must be at both end of the connection.
