Re: [wsjt-devel] Flex bug

[Bill Somerville]

On 24/04/2020 17:14, Black Michael via wsjt-devel wrote:

Whaddya' mean no timeouts?

PollingTransceiver::PollingTransceiver (int poll_interval, QObject * 
parent)

  : TransceiverBase {parent}
  , interval_ {poll_interval * 1000}
  , poll_timer_ {nullptr}
  , retries_ {0}

          poll_timer_ = new QTimer {this}; // pass ownership to
                                           // QObject which handles
                                           // destruction for us

          connect (poll_timer_, ::timeout, this,
 ::handle_timeout);

I would be talking about rig_caps.timeout

Using that plus a fudge factor would allow more responsive behavior 
for faster rigs and still allow for the slower ones.


And I would also expose the rig's timeout inside rigctld's rig_caps.

Mike




Mike,

that's not a timeout, its the polling interval. The thing that times out 
is the QTimer object, every tick of that triggers a read of various rig 
parameters like frequency and mode.


73
Bill
G4WJS.



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Flex bug

[Black Michael via wsjt-devel]

Whaddya' mean no timeouts?
 PollingTransceiver::PollingTransceiver (int poll_interval, QObject * parent)  
: TransceiverBase {parent}  , interval_ {poll_interval * 1000}  , poll_timer_ 
{nullptr}  , retries_ {0}
          poll_timer_ = new QTimer {this}; // pass ownership to                 
                          // QObject which handles                              
             // destruction for us
          connect (poll_timer_, ::timeout, this,                   
::handle_timeout);
I would be talking about rig_caps.timeout
Using that plus a fudge factor would allow more responsive behavior for faster 
rigs and still allow for the slower ones.
And I would also expose the rig's timeout inside rigctld's rig_caps.
Mike






 

On Friday, April 24, 2020, 10:49:03 AM CDT, Bill Somerville 
 wrote:  
 
  Mike, 
  WSJT-X calls Hamlib API functions which are blocking, there are no timeouts, 
it just waits for the function to finish. What is this timeout you are 
referring to? 
  73
 Bill
 G4WJS. 
  On 24/04/2020 16:40, Black Michael via wsjt-devel wrote:
  
   I've had several reports from the JTDX groupas I said due to the new 
power level calls it is making.  And now I'm running into rigs with 50ms 
post_write_delay that are too slow and hitting the timeout and I'm loathe to 
change that 50ms as most of those were determined by experimentation and I 
can't tell which were and which weren't. 
  I remember seeing quite a few timeouts on the WSJT-X groupI'm not going 
to bother to go find themthey weren't horribly common and now I can see why 
they were randomall they needed was some delay and WSJT-X would time out 
since most everybody uses the default 1 second polling rate..and therefore the 
1 second timeout.  I seem to recall some decreasing the polling rate.  That's 
what I've had to tell the Flex users. 
  There is no logical reason I can think of to have a 1 second timeout when it 
is well known that the underlying hardware has longer timeouts than that. 
  Nobody is going to even know there's a 3 or 4 second timeout.  Not that there 
is a difference between hamlib's timeout and WSJT-X's timeout.  hamlib will 
time out based on the rig settings.  WSJT-X does not. 
  It should be possible for WSJT-X to use the rig's "timeout" value plus maybe 
200ms.  Note that netrigctl has a 2.5 second timeout. 
  Then I can change rigctld to also use the rig's timeout if it's large than 
rigctld's timeout. 
  Mike 
  
  
   

  
  On Friday, April 24, 2020, 09:39:40 AM CDT, Bill Somerville 
 wrote:  
  
 Mike, 
  the only reports of Hamlib timeouts I have seen are where the connection is 
not set up right, e.g. the wrong COM port, baud rate, or handshaking. Can you 
point me to a report of a Hamlib timeout that is not caused by similar 
misconfiguration?
  
  73
 Bill
 G4WJS. 
   On 24/04/2020 15:29, Black Michael via wsjt-devel wrote:
  
   And please give consideration to lengthening the timeout to 3 
secondswe'll get rid of a lot of complaints about timeouts. 
  Mike  
   

  
  On Friday, April 24, 2020, 09:27:37 AM CDT, Bill Somerville 
 wrote:  
  
 Hi Mike, 
  OK, hold off from any Hamlib changes to rig_close for now. I will do some 
tests when I get some time and work out if WSJT-X is really calling rig_open 
twice on the same RIG handle without an intervening rig_close. I'll get back to 
you. 
  73
 Bill
 G4WJS. 
   On 24/04/2020 15:03, Black Michael via wsjt-devel wrote:
  
   I have no idea why it's treated differentlybeen that way since day#1. 
  I could add a flag to the RIG structure for "close_is_sync" that a client 
could set if it wants a synchronous close. 
  That way we wouldn't break any other apps not expecting it. 
  Mike  

  
  On Friday, April 24, 2020, 08:49:41 AM CDT, Bill Somerville 
 wrote:  
  
 On 24/04/2020 14:39, Black Michael via wsjt-devel wrote:
  
 rig_close being synchronous won't (shouldn't) matter.  The problem is that 
hamlib recovers from the timeout but when it's done WSJT-X has already timed 
out and shuts down rigctld.  And it also looks like WSJT-X starts another 
connection before closing the first one which then gives the invalid 
configuration errormaybe that's where a synchronous close would work 
betterbut it looks like the idea there was a client just tells rigctld "I'm 
done" and that's a 1-way conversation.  If we make it synchronous then the 
client has to stay around to take the answer or else we start hitting timeouts 
in rigctld.  I'm a bit reluctant to make it synchronous as I don't know what 
all the client programs are expecting. And if we make it synchronous and 
rigctld goes away then the client will be timing out trying to close it. 
  All timeouts are arbitrary but have to be based on what the hardware can do. 
. 
  Making the timeout = pollrate is arbitrary too.  If you made the polling 10ms 
everything would time out like crazy. 
  We've got a lot of rigs that just aren't very 

Re: [wsjt-devel] Flex bug

[Bill Somerville]

Mike,

WSJT-X calls Hamlib API functions which are blocking, there are no 
timeouts, it just waits for the function to finish. What is this timeout 
you are referring to?


73
Bill
G4WJS.

On 24/04/2020 16:40, Black Michael via wsjt-devel wrote:
I've had several reports from the JTDX groupas I said due to the 
new power level calls it is making.  And now I'm running into rigs 
with 50ms post_write_delay that are too slow and hitting the timeout 
and I'm loathe to change that 50ms as most of those were determined by 
experimentation and I can't tell which were and which weren't.


