Situation:
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.
Problem:
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
Question:
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.
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.
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.
Question:
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
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.
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 127.0.0.1 50004
Connection to 127.0.0.1 50004 port [udp/] succeeded!
pi@rpiham:~ $ netcat -uvz 127.0.0.1 50003
Connection to 127.0.0.1 50003 port [udp/] succeeded!
pi@rpiham:~ $ netcat -uvz 127.0.0.1 50002
Connection to 127.0.0.1 50002 port [udp/*] succeeded!
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