You don't say what OS you use but there is JTAlert for Windows.And GridTracker
and AlarmJT for Linux.
http://hamapps.com/
https://sourceforge.net/projects/alarmejt/
https://www.m0spn.co.uk/2020/02/01/gridtracker-a-jtalert-for-linux/
de Mike W9MDB
On Tuesday, May 12, 2020, 05:07:26 PM CDT, Gary Hinson <g...@isect.com>
wrote:
The OPTION to sort each 15 second batch of decodes by any of the message fields
or contents would be useful for DXers, Bill.
DXers are not necessarily keen to respond the very instant decodes appear:
sometimes, it is better to wait and watch a cycle or three, picking out DX
stations of interest in QSO, maybe turning the beam and then calling when
ready. DXing is more about listening and watching than transmitting!
‘Autorespond’ isn’t necessarily the best approach.
I can think of situations where, even if it took a while to do, it would be
useful to be able to re-sort the batches of messages by:
- dBs – DX signals are often weaker
- Frequency – perhaps trying to figure out who is behind a weak trace on the
waterfall, or a signal causing QRM to the DX I might be watching
- Callsign worked – to work out where the DX station is listening and
working other people, implying clear frequencies his end
- Callsign used* – an obvious way to find exotic or unusual DX stations, or
to hunt for decodes from a DX station that has been spotted on DXcluster
- Locator* [from CQs] – either to hunt for stations outside the normal
areas, maybe new states, or simply to collect grids
- Distance away – this isn’t currently shown but might be calculated from
the locator or estimated from the prefix, on the basis that DX is often distant
* An alternative, perhaps complementary approach would be to align the
displayed messages around the callsign used or locator (if present) rather than
simply all being left-aligned. That would make it easier to glance down the
decodes for interesting stations. So, instead of something like this:
213000 -10 0.2 1138 ~ CQ PE3T JO21
213000 -4 0.4 1862 ~ N1UL IZ2FDX JN25
213000 +2 -0.3 2598 ~ EL2BG JR3GWZ RR73
etc.
… which forces us to glance left and right to locate the fields of interest on
each line while speed-reading the latest batch of decodes, we would see:
213000 -10 0.2 1138 ~ CQ PE3T JO21
213000 -4 0.4 1862 ~ N1UL IZ2FDX JN25
213000 +2 -0.3 2598 ~ EL2BG JR3GWZ RR73
etc. [aligned by callsign used]
… or
213000 -10 0.2 1138 ~ CQ PE3T JO21
213000 -4 0.4 1862 ~ N1UL IZ2FDX JN25
213000 +2 -0.3 2598 ~ EL2BG JR3GWZ RR73
etc. [aligned by grid]
And for bonus marks, the aligned-by text might be shown in bold, drawing more
attention to them, or perhaps delineated with a subtle (e.g. 1 pixel wide grey)
vertical line immediately to its left.
The issue of the text jumping around on the screen as it is first
displayed-as-decoded then re-sorted-as-required, and hence the difficulty of
clicking on a specific line, would be lessened if updates (including display of
the next batch of messages received) were automatically frozen while the mouse
cursor is in that part of the screen, suggesting that the user is about to
click a decode. Mouse away to let it update and sort, mouse in to click a
specific line. Easy peasy! [I appreciate this might confuse newbies leading
to support calls about the messages being frozen, but they’d soon figure it out
for themselves! Maybe the screen freeze thing ought to be an ‘advanced
option’, disabled by default?]
73
Gary ZL2iFB
From: Bill Somerville <g4...@classdesign.com>
Sent: 13 May 2020 07:29
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] WSJT-X 2.2.0-rc1
On 12/05/2020 20:22, Christoph Berg wrote:
Re: Bill Somerville
this change is deliberate. Prior versions favour strong stations calling atthe
lowest audio offset, we think it is better to randomize the frequencyorder to
give all stations more equal weighting. This is particularly inrespect of the
"Call 1st" feature. There is also another factor, the latestFT8 decoder makes
up to three attempts at decoding, each doing up to threepasses. Each attempt
subtracts signals from prior attempts to reveal maskedsignals. There is no
sorting or randomizing across the attempts, theoverriding priority being to
print he decodes as soon as possible after theyare discovered.
Well that still favors the stronger stations. Was "calling at loweroffset"
something people were really rushing for, or did that have anybias towards them
in contests or crowded bands? What I wanted sometimes was a "favor callers
*not* on my txfrequency". (But that's probably an unrelated thing to this
change.) Another plus of the old ordering was that you could see the
threepasses and say "hey look it decoded this one because it subtracted
astronger signal first". The new ordering seems to be pretty messyinstead.
Christoph
Hi Christoph,
yes stronger signals may well be decoded on an earlier pass, but we cannot deal
with that without delaying the printing of any decodes until all decodes
attempts are completed, that would be very counterproductive given one feature
of the latest decoder is there to yield decodes before all transmissions are
completed. We could of course sort decodes continuously as they flow in, but
that would make the UI very confusing with decodes continuously shuffling just
as you are trying to read them. There is no optimal solution.
73
Bill
G4WJS.
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