I remember seeing quite a few timeouts on the WSJT-X groupI'm not 
going to bother to go find themthey weren't horribly common and 
now I can see why they were randomall they needed was some delay 
and WSJT-X would time out since most everybody uses the default 1 
second polling rate..and therefore the 1 second timeout.  I seem to 
recall some decreasing the polling rate.  That's what I've had to tell 
the Flex users.


There is no logical reason I can think of to have a 1 second timeout 
when it is well known that the underlying hardware has longer timeouts 
than that.


Nobody is going to even know there's a 3 or 4 second timeout.  Not 
that there is a difference between hamlib's timeout and WSJT-X's 
timeout. hamlib will time out based on the rig settings.  WSJT-X does not.


It should be possible for WSJT-X to use the rig's "timeout" value plus 
maybe 200ms. Note that netrigctl has a 2.5 second timeout.


Then I can change rigctld to also use the rig's timeout if it's large 
than rigctld's timeout.


Mike






On Friday, April 24, 2020, 09:39:40 AM CDT, Bill Somerville 
 wrote:



Mike,

the only reports of Hamlib timeouts I have seen are where the 
connection is not set up right, e.g. the wrong COM port, baud rate, or 
handshaking. Can you point me to a report of a Hamlib timeout that is 
not caused by similar misconfiguration?


73
Bill
G4WJS.

On 24/04/2020 15:29, Black Michael via wsjt-devel wrote:
And please give consideration to lengthening the timeout to 3 
secondswe'll get rid of a lot of complaints about timeouts.


Mike




On Friday, April 24, 2020, 09:27:37 AM CDT, Bill Somerville 
  wrote:



Hi Mike,

OK, hold off from any Hamlib changes to rig_close for now. I will do 
some tests when I get some time and work out if WSJT-X is really 
calling rig_open twice on the same RIG handle without an intervening 
rig_close. I'll get back to you.


73
Bill
G4WJS.

On 24/04/2020 15:03, Black Michael via wsjt-devel wrote:
I have no idea why it's treated differentlybeen that way since 
day#1.


I could add a flag to the RIG structure for "close_is_sync" that a 
client could set if it wants a synchronous close.


That way we wouldn't break any other apps not expecting it.

Mike



On Friday, April 24, 2020, 08:49:41 AM CDT, Bill Somerville 
  wrote:



On 24/04/2020 14:39, Black Michael via wsjt-devel wrote:
rig_close being synchronous won't (shouldn't) matter.  The problem 
is that hamlib recovers from the timeout but when it's done WSJT-X 
has already timed out and shuts down rigctld.  And it also looks 
like WSJT-X starts another connection before closing the first one 
which then gives the invalid configuration errormaybe that's 
where a synchronous close would work betterbut it looks like 
the idea there was a client just tells rigctld "I'm done" and 
that's a 1-way conversation.  If we make it synchronous then the 
client has to stay around to take the answer or else we start 
hitting timeouts in rigctld.  I'm a bit reluctant to make it 
synchronous as I don't know what all the client programs are expecting.
And if we make it synchronous and rigctld goes away then the client 
will be timing out trying to close it.


All timeouts are arbitrary but have to be based on what the 
hardware can do. .


Making the timeout = pollrate is arbitrary too. If you made the 
polling 10ms everything would time out like crazy.


We've got a lot of rigs that just aren't very fast on CAT and 1 
second is too short.


The timeouts aren't hit very often and nobody will even notice it 
in WSJT-X if there's a 3-second timeout that almost never gets 
triggered.
What they do notice is WSJT-X timing out too quickly. And the more 
data we ask from the rigs the more likely we are to hit the 1 
second timeout.


Mike


Hi Mike,

if WSJT-X is overlapping rig_open/rig_close calls then it should be 
doing it on a separate RIG handle, that should not cause a problem.


I thought the Hamlib API was synchronous, why is the rig_close call 
being treated differently, that's very confusing to me.


73
Bill
G4WJS.



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Flex bug

[Black Michael via wsjt-devel]

I've had several reports from the JTDX groupas I said due to the new power 
level calls it is making.  And now I'm running into rigs with 50ms 
post_write_delay that are too slow and hitting the timeout and I'm loathe to 
change that 50ms as most of those were determined by experimentation and I 
can't tell which were and which weren't.
I remember seeing quite a few timeouts on the WSJT-X groupI'm not going to 
bother to go find themthey weren't horribly common and now I can see why 
they were randomall they needed was some delay and WSJT-X would time out 
since most everybody uses the default 1 second polling rate..and therefore the 
1 second timeout.  I seem to recall some decreasing the polling rate.  That's 
what I've had to tell the Flex users.
There is no logical reason I can think of to have a 1 second timeout when it is 
well known that the underlying hardware has longer timeouts than that.
Nobody is going to even know there's a 3 or 4 second timeout.  Not that there 
is a difference between hamlib's timeout and WSJT-X's timeout.  hamlib will 
time out based on the rig settings.  WSJT-X does not.
It should be possible for WSJT-X to use the rig's "timeout" value plus maybe 
200ms.  Note that netrigctl has a 2.5 second timeout.
Then I can change rigctld to also use the rig's timeout if it's large than 
rigctld's timeout.
Mike



 

On Friday, April 24, 2020, 09:39:40 AM CDT, Bill Somerville 
 wrote:  
 
  Mike, 
  the only reports of Hamlib timeouts I have seen are where the connection is 
not set up right, e.g. the wrong COM port, baud rate, or handshaking. Can you 
point me to a report of a Hamlib timeout that is not caused by similar 
misconfiguration?
  
  73
 Bill
 G4WJS. 
  On 24/04/2020 15:29, Black Michael via wsjt-devel wrote:
  
   And please give consideration to lengthening the timeout to 3 
secondswe'll get rid of a lot of complaints about timeouts. 
  Mike  
   

  
  On Friday, April 24, 2020, 09:27:37 AM CDT, Bill Somerville 
 wrote:  
  
 Hi Mike, 
  OK, hold off from any Hamlib changes to rig_close for now. I will do some 
tests when I get some time and work out if WSJT-X is really calling rig_open 
twice on the same RIG handle without an intervening rig_close. I'll get back to 
you. 
  73
 Bill
 G4WJS. 
   On 24/04/2020 15:03, Black Michael via wsjt-devel wrote:
  
   I have no idea why it's treated differentlybeen that way since day#1. 
  I could add a flag to the RIG structure for "close_is_sync" that a client 
could set if it wants a synchronous close. 
  That way we wouldn't break any other apps not expecting it. 
  Mike  

  
  On Friday, April 24, 2020, 08:49:41 AM CDT, Bill Somerville 
 wrote:  
  
 On 24/04/2020 14:39, Black Michael via wsjt-devel wrote:
  
 rig_close being synchronous won't (shouldn't) matter.  The problem is that 
