Mike,
See below --
On Thu, Feb 7, 2019 at 8:24 AM Black Michael <mdblac...@yahoo.com> 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 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.
>
I was personally motivated to look into modifying WSJT before FT8 came
along and took the world by storm. I just have been busy and only had
enough time to open up the source, take a quick look and say "this looks
like it might be involved." With FT8, it's no longer just me and our
company is very interested in seeing if we can find a path to a WSJT
something like what I described. We haven't found the right solution yet,
but have considered even compensating someone financially to help with this
project. If it looks like the best way to go is to have multiple audio
channels mixed together into a single passband, we could certainly discuss
that. If there's some interest in looking for a path, we'd be interested
in having the discussion and making sure everyone agrees with the design
path before committing any resources. Probably not terribly important, be
the radio can already send about 20kHz of bandwidth off each receiver for
decode (or up to 192ksps if we went with IQ output), but the operation on
the bands is generally limited to a bandwidth supported by most rigs. I do
think this capability is probably less important than multi-band, but I
could be wrong.
>
> Can the Flex present a mixed audio channel like that? Or add an audio
> offset to each channel so they can be mixed?
>
We could certainly allow each to be tuned with an offset and provide a
passband that would be commensurate with the offset. For example, you
could tune to 14.076 on one receiver and 7.072 on the next, but set the 40m
filter to 4-7kHz , capturing the right subband, but having it offset so all
the bands could be mixed together. Our current limit would be about 20kHz
audio frequency, but this would provide up to four 5kHz bands or six 3kHz
bands. With sharp filters, we probably don't have to provide much of a
transition band.
>
> 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?
>
This question is probably best suited for a plurality of users rather than
just me. I really only use the waterfall for setup and debug. Once I'm
running, I mostly look at the text output. I guess I do look to see the
relative strength of signals in my channel occasionally, but I don't feel
like it's a "must have." Well, I make take this back -- the other real
reason is when you want to call CQ to find an open spot in the band. Could
it be setup where multiple bands are run, but only one shows up in the
waterfall? Thinking out loud here...
>
> 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....
>
Thanks for considering this. I really think it could be a killer operating
setup which is what really drives me to think about it.
>
> de Mike W9MDB
>
>
> 73,
Steve
>
>
>
> 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, N5AC
> VP 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
>
--
Stephen Hicks, N5AC
VP 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
