Hi Matt,
You should be possible to send CQ message without grid square locator and make
contacts with the help on hashed call sign using automatic message generation.
There strong limits what can be included into a single message, when the basic
call sign is 7 characters long. As a workaround y
Martin and Bill,
Yes, decoding do continue after the start of next transmission period. I do
see sometimes many decodes after my transmitter has put full power out.
I also do prefer that this issue is corrected as timestamps in ALL.TXT
provide a nice comparison possibility e.g. for reception by two
Hi there,
I'm using WSJT-X (WSPR Mode) for quite a while for receiving and now I've
attempted to transmit.
I am a Foundation Licence holder in Australia (VK), which means I have a 7
digit callsign - VK3FDLL
With various tests, I can hear my WSPR transmissions away from my station
and WSJT-X can e
Christoph ,
Do we know for a fact that band change decodes (those following a dashed
line w/o a band indicated) are actually submitted to PSKReporter? Maybe
one of the Development Group can verify this. If this is actually
happening, it should be corrected in a future update of WSJT-X.
73,
Rich
On 20 Feb 2020 at 23:10, Bill Somerville wrote:
> Hi Martin,
>
> I suspect the ALL.TXT rows you are referring to were decoded after the
> following period started. The algorithm for allocating to the Rx period
> is simplistic and probably unchanged since times when changeover periods
> were su
Hi Mike,
I'm not sure without reviewing the code, but it probably happens because
the ALL.TXT writing has been abstracted into a common routine so as to
make the format more consistent.
73
Bill
G4WJS.
On 20/02/2020 23:42, Black Michael via wsjt-devel wrote:
Why aren;t the times for ALL.TXT t
Why aren;t the times for ALL.TXT taken from the jt9 decode process which has to
get them right since it's got the wav filename to work with?
de Mike W9MDB
On Thursday, February 20, 2020, 05:16:06 PM CST, Bill Somerville
wrote:
On 20/02/2020 22:01, Martin Davies G0HDB wrote:
I'm r
On 20/02/2020 22:01, Martin Davies G0HDB wrote:
I'm running WSJT-X v2.1.2 0068f9 on a PC with Win 7 (Pro).
Back in late January I posted a message, #5852, on ws...@groups.io
about a 15-second discrepancy I'd observed between the times of FT8
decodes displayed in the Band activity window and t
I just noticed the same thing today. I had two decode periods that both showed
the same time in ALL.TXT when I was debugging problem with JTAlert. I
confirmed they were two separate periods by decoding the WAV files manually.
So the question is where does time for ALL.TXT come from and/or how c
On 20 Feb 2020 at 16:12, Ron WV4P wrote:
> The TX entry is probably because you hit the Watchdog timer.. set it short
> and let it hit it a few times to duplicate.
Sorry Ron, but I can't see how the watchdog timer figures in this at all, and
in any event I
know for certain that the timer wasn't
The TX entry is probably because you hit the Watchdog timer.. set it short
and let it hit it a few times to duplicate.
On Thu, Feb 20, 2020, 4:06 PM Martin Davies G0HDB
wrote:
> I'm running WSJT-X v2.1.2 0068f9 on a PC with Win 7 (Pro).
>
> Back in late January I posted a message, #5852, on ws.
I'm running WSJT-X v2.1.2 0068f9 on a PC with Win 7 (Pro).
Back in late January I posted a message, #5852, on ws...@groups.io about a
15-second
discrepancy I'd observed between the times of FT8 decodes displayed in the Band
activity
window and the times recorded in the ALL.TXT file. The full
Uwe I guess I misunderstood your problem. I thought the colors
indicating needed calls etc were not correct after a band change. The
adi file should be read when WSJTX starts, but at times I have had to
rescan, for some reason, the file to make the colors respond to the
needed calls etc. Sorry
Have the Flex 6700 so have multiple instances open. Found switching
profiles just after the decode period works well and turning off the
monitor ICON will also assure no decodes from the previous band.
Hope this helps;
Bill
W2PKY
On Thu, Feb 20, 2020 at 10:17 AM Rich Zwirko - K1HTV
wrote:
> Uwe,
Here is what I mean:
http://www.dg2ycb.duckdns.org/wsjt-x_band_change_bug.mp4
IMO band changes make sense most, immediately when one RX cycle has been
finished, because of course I don't want to lose the next cycle. However, in
practice this means +- 1 second before or after the end of one cycle
Re: Rich Zwirko - K1HTV 2020-02-20
> If you use the "Blank lines between decode period" option,disregard the
> data below the separating dashed line which does NOT show the band on the
> right side of the line.
The point is, if wsjtx knows there was a band change with possibly
mixed decodes, why
To be more precise: The point is, that when doing a band change and the
decoding process is still running, from the millisecond of the band change
on, wsjt-x seems to allocate IMMEDIATELY all decodes to the NEW band, and
not to the old band from which the wav file has been recorded.
73 de Uwe, DG2
Uwe,
Remember that for FT8 WSJT-X records a WAV file for 13 seconds then
decodes it. If you switch bands in the middle of the receive cycle, you
will record a mix of stations from both bands into the WAV file. When it is
decoded, you will see a mix of decodes from both bands which you can't rely
Did you rescan the adi file under the colors tab? Settings>Colors>Rescan
ADIF File.
Bobby/N4AU
--
bob...@bellsouth.net
n...@arrl.net
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Hi Reino,
Makes no sense for me. Would be an easy task to let wsjt-x remember the old
cycle's band while decoding. In the past, JTAlert showed the same
misbehavior, but then it was fixed. Is working well since then, and
false-spotting due to band changes are successfully prevented.
73 de Uwe, DG2
Hi Uwe,
That is feature and it is recommended to stop monitoring for the duration of
band change and erase Band activity display.
73, Reino oh3mA
From: DG2YCB, Uwe [mailto:dg2...@gmx.de]
Sent: 20. helmikuuta 2020 12:20
To: wsjt-devel@lists.sourceforge.net
Subject: [wsjt-devel] Band change @
Hi Joe, Steve, Bill et al.,
I don't know if it's already known: At WSJT-X v2.1.2 0068f9 after changing
the band, remaining decodes of the old cycle are still falsely detected as
from the new band. And likely, these decodes are then also reported to PSK
Reporter or HamSpots for the wrong band. Woul
22 matches
Mail list logo