hamlib recovers from the timeout but when it's done WSJT-X has already timed 
out and shuts down rigctld.  And it also looks like WSJT-X starts another 
connection before closing the first one which then gives the invalid 
configuration errormaybe that's where a synchronous close would work 
betterbut it looks like the idea there was a client just tells rigctld "I'm 
done" and that's a 1-way conversation.  If we make it synchronous then the 
client has to stay around to take the answer or else we start hitting timeouts 
in rigctld.  I'm a bit reluctant to make it synchronous as I don't know what 
all the client programs are expecting. And if we make it synchronous and 
rigctld goes away then the client will be timing out trying to close it. 
  All timeouts are arbitrary but have to be based on what the hardware can do. 
. 
  Making the timeout = pollrate is arbitrary too.  If you made the polling 10ms 
everything would time out like crazy. 
  We've got a lot of rigs that just aren't very fast on CAT and 1 second is too 
short.  
  The timeouts aren't hit very often and nobody will even notice it in WSJT-X 
if there's a 3-second timeout that almost never gets triggered. What they do 
notice is WSJT-X timing out too quickly.  And the more data we ask from the 
rigs the more likely we are to hit the 1 second timeout. 
  Mike 
 
Hi Mike,
 
if WSJT-X is overlapping rig_open/rig_close calls then it should be doing it on 
a separate RIG handle, that should not cause a problem.
 
I thought the Hamlib API was synchronous, why is the rig_close call being 
treated differently, that's very confusing to me.
  
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

Re: [wsjt-devel] Flex bug

[Bill Somerville]

Mike,

the only reports of Hamlib timeouts I have seen are where the connection 
is not set up right, e.g. the wrong COM port, baud rate, or handshaking. 
Can you point me to a report of a Hamlib timeout that is not caused by 
similar misconfiguration?


73
Bill
G4WJS.

On 24/04/2020 15:29, Black Michael via wsjt-devel wrote:
And please give consideration to lengthening the timeout to 3 
secondswe'll get rid of a lot of complaints about timeouts.


Mike




On Friday, April 24, 2020, 09:27:37 AM CDT, Bill Somerville 
 wrote:



Hi Mike,

OK, hold off from any Hamlib changes to rig_close for now. I will do 
some tests when I get some time and work out if WSJT-X is really 
calling rig_open twice on the same RIG handle without an intervening 
rig_close. I'll get back to you.


73
Bill
G4WJS.

On 24/04/2020 15:03, Black Michael via wsjt-devel wrote:

I have no idea why it's treated differentlybeen that way since day#1.

I could add a flag to the RIG structure for "close_is_sync" that a 
client could set if it wants a synchronous close.


That way we wouldn't break any other apps not expecting it.

Mike



On Friday, April 24, 2020, 08:49:41 AM CDT, Bill Somerville 
  wrote:



On 24/04/2020 14:39, Black Michael via wsjt-devel wrote:
rig_close being synchronous won't (shouldn't) matter. The problem is 
that hamlib recovers from the timeout but when it's done WSJT-X has 
already timed out and shuts down rigctld.  And it also looks like 
WSJT-X starts another connection before closing the first one which 
then gives the invalid configuration errormaybe that's where a 
synchronous close would work betterbut it looks like the idea 
there was a client just tells rigctld "I'm done" and that's a 1-way 
conversation.  If we make it synchronous then the client has to stay 
around to take the answer or else we start hitting timeouts in 
rigctld. I'm a bit reluctant to make it synchronous as I don't know 
what all the client programs are expecting.
And if we make it synchronous and rigctld goes away then the client 
will be timing out trying to close it.


All timeouts are arbitrary but have to be based on what the hardware 
can do. .


Making the timeout = pollrate is arbitrary too. If you made the 
polling 10ms everything would time out like crazy.


We've got a lot of rigs that just aren't very fast on CAT and 1 
second is too short.


The timeouts aren't hit very often and nobody will even notice it in 
WSJT-X if there's a 3-second timeout that almost never gets triggered.
What they do notice is WSJT-X timing out too quickly.  And the more 
data we ask from the rigs the more likely we are to hit the 1 second 
timeout.


Mike


Hi Mike,

if WSJT-X is overlapping rig_open/rig_close calls then it should be 
doing it on a separate RIG handle, that should not cause a problem.


I thought the Hamlib API was synchronous, why is the rig_close call 
being treated differently, that's very confusing to me.


73
Bill
G4WJS.



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Flex bug

[Black Michael via wsjt-devel]

And please give consideration to lengthening the timeout to 3 secondswe'll 
get rid of a lot of complaints about timeouts.
Mike 

 

On Friday, April 24, 2020, 09:27:37 AM CDT, Bill Somerville 
 wrote:  
 
  Hi Mike, 
  OK, hold off from any Hamlib changes to rig_close for now. I will do some 
tests when I get some time and work out if WSJT-X is really calling rig_open 
twice on the same RIG handle without an intervening rig_close. I'll get back to 
you. 
  73
 Bill
 G4WJS. 
  On 24/04/2020 15:03, Black Michael via wsjt-devel wrote:
  
   I have no idea why it's treated differentlybeen that way since day#1. 
  I could add a flag to the RIG structure for "close_is_sync" that a client 
could set if it wants a synchronous close. 
  That way we wouldn't break any other apps not expecting it. 
  Mike  

  
  On Friday, April 24, 2020, 08:49:41 AM CDT, Bill Somerville 
 wrote:  
  
 On 24/04/2020 14:39, Black Michael via wsjt-devel wrote:
  
 rig_close being synchronous won't (shouldn't) matter.  The problem is that 
hamlib recovers from the timeout but when it's done WSJT-X has already timed 
out and shuts down rigctld.  And it also looks like WSJT-X starts another 
connection before closing the first one which then gives the invalid 
configuration errormaybe that's where a synchronous close would work 
betterbut it looks like the idea there was a client just tells rigctld "I'm 
done" and that's a 1-way conversation.  If we make it synchronous then the 
client has to stay around to take the answer or else we start hitting timeouts 
in rigctld.  I'm a bit reluctant to make it synchronous as I don't know what 
all the client programs are expecting. And if we make it synchronous and 
rigctld goes away then the client will be timing out trying to close it. 
  All timeouts are arbitrary but have to be based on what the hardware can do. 
. 
  Making the timeout = pollrate is arbitrary too.  If you made the polling 10ms 
everything would time out like crazy. 
  We've got a lot of rigs that just aren't very fast on CAT and 1 second is too 
short.  
  The timeouts aren't hit very often and nobody will even notice it in WSJT-X 
