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 the width of what we decode to 40kHz instead of 5kHz. But you
would still have to have some logic for CAT control of each slice.
Can the Flex present a mixed audio channel like that? Or add an audio offset to
each channel so they can be mixed?
I could also imagine a new Configuration tab for more audio channels and cat
control for each. This would also imply multiple jt9.exe processes. Would we
need a waterfall for each slice do you think?
The advantage I can see compared to what we have now is you would only need one
instance of WSJT-X, with maybe 8 waterfalls so a lot less screen real estate.
Then we need to add band to the Band Activity decodes.
Sounds interesting....
de Mike W9MDB
On Thursday, February 7, 2019, 5:56:58 AM CST, Stephen Hicks
<st...@flexradio.com> 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 this seemed like a logical recommendation and it seems to work well.
Without knowing a lot about WSJT internals, my recommendation would be to do
the same thing for the FlexRadio setting as you do for the Kenwood setting or
write directly to the SmartSDR API (TCP/IP and possibly UDP/IP for audio).
I do understand the objection to writing to the SmartSDR API which is generally
given (don’t want to write to a protocol for one specific rig manufacturer) but
the hope is that eventually one of the WSJT developers or ourselves will have
the time to write to the API because of what it could buy — the ability to
watch and decode many bands at once and without all the complicated setup
outside WSJT. Our customers often do this with WSJT now (decode many receivers
at once), but it’s complicated to setup. A CAT port has to be created for each
of up to 8 receivers in the radio, a separate directory for the wave storage
for each receiver and a DAX receive channel (virtual sound card) for each
receiver.
Please don’t take the above as criticism. The WSJT software is terrific and I
use it often as do our customers. Just like my customers do with me, I dream
of more without always acknowledging the work involved and thanking those that
tirelessly provide it. So please understand I respect and thank everyone here
for both your skills and the effort you put into the project.
73,Steve
On Wed, Feb 6, 2019 at 23:39 Black Michael via wsjt-devel
<wsjt-devel@lists.sourceforge.net> 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
On Wednesday, February 6, 2019, 6:14:13 PM CST, Bill Somerville
<g4...@classdesign.com> wrote:
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]:
IF000070740000010+0000000000090000000;
2019-02-06 14:28:35.788 TCP 26001 [rcvd]: TX;
2019-02-06 14:28:35.790 TCP 26001 [rcvd]: ID;
2019-02-06 14:28:35.791 TCP 26001 [sent]: ID909;
2019-02-06 14:28:36.646 TCP 26001 [rcvd]: RX;
2019-02-06 14:28:36.647 TCP 26001 [rcvd]: ID;
2019-02-06 14:28:37.246 TCP 26001 [rcvd]: RX;
2019-02-06 14:28:37.246 TCP 26001 [rcvd]: ID;
2019-02-06 14:28:37.717 TCP 26001 [sent]: ID909;
2019-02-06 14:28:37.718 TCP 26001 [sent]: ID909;
At this point the only recourse is to kill WSJT-X with the task manager and
restart. I a normal situation the ID; following the first RX, receives an
ID909; response in 100msec and the second RX is not sent.
AL, K0VM
Hi Al,
that's interesting and surprising. The whole point of the ID commands is to
know that the "rig" has completed the prior command. Because the Kenwood style
CAT protocol that is used by SmartSDR, Elecraft and Yaesu as well these days,
has no acknowledgement of set commands; we have no way of telling when it is
safe to send another command. The ID command is used because it is very fast
and changes nothing at the rig, it is effectively a no-op with an
acknowledgement for when the prior command has been processed.
Hard to say without a trace from WSJT-X, but I would guess that the RX command
is taking some time and the timeout is too short so it is being retried.
So I have to wonder why SSDR and the Flex are taking more than one second to
respond to the command sequence "RX;ID;", that's glacial!
You can temporarily adjust the Hamlib timeout by creating a text file in the
WSJT-X log files directory ("Menu->File->Open log file directory") called
hamlib_settings.json and put the following into it:
{
"config": {
"timeout": "2000"
}
}
That will adjust the command timeout to 2 seconds (the default command timeout
for the Flex6xxx driver is 600 mS). Please give it a try and see if that stops
the hang up problem?
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
--
Stephen Hicks, N5ACVP Engineering / CTO
FlexRadio Systems™
4616 W Howard Ln Ste 1-150
Austin, TX 78728
Phone: 512-535-4713 x205
Email: st...@flexradio.com
Web: www.flexradio.com
Tune In Excitement™
PowerSDR™ and SmartSDR™ are trademarks of FlexRadio Systems _______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
