WRN default: QIODevice::write (QSerialPort): device not open


Remote RIG IC-7300 gets switched off (not importent what causes his)
Remote raspi and wfview is still operating.
Rig gets switched on again.
Wfview shows no data anymore.
Wfview at server site (not the server) gets stopped and started again.

Wfview fails to show data because of following failure, see part of log file:

2022-01-06 21:10:06.206 INF default: Setting rig state for wfmain
2022-01-06 21:10:06.206 INF default: Setting rig state
2022-01-06 21:10:06.206 WRN default: QIODevice::write (QSerialPort): device not open

How can I solve the problem without restarting the raspi ?
What process should I restart before starting wfview again ?

Additional Info:
Sometimes I had a hanging wfview process (see ps aux) and even when killing wfview it could not restart and I had to reboot the raspi.

Any hint or solution is welcome.
73, Michael

Hi Michael.

If the radio loses power for some reason, the USB devices that it provides will be removed from Linux and once reconnected, they will have different device identifiers so restarting wfview will be the only option to recover. We can try to make wfview detect loss of devices better but under normal circumstances, this shouldn’t happen.

73 Phil M0VSE

Hi Phil,
thank you for your explanation.
In my case the problem is that restarting wfview didn’t help. I had to reboot the Raspi each time. So I think there is some process (usb device at server => raspi) hanging.
Maybe I have to restart the usb module first and afterwards start wfview.
What can start a chain of other problems with USB devices on a desktop machine, but could be ok on a dedicated server handling only wfview.
Is there a place where the usb id of a former failed connection is stored and when restarting wfview, read it in and check if still a hanging process using this id is existing, clear it and establish afterwards a new clean connection.
(Background of all is to have at the end a script useable in a watchdog process to establish continous remote operation. At the end of the logfile I could see that the udp server was shut down. Pinging local somehow the udp port at 50001 could be a good starting point to detect a problem. I think such things should be discussed in a new topic called watchdog or similar)
73 Michael

Hi Michael.

I suspect that wfview is unable to cleanly close the device as it has ‘disappeared’ so it is likely something is ending-up in an unstable state. I will try to simulate this condition here and see if I can work out what is happening.

We are planning to provide a server only version of wfview (without the gui) and some sort of watchdog to monitor/restart the server is definitely something that could be useful.

73 Phil M0VSE

Hi Phil,
now at home I tried to recheck the problems as mentioned before.
I’m now a little bit confused.

When IC-7300 Power off you can see in wfview-p1.log the result beginning at time 2022-01-07 23:22:45.407.
From 2022-01-07 23:23:37.778 power to IC-7300 went on again and therefor no entries any more.

Remote Server:
During power off and afterwards power on no diff. in connectivity to udp ports

pi@rpiham:~ $ netcat -uvz 50004
Connection to 50004 port [udp/] succeeded!
pi@rpiham:~ $ netcat -uvz 50003
Connection to 50003 port [udp/
] succeeded!
pi@rpiham:~ $ netcat -uvz 50002
Connection to 50002 port [udp/*] succeeded!

pi@rpiham:~ $ sudo lsmod | grep usbserial
usbserial 36864 3 cp210x

wfview is controlling the IC-7300 and vice versa changes at the Rig are reflected to wfview
E.g. S-meter schows changes of fluctuating noise or signal

Waterfall and spectrum are frozen.

Local Client switched on => gets connected to remote server.
I’m perplex, waterfall and spectrum woring suddenly OK on server side and client too.
see time starting 2022-01-07 23:49:32.131 in wfview-p2.log

wfview-p2.log (8.7 KB)
wfview-p1.log (4.5 KB)

I never had this behavor recognized earlier. The failure:
WRN default: QIODevice::write (QSerialPort): device not open
didn’t appear.

What to say to you; I’m speechless

Will test now with wsjt-x as client at the remote server machine running and local running and check again results.

73 Michael