Re: [wsjt-devel] PSKReporter and non-standard CQ messages

2018-05-18 Thread Bill Somerville 

Hi Philip,

the messages that normally have grids are CQ calls, replies to CQ calls, 
and QRZ messages. That accounts for roughly 33% of all messages. If we 
sent spots for all of those instead of just those with grid squares then 
the overall increase would be quite small as most of them already have 
grid squares.


There are often queries as to why stations don't get spotted on 
PSKReporter when they shorten QSO exchanges by not bothering to reply to 
CQ calls with a grid message, instead replying directly with a report. 
This technique shortens the QSO but replier never gets spotted, it would 
seem sensible to try and help these stations as well, the impact of that 
would be greater as we would have to spot all report messages as well 
and there will be at least one of those for every QSO. I think that 
would more than double the number of spots going to PSKReporter from WSJT-X.


73
Bill
G4WJS.

On 18/05/2018 13:28, Philip Gladstone wrote:
I already get a bunch of spots (from other modes) without locators. 
This will just encourage me to allow people to enter grids on 
pskreporter. I'm already think that I have to deal with the /B calls 
and just use the locator of the base callsign.


Do you really think that this would be a big increase in traffic? It 
would still be packets that have a CQ at the front -- correct?


Philip

On 18/05/2018 07:04, Black Michael via wsjt-devel wrote:
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 
 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 
 ", "CQ  ", 
and "QRZ  ". Note that standard 
directional CQ calls like "CQ AS  " 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. " " 
and "CQ " 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?

Re: [wsjt-devel] PSKReporter and non-standard CQ messages

2018-05-18 Thread Joe Taylor 

Hi Al and all,

On 5/18/2018 11:21 AM, Al Pawlowski K6AVP wrote:

Why not make the FT/JT messages a bit longer to accommodate the compound calls?

If a longer tx/rx cycle time would be needed for FT8 - up to 30s would be fine 
by me. It would be nice to have enough time to manually initiate a decodable CQ 
answer.

If a longer cycle time or message improved decode performance, that too would 
be nice. I do not remember yet having a FT8 decode below about -20, but 
regularly had  JT65’s below -25.


Of course longer messages are possible, in principle.

We think all the time about trade-offs involving such things as 
information packet size, data compression scheme, transmission length, 
decoder complexity, threshold S/N, false-decode rate, T/R turn-around 
interval, signal bandwidth, and channel characteristics.  Each mode 
currently supported in WSJT-X (and the various knock-off programs 
derived from WSJT-X) represents a different set of choices for the 
relevant algorithms and parameters.


Do keep in mind that while it takes only a few seconds to drop such a 
suggestion into an email to this list, it takes many person-months to 
develop and implement a new mode.


For every finished mode that you find in WSJT-X, there are several 
variations (and several completely different possibilities) that we 
tried and eventually rejected.


-- 73, Joe, K1JT

--
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

Re: [wsjt-devel] PSKReporter and non-standard CQ messages

2018-05-18 Thread Al Pawlowski 
Why not make the FT/JT messages a bit longer to accommodate the compound calls?

If a longer tx/rx cycle time would be needed for FT8 - up to 30s would be fine 
by me. It would be nice to have enough time to manually initiate a decodable CQ 
answer.  

If a longer cycle time or message improved decode performance, that too would 
be nice. I do not remember yet having a FT8 decode below about -20, but 
regularly had  JT65’s below -25.



Al Pawlowski, K6AVP
Los Osos, CA USA


--
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

Re: [wsjt-devel] PSKReporter and non-standard CQ messages

2018-05-18 Thread Philip Gladstone 
I already get a bunch of spots (from other modes) without locators. This 
will just encourage me to allow people to enter grids on pskreporter. 
I'm already think that I have to deal with the /B calls and just use the 
locator of the base callsign.


Do you really think that this would be a big increase in traffic? It 
would still be packets that have a CQ at the front -- correct?


Philip

On 18/05/2018 07:04, Black Michael via wsjt-devel wrote:
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 
 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 
 ", "CQ  ", 
and "QRZ  ". Note that standard 
directional CQ calls like "CQ AS  " 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. " " and "CQ 
" 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



--
Check out the vibrant tech community on one of the world's most
engaging tech sites,

Re: [wsjt-devel] PSKReporter and non-standard CQ messages

2018-05-18 Thread Black Michael via wsjt-devel 
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 
 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  
", "CQ  ", and "QRZ  
". Note that standard directional CQ calls like "CQ AS 
 " 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. " " and "CQ " 
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

Re: [wsjt-devel] PSKReporter and non-standard CQ messages

2018-05-18 Thread Bill Somerville 

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 
 ", "CQ  ", and 
"QRZ  ". Note that standard directional CQ 
calls like "CQ AS  " 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. " " and "CQ 
" 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

[wsjt-devel] PSKReporter and non-standard CQ messages

2018-05-17 Thread Philip Gladstone 
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


--
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