if there's a 3-second timeout that almost never gets triggered. What they do 
notice is WSJT-X timing out too quickly.  And the more data we ask from the 
rigs the more likely we are to hit the 1 second timeout. 
  Mike 
 
Hi Mike,
 
if WSJT-X is overlapping rig_open/rig_close calls then it should be doing it on 
a separate RIG handle, that should not cause a problem.
 
I thought the Hamlib API was synchronous, why is the rig_close call being 
treated differently, that's very confusing to me.
  
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

Re: [wsjt-devel] Flex bug

[Bill Somerville]

Hi Mike,

OK, hold off from any Hamlib changes to rig_close for now. I will do 
some tests when I get some time and work out if WSJT-X is really calling 
rig_open twice on the same RIG handle without an intervening rig_close. 
I'll get back to you.


73
Bill
G4WJS.

On 24/04/2020 15:03, Black Michael via wsjt-devel wrote:

I have no idea why it's treated differentlybeen that way since day#1.

I could add a flag to the RIG structure for "close_is_sync" that a 
client could set if it wants a synchronous close.


That way we wouldn't break any other apps not expecting it.

Mike



On Friday, April 24, 2020, 08:49:41 AM CDT, Bill Somerville 
 wrote:



On 24/04/2020 14:39, Black Michael via wsjt-devel wrote:
rig_close being synchronous won't (shouldn't) matter.  The problem is 
that hamlib recovers from the timeout but when it's done WSJT-X has 
already timed out and shuts down rigctld.  And it also looks like 
WSJT-X starts another connection before closing the first one which 
then gives the invalid configuration errormaybe that's where a 
synchronous close would work betterbut it looks like the idea 
there was a client just tells rigctld "I'm done" and that's a 1-way 
conversation.  If we make it synchronous then the client has to stay 
around to take the answer or else we start hitting timeouts in 
rigctld.  I'm a bit reluctant to make it synchronous as I don't know 
what all the client programs are expecting.
And if we make it synchronous and rigctld goes away then the client 
will be timing out trying to close it.


All timeouts are arbitrary but have to be based on what the hardware 
can do. .


Making the timeout = pollrate is arbitrary too. If you made the 
polling 10ms everything would time out like crazy.


We've got a lot of rigs that just aren't very fast on CAT and 1 
second is too short.


The timeouts aren't hit very often and nobody will even notice it in 
WSJT-X if there's a 3-second timeout that almost never gets triggered.
What they do notice is WSJT-X timing out too quickly.  And the more 
data we ask from the rigs the more likely we are to hit the 1 second 
timeout.


Mike


Hi Mike,

if WSJT-X is overlapping rig_open/rig_close calls then it should be 
doing it on a separate RIG handle, that should not cause a problem.


I thought the Hamlib API was synchronous, why is the rig_close call 
being treated differently, that's very confusing to me.


73
Bill
G4WJS.



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Flex bug

[Black Michael via wsjt-devel]

I have no idea why it's treated differentlybeen that way since day#1.
I could add a flag to the RIG structure for "close_is_sync" that a client could 
set if it wants a synchronous close.
That way we wouldn't break any other apps not expecting it.
Mike
 

On Friday, April 24, 2020, 08:49:41 AM CDT, Bill Somerville 
 wrote:  
 
  On 24/04/2020 14:39, Black Michael via wsjt-devel wrote:
  
 rig_close being synchronous won't (shouldn't) matter.  The problem is that 
hamlib recovers from the timeout but when it's done WSJT-X has already timed 
out and shuts down rigctld.  And it also looks like WSJT-X starts another 
connection before closing the first one which then gives the invalid 
configuration errormaybe that's where a synchronous close would work 
betterbut it looks like the idea there was a client just tells rigctld "I'm 
done" and that's a 1-way conversation.  If we make it synchronous then the 
client has to stay around to take the answer or else we start hitting timeouts 
in rigctld.  I'm a bit reluctant to make it synchronous as I don't know what 
all the client programs are expecting. And if we make it synchronous and 
rigctld goes away then the client will be timing out trying to close it. 
  All timeouts are arbitrary but have to be based on what the hardware can do. 
. 
  Making the timeout = pollrate is arbitrary too.  If you made the polling 10ms 
everything would time out like crazy. 
  We've got a lot of rigs that just aren't very fast on CAT and 1 second is too 
short.  
  The timeouts aren't hit very often and nobody will even notice it in WSJT-X 
if there's a 3-second timeout that almost never gets triggered. What they do 
notice is WSJT-X timing out too quickly.  And the more data we ask from the 
rigs the more likely we are to hit the 1 second timeout. 
  Mike 
 
Hi Mike,
 
if WSJT-X is overlapping rig_open/rig_close calls then it should be doing it on 
a separate RIG handle, that should not cause a problem.
 
I thought the Hamlib API was synchronous, why is the rig_close call being 
treated differently, that's very confusing to me.
 
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

Re: [wsjt-devel] Flex bug

[Bill Somerville]

On 24/04/2020 14:39, Black Michael via wsjt-devel wrote:
rig_close being synchronous won't (shouldn't) matter.  The problem is 
that hamlib recovers from the timeout but when it's done WSJT-X has 
already timed out and shuts down rigctld.  And it also looks like 
WSJT-X starts another connection before closing the first one which 
then gives the invalid configuration errormaybe that's where a 
synchronous close would work betterbut it looks like the idea 
there was a client just tells rigctld "I'm done" and that's a 1-way 
conversation.  If we make it synchronous then the client has to stay 
around to take the answer or else we start hitting timeouts in 
rigctld.  I'm a bit reluctant to make it synchronous as I don't know 
what all the client programs are expecting.
And if we make it synchronous and rigctld goes away then the client 
will be timing out trying to close it.


All timeouts are arbitrary but have to be based on what the hardware 
can do. .


Making the timeout = pollrate is arbitrary too. If you made the 
polling 10ms everything would time out like crazy.


We've got a lot of rigs that just aren't very fast on CAT and 1 second 
is too short.


The timeouts aren't hit very often and nobody will even notice it in 
WSJT-X if there's a 3-second timeout that almost never gets triggered.
What they do notice is WSJT-X timing out too quickly.  And the more 
data we ask from the rigs the more likely we are to hit the 1 second 
timeout.


Mike


Hi Mike,

if WSJT-X is overlapping rig_open/rig_close calls then it should be 
doing it on a separate RIG handle, that should not cause a problem.


I thought the Hamlib API was synchronous, why is the rig_close call 
being treated differently, that's very confusing to me.


73
Bill
G4WJS.

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Flex bug

[Black Michael via wsjt-devel]

