I can reproduce this problem. This appears to be a bug in SmartSDR. When
sending TX, then RX with transmit inhibited SmartSDR has a long delay in
responding causing a timeout.
This sequence using rigctld-wsjtx with TX Inhibit causes the Flex to respond
slowly at the "T 0" command.It appears
Mike,
See below --
On Thu, Feb 7, 2019 at 8:24 AM Black Michael wrote:
> We will get the Flex to behave with TCP/IP -- give me a couple of days
> since we now have a way to duplicate the problem.
>
Much appreciated!
>
> Trying to modify WSJT-X to use multiple slices would be non-trivial to
We will get the Flex to behave with TCP/IP -- give me a couple of days since we
now have a way to duplicate the problem.
Trying to modify WSJT-X to use multiple slices would be non-trivial to say the
least. The easy way would be if one could just present a 5kHz*8 audio channel
and just expand
On 07/02/2019 11:56, Stephen Hicks wrote:
Good Morning —
I’m not sure if it’s the right thing to do, but we generally just tell
our customers to use TS-2000 for the rig setting in WSJT because the
FLEX setting has been unreliable. Our CAT protocol is modeled after
the Kenwood command set so
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
Good Morning —
I’m not sure if it’s the right thing to do, but we generally just tell our
customers to use TS-2000 for the rig setting in WSJT because the FLEX
setting has been unreliable. Our CAT protocol is modeled after the Kenwood
command set so this seemed like a logical recommendation and
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 problemafter
this sequence hamlib just loops around the network_flush() routine and
On 06/02/2019 20:51, Al wrote:
This is from the SSDR CAT log for the TCP port leading up to the
event with TX inhibited..
19-02-06 14:28:05.123 TCP 26001 [sent]: ZZFI01;
2019-02-06 14:28:05.123 TCP 26001 [rcvd]: IF;
2019-02-06 14:28:05.125 TCP 26001 [sent]:
This has been reported before ... Maybe you've already fixed it;
If WSJT-X is configured to use the FlexRadio 6xxx rig interface method
then at random intervals WSJT-X will cease to function correctly.
Various different features cease to work each time and the CPU usage
will increase to about
