Hi Mike, I wonder if the retry count could be reset after a successful connection. 73 Alan M0NNB
On Mon, Jul 12, 2021 at 5:06 PM Alan Hopper <[email protected]> wrote: > Hi Mike, > this is with WSJT-X connecting to the fake rigctld in SparkSDR. It > connects and then if a delay happens some time later (hours in real use) it > will reconnect again but if the delay happens again it does not retry. > Maybe be retry was planned for the initial connect? For long running > connections it would be nice if it kept reconnecting. > 73 Alan M0NNB > > On Mon, Jul 12, 2021 at 4:45 PM Black Michael via wsjt-devel < > [email protected]> wrote: > >> It should be trying to reconnect twice with 3 second timeout each time. >> >> What rig are you using? You could increase the timeout value by adding >> a switch to rigctld >> >> rigctld --set-conf=timeout=10000 >> >> >> You could also try increasing the retry in rigctld.c from 3 to maybe 4 or >> 5 and see if that makes it happy. >> >> >> if (retcode < 0 && !RIG_IS_SOFT_ERRCODE(-retcode)) >> >> { >> >> int retry = 3; >> >> >> >> Mike W9MDB >> >> >> >> >> On Monday, July 12, 2021, 10:08:36 AM CDT, Alan Hopper < >> [email protected]> wrote: >> >> >> Hi all, >> I've been doing some testing to try and make the hamlib NET rigctl >> connection to SparkSDR as robust as possible. Very infrequently (maybe once >> in 24hrs) responses from spark are delayed by a few seconds, This causes a >> time out at the WSJT-X side which then auto reconnects which is great, >> however if it happens a second time the auto retry does not seem to happen >> (I see no attempt to reconnect) and a dialog pops up with :- >> >> "Hamlib error: Communication timed out >> read_string called, rxmax=1024 >> read_string(): Timed out 3.000 seconds after 0 chars >> rig.c(1000):rig_open return(-5) while opening connection to rig >> >> Timestamp: 2021-07-11T20:55:06.057Z" >> >> I've added an artificial delay to test and the auto retry only ever >> appears to happen once. A manual retry does work after the second failure. >> >> In the ideal world spark would never send a delayed response but it is >> often used on heavily loaded pcs running many WSJT-X instances 24/7. The >> delays happen in a low level socket send so I don't think I have any >> control over it. >> >> I see it in 2.4.0 and 2.5.0rc3, I've not tested with any other versions. >> >> Is this intended behaviour or a bug? >> >> 73 Alan M0NNB >> >> >> _______________________________________________ >> wsjt-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/wsjt-devel >> _______________________________________________ >> wsjt-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/wsjt-devel >> >
_______________________________________________ wsjt-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wsjt-devel