rig_close being synchronous won't (shouldn't) matter.  The problem is that 
hamlib recovers from the timeout but when it's done WSJT-X has already timed 
out and shuts down rigctld.  And it also looks like WSJT-X starts another 
connection before closing the first one which then gives the invalid 
configuration errormaybe that's where a synchronous close would work 
betterbut it looks like the idea there was a client just tells rigctld "I'm 
done" and that's a 1-way conversation.  If we make it synchronous then the 
client has to stay around to take the answer or else we start hitting timeouts 
in rigctld.  I'm a bit reluctant to make it synchronous as I don't know what 
all the client programs are expecting.And if we make it synchronous and rigctld 
goes away then the client will be timing out trying to close it.
All timeouts are arbitrary but have to be based on what the hardware can do. .
Making the timeout = pollrate is arbitrary too.  If you made the polling 10ms 
everything would time out like crazy.
We've got a lot of rigs that just aren't very fast on CAT and 1 second is too 
short. 
The timeouts aren't hit very often and nobody will even notice it in WSJT-X if 
there's a 3-second timeout that almost never gets triggered.What they do notice 
is WSJT-X timing out too quickly.  And the more data we ask from the rigs the 
more likely we are to hit the 1 second timeout.
Mike





 

On Friday, April 24, 2020, 08:18:50 AM CDT, Bill Somerville 
 wrote:  
 
  Hi Mike, 
  I really dislike arbitrary timeouts, they make software seem unresponsive. 
  Why is rig_close() not synchronous? 
  73
 Bill
 G4WJS. 
  On 24/04/2020 14:04, Black Michael via wsjt-devel wrote:
  
   Direct control has the same problem.  And you don't need a network-based rig 
for this problem.  I duplicated it on my MK706MKIIG over serial just by turning 
the rig off, wait for the timeout, turn it back on, and retry. 
  I think this is why we keep seeing all these random errors for getting 
vfo/freq etc.it's been borderline for a long time. 
  JTDX has added getting power levels and it is popping up there a lot now due 
to the added commands. 
  The polling interval/timeout applies to any communicationso having a 
longer timeout there unrelated to polling rate would be better.  I would vote 
at least 3 seconds. 
  The longest timeout we have in hamlib right now is 10 seconds for trxmanager. 
   We have 2.5 seconds in netrigctl.c And lots of 2 second timeouts. Note that 
even those can have multiple retries and that's where the 600ms timeout in the 
Flex started being triggered during profile changes with WSJT-X timing out on 
top of it. 
  Mike 
  

  
  On Friday, April 24, 2020, 05:51:18 AM CDT, Bill Somerville 
 wrote:  
  
 Hi Mike, 
  I was think about the TCP/IP connection to the rig, the rig_close() needs to 
shutdown and close that rather than be still waiting. In that case the close 
should be processed promptly. I don't have a FlexRadio or any other network 
connected rig.
  
  Another question, what happens when rigctld is not included? I ask because 
direct control must appear to behave exactly the same as indirect control via 
rigctld, if that is not he case then there is a more serious issue there. 
  73
 Bill
 G4WJS. 
   On 24/04/2020 04:21, Black Michael via wsjt-devel wrote:
  
   Via the rigctld interface would be the "q" command getting sent by WSJT-X 
via rig_close()...but the rigctld thread would be locked by the mutex while 
it's still waiting for response from the rig. 
  But the "q" is fire-and-forget so WSJT-X could still close the port which may 
