l be here:
> ~/.local/share/WSJT-X
>
>
> For MacOS put it in
> /Users/[username]/Library/Preferences
>
> Restart WSJT-X and duplicate the problem.
> Shut down WSJT-X
>
>
> Then send me the WSJT-X_RigControl.log file
> Mike W9MDB
>
>
> Mike W9MDB
&
Richard,
Also check the mode the TX VFO is using to make sure it's actually DATA.
My FT-891 is a similar radio and more than once when running true split,
VFO B / TX has been in SSB mode while VFO A / RX was in DATA mode.
If the problem goes away running with split set to None as Reino suggested,
t
[reposting to the original thread; didn't realize it had split]
Intel provides tools to do the feature identification for you. See:
https://www.intel.com/content/www/us/en/support/articles/05607/boards-and-kits/desktop-boards.html
The Intel processor identification utility provides the infor
Intel provides tools to do the feature identification for you. See:
https://www.intel.com/content/www/us/en/support/articles/05607/boards-and-kits/desktop-boards.html
The Intel processor identification utility provides the information
directly. (I believe this is windows only, but didn't dig
On Tue, Oct 15, 2019 at 12:07 PM Bill Somerville
wrote:
>
> Hi Mike,
>
> clients must discover the server they talk to somehow. For example web
> servers are discovered via hypertext links or by typing a web server
> address and port number into the client user interface of the client web
> brows
On Tue, Oct 15, 2019 at 9:34 AM Black Michael via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:
>
> NetworkMessage.hpp -- several places. Though after reading some more
descriptions it does seem to free flow back and forth as to who is client
and who is server. The message aggregator is r
Thanks, Bill,
This is the enlightenment I needed. I'll make it a point to implement
multicast support correctly.
mike, kj6vcp
On Tue, Oct 15, 2019 at 7:38 AM Bill Somerville
wrote:
>
> Hi Mike,
>
> the terminology of client and server are somewhat loose in UDP protocols
> but with the WSJT-X
I've been playing around with the UDP server capability in wsjt-x, and I
think I've got most of the lower level details figured out. However, I got
blocked on the schema negotiation part, which raised a deeper question.
I have been assuming wsjt-x is a server, and my code is a client. So I
sent
I won't be moving to Fedora 28 until after Field Day at the earliest.
I have too many dependencies to make it a simple process. I may poke
around before then to see what I find.
mike
--
Check out the vibrant tech communi
I'm not running this config, but I have Fedora 27 with 1.8. I recommend
poking around in the pule audio mixer (pavucontrol)
Pulse remembers the setting for individual applications - the version
change may have caused it to treat wsjt as a 'new' application, and forget
all you're carefully tweak
Thanks to all for the help and suggestions.
The fedora build with an executable stack resolves the jt9 crashes.
mike, kj6vcp
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdo
[ resend - mailman rejected the zipped attachments, so I forwarded
them directly to Bill. ]
On Fri, Jan 19, 2018 at 5:40 AM, Michael Pittaro wrote:
> Here are some sample .wav files and my config file.
>
> All my ft8 samples crash with with a SIGSEGV, but only some of the
> JT
Hi, Bill,
My issue with the WSJT project rpm mysteriously 'went away'. jt9
definitely crashed intermittently on the first few decodes while I was
setting up and twiddling things, but I don't have the core files or
any notes on what what going on at the time. I don't like heisenbugs,
but after th
Here's the read elf result on my machine with the original build I
reported the problem with - the stack is not marked executable. Also,
selinux is in permissive mode, and it's kernel 4.14.8-300.fc27.x86_64
[mikeyp@microhertz ft8_samples]$ readelf -lW `which jt9` | grep GNU_STACK
GNU_STACK
OK - this all gives me some ideas to run with.
rpmlint is warning about the executable stack, but I don't think
anything is enforcing it. Also, I expect a general protection fault
rather than a segmentation violation if the stack is not executable.
I'll check binaries here, and see if I can get
I'm seeing a fairly consistent failure where jt9 crashes when it's
started by wsjt-x on Fedora 27.
The crash happens right after decode starts. It's somewhat
intermittent - it seems to always happen in ft8 mode, but also
sometimes in jt9 and jt65+jt9 mode.In general, it crashes on the
first
16 matches
Mail list logo
