Remote WFVIEW Virtual Serial Port Control Problems

I have an ICOM IC-7300 connected via USB to a Raspberry Pi set up for server operation. Accessing this server via the Internet is a Win 10 laptop running WFVIEW. This all works well. In the Win 10 laptop I have two virtual audio cables and a TCP link connected to WSJT-X. This all works well with WSJT-X able to control the TX frequencies. No problem so far.

Now the problem.

I decided to try MMSSTV, a popular SSTV program. Again, it is connected to the two virtual audio cables and that connection works fine. Rig control is the issue. I installed a VSPE virtual com port, and used it to connect to the MMSSTV com port.

The rig commands, although correct, are not received by WFVIEW and do not create a Pseudo Terminal.

Now I am going to make a long story short. To troubleshoot the problem I made the simplest test setup that I could.

I connected Tera Term, a common terminal emulator, to the same come port as MMSSTV was using and proceeded to test.
Using a file with a transmit command from Tera Term, the command was received by WFVIEW and a pseudo terminal created with a log entry of the correct command. This worked. It worked regardless of Tera Term’s bit rate setting also. The only difference that I could detect between Tera Term and MMSSTV was that the characters from MMSSTV visually seemed to be sent at a much slower rate, a significant gap between characters.

To prove that this was the issue, I optioned Tera Term with a 1ms delay between characters, and sent the same file. With that small delay, it was not recognized by WFVIEW and no Pseudo Terminal appeared in the log. This was a repeatable situation;
remove the delay, and the command is sent and recognized by the 7300.

Normally, delays between characters within reason should be accepted. The monitoring capability of the VSPE virtual com port also showed correct data going to WFVIEW but still no WFVIEW log info.

It seems that the pseudo terminal buffer is not being created or sent when there are async character delays. Is there some control character such as CR or LF that would help? I could pre or append them after a delay if appropriate.

I realize this is a rather obscure problem that few people will encounter, but if I could make it work,I would like to.

I would appreciate any ideas or approaches on further troubleshooting of my situation.

Al Jamison

Hi Allan,

Just to confirm, you are using wfview’s virtual serial port, per our documentation, correct? It was not clear to me exactly how you are connecting to wfview.

There is no need for a CR or LF within the commands, and in fact I would strongly recommend against using them.

We have not experimented to see how slow commands can go to the radio. One thing you could try though, is to slow down wfview’s own polling to perhaps make more room for your commands. Under Settings there is a polling setting, you can try a large setting such as 200ms and see if it helps any.

de W6EL


Yes, I am using the Virtual Serial Port in the External Control Settings tab. I am also have Enable Rig Ctld and am using Port 4533 but not with the MMSSTV app and not at the same time.

I am not using CR or LF but wondered if I could force the TX buffer to send. Further experiments showed that the IC-7300 will not tolerate additional characters after the FD terminator so, as you have said, that is not a good idea.

I have not altered the polling yet but will try and see what happens. I wondered if the fact that the WVVIEW debug log does not show a pseudo term entry for the slower command but does for the faster version is a clue?




I just changed the polling interval to 250 ms and the symptoms didn’t change. The command with 1ms between characters was ignored by WFVIEW while the same command with no character delay was accepted.


Try starting wfview with the “–debug” flag for more logging. Maybe you’ll see it. I can’t recall if we log pseudo-term traffic or not.


I did that and the pseudo-term traffic is logged correctly under the pseudo-term category when the command is sent without character delays. With the 1ms delay, there is no log entry I can see and no ‘pseudo-term’ when the log is searched. I also searched for the command FE FE 94 E0 1C 00 01 FD which is my test command, it turns on transmit. I could not see it either under the failure conditions. Under success conditions with no character delay the above command is logged.



I ran into something similar. Discovered it yesterday. But with a different setup.
Rig IC-7610 with latest firmware
Win10 computer connected to radio. with USB
Com0Com virtual comport pair installed on computer.
Logger32 (Latest version) connected to WFview (V1.62) via the virtual comport pair.

I can click on spot in logger32 and radio moves to frequency. But if I change frequency on radio, logger32 do not change. Wfview follow ok all the time.

If I connect Wfview to the radio over network. To the built in server in the radio. And the same setup with virtual comport between wfview and logger32 everything works. Logger32 can poll radio and follows all changes.

If I use UCXlog instead of Logger32 also the first example works, with USB between radio and wfview. Exactly the same com port settings all the way.

Any ideas?


Hi George,

wfview works best when third party programs use wfview’s virtual serial interface. I can’t recommend splitting the communications between wfview and the radio. We have tested our own virtual serial connection much more, and it is designed specifically around the CI-V protocol.

I recommend always letting wfview connect to the radio as directly as possible.

de W6EL

Hi Elliot

You misunderstood. There is no com-port sharing. WFview have exclusive access to the radio allthe time. Will try to explain in a different way.

IC-7610–>USB cable (Com12)–Wfview (Com10 virtual pair)–>Logger32 (Com11 virtual pair)
Radio does not update logger32, logger32 can update radio.

IC-7610–network–>Wfview (Com10 virtual pair)–>Logger32 (Com11 virtual pair)
Everything works. updates both ways.

IC-7610–USB cable (Com12)–>Wfview (Com10 virtual pair)->-UCXlog (Com11 virtual pair)
Everything works. updates both ways.

I dont use logger32 and UCX at the same time. Just describing different behavior.
Exact same com port settings in both logger32 and UCXlog.
All cases uses the virtual com-port function in wfview. (Com10-Com11)


Hi Orjan / George

It could be the same problem I am experiencing. You might want to see if the output character delay of Logger32 differs from UCXlog. If it does, it could be the same issue. The program with the longer delay would be the one I would expect to fail.

I don’t use either program so I have no direct experience.

Al Jamison

Hi George,

Thank you for clarifying.

Via what means are the commands sent using UCXlog and logger32? Are there any controls which may account for the difference in success?


de W6EL


Both logging software can change frequency or mode on the radio and logger32 can send cat commands to radio. But when turning VFO on radio or change mode it does not reflect back to logger32. That works in UCXlog.
And I can see in the debug window in logger32 that polling the radio does not work if the connection between wfview and radio is USB.It works when connection from wfview to radio is network.