Hi,
Just a reminder, why there are so many false band spots. From the current
candidate release notes rc1:
Correct a flaw that could send incorrect frequencies to ALL.TXT
and PSK Reporter after a band change
That happens each time you change the band during monitoring. The previous band
Hi Phillip,
It would be nice if the problem could be reduced at the source of the spot
then there is less complexity needed upstream. My thought is the
PSKreporter option in WSJT-X can only be enabled if CAT is defined, this
might filter some of the chaff from the wheat when it comes to spots bef
pskreporter has an algorithm to identify and filter out most of those bad
spots. However, this can only happen once confirming/disconfirming spot
reports arrive from other monitoring stations. Thus HamSpots will be passed
these bad spots before pskreporter can figure out that they are bad.
Philip
On 16/08/2022 9:52 am, Laurie, VK3AMA via wsjt-devel wrote:
HamSpots has a couple of thousand callsigns that have their spots
permanently blocked because of repeated occurrences of wrong-band
spotting by the callsign
I neglected to add, that the majority of those habitual wrong-band
spot
On 16/08/2022 9:32 am, Peter Sumner via wsjt-devel wrote:
Why? oh too often many of us have seen 'false spots' from a busy band
appearing on what is a very quiet band via PSKreporter because an OP
somewhere has changed bands on the rig but not on WSJT-X
HamSpots has a couple of thousand c
Hello.
I would like to see the PSKreporter functionality in WSJT-X be restricted
to situations where the CAT control of the rig is active.
Why? oh too often many of us have seen 'false spots' from a busy band
appearing on what is a very quiet band via PSKreporter because an OP
somewhere has cha
I have both tried with an USB soundcard on RBPi and on my
stationary machine. On the latter I have the same problem also
with motherboard audio.
This autosuspend seems only to apply for USB.
When the waterfall (and any reception) has stopped in WSJT-X I c
Wow, classic signs of RFI, but not without a transmitter. 8*)
Next guess would be power supply? Or overheating?
73, Willie N1JBJ
> On Aug 15, 2022, at 7:58 AM, Daniel Uppström via wsjt-devel
> wrote:
>
> Hi all,
> I still experience this problem, described below. Now tested on WSJT-X v2.5.4
What does your audio chain look like?
Have you tried disabling autosuspend?
set autosuspend=-1
https://docs.kernel.org/driver-api/usb/power-management.html
Mike W9MDB
On Monday, August 15, 2022 at 07:05:11 AM CDT, Daniel Uppström via
wsjt-devel wrote:
Hi all,
I still experience
On 8/15/22 14:23, Steve Platt wrote:
On 15 August 2022 13:58:25 CEST, "Daniel
Uppström via wsjt-devel"
wrote:
Hi all,
I still experience this problem, described below. Now tested
on WSJT-X v2.5.4 under Lin
On 15 August 2022 13:58:25 CEST, "Daniel Uppström via wsjt-devel"
wrote:
>
Are you using the same audio device for Rx and for Tx? EG using "pulse" for
both?
I have found that doing so gives the results you describe; also that one of the
threads goes into a loop so that you have to kill the pr
Hi all,
I still experience this problem, described below. Now tested on
WSJT-X v2.5.4 under Linux Mint.
Waterfall stops updating after TX. Without any radio connected at
all. So not an RFI issue.
Am I the only one that has seen this problem?
Tha
12 matches
Mail list logo
