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

Reply via email to