Yeah...Al is a beta tester for Flex so perhaps ask them about this. We just
have to get enough information to give Flex something to work with.
My other Flex user that I'm working with sees this same network_flush loop but
it only happens to him once every couple of hours. So it may be a stacked
problem. We have to get network_flush behaving correctly (it appears it always
returns some value in "len" but it never gets read). Once we figure that out
that will let WSJT-X continue running so we can see the behavior.
I use the FLRig interface which is also network based so uses this same logic
path and never have any problems. It's just the Flex users where this is
happening. So TX inhibit is just a way to cause the lockup to occur. When
that's disabled it runs OK (for a while).
Mike
On Thursday, February 7, 2019, 6:09:02 AM CST, Bill Somerville
<[email protected]> wrote:
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
_______________________________________________
wsjt-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
