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
ed, after the non-linear
> compressor/clipper, so the FT8 signal is not subjected to non-linearity.
> >
> > OZ1HFT
> >
> > -
> >
> >> Den 23. sep. 2021 kl. 19.27 skrev Philip Gladstone <
> pjsg-w...@nospam.gladstonefamily.net>:
> >>
> &
I think that it would be an interesting experiment to transmit voice on SSB
with a continuous FT8 transmission (maybe at around the 1kHz offset) and
see whether there is a combination of offset & volume difference that makes
the FT8 decodable if the SSB is barely understandable or better, and yet
h
My understanding of GRAND is that it relies on the fact that the SNR is
high -- which is very much not the case for FT8.
Philip
On Tue, Sep 21, 2021 at 3:26 PM Glenn M-H via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:
> Hi!
>
> Please consider using "Guessing Random Additive Noise Deco
ver issues later.
On Wed, Jun 17, 2020 at 8:36 AM Bill Somerville
wrote:
> On 07/06/2020 02:23, Philip Gladstone wrote:
>
> There are a (small) number of WSJT-X users who have difficulty reporting
> their spots to pskreporter. Some of these are in "difficult" areas o
7; seem to understand
> the OSI 7-layer modelall of which made me very leery of banking
>
> Mike W9MDB
>
>
>
> On Sunday, June 7, 2020, 04:11:10 AM CDT, Bill Somerville <
> g4...@classdesign.com> wrote:
>
>
> On 07/06/2020 02:23, Philip Gladstone wrot
There are a (small) number of WSJT-X users who have difficulty reporting
their spots to pskreporter. Some of these are in "difficult" areas of
network connectivity (e.g. Marine Mobile) and I suspect that the UDP
transport is losing most of their packets. The general loss rate seems to
be around 1%-
Whether PSK reporter gets to see some particular signal depends on the
decoding software. It is easy enough to experiment with various
transmissions and see which get reported. Use different callsigns
(suffixes) so that you can tell which signals get through.
On Sat, Jan 4, 2020 at 10:26 AM Reino
How much traffic does WSPRNET get? How many spots are reported on a daily
basis? I'm trying to figure out if supporting all that traffic in
pskreporter would kill it
On Thu, Oct 10, 2019 at 4:59 AM Benjamin Bänziger
wrote:
> Hi,
>
> This is probably not the right place for this issue, but al
I suspect that the root cause is that he can't see any reports on psk
reporter. This is probably for two reasons -- there is no locator in the CQ
message (and so no psk report) and for other systems which do report this
type of message, there is no locator in psk reporter database and so it
cannot
Thanks for all the comments -- I think that these particular cases are due
to power line issues. [And I had forgot about the non-standard callsign
issue.]
Philip
On Mon, Jan 21, 2019 at 10:59 AM Joe Taylor wrote:
> On 1/21/2019 10:49 AM, DG2YCB, Uwe wrote:
> > Interesting is the following: Same
I notice that I am getting a bunch of duplicates in the packets (as seen in
the raw packet captures) being sent to pskreporter. For example:
WE6Z reported seeing KG7VOR twice at Jan 21, 2019 03:03:29. The only
differences were:
One entry had Frequency 1841279 with snr -15
Another had Frequency 18
I filtered down to WSJT* only and counted by unique callsigns:
+---+--+
| antennaInformation | count(distinct callsign) |
+---+--+
| 43' Vertical | 5 |
| 43 FOOT VERTICAL
The stats for the most common antennas used over the last 7 days are:
++--+
| antennaInformation | count(*) |
++--+
| ZS6BKW|32 |
| SLOPER|32 |
| Magnetic Loop|33 |
| RX Op05|37 |
| DP|39 |
| RX Op32|43 |
| Hex Beam|45 |
| LW|47 |
W(MDB
On Friday, May 18, 2018, 3:36:47 AM CDT, Bill Somerville
wrote:
On 18/05/2018 03:43, Philip Gladstone wrote:
I've been contacted by a few people with compound callsigns whose
transmissions are never reported to PSKReporter. I took a quick look
at the WSJT-X code and it appear
I've been contacted by a few people with compound callsigns whose
transmissions are never reported to PSKReporter. I took a quick look at
the WSJT-X code and it appears that the CQ is only reported if there is
both a callsign *and* a grid. I suspect that these compound callsigns
are not being e
One of the pskreporter users reported that when he runs pskreporter and
wsjt-x then decodes are much reduced. If he turns off the night shadow
in pskreporter, then decode performance returns to normal. I suspect
some type of GPU issue as the night shadow in pskreporter uses WebGL to
render the
On 16/12/2017 19:11, Bill Somerville wrote:
On 16/12/2017 23:21, Philip Gladstone wrote:
Hi
Pskreporter receives multiple packets per second from WSJT that are
in the local WSJT UDP protocol. I suspect that users may have
deliberately pointed these streams at me (thinking that it would do
Hi
Pskreporter receives multiple packets per second from WSJT that are in
the local WSJT UDP protocol. I suspect that users may have deliberately
pointed these streams at me (thinking that it would do something) but
I'm not sure. If you can somehow make it clear that pointing this stream
at p
And, importantly, the 6 character grid is used when submitting reports
to pskreporter (so that it knows where to put your marker). I get a
number of people asking me to "correct" their location, and I tell them
to use the full locator in wsjt-x.
Philip
On 16/10/2017 22:06, Joe Taylor wrote:
I suspect that the decoding of the country file is incorrect -- in
particular AK4PR decodes to be in Alaska (rather than USA). The country
file has =AK4P as being in Alaska, but this indicates an exact match.
WSJT-X 1.8.0 r8069
Philip
---
On 16/08/2017 11:30, Bill Somerville wrote:
On 16/08/2017 12:02, Philip Gladstone wrote:
I'm getting a bunch of strange packets sent to pskreporter that (I
think) are coming from wsjt implementations. For example:
AD BC CB DA 00 00 00 01 00 00 00 00 00 00 00 04 4D 53 48 56 00 00 00
01
I'm getting a bunch of strange packets sent to pskreporter that (I
think) are coming from wsjt implementations. For example:
AD BC CB DA 00 00 00 01 00 00 00 00 00 00 00 04 4D 53 48 56 00 00 00 01
00 00 00 04 31 2E 34 32
I think that this is wsjt because of the adbccbda header (which google
On 08/07/2017 17:37, Bill Somerville wrote:
On 08/07/2017 22:31, Alessandro Gorobey via wsjt-devel wrote:
Hi Bill,
seem you have connected strange locations!
https://pskreporter.info/pskmap.html?preset&callsign=G4WJS&txrx=rx&mode=FT8&timerange=10800&distunit=km&hideunrec=1&hidelight=1&showtx=1
Can you give me an example, and what you think it ought to be saying and
I can take a look at it. A screenshot is always helpful. You can reply
off-list.
Philip
On 08/07/2017 07:17, Rick wrote:
Good morning all,
Checking PSKReporter (with mode filter FT8 enabled) shows several
transmitters
I'd like to see a message type that consisted of a callsign in the
current format, and the rest of the bits are in a callsign specific
message format. It should be displayed as HEX. There should be a website
somewhere where the message format is defined based on the sending
callsign. For exampl
You are correct -- pskreporter does not modify frequencies. The other
note for this mailing list (from a pskreporter perspective) is to
encourage people to enter their six character locator (even though only
four characaters are used in the various JT* modes). Using the six
character locator ca
27 matches
Mail list logo
