1.64 can receive on remote, but cannot send or change freq

I’m running 1.64 on my Win10 PC at home, connected to my 7300.
I’m running 1.64 on my MBP Monterey 12.6.6.

On my remote computer, I’m receiving audio, and receiving frequency and other settings FROM the radio just fine. I am unable to change frequency, transmit, and I’m not seeing any waterfall activity.

I did a desktop remote to my win10pc and I can change frequency and transmit from the WFView connected to the radio there, and it receives the audio from my remote PC.

It seems strange to me that I can receive data from the server pc, but not send.

I just tried to exit and restart the app on my remote, and now have no audio. Sometimes I have receive audio on remote, sometimes I don’t. Haven’t really figured that out.

Getting a lot of these messages in the log:
2023-07-24 13:03:52.159 INF rig: Warning: Spectrum sequence max was zero, yet spectrum was received.
2023-07-24 13:03:52.166 INF rig: Warning: Spectrum sequence max was zero, yet spectrum was received.
2023-07-24 13:03:52.206 INF rig: Warning: Spectrum sequence max was zero, yet spectrum was received.
2023-07-24 13:03:52.211 INF rig: Warning: Spectrum sequence max was zero, yet spectrum was received.

This is most common if wfview isn’t able to auto detect the rig type. You MUST enable C-IV transceive on your IC7300 and leave the C-IV address on both the server and client to auto, do NOT manually configure the C-IV address.

73 Phil M0VSE

Ok, I guess “Auto” is unchecking the box? If so, after doing that, it didn’t work at all.
I did set to manual and radio 94 on both server and client, now it is working.

Thanks
Paul

The log is still logging the error messages above on a continuous basis. Seems like a lot of log messages.

That will be because C-IV transceive is disabled on the radio, you MUST enable that for proper operation.

~WRD0001.jpg

I remember enabling CI-V on the radio. If that was off, wouldn’t it not transmit at all?

I had that issue a few weeks back, and I found that the setting was off at the radio and turned it on, and it worked.

At this point, everything is working except waterfall on the remote, which is unfortunate, but not required.

No it is C-IV transceive, not C-IV itself (which you can’t really disable), this is a specific feature that will automatically broadcast frequency/mode changes that wfview relies on for proper operation.

Certain software will attempt to disable it because they can’t handle unsolicited data.

Phil

~WRD0001.jpg

Yes, CI-V Transceive is the setting I enabled a few weeks ago.

Today I could transmit from the wfview server instance, but not the remote. As soon as I entered 94 in the address of the remote, then it worked. If i unchecked the manual address setting, wfview didn’t read anything from the radio.

The only thing not working now is waterfall.

Which generally is because ci-v transceiveis off. Double check this.

If this is off, then I wouldn’t be able to transmit from the server app correct?

Go look up what CI-V Transceive does, it may surprise you. It confused me the first time I heard it too!

–E
de W6EL

1 Like

note also that some other programs need to have CI-V off and may even force this to be off when used.
It has to do with the fact that older programs may not easily handle nsollicited data from the rigs.

WFVIEW can do without issues and in fact benefits from CI-V transceive being on.

Also be sure that you always have the baudrate set up correct as well as things like unlink-from-remote. If you fail to do so, you will not have scope data either.

Ok so it appears that if CI-V Transceive is off, I can still use WFView locally to transmit, get scope data, etc, all works fine locally, but all things doesn’t work remotely until it is turned on.

It appears that when I run Log4OM, it’s turning this setting off. I will have to look to see which rig control interface it’s using. What’s additionally frustrating about that, if I turn cat control OFF in Log4OM, it’s not letting go of the transceiver, so I have to completely exit the program, run WFView, then run log4om without enabling cat control.

Thanks for all your responses, at least I know what’s going on now. I know I turned that setting on long ago, but didn’t realize the logger was turning it back off.