When you have 8 instances of WSJT-X running seems a bit awkward to click retry
8 times.
You don't think getting an error doesn't deserve to get fixed? Is there some
problem with doing a proper delay?
And sometimes doing retry will give a configuration error too which requires a
restart of WSJT-X...also undesirable.
Mike
On Thursday, April 23, 2020, 01:13:33 PM CDT, Bill Somerville
<g4...@classdesign.com> wrote:
Hi Mike,
so what's wrong with the WSJT-X user pressing Retry when changing a SmartSDR
profile breaks the CAT connection?
73
Bill
G4WJS.
On 23/04/2020 18:20, Black Michael via wsjt-devel wrote:
Yes....
On Thursday, April 23, 2020, 12:19:11 PM CDT, Bill Somerville
<g4...@classdesign.com> wrote:
Hi Mike,
Does this cause WSJT-X to offer a Retry/Reconfigure/Cancel message box?
73
Bill
G4WJS.
On 23/04/2020 18:00, Black Michael via wsjt-devel wrote:
The Flex takes almost 3 seconds to do a profile change and with a polling
rate of 1 second the code in PollingTransceiver.cpp times out and does a
shutdown so sends "q" to rigctld for example.
Not talking about changing the polling_rate....need to add a counter to only
time out after 4 seconds instead of using the polling rate to determine the
timeout.
Any rig should be able to poll at 1 second (or even faster for that matter)
but the timeout should not be 1 second....it needs to be the worst case
scenario to avoid WSJT-X from disconnecting unnecessarily.
Mike
On Thursday, April 23, 2020, 11:49:27 AM CDT, Bill Somerville
<g4...@classdesign.com> wrote:
On 23/04/2020 17:34, Black Michael via wsjt-devel wrote:
Found a problem with Flex which is fixed by changing the rig polling rate to 3
seconds and adding some changes to hamlib. Doing a profile change on Flex can
take almost 3 seconds. So if you have polling at 1 second WSJT-X times out
waiting for the profile change and actually requests hamlib to disconnect
*(i.e. shutdown). This may explain random disconnects when any rig takes too
long to respond on any command.
There are a few possible solutions which I'll rank in my preference order....
#1 Fix the polling to provide a fixed timeout of 4 seconds. Users won't have
any idea what to set for this and I don't see any problem with waiting up to 4
seconds when things are getting delayed. Normally we don't run into this
timeout but we need to gracefully recover when we do. #2 Provide a
user-controllable setting which defaults to 4 seconds. Just in case this
longer timeout causes a different problem. Maybe put it in the release
candidate and then remove it when nobody complains.
So...for Flex users....change polling to 3 seconds and use this
hamlib_settings.json file in the WSJT-X configuration directory This changes
will be in the next version of WSJT-X for the Flex6xxx entry.
{ "config": { "retry": "13", "post_write_delay": "0",
"timeout": "300" } }
de Mike W9MDB
Hi Mike,
please explain what you mean by requests Hamlib to disconnect? Are you
referring to a TCP/IP connection failure? Does this cause WSJT-X to offer a
Retry/Reconfigure/Cancel message box?
A 3 s polling interval being enforced is not acceptable for an issue that only
happens when a profile is changed on SmartSDR.
73
Bill
G4WJS.
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
