|
Kenwood TS-590sg, not using internal tuner. Only using the MFJ-998RT in the shack, 1500w autotuner.
On Fri, Sep 10, 2021 at 3:29 AM Bill Somerville < g4wjs@...> wrote:
Hi Hasan,
which rig are you using? Are you using
an auto-ATU built into your rig?
73
Bill
G4WJS.
On 08/09/2021 21:22, Hasan Schiers N0AN
wrote:
Also RC6
here, although downloaded a few days ago. I think there was a
hamlib fix since then, but have not downloaded since very
early RC6.
73, N0AN
On Wed, Sep 8, 2021 at 11:21
AM Bill Somerville < g4wjs@...> wrote:
Hi Hasan,
Steve, K9AN, and I are running WSPR band-hopping with a
variety of bands set for Tune and Rx only. Neither of us
are seeing this issue so far. I am using the latest 2.5.0
RC6 version.
73
Bill
G4WJS.
On 08/09/2021 15:00, Hasan Schiers N0AN wrote:
No,
no errors at all, see an occasional audio stream
error, nothing else
On Wed, Sep 8, 2021 at
8:20 AM Bill Somerville < g4wjs@...>
wrote:
Hi Hasan,
are there any Hamlib error messages in the
WJST-X wsjtx_syslog.log file that correlate with
the time of the issue?
73
Bill
G4WJS.
On 08/09/2021 01:09, Hasan Schiers N0AN wrote:
Bill,
I found the
correlation I was looking for.
If I tell WSPR
Schedule to use the TUNE function (to make the
autotuner adjust the antenna SWR on each band
prior to transmitting), the ENABLE Tx light
goes out in short order (next transmission or
so).
If I uncheck the boxes
on each band for Tune, and let the transmit
signal itself actuate the auto-tuner,
everything works normally.
In reality, the TUNE
function in the Scheduler is redundant,
because the autotuner itself will auto-tune
when RF is sent to it anyway, there is no need
to 'pre-tune' things.
However, what I am
reporting is undesirable and probably should
be fixed, if it's a real malfunction.
73, N0AN
On Sat, Sep 4,
2021 at 12:21 PM Bill Somerville < g4wjs@...>
wrote:
On 04/09/2021 13:34, Hasan Schiers N0AN
wrote:
WSJT-X 2.5.0
RC5
Mode WSPR
Issue:
When in Band
Hopping Mode, with a proper
schedule, the Enable Transmit button
randomly goes dark and never lights
up again.
This results
in hours and hours of listening
overnight with no transmitting.
Is there an
order effect or something that would
cause this in terms of setup? It
used to work perfectly with
identical settings many versions
ago.
Anyone else
seen this?
TIA, 73,
N0AN
Hi Hasan,
that behaviour may be caused by a CAT
error. Have a look in the wsjtx_syslog.log
file (in the WSJT-X log files directory)
for any Hamlib error messages around the
time that the "Enable Tx" button resets.
73
Bill
G4WJS.
|
|
|
Bill Somerville
Hi Hasan,
which rig are you using? Are you using
an auto-ATU built into your rig?
73
Bill
G4WJS.
On 08/09/2021 21:22, Hasan Schiers N0AN
wrote:
toggle quoted message
Show quoted text
Also RC6
here, although downloaded a few days ago. I think there was a
hamlib fix since then, but have not downloaded since very
early RC6.
73, N0AN
On Wed, Sep 8, 2021 at 11:21
AM Bill Somerville < g4wjs@...> wrote:
Hi Hasan,
Steve, K9AN, and I are running WSPR band-hopping with a
variety of bands set for Tune and Rx only. Neither of us
are seeing this issue so far. I am using the latest 2.5.0
RC6 version.
73
Bill
G4WJS.
On 08/09/2021 15:00, Hasan Schiers N0AN wrote:
No,
no errors at all, see an occasional audio stream
error, nothing else
On Wed, Sep 8, 2021 at
8:20 AM Bill Somerville < g4wjs@...>
wrote:
Hi Hasan,
are there any Hamlib error messages in the
WJST-X wsjtx_syslog.log file that correlate with
the time of the issue?
73
Bill
G4WJS.
On 08/09/2021 01:09, Hasan Schiers N0AN wrote:
Bill,
I found the
correlation I was looking for.
If I tell WSPR
Schedule to use the TUNE function (to make the
autotuner adjust the antenna SWR on each band
prior to transmitting), the ENABLE Tx light
goes out in short order (next transmission or
so).
If I uncheck the boxes
on each band for Tune, and let the transmit
signal itself actuate the auto-tuner,
everything works normally.
In reality, the TUNE
function in the Scheduler is redundant,
because the autotuner itself will auto-tune
when RF is sent to it anyway, there is no need
to 'pre-tune' things.
However, what I am
reporting is undesirable and probably should
be fixed, if it's a real malfunction.
73, N0AN
On Sat, Sep 4,
2021 at 12:21 PM Bill Somerville < g4wjs@...>
wrote:
On 04/09/2021 13:34, Hasan Schiers N0AN
wrote:
WSJT-X 2.5.0
RC5
Mode WSPR
Issue:
When in Band
Hopping Mode, with a proper
schedule, the Enable Transmit button
randomly goes dark and never lights
up again.
This results
in hours and hours of listening
overnight with no transmitting.
Is there an
order effect or something that would
cause this in terms of setup? It
used to work perfectly with
identical settings many versions
ago.
Anyone else
seen this?
TIA, 73,
N0AN
Hi Hasan,
that behaviour may be caused by a CAT
error. Have a look in the wsjtx_syslog.log
file (in the WSJT-X log files directory)
for any Hamlib error messages around the
time that the "Enable Tx" button resets.
73
Bill
G4WJS.
|
|
|
Also RC6 here, although downloaded a few days ago. I think there was a hamlib fix since then, but have not downloaded since very early RC6.
73, N0AN
On Wed, Sep 8, 2021 at 11:21 AM Bill Somerville < g4wjs@...> wrote:
Hi Hasan,
Steve, K9AN, and I are running WSPR
band-hopping with a variety of bands set for Tune and Rx only.
Neither of us are seeing this issue so far. I am using the latest
2.5.0 RC6 version.
73
Bill
G4WJS.
On 08/09/2021 15:00, Hasan Schiers N0AN
wrote:
No, no errors
at all, see an occasional audio stream error, nothing else
On Wed, Sep 8, 2021 at 8:20 AM
Bill Somerville < g4wjs@...> wrote:
Hi Hasan,
are there any Hamlib error messages in the WJST-X
wsjtx_syslog.log file that correlate with the time of the
issue?
73
Bill
G4WJS.
On 08/09/2021 01:09, Hasan Schiers N0AN wrote:
Bill,
I
found the correlation I was looking for.
If I
tell WSPR Schedule to use the TUNE function (to make
the autotuner adjust the antenna SWR on each band
prior to transmitting), the ENABLE Tx light goes out
in short order (next transmission or so).
If I
uncheck the boxes on each band for Tune, and let the
transmit signal itself actuate the auto-tuner,
everything works normally.
In
reality, the TUNE function in the Scheduler is
redundant, because the autotuner itself will auto-tune
when RF is sent to it anyway, there is no need to
'pre-tune' things.
However,
what I am reporting is undesirable and probably should
be fixed, if it's a real malfunction.
73,
N0AN
On Sat, Sep 4, 2021 at
12:21 PM Bill Somerville < g4wjs@...>
wrote:
On 04/09/2021 13:34, Hasan Schiers N0AN wrote:
WSJT-X 2.5.0 RC5
Mode WSPR
Issue:
When in Band Hopping
Mode, with a proper schedule, the Enable
Transmit button randomly goes dark and never
lights up again.
This results in
hours and hours of listening overnight with
no transmitting.
Is there an order
effect or something that would cause this in
terms of setup? It used to work perfectly
with identical settings many versions ago.
Anyone else seen
this?
TIA, 73, N0AN
Hi Hasan,
that behaviour may be caused by a CAT error. Have
a look in the wsjtx_syslog.log file (in the WSJT-X
log files directory) for any Hamlib error messages
around the time that the "Enable Tx" button
resets.
73
Bill
G4WJS.
|
|
|
Here is a recent sample of the error log, Bill:
[SYSLOG][2021-09-08 11:29:54.060941][12:29:07.539049][warning] Detected dropped audio source samples: 912 (0.019 S) [SYSLOG][2021-09-08 11:40:28.319469][12:39:41.807077][info] shmem size: 48275456 [RIGCTRL][2021-09-08 11:40:28.341453][12:39:41.828568][info] Hamlib version: Hamlib 4.4~git Wed Sep 01 17:45:29 2021 +0000 SHA=6de458 [SYSLOG][2021-09-08 12:24:01.924582][13:23:15.439149][info] shmem size: 48275456 [RIGCTRL][2021-09-08 12:24:01.949567][13:23:15.464064][info] Hamlib version: Hamlib 4.4~git Wed Sep 01 17:45:29 2021 +0000 SHA=6de458 [SYSLOG][2021-09-08 12:24:57.648924][13:24:11.165287][warning] Detected dropped audio source samples: 720 (0.015 S) [SYSLOG][2021-09-08 12:27:57.670814][13:27:11.187554][warning] Detected dropped audio source samples: 960 (0.02 S) [SYSLOG][2021-09-08 12:31:57.652399][13:31:11.170195][warning] Detected dropped audio source samples: 864 (0.018 S) [SYSLOG][2021-09-08 13:31:57.679875][14:31:11.243958][warning] Detected dropped audio source samples: 1728 (0.036 S) [SYSLOG][2021-09-08 13:54:57.670548][14:54:11.249594][warning] Detected dropped audio source samples: 624 (0.013 S) [SYSLOG][2021-09-08 14:04:27.682899][15:03:41.268923][warning] Detected dropped audio source samples: 1728 (0.036 S) [SYSLOG][2021-09-08 14:06:27.680240][15:05:41.269116][warning] Detected dropped audio source samples: 768 (0.016 S) [SYSLOG][2021-09-08 14:10:33.025069][15:09:46.616088][info] shmem size: 48275456 [RIGCTRL][2021-09-08 14:10:33.046057][15:09:46.637030][info] Hamlib version: Hamlib 4.4~git Wed Sep 01 17:45:29 2021 +0000 SHA=6de458
I assume it is local time , so 2:10:33 p.m.?
73, N0AN
On Wed, Sep 8, 2021 at 11:22 AM Bill Somerville < g4wjs@...> wrote:
Hi Hasan,
what are the audio stream errors?
73
Bill
G4WJS.
On 08/09/2021 15:00, Hasan Schiers N0AN
wrote:
No, no errors
at all, see an occasional audio stream error, nothing else
On Wed, Sep 8, 2021 at 8:20 AM
Bill Somerville < g4wjs@...> wrote:
Hi Hasan,
are there any Hamlib error messages in the WJST-X
wsjtx_syslog.log file that correlate with the time of the
issue?
73
Bill
G4WJS.
On 08/09/2021 01:09, Hasan Schiers N0AN wrote:
Bill,
I
found the correlation I was looking for.
If I
tell WSPR Schedule to use the TUNE function (to make
the autotuner adjust the antenna SWR on each band
prior to transmitting), the ENABLE Tx light goes out
in short order (next transmission or so).
If I
uncheck the boxes on each band for Tune, and let the
transmit signal itself actuate the auto-tuner,
everything works normally.
In
reality, the TUNE function in the Scheduler is
redundant, because the autotuner itself will auto-tune
when RF is sent to it anyway, there is no need to
'pre-tune' things.
However,
what I am reporting is undesirable and probably should
be fixed, if it's a real malfunction.
73,
N0AN
On Sat, Sep 4, 2021 at
12:21 PM Bill Somerville < g4wjs@...>
wrote:
On 04/09/2021 13:34, Hasan Schiers N0AN wrote:
WSJT-X 2.5.0 RC5
Mode WSPR
Issue:
When in Band Hopping
Mode, with a proper schedule, the Enable
Transmit button randomly goes dark and never
lights up again.
This results in
hours and hours of listening overnight with
no transmitting.
Is there an order
effect or something that would cause this in
terms of setup? It used to work perfectly
with identical settings many versions ago.
Anyone else seen
this?
TIA, 73, N0AN
Hi Hasan,
that behaviour may be caused by a CAT error. Have
a look in the wsjtx_syslog.log file (in the WSJT-X
log files directory) for any Hamlib error messages
around the time that the "Enable Tx" button
resets.
73
Bill
G4WJS.
|
|
|
On Wednesday, September 8, 2021, 11:21:24 AM CDT, Bill Somerville <g4wjs@...> wrote:
Hi Hasan,
Steve, K9AN, and I are running WSPR
band-hopping with a variety of bands set for Tune and Rx only.
Neither of us are seeing this issue so far. I am using the latest
2.5.0 RC6 version.
73
Bill
G4WJS.
On 08/09/2021 15:00, Hasan Schiers N0AN
wrote:
No, no errors
at all, see an occasional audio stream error, nothing else
On Wed, Sep 8, 2021 at 8:20 AM
Bill Somerville < g4wjs@...> wrote:
Hi Hasan,
are there any Hamlib error messages in the WJST-X
wsjtx_syslog.log file that correlate with the time of the
issue?
73
Bill
G4WJS.
On 08/09/2021 01:09, Hasan Schiers N0AN wrote:
Bill,
I
found the correlation I was looking for.
If I
tell WSPR Schedule to use the TUNE function (to make
the autotuner adjust the antenna SWR on each band
prior to transmitting), the ENABLE Tx light goes out
in short order (next transmission or so).
If I
uncheck the boxes on each band for Tune, and let the
transmit signal itself actuate the auto-tuner,
everything works normally.
In
reality, the TUNE function in the Scheduler is
redundant, because the autotuner itself will auto-tune
when RF is sent to it anyway, there is no need to
'pre-tune' things.
However,
what I am reporting is undesirable and probably should
be fixed, if it's a real malfunction.
73,
N0AN
On Sat, Sep 4, 2021 at
12:21 PM Bill Somerville < g4wjs@...>
wrote:
On 04/09/2021 13:34, Hasan Schiers N0AN wrote:
WSJT-X 2.5.0 RC5
Mode WSPR
Issue:
When in Band Hopping
Mode, with a proper schedule, the Enable
Transmit button randomly goes dark and never
lights up again.
This results in
hours and hours of listening overnight with
no transmitting.
Is there an order
effect or something that would cause this in
terms of setup? It used to work perfectly
with identical settings many versions ago.
Anyone else seen
this?
TIA, 73, N0AN
Hi Hasan,
that behaviour may be caused by a CAT error. Have
a look in the wsjtx_syslog.log file (in the WSJT-X
log files directory) for any Hamlib error messages
around the time that the "Enable Tx" button
resets.
73
Bill
G4WJS.
|
|
|
Bill Somerville
Hi Hasan,
what are the audio stream errors?
73
Bill
G4WJS.
On 08/09/2021 15:00, Hasan Schiers N0AN
wrote:
toggle quoted message
Show quoted text
No, no errors
at all, see an occasional audio stream error, nothing else
On Wed, Sep 8, 2021 at 8:20 AM
Bill Somerville < g4wjs@...> wrote:
Hi Hasan,
are there any Hamlib error messages in the WJST-X
wsjtx_syslog.log file that correlate with the time of the
issue?
73
Bill
G4WJS.
On 08/09/2021 01:09, Hasan Schiers N0AN wrote:
Bill,
I
found the correlation I was looking for.
If I
tell WSPR Schedule to use the TUNE function (to make
the autotuner adjust the antenna SWR on each band
prior to transmitting), the ENABLE Tx light goes out
in short order (next transmission or so).
If I
uncheck the boxes on each band for Tune, and let the
transmit signal itself actuate the auto-tuner,
everything works normally.
In
reality, the TUNE function in the Scheduler is
redundant, because the autotuner itself will auto-tune
when RF is sent to it anyway, there is no need to
'pre-tune' things.
However,
what I am reporting is undesirable and probably should
be fixed, if it's a real malfunction.
73,
N0AN
On Sat, Sep 4, 2021 at
12:21 PM Bill Somerville < g4wjs@...>
wrote:
On 04/09/2021 13:34, Hasan Schiers N0AN wrote:
WSJT-X 2.5.0 RC5
Mode WSPR
Issue:
When in Band Hopping
Mode, with a proper schedule, the Enable
Transmit button randomly goes dark and never
lights up again.
This results in
hours and hours of listening overnight with
no transmitting.
Is there an order
effect or something that would cause this in
terms of setup? It used to work perfectly
with identical settings many versions ago.
Anyone else seen
this?
TIA, 73, N0AN
Hi Hasan,
that behaviour may be caused by a CAT error. Have
a look in the wsjtx_syslog.log file (in the WSJT-X
log files directory) for any Hamlib error messages
around the time that the "Enable Tx" button
resets.
73
Bill
G4WJS.
|
|
|
Bill Somerville
Hi Hasan,
Steve, K9AN, and I are running WSPR
band-hopping with a variety of bands set for Tune and Rx only.
Neither of us are seeing this issue so far. I am using the latest
2.5.0 RC6 version.
73
Bill
G4WJS.
On 08/09/2021 15:00, Hasan Schiers N0AN
wrote:
toggle quoted message
Show quoted text
No, no errors
at all, see an occasional audio stream error, nothing else
On Wed, Sep 8, 2021 at 8:20 AM
Bill Somerville < g4wjs@...> wrote:
Hi Hasan,
are there any Hamlib error messages in the WJST-X
wsjtx_syslog.log file that correlate with the time of the
issue?
73
Bill
G4WJS.
On 08/09/2021 01:09, Hasan Schiers N0AN wrote:
Bill,
I
found the correlation I was looking for.
If I
tell WSPR Schedule to use the TUNE function (to make
the autotuner adjust the antenna SWR on each band
prior to transmitting), the ENABLE Tx light goes out
in short order (next transmission or so).
If I
uncheck the boxes on each band for Tune, and let the
transmit signal itself actuate the auto-tuner,
everything works normally.
In
reality, the TUNE function in the Scheduler is
redundant, because the autotuner itself will auto-tune
when RF is sent to it anyway, there is no need to
'pre-tune' things.
However,
what I am reporting is undesirable and probably should
be fixed, if it's a real malfunction.
73,
N0AN
On Sat, Sep 4, 2021 at
12:21 PM Bill Somerville < g4wjs@...>
wrote:
On 04/09/2021 13:34, Hasan Schiers N0AN wrote:
WSJT-X 2.5.0 RC5
Mode WSPR
Issue:
When in Band Hopping
Mode, with a proper schedule, the Enable
Transmit button randomly goes dark and never
lights up again.
This results in
hours and hours of listening overnight with
no transmitting.
Is there an order
effect or something that would cause this in
terms of setup? It used to work perfectly
with identical settings many versions ago.
Anyone else seen
this?
TIA, 73, N0AN
Hi Hasan,
that behaviour may be caused by a CAT error. Have
a look in the wsjtx_syslog.log file (in the WSJT-X
log files directory) for any Hamlib error messages
around the time that the "Enable Tx" button
resets.
73
Bill
G4WJS.
|
|
|
If I were to make a WAG, I would think it is a logic problem that crept in, cuz it used to work last year without dropping out (with Tune selected in the BandHop Sked)
On Wed, Sep 8, 2021 at 8:20 AM Bill Somerville < g4wjs@...> wrote:
Hi Hasan,
are there any Hamlib error messages in
the WJST-X wsjtx_syslog.log file that correlate with the time of
the issue?
73
Bill
G4WJS.
On 08/09/2021 01:09, Hasan Schiers N0AN
wrote:
Bill,
I found the
correlation I was looking for.
If I tell
WSPR Schedule to use the TUNE function (to make the autotuner
adjust the antenna SWR on each band prior to transmitting),
the ENABLE Tx light goes out in short order (next transmission
or so).
If I uncheck
the boxes on each band for Tune, and let the transmit signal
itself actuate the auto-tuner, everything works normally.
In reality,
the TUNE function in the Scheduler is redundant, because the
autotuner itself will auto-tune when RF is sent to it anyway,
there is no need to 'pre-tune' things.
However, what
I am reporting is undesirable and probably should be fixed, if
it's a real malfunction.
73, N0AN
On Sat, Sep 4, 2021 at 12:21
PM Bill Somerville < g4wjs@...> wrote:
On 04/09/2021 13:34, Hasan Schiers N0AN wrote:
WSJT-X
2.5.0 RC5
Mode
WSPR
Issue:
When
in Band Hopping Mode, with a proper schedule, the
Enable Transmit button randomly goes dark and never
lights up again.
This
results in hours and hours of listening overnight
with no transmitting.
Is
there an order effect or something that would cause
this in terms of setup? It used to work perfectly
with identical settings many versions ago.
Anyone
else seen this?
TIA,
73, N0AN
Hi Hasan,
that behaviour may be caused by a CAT error. Have a look
in the wsjtx_syslog.log file (in the WSJT-X log files
directory) for any Hamlib error messages around the time
that the "Enable Tx" button resets.
73
Bill
G4WJS.
|
|
|
No, no errors at all, see an occasional audio stream error, nothing else
On Wed, Sep 8, 2021 at 8:20 AM Bill Somerville < g4wjs@...> wrote:
Hi Hasan,
are there any Hamlib error messages in
the WJST-X wsjtx_syslog.log file that correlate with the time of
the issue?
73
Bill
G4WJS.
On 08/09/2021 01:09, Hasan Schiers N0AN
wrote:
Bill,
I found the
correlation I was looking for.
If I tell
WSPR Schedule to use the TUNE function (to make the autotuner
adjust the antenna SWR on each band prior to transmitting),
the ENABLE Tx light goes out in short order (next transmission
or so).
If I uncheck
the boxes on each band for Tune, and let the transmit signal
itself actuate the auto-tuner, everything works normally.
In reality,
the TUNE function in the Scheduler is redundant, because the
autotuner itself will auto-tune when RF is sent to it anyway,
there is no need to 'pre-tune' things.
However, what
I am reporting is undesirable and probably should be fixed, if
it's a real malfunction.
73, N0AN
On Sat, Sep 4, 2021 at 12:21
PM Bill Somerville < g4wjs@...> wrote:
On 04/09/2021 13:34, Hasan Schiers N0AN wrote:
WSJT-X
2.5.0 RC5
Mode
WSPR
Issue:
When
in Band Hopping Mode, with a proper schedule, the
Enable Transmit button randomly goes dark and never
lights up again.
This
results in hours and hours of listening overnight
with no transmitting.
Is
there an order effect or something that would cause
this in terms of setup? It used to work perfectly
with identical settings many versions ago.
Anyone
else seen this?
TIA,
73, N0AN
Hi Hasan,
that behaviour may be caused by a CAT error. Have a look
in the wsjtx_syslog.log file (in the WSJT-X log files
directory) for any Hamlib error messages around the time
that the "Enable Tx" button resets.
73
Bill
G4WJS.
|
|
|
Bill Somerville
Hi Hasan,
are there any Hamlib error messages in
the WJST-X wsjtx_syslog.log file that correlate with the time of
the issue?
73
Bill
G4WJS.
On 08/09/2021 01:09, Hasan Schiers N0AN
wrote:
toggle quoted message
Show quoted text
Bill,
I found the
correlation I was looking for.
If I tell
WSPR Schedule to use the TUNE function (to make the autotuner
adjust the antenna SWR on each band prior to transmitting),
the ENABLE Tx light goes out in short order (next transmission
or so).
If I uncheck
the boxes on each band for Tune, and let the transmit signal
itself actuate the auto-tuner, everything works normally.
In reality,
the TUNE function in the Scheduler is redundant, because the
autotuner itself will auto-tune when RF is sent to it anyway,
there is no need to 'pre-tune' things.
However, what
I am reporting is undesirable and probably should be fixed, if
it's a real malfunction.
73, N0AN
On Sat, Sep 4, 2021 at 12:21
PM Bill Somerville < g4wjs@...> wrote:
On 04/09/2021 13:34, Hasan Schiers N0AN wrote:
WSJT-X
2.5.0 RC5
Mode
WSPR
Issue:
When
in Band Hopping Mode, with a proper schedule, the
Enable Transmit button randomly goes dark and never
lights up again.
This
results in hours and hours of listening overnight
with no transmitting.
Is
there an order effect or something that would cause
this in terms of setup? It used to work perfectly
with identical settings many versions ago.
Anyone
else seen this?
TIA,
73, N0AN
Hi Hasan,
that behaviour may be caused by a CAT error. Have a look
in the wsjtx_syslog.log file (in the WSJT-X log files
directory) for any Hamlib error messages around the time
that the "Enable Tx" button resets.
73
Bill
G4WJS.
|
|
|
Bill, I found the correlation I was looking for.
If I tell WSPR Schedule to use the TUNE function (to make the autotuner adjust the antenna SWR on each band prior to transmitting), the ENABLE Tx light goes out in short order (next transmission or so).
If I uncheck the boxes on each band for Tune, and let the transmit signal itself actuate the auto-tuner, everything works normally.
In reality, the TUNE function in the Scheduler is redundant, because the autotuner itself will auto-tune when RF is sent to it anyway, there is no need to 'pre-tune' things.
However, what I am reporting is undesirable and probably should be fixed, if it's a real malfunction.
73, N0AN
On Sat, Sep 4, 2021 at 12:21 PM Bill Somerville < g4wjs@...> wrote:
On 04/09/2021 13:34, Hasan Schiers N0AN
wrote:
WSJT-X
2.5.0 RC5
Mode WSPR
Issue:
When in
Band Hopping Mode, with a proper schedule, the Enable
Transmit button randomly goes dark and never lights up
again.
This
results in hours and hours of listening overnight with no
transmitting.
Is there
an order effect or something that would cause this in terms
of setup? It used to work perfectly with identical settings
many versions ago.
Anyone
else seen this?
TIA, 73,
N0AN
Hi Hasan,
that behaviour may be caused by a CAT error. Have a look in the
wsjtx_syslog.log file (in the WSJT-X log files directory) for any
Hamlib error messages around the time that the "Enable Tx" button
resets.
73
Bill
G4WJS.
|
|
|
Last two days, it has behaved normally. Looks like it was a random glitch, possibly cleared by a reboot. 73, N0AN
Thanks Bill, I'll keep watch for it the next time it happens. It ran for two hours without that error this morning, but was doing it frequently yesterday 73, N0AN
On Sat, Sep 4, 2021 at 12:21 PM Bill Somerville < g4wjs@...> wrote:
On 04/09/2021 13:34, Hasan Schiers N0AN
wrote:
WSJT-X
2.5.0 RC5
Mode WSPR
Issue:
When in
Band Hopping Mode, with a proper schedule, the Enable
Transmit button randomly goes dark and never lights up
again.
This
results in hours and hours of listening overnight with no
transmitting.
Is there
an order effect or something that would cause this in terms
of setup? It used to work perfectly with identical settings
many versions ago.
Anyone
else seen this?
TIA, 73,
N0AN
Hi Hasan,
that behaviour may be caused by a CAT error. Have a look in the
wsjtx_syslog.log file (in the WSJT-X log files directory) for any
Hamlib error messages around the time that the "Enable Tx" button
resets.
73
Bill
G4WJS.
|
|
|
Thanks Bill, I'll keep watch for it the next time it happens. It ran for two hours without that error this morning, but was doing it frequently yesterday 73, N0AN
On Sat, Sep 4, 2021 at 12:21 PM Bill Somerville < g4wjs@...> wrote:
On 04/09/2021 13:34, Hasan Schiers N0AN
wrote:
WSJT-X
2.5.0 RC5
Mode WSPR
Issue:
When in
Band Hopping Mode, with a proper schedule, the Enable
Transmit button randomly goes dark and never lights up
again.
This
results in hours and hours of listening overnight with no
transmitting.
Is there
an order effect or something that would cause this in terms
of setup? It used to work perfectly with identical settings
many versions ago.
Anyone
else seen this?
TIA, 73,
N0AN
Hi Hasan,
that behaviour may be caused by a CAT error. Have a look in the
wsjtx_syslog.log file (in the WSJT-X log files directory) for any
Hamlib error messages around the time that the "Enable Tx" button
resets.
73
Bill
G4WJS.
|
|
|
Bill Somerville
On 04/09/2021 13:34, Hasan Schiers N0AN
wrote:
WSJT-X
2.5.0 RC5
Mode WSPR
Issue:
When in
Band Hopping Mode, with a proper schedule, the Enable
Transmit button randomly goes dark and never lights up
again.
This
results in hours and hours of listening overnight with no
transmitting.
Is there
an order effect or something that would cause this in terms
of setup? It used to work perfectly with identical settings
many versions ago.
Anyone
else seen this?
TIA, 73,
N0AN
Hi Hasan,
that behaviour may be caused by a CAT error. Have a look in the
wsjtx_syslog.log file (in the WSJT-X log files directory) for any
Hamlib error messages around the time that the "Enable Tx" button
resets.
73
Bill
G4WJS.
|
|
|
WSJT-X 2.5.0 RC5
Mode WSPR
Issue:
When in Band Hopping Mode, with a proper schedule, the Enable Transmit button randomly goes dark and never lights up again.
This results in hours and hours of listening overnight with no transmitting.
Is there an order effect or something that would cause this in terms of setup? It used to work perfectly with identical settings many versions ago.
Anyone else seen this?
TIA, 73, N0AN
|
|
|
