First of all, no, the cause is not clock error.
I have found the "proximate" cause, however, after weeks of hunting. I
worked with W9MDB and tested/considered many potential causes. I even
thought I had found it several times. In all those cases there was a
confounding variable, which I have now
Hi Hasan,
An interesting observation! What if you uncheck the boxed “Color Band
Activity…” and/or “Highlight Band Activity…”? Is the error still there or is it
gone?
I had in the past also some (other) troubles with JTAlert, but it turned out
that some files on my computer must
Hasan,
Try this:
On wsjtx go to settings, General. Make sure
'Start new period decodes at top' is not ticked.
Bobby/N4AU
On 7/30/2019 7:26 AM, Hasan al-Basri
wrote:
Uwe,
I just
changed both those
What do you have for the soundcard setting in JTAlert and WSJT-X?
On Tuesday, July 30, 2019, 07:30:17 AM CDT, Hasan al-Basri
wrote:
Uwe,I just changed both those settings you recommended. Now, I'll have to
wait, up to a couple days to see if it accomplished anything.
Unfortunately
Hi Mike
Never. The monitor (Hi-Sense TV) is on until I go to bed, then I turn the
TV off. Ever since I found out that there was a JTA > X interaction that
was causing the problem, I have looked carefully in the morning when I come
down to the shack to see if X is still decoding...and it is,
Totally different sound cards. JTA uses my HDMI monitor seen as an Nvidia,
X uses my USB sound dongle. I've changed dongles, ...no difference. I've
chased the sound card potential issue from several angles...that's not it.
...and Windows system uses the internal sound card of the computer.
Hasan
Joe (and the team),
First, the last (new) rev of WSJT-X is WAY FASTER to decode a busy band. THANK
YOU!
My suggestion: Because I made thousands of FT8 contacts (especially on 20m, 30m
and 40m), a huge amount of the CQ decodes on a busy band are GREEN (confirmed
QSO for call/band/etc). Even
When it happens again do the WWV recording with Audacity and note the time you
shut down JTAlert in the recording time indication.It has to be doing something
to the sound recording --
Having both the Audacity and WAV files would be of use.
On Tuesday, July 30, 2019, 08:21:29 AM CDT,
Uwe,
I just changed both those settings you recommended. Now, I'll have to wait,
up to a couple days to see if it accomplished anything.
Unfortunately the onset of the problem is random, and can take 2 or 3 days
or only a few hours. Curing it is easy. I'll report back as I'm watching
it. For sure
Does your monitor go to sleep? JTAlert should only be hooking up to the
playback device so not sure how it could affect recording. Possible that the
JTAlert package does passively hook up to recording...that would explain why a
restart might have an effect on recordingperhaps changing the
Bobby,
That has always been my setting. (not checked)
tnx, 73, N0AN
Hasan
On Tue, Jul 30, 2019 at 8:03 AM Bobby Chandler wrote:
> Hasan,
>
> Try this:
>
> On wsjtx go to settings, General. Make sure 'Start new period decodes at
> top' is not ticked.
>
> Bobby/N4AU
> On 7/30/2019 7:26 AM, Hasan
( wsjt-x 2.1.0(32 or 64), JtAlert 2.14.1, DXKeeper 15.0.0, wint10 1903 )
There appears to be an interaction of wsjt, JTAlert and DXKeeper that
causes WSJT(ft4/8) to miss a decode cycle after a contact is logger.
JTAlert is configured to log contacts to DXK rather than WSJT direct to DXK.
1)
I'll soon be upgrading my Debian 9.x to 10.0 Buster. And while it's possible
to perform an in-place upgrade I usually take the opportunity to replace the
hard drive and do a fresh install entirely. I've been compiling WSJT-X for
awhile now and have had no problems doing so.
But I've got a
Ok, I'll look at another way to close it.
Tnx tip, 73, N0AN
Hasan
On Tue, Jul 30, 2019 at 3:53 PM Laurie, VK3AMA <_vk3a...@vkdxer.net> wrote:
>
> On 31/07/2019 2:03 am, Hasan al-Basri wrote:
>
> Put this in a batch file: (use notepad to create)
>
> taskkill /F /IM jtalert.exe
>
>
> NO, don't do
On 30/07/2019 20:21, Paul Bramscher wrote:
But I've got a general question with ~/.local/share/WSJT-X. What are
the minimally useful files to copy over, to preserve settings and
logs? The entire directory (except the contents of 'save') -- or is
there a smaller subset?
Hi Paul,
I would
On 31/07/2019 2:03 am, Hasan al-Basri wrote:
Put this in a batch file: (use notepad to create)
taskkill /F /IM jtalert.exe
NO, don't do this!
Force killing the JTAlert process, rather than a managed shutdown,
*doesn't close any of the JTAlert plugin processes or the Decodes
History
Laurie,
How about this then:
taskkill /IM /T jtalert.exe
That is supposed to not forcefully terminate but issue a WM_CLOSE followed
by telling any Child Process started by the JTA program to also close.
Is that safe? Or what is the proper command line to tell JTALERT.EXE to
close "properly" ?
Since I'm replacing this AMD computer with an Intel Core I5 in a short
while, I don't want to invest a ton of time chasing down this problem if it
only affects me and a couple others. It will go away when I change
computers, as I have this same combo running on another machine with no
issues.
In
I am receiving confirmations via eQSL of qsos in FT4 mode, but they
indicate that the working mode is MFSK (FT4) or only MFSK.
In the Log40M guard book, the qsos are listed as FT4 in mode.
I have reviewed the instructions of FT4, FT8 on the WSJT-X website and
cannot find references to MFSK or MFSK
On 7/30/19 5:57 PM, Jesús Gutiérrez Rodríguez wrote:
Hi Jesús and all,
I am receiving confirmations via eQSL of qsos in FT4 mode, but they
indicate that the working mode is MFSK (FT4) or only MFSK.
In a vote, 14 voting members of the ADIF development group have approved
the proposal,
20 matches
Mail list logo
