On 07/02/2019 04:36, Black Michael via wsjt-devel wrote:
There's actually another problem going on.
I worked with Al a bit this afternoon using rigctld.
Al is the 2nd person I'm working with on the same problem....after
this sequence hamlib just loops around the network_flush() routine and
never returns from it causing WSJT-X to lock up.
So I'm making some debug info to track it down....hopefully have
something figured out tomorrow since Al can reproduce this easily.
This is apparently a common complaint from the Flex users between
lockups and crashes using the flex6xxx backend.
de Mike W9MDB
Hi Mike,
RR I had seen your changes related to the low level network code in
Hamlib. I would not be surprised at any misbehaviour resulting from a
communications failure, handling this on a TCP connection is always
tricky as long delays (~30 seconds) are necessary to allow for transient
conditions but those are often unacceptable for the use cases being handled.
What is certain is that if SSDR and a Flex radio are likely to take over
a second to process some CAT commands then the Hamlib timeout for that
model needs to be that long and more. Whether a 1 second delay on a CAT
command is acceptable for a mode like FT8 is doubtful. It would be
interesting to know if the same happens when an RX command is sent
without TX inhibit, which is after all an artificial test case, and if
it really does take that long to return to receive from transmit
whether the receiver gets up and running quickly or is delayed as well.
73
Bill
G4WJS.
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
