I don't think it's the location that is important but the "who's seeing me"
which doesn't care about your location. You just can't draw the traces without
it.This should only be done for CQ messages so very little traffic
increase.Philip probably maintains the last grid reported for a call sign but
it doesn't really matter for what these people are probably interested in
anyways.
de Mike W(MDB
On Friday, May 18, 2018, 3:36:47 AM CDT, Bill Somerville
<g4...@classdesign.com> 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 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 encoded as a
callsign but as the free text form (and there is no room for the grid). This
then doesn't get reported.
I wonder if the grid present requirement could be relaxed?
Thanks
Philip
Hi Philip.
there are two ways to encode messages containing supported compound callsigns
in the WSJT/WSJT-X modes, the one used depends on the prefix or suffix used.
They both have limitations on what other information can be included in
standard form messages because the prefix or suffix is partially stored in
parts of the message normally used for other things like the grid. Type 1
compound calls are those with the prefixes or suffixes shown in the WSJT-X
"Menu->Help->List of Type 1 prefixes and suffixes", these cannot send a grid
and their full callsign in the same standard message.
Type 2 compound callsigns are the rest of the supported compound callsigns,
these can send a grid in messages of the form "DE <type-2-compound-call>
<grid>", "CQ <type-2-compound-call> <grid>", and "QRZ <type-2-compound-call>
<grid>". Note that standard directional CQ calls like "CQ AS
<type-2-compound-call> <grid>" are not possible.
So these complaints are almost certainly coming from those using Type 1
compound callsigns. We could relax the restriction of only spotting to
PSKReporter decodes that contain grid information but I doubt you would like
that as the increase in traffic would be enormous and we would be vastly
increasing the inaccuracy of mapping. Another option is available to some Type
1 compound call holders, a Type 1 compound call can sometimes be converted to a
Type 2 compound callsign by moving a prefix to a suffix or choosing a prefix
that is still a valid form for the user but not in the Type 1 list of suffixes.
The former option may well be restricted by local licensing regulations i.e. a
1A/G4WJS (Type 1) call may not be able to be legally sent as G4WJS/1A (Type 2),
the latter option may not be available i.e. a US station in may sign as K/G4WJS
(Type 1) or switch to W/G4WJS (Type 2) but a maritime mobile signing G4WJS/MM
(Type 1) cannot sign as MM/G4WJS (Type 2) without docking in Scotland.
Another option, which may be the best one, could be to detect type 1 compound
callsigns in messages where normal or Type 2 callsign holders could send a
grid, e.g. "<his-call> <type-1-compond-call>" and "CQ <type-1-compound-call>"
and spot just those to PSKReporter. This would not increase the traffic
significantly but does need some extra processing on all decoded messages to
classify them as such.
Are you confident that the mapping accuracy will be sufficiently good on
PSKReporter without grid information, that would mean you processing every
possible prefix (note not just the Type 1 prefixes as you would get type 1
suffixes like /P without a grid too) to give a valid location. Also where are
you going to map them too?
73
Bill
G4WJS.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org!
http://sdm.link/slashdot_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