solve the problem with the invalid configuration. 
static int netrigctl_close(RIG *rig) {     rig_debug(RIG_DEBUG_VERBOSE, "%s 
called\n", __func__); 
      /* clean signoff, no read back */     write_block(>state.rigport, 
"q\n", 2); 
      return RIG_OK; } 
   Did you try and duplicate this by turning off your rig? 
  Mike 
   

  
  On Thursday, April 23, 2020, 06:49:50 PM CDT, Bill Somerville 
 wrote:  
  
 Hi Mike, 
  are we dealing with a long wait for the TCP/IP connection to close down? IIRC 
if the client end initiates the shutdown of a TCP/IP connection there should be 
minimum delay. rig_close() will have been called before rig_open() is called 
again on the same RIG handle. 
  73
 Bill
 G4WJS. 
   On 23/04/2020 22:20, Black Michael via wsjt-devel wrote:
  
   Actually I just repeated it.   Has to do with the timeout.using 
rigctldor any network-based rig. So if the rig takes too long to 
respond...then you get the timeout...the rig wakes up again...you click the 
Retry and get invalid configuration because the rig is till open. 
  You may be able to duplicate this by turning off your rig, wait for the 
timeout, and turn it back on, then click Retry. 
  de Mike W9MDB 
  
   

  
  On Thursday, April 23, 2020, 04:10:51 PM CDT, Black Michael via 
wsjt-devel  wrote:  
  
   Don't have any more 

Re: [wsjt-devel] Flex bug

[Bill Somerville]

Hi Mike,

I really dislike arbitrary timeouts, they make software seem unresponsive.

Why is rig_close() not synchronous?

73
Bill
G4WJS.

On 24/04/2020 14:04, Black Michael via wsjt-devel wrote:
Direct control has the same problem.  And you don't need a 
network-based rig for this problem.  I duplicated it on my MK706MKIIG 
over serial just by turning the rig off, wait for the timeout, turn it 
back on, and retry.


I think this is why we keep seeing all these random errors for getting 
vfo/freq etc.it's been borderline for a long time.


JTDX has added getting power levels and it is popping up there a lot 
now due to the added commands.


The polling interval/timeout applies to any communicationso having 
a longer timeout there unrelated to polling rate would be better.  I 
would vote at least 3 seconds.


The longest timeout we have in hamlib right now is 10 seconds for 
trxmanager.


We have 2.5 seconds in netrigctl.c
And lots of 2 second timeouts.
Note that even those can have multiple retries and that's where the 
600ms timeout in the Flex started being triggered during profile 
changes with WSJT-X timing out on top of it.


Mike




On Friday, April 24, 2020, 05:51:18 AM CDT, Bill Somerville 
 wrote:



Hi Mike,

I was think about the TCP/IP connection to the rig, the rig_close() 
needs to shutdown and close that rather than be still waiting. In that 
case the close should be processed promptly. I don't have a FlexRadio 
or any other network connected rig.


Another question, what happens when rigctld is not included? I ask 
because direct control must appear to behave exactly the same as 
indirect control via rigctld, if that is not he case then there is a 
more serious issue there.


73
Bill
G4WJS.

On 24/04/2020 04:21, Black Michael via wsjt-devel wrote:
Via the rigctld interface would be the "q" command getting sent by 
WSJT-X via rig_close()...but the rigctld thread would be locked by 
the mutex while it's still waiting for response from the rig.


But the "q" is fire-and-forget so WSJT-X could still close the port 
which may solve the problem with the invalid configuration.


static int netrigctl_close(RIG *rig)
{
    rig_debug(RIG_DEBUG_VERBOSE, "%s called\n", __func__);

    /* clean signoff, no read back */
write_block(>state.rigport, "q\n", 2);

    return RIG_OK;
}

Did you try and duplicate this by turning off your rig?

Mike




On Thursday, April 23, 2020, 06:49:50 PM CDT, Bill Somerville 
  wrote:



Hi Mike,

are we dealing with a long wait for the TCP/IP connection to close 
down? IIRC if the client end initiates the shutdown of a TCP/IP 
connection there should be minimum delay. rig_close() will have been 
called before rig_open() is called again on the same RIG handle.


73
Bill
G4WJS.

On 23/04/2020 22:20, Black Michael via wsjt-devel wrote:
Actually I just repeated it.   Has to do with the timeout.using 
rigctldor any network-based rig.
So if the rig takes too long to respond...then you get the 
timeout...the rig wakes up again...you click the Retry and get 
invalid configuration because the rig is till open.


You may be able to duplicate this by turning off your rig, wait for 
the timeout, and turn it back on, then click Retry.


de Mike W9MDB





On Thursday, April 23, 2020, 04:10:51 PM CDT, Black Michael via 
wsjt-devel  
 wrote:



Don't have any more details than the error message of invalid 
configuration.


I've seen it on my system too once in a while but never repeatable 
of course.


I think it may have to do with WSJT-X opening a 2nd connection 
without closing the 1st connection as I saw some of that in recent 
debug logs.


I do notice that do_start does not ensure that the rig is closed

int HamlibTransceiver::do_start ()
{
  TRACE_CAT ("HamlibTransceiver",
 QString::fromLatin1 (rig_->caps->mfg_name).trimmed ()
 << QString::fromLatin1 (rig_->caps->model_name).trimmed ());

  error_check (rig_open (rig_.data ()), tr ("opening connection to 
rig"));



Mike







On Thursday, April 23, 2020, 02:40:48 PM CDT, Bill Somerville 
  wrote:



On 23/04/2020 20:15, Black Michael via wsjt-devel wrote:
> And sometimes doing retry will give a configuration error too which
> requires a restart of WSJT-X...also undesirable.
>
> Mike

Hi Mike,

that's the first report of that, can you supply more details please?


73
Bill
G4WJS.



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Flex bug

[Black Michael via wsjt-devel]

Direct control has the same problem.  And you don't need a network-based rig 
for this problem.  I duplicated it on my MK706MKIIG over serial just by turning 
the rig off, wait for the timeout, turn it back on, and retry.
I think this is why we keep seeing all these random errors for getting vfo/freq 
etc.it's been borderline for a long time.
JTDX has added getting power levels and it is popping up there a lot now due to 
the added commands.
The polling interval/timeout applies to any communicationso having a longer 
timeout there unrelated to polling rate would be better.  I would vote at least 
3 seconds.
The longest timeout we have in hamlib right now is 10 seconds for trxmanager.
We have 2.5 seconds in netrigctl.cAnd lots of 2 second timeouts.Note that even 
those can have multiple retries and that's where the 600ms timeout in the Flex 
started being triggered during profile changes with WSJT-X timing out on top of 
it.
Mike

 

On Friday, April 24, 2020, 05:51:18 AM CDT, Bill Somerville 
 wrote:  
 
  Hi Mike, 
  I was think about the TCP/IP connection to the rig, the rig_close() needs to 
shutdown and close that rather than be still waiting. In that case the close 
should be processed promptly. I don't have a FlexRadio or any other network 
connected rig.
  
  Another question, what happens when rigctld is not included? I ask because 
direct control must appear to behave exactly the same as indirect control via 
rigctld, if that is not he case then there is a more serious issue there. 
  73
 Bill
 G4WJS. 
  On 24/04/2020 04:21, Black Michael via wsjt-devel wrote:
  
   Via the rigctld interface would be the "q" command getting sent by WSJT-X 
via rig_close()...but the rigctld thread would be locked by the mutex while 
it's still waiting for response from the rig. 
  But the "q" is fire-and-forget so WSJT-X could still close the port which may 
solve the problem with the invalid configuration. 
static int netrigctl_close(RIG *rig) {     rig_debug(RIG_DEBUG_VERBOSE, "%s 
called\n", __func__); 
      /* clean signoff, no read back */     write_block(>state.rigport, 
"q\n", 2); 
      return RIG_OK; } 
   Did you try and duplicate this by turning off your rig? 
  Mike 
   

  
  On Thursday, April 23, 2020, 06:49:50 PM CDT, Bill Somerville 
 wrote:  
  
 Hi Mike, 
  are we dealing with a long wait for the TCP/IP connection to close down? IIRC 
if the client end initiates the shutdown of a TCP/IP connection there should be 
minimum delay. rig_close() will have been called before rig_open() is called 
again on the same RIG handle. 
  73
 Bill
 G4WJS. 
   On 23/04/2020 22:20, Black Michael via wsjt-devel wrote:
  
   Actually I just repeated it.   Has to do with the timeout.using 
rigctldor any network-based rig. So if the rig takes too long to 
respond...then you get the timeout...the rig wakes up again...you click the 
Retry and get invalid configuration because the rig is till open. 
  You may be able to duplicate this by turning off your rig, wait for the 
timeout, and turn it back on, then click Retry. 
  de Mike W9MDB 
  
   

  
  On Thursday, April 23, 2020, 04:10:51 PM CDT, Black Michael via 
wsjt-devel  wrote:  
  
   Don't have any more details than the error message of invalid 
configuration. 
  I've seen it on my system too once in a while but never repeatable of course. 
  I think it may have to do with WSJT-X opening a 2nd connection without 
closing the 1st connection as I saw some of that in recent debug logs. 
  I do notice that do_start does not ensure that the rig is closed 
int HamlibTransceiver::do_start () {   TRACE_CAT ("HamlibTransceiver",      
        QString::fromLatin1 (rig_->caps->mfg_name).trimmed ()              << 
QString::fromLatin1 (rig_->caps->model_name).trimmed ()); 
    error_check (rig_open (rig_.data ()), tr ("opening connection to rig"));  
  
  Mike 
  
  
  
   

  
   On Thursday, April 23, 2020, 02:40:48 PM CDT, Bill Somerville 
 wrote:  
  
   On 23/04/2020 20:15, Black Michael via wsjt-devel wrote:
 > And sometimes doing retry will give a configuration error too which 
 > requires a restart of WSJT-X...also undesirable.
 >
 > Mike
 
 Hi Mike,
 
 that's the first report of that, can you supply more details please? 
 
 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

Re: [wsjt-devel] Flex bug

[Bill Somerville]

Hi Mike,

I was think about the TCP/IP connection to the rig, the rig_close() 
needs to shutdown and close that rather than be still waiting. In that 
case the close should be processed promptly. I don't have a FlexRadio or 
any other network connected rig.


Another question, what happens when rigctld is not included? I ask 
because direct control must appear to behave exactly the same as 
indirect control via rigctld, if that is not he case then there is a 
more serious issue there.


73
Bill
G4WJS.

On 24/04/2020 04:21, Black Michael via wsjt-devel wrote:
Via the rigctld interface would be the "q" command getting sent by 
WSJT-X via rig_close()...but the rigctld thread would be locked by the 
mutex while it's still waiting for response from the rig.


But the "q" is fire-and-forget so WSJT-X could still close the port 
which may solve the problem with the invalid configuration.


static int netrigctl_close(RIG *rig)
{
    rig_debug(RIG_DEBUG_VERBOSE, "%s called\n", __func__);

    /* clean signoff, no read back */
    write_block(>state.rigport, "q\n", 2);

    return RIG_OK;
}

Did you try and duplicate this by turning off your rig?

Mike




On Thursday, April 23, 2020, 06:49:50 PM CDT, Bill Somerville 
 wrote:



Hi Mike,

are we dealing with a long wait for the TCP/IP connection to close 
down? IIRC if the client end initiates the shutdown of a TCP/IP 
connection there should be minimum delay. rig_close() will have been 
called before rig_open() is called again on the same RIG handle.


73
Bill
G4WJS.

On 23/04/2020 22:20, Black Michael via wsjt-devel wrote:
Actually I just repeated it.  Has to do with the timeout.using 
rigctldor any network-based rig.
So if the rig takes too long to respond...then you get the 
timeout...the rig wakes up again...you click the Retry and get 
invalid configuration because the rig is till open.


You may be able to duplicate this by turning off your rig, wait for 
the timeout, and turn it back on, then click Retry.


de Mike W9MDB





On Thursday, April 23, 2020, 04:10:51 PM CDT, Black Michael via 
wsjt-devel  
 wrote:



Don't have any more details than the error message of invalid 
configuration.


I've seen it on my system too once in a while but never repeatable of 
course.


I think it may have to do with WSJT-X opening a 2nd connection 
without closing the 1st connection as I saw some of that in recent 
debug logs.


I do notice that do_start does not ensure that the rig is closed

int HamlibTransceiver::do_start ()
{
  TRACE_CAT ("HamlibTransceiver",
 QString::fromLatin1 (rig_->caps->mfg_name).trimmed ()
             << QString::fromLatin1 (rig_->caps->model_name).trimmed ());

  error_check (rig_open (rig_.data ()), tr ("opening connection to 
rig"));



Mike







On Thursday, April 23, 2020, 02:40:48 PM CDT, Bill Somerville 
  wrote:



On 23/04/2020 20:15, Black Michael via wsjt-devel wrote:
> And sometimes doing retry will give a configuration error too which
> requires a restart of WSJT-X...also undesirable.
>
> Mike

Hi Mike,

that's the first report of that, can you supply more details please?


73
Bill
G4WJS.





___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Flex bug

[Black Michael via wsjt-devel]

Via the rigctld interface would be the "q" command getting sent by WSJT-X via 
rig_close()...but the rigctld thread would be locked by the mutex while it's 
still waiting for response from the rig.
But the "q" is fire-and-forget so WSJT-X could still close the port which may 
solve the problem with the invalid configuration.
static int netrigctl_close(RIG *rig){    rig_debug(RIG_DEBUG_VERBOSE, "%s 
called\n", __func__);
    /* clean signoff, no read back */    write_block(>state.rigport, 
"q\n", 2);
    return RIG_OK;}
Did you try and duplicate this by turning off your rig?
Mike

 

On Thursday, April 23, 2020, 06:49:50 PM CDT, Bill Somerville 
 wrote:  
 
  Hi Mike, 
  are we dealing with a long wait for the TCP/IP connection to close down? IIRC 
if the client end initiates the shutdown of a TCP/IP connection there should be 
minimum delay. rig_close() will have been called before rig_open() is called 
again on the same RIG handle. 
  73
 Bill
 G4WJS. 
  On 23/04/2020 22:20, Black Michael via wsjt-devel wrote:
  
   Actually I just repeated it.   Has to do with the timeout.using 
rigctldor any network-based rig. So if the rig takes too long to 
respond...then you get the timeout...the rig wakes up again...you click the 
Retry and get invalid configuration because the rig is till open. 
  You may be able to duplicate this by turning off your rig, wait for the 
timeout, and turn it back on, then click Retry. 
  de Mike W9MDB 
  
   

  
  On Thursday, April 23, 2020, 04:10:51 PM CDT, Black Michael via 
wsjt-devel  wrote:  
  
   Don't have any more details than the error message of invalid 
configuration. 
  I've seen it on my system too once in a while but never repeatable of course. 
  I think it may have to do with WSJT-X opening a 2nd connection without 
closing the 1st connection as I saw some of that in recent debug logs. 
  I do notice that do_start does not ensure that the rig is closed 
int HamlibTransceiver::do_start () {   TRACE_CAT ("HamlibTransceiver",      
        QString::fromLatin1 (rig_->caps->mfg_name).trimmed ()              << 
QString::fromLatin1 (rig_->caps->model_name).trimmed ()); 
    error_check (rig_open (rig_.data ()), tr ("opening connection to rig"));  
  
  Mike 
  
  
  
   

  
   On Thursday, April 23, 2020, 02:40:48 PM CDT, Bill Somerville 
 wrote:  
  
   On 23/04/2020 20:15, Black Michael via wsjt-devel wrote:
 > And sometimes doing retry will give a configuration error too which 
 > requires a restart of WSJT-X...also undesirable.
 >
 > Mike
 
 Hi Mike,
 
 that's the first report of that, can you supply more details please? 
 
 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

Re: [wsjt-devel] Flex bug

[Bill Somerville]

Hi Mike,

are we dealing with a long wait for the TCP/IP connection to close down? 
IIRC if the client end initiates the shutdown of a TCP/IP connection 
there should be minimum delay. rig_close() will have been called before 
rig_open() is called again on the same RIG handle.


73
Bill
G4WJS.

On 23/04/2020 22:20, Black Michael via wsjt-devel wrote:
Actually I just repeated it.   Has to do with the timeout.using 
rigctldor any network-based rig.
So if the rig takes too long to respond...then you get the 
timeout...the rig wakes up again...you click the Retry and get invalid 
configuration because the rig is till open.


You may be able to duplicate this by turning off your rig, wait for 
the timeout, and turn it back on, then click Retry.


de Mike W9MDB





On Thursday, April 23, 2020, 04:10:51 PM CDT, Black Michael via 
wsjt-devel  wrote:



Don't have any more details than the error message of invalid 
configuration.


I've seen it on my system too once in a while but never repeatable of 
course.


I think it may have to do with WSJT-X opening a 2nd connection without 
closing the 1st connection as I saw some of that in recent debug logs.


I do notice that do_start does not ensure that the rig is closed

int HamlibTransceiver::do_start ()
{
  TRACE_CAT ("HamlibTransceiver",
             QString::fromLatin1 (rig_->caps->mfg_name).trimmed ()
             << QString::fromLatin1 (rig_->caps->model_name).trimmed ());

  error_check (rig_open (rig_.data ()), tr ("opening connection to rig"));


Mike







On Thursday, April 23, 2020, 02:40:48 PM CDT, Bill Somerville 
 wrote:



On 23/04/2020 20:15, Black Michael via wsjt-devel wrote:
> And sometimes doing retry will give a configuration error too which
> requires a restart of WSJT-X...also undesirable.
>
> Mike

Hi Mike,

that's the first report of that, can you supply more details please?


73
Bill
G4WJS.



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Flex bug

[Black Michael via wsjt-devel]

Actually I just repeated it.   Has to do with the timeout.using 
rigctldor any network-based rig.So if the rig takes too long to 
respond...then you get the timeout...the rig wakes up again...you click the 
Retry and get invalid configuration because the rig is till open.
You may be able to duplicate this by turning off your rig, wait for the 
timeout, and turn it back on, then click Retry.
de Mike W9MDB


 

On Thursday, April 23, 2020, 04:10:51 PM CDT, Black Michael via wsjt-devel 
 wrote:  
 
 Don't have any more details than the error message of invalid configuration.
I've seen it on my system too once in a while but never repeatable of course.
I think it may have to do with WSJT-X opening a 2nd connection without closing 
the 1st connection as I saw some of that in recent debug logs.
I do notice that do_start does not ensure that the rig is closed
int HamlibTransceiver::do_start (){  TRACE_CAT ("HamlibTransceiver",            
 QString::fromLatin1 (rig_->caps->mfg_name).trimmed ()             << 
QString::fromLatin1 (rig_->caps->model_name).trimmed ());
  error_check (rig_open (rig_.data ()), tr ("opening connection to rig"));

Mike




 

On Thursday, April 23, 2020, 02:40:48 PM CDT, Bill Somerville 
 wrote:  
 
 On 23/04/2020 20:15, Black Michael via wsjt-devel wrote:
> And sometimes doing retry will give a configuration error too which 
> requires a restart of WSJT-X...also undesirable.
>
> Mike

Hi Mike,

that's the first report of that, can you supply more details please?

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
  ___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Flex bug

[Black Michael via wsjt-devel]

Don't have any more details than the error message of invalid configuration.
I've seen it on my system too once in a while but never repeatable of course.
I think it may have to do with WSJT-X opening a 2nd connection without closing 
the 1st connection as I saw some of that in recent debug logs.
I do notice that do_start does not ensure that the rig is closed
int HamlibTransceiver::do_start (){  TRACE_CAT ("HamlibTransceiver",            
 QString::fromLatin1 (rig_->caps->mfg_name).trimmed ()             << 
QString::fromLatin1 (rig_->caps->model_name).trimmed ());
  error_check (rig_open (rig_.data ()), tr ("opening connection to rig"));

Mike




 

On Thursday, April 23, 2020, 02:40:48 PM CDT, Bill Somerville 
 wrote:  
 
 On 23/04/2020 20:15, Black Michael via wsjt-devel wrote:
> And sometimes doing retry will give a configuration error too which 
> requires a restart of WSJT-X...also undesirable.
>
> Mike

Hi Mike,

that's the first report of that, can you supply more details please?

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

Re: [wsjt-devel] Flex bug

[Bill Barrett]

George-
I have a 6700 and do "8 panadapter" profile switches. That many
panaadapters take a while to switch.
It not a network issue.

On Thu, Apr 23, 2020 at 2:34 PM George J Molnar  wrote:

> I do not experience this issue when switching profiles. Profile switches
> are also much quicker than the 3 seconds reported. Suggest that Mike’s case
> may include a user network issue.
>
> Flex 6600, Mac OS Catalina. WSJT-X 2.1.2
>
> *George J Molnar*
> Arlington, Virginia, USA
> (702) 767-5420
> KF2T   -   FM18lu
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Apr 23, 2020, at 2:08 PM, Bill Somerville 
> 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
>   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_rateneed 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 secondit 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
>   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 userschange 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
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Flex bug

[Bill Somerville]

On 23/04/2020 20:15, Black Michael via wsjt-devel wrote:
And sometimes doing retry will give a configuration error too which 
requires a restart of WSJT-X...also undesirable.


Mike


Hi Mike,

that's the first report of that, can you supply more details please?

73
Bill
G4WJS.



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Flex bug

[Black Michael via wsjt-devel]

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 
 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 
 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_rateneed 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 secondit 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 
 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 userschange 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

Re: [wsjt-devel] Flex bug

[George J Molnar]

I do not experience this issue when switching profiles. Profile switches are 
also much quicker than the 3 seconds reported. Suggest that Mike’s case may 
include a user network issue.

Flex 6600, Mac OS Catalina. WSJT-X 2.1.2

George J Molnar
Arlington, Virginia, USA
(702) 767-5420
KF2T   -   FM18lu














> On Apr 23, 2020, at 2:08 PM, Bill Somerville  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 
>>   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_rateneed 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 secondit 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 
>>>   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 userschange 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

Re: [wsjt-devel] Flex bug

[Bill Somerville]

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 
 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_rateneed 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 secondit 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 
  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 userschange 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

Re: [wsjt-devel] Flex bug

[Black Michael via wsjt-devel]

Yes

 

On Thursday, April 23, 2020, 12:19:11 PM CDT, Bill Somerville 
 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_rateneed 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 secondit 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 
 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 userschange 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

Re: [wsjt-devel] Flex bug

[Bill Somerville]

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_rateneed 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 secondit 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 
 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 userschange 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

Re: [wsjt-devel] Flex bug

[Black Michael via wsjt-devel]

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_rateneed 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 secondit 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 
 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 userschange 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

Re: [wsjt-devel] Flex bug

[Bill Somerville]

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 userschange 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