I have been using Wfview remotely with the client connected to the server it works well except. When I am using Wsjt-x I noticed that the frequency changes and not the frequency shift you expect when using Wsjt-x.
For example, I was on 20 meters operating Wsjt-x and using the default frequency of 14.074.
My Tx was set to 730 hz and Rx was set to 1530 hz.
When transmitting the radio shifts down from 14.074 to 14.073 which is what I expect. However from time to time the frequency changes from 14.074 to 14.073 with no interaction by me and either Wfview or Wsjt-x.
Then the software is on 14.073 and shifting down to 14.072. Iāve tried to watch and see if there is something thatās causing this behaviour and I canāt see anything.
It seems to happen only when I am transmitting. Just having the Wsjt-x and monitoring the frequency doesnāt change from what I can tell.
Any ideas? Possible a setting that I missed? Itās kind of annoying for this to happen when I am in the middle of a connection with another station.
When this happens and I donāt notice the frequency change right away, it tends to keep me from finishing the contact.
Any help is greatly appreciated.
How about changing how WSJTx handles itās tone - Try the FAKE IT option, or NONE for a while see if this mystery move still happens.
Also, maybe try JTDX or MSHV instead, and see if the same happens.
Have you any controllers connected to the client? They can cause a move from vibration, depending on how sensitive they are,
Another thing to think on is the version of WSJTx - is it a beta? Same for any Hamlib or whatnot. While these may appear on the surface to be stable, there might be room for strangeness as a result of the āun-finalā status of the version build.
Also, it would help to know the rig You are using, the path to it from the client, and how the rig is talking to the server instance, along with the OS on either end, and any other software You run that might interact with WSJTx or WFview - as in logging, port duplicators, rotor controllers etc.
Have to say, since Version 2.x, I have not seen any funky VFO things happening at all, where it was a regular feature with 1.6x and my IC7100.
Thanks for the thoughtful reply. I have tried using both the rig and fake it settings in Wsjt-x for split operation.
Changing from rig to fake it didnāt seem to make a difference.
My thoughts are that it is something in the Wsjt-x software and not in the Wfview software but I canāt be sure.
I am using version 2.6.1 of Wsjt-x. And using Wfview in client mode connected to another instance of Wfview running as the server on both on Windows 10.
My radio is an Icom 7300.
I have noticed that when I use Wsjt-x alone, connected to the radio directly and not using Wfview I do not see the unexpected frequency changes.
I did have issues with VFO at 2.03 especially with WSJT 2.6.1. See Rigctld/hamlib issues with 2.03. With WSJT beta it was more stable, but still not enough to keep it. Iām waiting for an updated version as mentioned in the response in the thread I referenced.
The second shows when I started my session calling CQ just 17 minutes before.
So the frequency moved down from 28.074 to 28.070 during that time period.
Just a thought, is the 28.074 frequency added in frequencies settings on WSJTx? without mode set, just the frequency?
I notice sometimes WSJTx will move to whatever frequency is set for the mode you are in on the band you are on by itself if You are off the āusualā frequency, for something like an expedition or sced or whatnot. Iām in the habit now of adding a QSY to my frequencies settings to avoid this.
