Re: [wsjt-devel] r2.2.2 Minor Issue with "short" calls that use DX

2020-08-21 Thread Stephen VK3SIR
Hi Core Developer Team,

For some time now I have been seeking guidance with patches for the Windows 
JTSDK 3.1 x64 with respect to upgrading Windows CMAKE to a more contemporary 
version found on many Linux distros (i.e. v3.14.4 is delivered in Greg KI7MT’s 
original files; v3.18.2 is the current release).

After releasing Alpha versions of scripts to support Qt 5.15.1 (at 
https://groups.io/g/JTSDK/topic/preview_version_0_4a_alpha/76299954?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,76299954
 ) - the latest set of “experiment” patches that can be applied to Greg Beam 
KI7MT’s JTSDK 3.1 x64 (to implement commands such as jtbuild) - I thought I 
would have another go.

I finally cracked it with steps documented at 
https://groups.io/g/JTSDK/topic/upgrading_jtsdk_3_1_packages/76339523?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,76339523
 .

[ For community Reference, basically it required two environment variables: 
FFTW3_LIBRARY needed to point to C:\JTSDK64-Tools\tools\fftw\libfftw3-3.dll and 
FFTW3F_LIBRARY to point to C:\JTSDK64-Tools\tools\fftw\libfftw3f-3.dll. These 
needed to be passed as additional parameters to “The CMAKE Prefix Path” so that 
CMAKE could locate libraries during preprocessing and use these libraries when 
compiling the C++ and Fortran code. ]

Behaviour is inconsistent across CMAKE versions; The CMakeLists.txt file works 
PERFECTLY with Windows CMAKE 3.14.4 … but additional parameters need be passed 
should you upgrade from this Windows version.

Can I please request that the CMakeLists.txt file in future releases be 
reviewed mindful of my observations on working to make the JTSDK 3.1 accessible 
to our community? CMakeFiles of the standard employed in WSJT-X r2.2.2 are only 
elementary to my expertise otherwise I’d do it myself.

Changes may not be needed and/or may not necessarily be desirable. Testing of 
this is VERY preliminary but on Windows has been rather extensive . I also 
recognise that what I request here can impact Linux and MacOS compiles.

Thanks, and there is no need to respond further.

73 and thanks.

Steve I
VK3VM / VK3SIR

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] r2.2.2 Minor Issue with "short" calls that use DX

2020-08-20 Thread Reino Talarmo
Hi All,

 

Interesting discussion, but it may be time to drew conclusions on the WSJT-X 
features point of view. 

1.   WSJT-X main target is to improve weak signal communication (minimum) 
information exchange.

2.   WSJT-X automatic sequencing should help user make QSOs, when protocol 
speed is challenging for human beings e.g. FT8 and FT4.

3.   WSJT-X should not replace operator and operator skills.

 

The last one means that operators should tolerate limitations such as false 
decodes and limitations how well external information (cty.dat) happens to 
identify country codes. (Support or non-support of special call signs belongs 
to that category, it has been another discussion.)

 

If additional help to users is wanted or needed e.g. to identify wrong call 
sign structures, false decodes and pirates, then that should be implemented 
outside WSJT-X in the same manner as e.g. JTAlert is done by other interested 
parties. 

 

73, Reino OH3mA

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] r2.2.2 Minor Issue with "short" calls that use DX

2020-08-19 Thread Neil Zampella

Um ... you just got it ... :)

Neil, KN3ILZ

On 8/19/2020 4:44 PM, jbozell wrote:


Well! This seemingly innocuous (but useful) thread has suddenly gotten
much more interesting. Popcorn please...who has the square for the
first person to say “if you don’t like it, scroll down”? 

73,

WB0CDY

*From: *Paul Randall 
*Reply-To: *WSJT software development 
*Date: *Wednesday, August 19, 2020 at 3:17 PM
*To: *WSJT software development 
*Subject: *Re: [wsjt-devel] r2.2.2 Minor Issue with "short" calls that
use DX

*[External Email]*

Actually, NO.

I've asked stupid questions on here, been pointed at the answer
elsewhere and regretted my lack of "go find it".

What I can say is I didn't make my questions into a boxed set, to be
enjoyed for a whole season.

If you've nothing better to do it may be a distraction but this forum
is purposed for "WSJT Software development"

WSJT software allows us all to use some extremely clever turnkey
signal processing software to make contacts on almost every band with
potentially minimal equipment. It does however still require operators
to have a tad more than minimal "pizzaz!"

A while back I saw CQs from (bogus) T3ST (bogus) - I'm sure I could
have complained here "why did I see this?" and who could have known
this was BOGUS (bogus callsign) BOGUS.  T3ST? who could have guessed?
BOGUS

So, if you are operating CW or SSB or AM or FM or RTTY or anything
else, and you hear a BOGUS (bogus) callsign, please don't expect your
morse key, or electronic keyer, or balanced modulator, or any other
modulator, to remove from you the need to identify the callsign as
BOGUS (bogus) or prevent you from replying.

WSJT software in conjunction with PSKReporter has revolutionised our
view of LF, VHF and UHF propagation. I worked Falklands on top band!
My neighbour was able to record transmissions from D4VHF Cape Verde on
2M for almost every day in June, a path length equivalent to Europe -
North America. I personally worked D4VHF on 70cm twice in July.
Transatlantic path length on 70cm??? Really?

Let's keep this channel open and clear for input to the software
development team for that purpose - software development, also keep in
mind WSJT software has a specific purpose and is not intended to be a
"go everywhere, do everything" answer for every possible scenario you
might experience. Licensed operator is still required.

Maybe a lot of these posts might be better sent to a WSJT user forum,
where operators can exchange experiences and gain understanding.

So,  I echo the OMs intention, let's rejoice in asking questions, but
please re-consider the bandwidth you are occupying, is it appropriate
or perhaps better elsewhere?

My 2p worth

Paul G3NJV



*From:*Carey Fisher 
*Sent:* 19 August 2020 20:36
*To:* WSJT software development 
*Subject:* Re: [wsjt-devel] r2.2.2 Minor Issue with "short" calls that
use DX

I find the discussion interesting.

73, Carey, WB4HXE

On Wed, Aug 19, 2020 at 2:42 PM Gary McDuffie mailto:mcduf...@ag0n.net>> wrote:


> On Aug 19, 2020, at 02:21, Stephen VK3SIR mailto:vk3...@hotmail.com>> wrote:
>
>
>

--
>
> Why has the stream been decoded (good) and the logic allowed it
to be identified – displayed - as coming from Morocco (bad)? The
station should not display that it has come from Morocco in the
first place as the call violates the rules of callsign structures
for that DXCC entity. That is the real point I am making here !
>
> —
>

Good grief!  Can this thread not die?  If you don’t know the call
and it looks bogus (yes it does) why are you even looking at it? 
Dimiss it and move on. There is supposed to be an operator at the
keyboard to interpret these things.

Gary - AG0N

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
<mailto:wsjt-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


--

Carey Fisher

careyfis...@gmail.com <mailto:careyfis...@gmail.com>

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] r2.2.2 Minor Issue with "short" calls that use DX

2020-08-19 Thread Stephen VK3SIR
Hey Kiddies,

Stop. End. I started this based on a genuine observation. Very useful and 
productive discussion - learning for many - has occurred. Likewise my intent 
has been clearly been established and teased out. There may be further 
discussion warranted, but most of what I am seeing is basically trolling now. 
Trolling is anti to what AR is really about yet is too often seen in our 
community.

This place is moderated; Moderators please step in heavily on any further 
non-productive discussion.

73

Steve I
VK3VM / VK3SIR
HAM – Help All Mankind

From: Paul Randall 
Sent: Thursday, 20 August 2020 8:38 AM
To: WSJT software development 
Subject: Re: [wsjt-devel] r2.2.2 Minor Issue with "short" calls that use DX

PLS QSY to PM for any chat or popcorn you must have; I believe this channel 
already in use for software development.
TKS 73s

From: jbozell via wsjt-devel 
mailto:wsjt-devel@lists.sourceforge.net>>
Sent: 19 August 2020 22:44
To: WSJT software development 
mailto:wsjt-devel@lists.sourceforge.net>>
Cc: jbozell mailto:jboz...@utk.edu>>
Subject: Re: [wsjt-devel] r2.2.2 Minor Issue with "short" calls that use DX


Well! This seemingly innocuous (but useful) thread has suddenly gotten much 
more interesting. Popcorn please...who has the square for the first person to 
say “if you don’t like it, scroll down”? 



73,



WB0CDY



From: Paul Randall mailto:paulfrand...@hotmail.com>>
Reply-To: WSJT software development 
mailto:wsjt-devel@lists.sourceforge.net>>
Date: Wednesday, August 19, 2020 at 3:17 PM
To: WSJT software development 
mailto:wsjt-devel@lists.sourceforge.net>>
Subject: Re: [wsjt-devel] r2.2.2 Minor Issue with "short" calls that use DX



[External Email]

Actually, NO.

I've asked stupid questions on here, been pointed at the answer elsewhere and 
regretted my lack of "go find it".

What I can say is I didn't make my questions into a boxed set, to be enjoyed 
for a whole season.

If you've nothing better to do it may be a distraction but this forum is 
purposed for "WSJT Software development"

WSJT software allows us all to use some extremely clever turnkey signal 
processing software to make contacts on almost every band with potentially 
minimal equipment. It does however still require operators to have a tad more 
than minimal "pizzaz!"



A while back I saw CQs from (bogus) T3ST (bogus) - I'm sure I could have 
complained here "why did I see this?" and who could have known this was BOGUS 
(bogus callsign) BOGUS.  T3ST? who could have guessed? BOGUS



So, if you are operating CW or SSB or AM or FM or RTTY or anything else, and 
you hear a BOGUS (bogus) callsign, please don't expect your morse key, or 
electronic keyer, or balanced modulator, or any other modulator, to remove from 
you the need to identify the callsign as BOGUS (bogus) or prevent you from 
replying.



WSJT software in conjunction with PSKReporter has revolutionised our view of 
LF, VHF and UHF propagation. I worked Falklands on top band! My neighbour was 
able to record transmissions from D4VHF Cape Verde on 2M for almost every day 
in June, a path length equivalent to Europe - North America. I personally 
worked D4VHF on 70cm twice in July. Transatlantic path length on 70cm??? Really?



Let's keep this channel open and clear for input to the software development 
team for that purpose - software development, also keep in mind WSJT software 
has a specific purpose and is not intended to be a "go everywhere, do 
everything" answer for every possible scenario you might experience. Licensed 
operator is still required.



Maybe a lot of these posts might be better sent to a WSJT user forum, where 
operators can exchange experiences and gain understanding.



So,  I echo the OMs intention, let's rejoice in asking questions, but please 
re-consider the bandwidth you are occupying, is it appropriate or perhaps 
better elsewhere?



My 2p worth



Paul G3NJV













From: Carey Fisher mailto:careyfis...@gmail.com>>
Sent: 19 August 2020 20:36
To: WSJT software development 
mailto:wsjt-devel@lists.sourceforge.net>>
Subject: Re: [wsjt-devel] r2.2.2 Minor Issue with "short" calls that use DX



I find the discussion interesting.

73, Carey, WB4HXE



On Wed, Aug 19, 2020 at 2:42 PM Gary McDuffie 
mailto:mcduf...@ag0n.net>> wrote:

> On Aug 19, 2020, at 02:21, Stephen VK3SIR 
> mailto:vk3...@hotmail.com>> wrote:
>
>
> --
>
> Why has the stream been decoded (good) and the logic allowed it to be 
> identified – displayed - as coming from Morocco (bad)? The station should not 
> display that it has come from Morocco in the first place as the call violates 
> the r

Re: [wsjt-devel] r2.2.2 Minor Issue with "short" calls that use DX

2020-08-19 Thread Paul Randall
PLS QSY to PM for any chat or popcorn you must have; I believe this channel 
already in use for software development.
TKS 73s

From: jbozell via wsjt-devel 
Sent: 19 August 2020 22:44
To: WSJT software development 
Cc: jbozell 
Subject: Re: [wsjt-devel] r2.2.2 Minor Issue with "short" calls that use DX


Well! This seemingly innocuous (but useful) thread has suddenly gotten much 
more interesting. Popcorn please...who has the square for the first person to 
say “if you don’t like it, scroll down”? 



73,



WB0CDY



From: Paul Randall 
Reply-To: WSJT software development 
Date: Wednesday, August 19, 2020 at 3:17 PM
To: WSJT software development 
Subject: Re: [wsjt-devel] r2.2.2 Minor Issue with "short" calls that use DX



[External Email]

Actually, NO.

I've asked stupid questions on here, been pointed at the answer elsewhere and 
regretted my lack of "go find it".

What I can say is I didn't make my questions into a boxed set, to be enjoyed 
for a whole season.

If you've nothing better to do it may be a distraction but this forum is 
purposed for "WSJT Software development"

WSJT software allows us all to use some extremely clever turnkey signal 
processing software to make contacts on almost every band with potentially 
minimal equipment. It does however still require operators to have a tad more 
than minimal "pizzaz!"



A while back I saw CQs from (bogus) T3ST (bogus) - I'm sure I could have 
complained here "why did I see this?" and who could have known this was BOGUS 
(bogus callsign) BOGUS.  T3ST? who could have guessed? BOGUS



So, if you are operating CW or SSB or AM or FM or RTTY or anything else, and 
you hear a BOGUS (bogus) callsign, please don't expect your morse key, or 
electronic keyer, or balanced modulator, or any other modulator, to remove from 
you the need to identify the callsign as BOGUS (bogus) or prevent you from 
replying.



WSJT software in conjunction with PSKReporter has revolutionised our view of 
LF, VHF and UHF propagation. I worked Falklands on top band! My neighbour was 
able to record transmissions from D4VHF Cape Verde on 2M for almost every day 
in June, a path length equivalent to Europe - North America. I personally 
worked D4VHF on 70cm twice in July. Transatlantic path length on 70cm??? Really?



Let's keep this channel open and clear for input to the software development 
team for that purpose - software development, also keep in mind WSJT software 
has a specific purpose and is not intended to be a "go everywhere, do 
everything" answer for every possible scenario you might experience. Licensed 
operator is still required.



Maybe a lot of these posts might be better sent to a WSJT user forum, where 
operators can exchange experiences and gain understanding.



So,  I echo the OMs intention, let's rejoice in asking questions, but please 
re-consider the bandwidth you are occupying, is it appropriate or perhaps 
better elsewhere?



My 2p worth



Paul G3NJV













From: Carey Fisher 
Sent: 19 August 2020 20:36
To: WSJT software development 
Subject: Re: [wsjt-devel] r2.2.2 Minor Issue with "short" calls that use DX



I find the discussion interesting.

73, Carey, WB4HXE



On Wed, Aug 19, 2020 at 2:42 PM Gary McDuffie 
mailto:mcduf...@ag0n.net>> wrote:

> On Aug 19, 2020, at 02:21, Stephen VK3SIR 
> mailto:vk3...@hotmail.com>> wrote:
>
>
> --
>
> Why has the stream been decoded (good) and the logic allowed it to be 
> identified – displayed - as coming from Morocco (bad)? The station should not 
> display that it has come from Morocco in the first place as the call violates 
> the rules of callsign structures for that DXCC entity. That is the real point 
> I am making here !
>
> —
>

Good grief!  Can this thread not die?  If you don’t know the call and it looks 
bogus (yes it does) why are you even looking at it?  Dimiss it and move on.  
There is supposed to be an operator at the keyboard to interpret these things.

Gary - AG0N

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net<mailto:wsjt-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/wsjt-devel




--

Carey Fisher

careyfis...@gmail.com<mailto:careyfis...@gmail.com>


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] r2.2.2 Minor Issue with "short" calls that use DX

2020-08-19 Thread jbozell via wsjt-devel
Well! This seemingly innocuous (but useful) thread has suddenly gotten much 
more interesting. Popcorn please...who has the square for the first person to 
say “if you don’t like it, scroll down”? 

73,

WB0CDY

From: Paul Randall 
Reply-To: WSJT software development 
Date: Wednesday, August 19, 2020 at 3:17 PM
To: WSJT software development 
Subject: Re: [wsjt-devel] r2.2.2 Minor Issue with "short" calls that use DX


[External Email]
Actually, NO.
I've asked stupid questions on here, been pointed at the answer elsewhere and 
regretted my lack of "go find it".
What I can say is I didn't make my questions into a boxed set, to be enjoyed 
for a whole season.
If you've nothing better to do it may be a distraction but this forum is 
purposed for "WSJT Software development"
WSJT software allows us all to use some extremely clever turnkey signal 
processing software to make contacts on almost every band with potentially 
minimal equipment. It does however still require operators to have a tad more 
than minimal "pizzaz!"

A while back I saw CQs from (bogus) T3ST (bogus) - I'm sure I could have 
complained here "why did I see this?" and who could have known this was BOGUS 
(bogus callsign) BOGUS.  T3ST? who could have guessed? BOGUS

So, if you are operating CW or SSB or AM or FM or RTTY or anything else, and 
you hear a BOGUS (bogus) callsign, please don't expect your morse key, or 
electronic keyer, or balanced modulator, or any other modulator, to remove from 
you the need to identify the callsign as BOGUS (bogus) or prevent you from 
replying.

WSJT software in conjunction with PSKReporter has revolutionised our view of 
LF, VHF and UHF propagation. I worked Falklands on top band! My neighbour was 
able to record transmissions from D4VHF Cape Verde on 2M for almost every day 
in June, a path length equivalent to Europe - North America. I personally 
worked D4VHF on 70cm twice in July. Transatlantic path length on 70cm??? Really?

Let's keep this channel open and clear for input to the software development 
team for that purpose - software development, also keep in mind WSJT software 
has a specific purpose and is not intended to be a "go everywhere, do 
everything" answer for every possible scenario you might experience. Licensed 
operator is still required.

Maybe a lot of these posts might be better sent to a WSJT user forum, where 
operators can exchange experiences and gain understanding.

So,  I echo the OMs intention, let's rejoice in asking questions, but please 
re-consider the bandwidth you are occupying, is it appropriate or perhaps 
better elsewhere?

My 2p worth

Paul G3NJV






From: Carey Fisher 
Sent: 19 August 2020 20:36
To: WSJT software development 
Subject: Re: [wsjt-devel] r2.2.2 Minor Issue with "short" calls that use DX

I find the discussion interesting.
73, Carey, WB4HXE

On Wed, Aug 19, 2020 at 2:42 PM Gary McDuffie 
mailto:mcduf...@ag0n.net>> wrote:

> On Aug 19, 2020, at 02:21, Stephen VK3SIR 
> mailto:vk3...@hotmail.com>> wrote:
>
>
> --
>
> Why has the stream been decoded (good) and the logic allowed it to be 
> identified – displayed - as coming from Morocco (bad)? The station should not 
> display that it has come from Morocco in the first place as the call violates 
> the rules of callsign structures for that DXCC entity. That is the real point 
> I am making here !
>
> —
>

Good grief!  Can this thread not die?  If you don’t know the call and it looks 
bogus (yes it does) why are you even looking at it?  Dimiss it and move on.  
There is supposed to be an operator at the keyboard to interpret these things.

Gary - AG0N

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net<mailto:wsjt-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


--
Carey Fisher
careyfis...@gmail.com<mailto:careyfis...@gmail.com>

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] r2.2.2 Minor Issue with "short" calls that use DX

2020-08-19 Thread Carey Fisher
Nevertheless, I still find this discussion interesting.
 73, Carey, WB4HXE

On Wed, Aug 19, 2020 at 5:20 PM Paul Randall 
wrote:

> Actually, NO.
> I've asked stupid questions on here, been pointed at the answer elsewhere
> and regretted my lack of "go find it".
> What I can say is I didn't make my questions into a boxed set, to be
> enjoyed for a whole season.
> If you've nothing better to do it may be a distraction but this forum is
> purposed for "WSJT Software development"
> WSJT software allows us all to use some extremely clever turnkey signal
> processing software to make contacts on almost every band with potentially
> minimal equipment. It does however still require operators to have a tad
> more than minimal "pizzaz!"
>
> A while back I saw CQs from (bogus) T3ST (bogus) - I'm sure I could have
> complained here "why did I see this?" and who could have known this was
> BOGUS (bogus callsign) BOGUS.  T3ST? who could have guessed? BOGUS
>
> So, if you are operating CW or SSB or AM or FM or RTTY or anything else,
> and you hear a BOGUS (bogus) callsign, please don't expect your morse key,
> or electronic keyer, or balanced modulator, or any other modulator, to
> remove from you the need to identify the callsign as BOGUS (bogus) or
> prevent you from replying.
>
> WSJT software in conjunction with PSKReporter has revolutionised our view
> of LF, VHF and UHF propagation. I worked Falklands on top band! My
> neighbour was able to record transmissions from D4VHF Cape Verde on 2M for
> almost every day in June, a path length equivalent to Europe - North
> America. I personally worked D4VHF on 70cm twice in July. Transatlantic
> path length on 70cm??? Really?
>
> Let's keep this channel open and clear for input to the software
> development team for that purpose - software development, also keep in mind
> WSJT software has a specific purpose and is not intended to be a "go
> everywhere, do everything" answer for every possible scenario you might
> experience. Licensed operator is still required.
>
> Maybe a lot of these posts might be better sent to a WSJT user forum,
> where operators can exchange experiences and gain understanding.
>
> So,  I echo the OMs intention, let's rejoice in asking questions, but
> please re-consider the bandwidth you are occupying, is it appropriate or
> perhaps better elsewhere?
>
> My 2p worth
>
> Paul G3NJV
>
>
>
>
>
> --
> *From:* Carey Fisher 
> *Sent:* 19 August 2020 20:36
> *To:* WSJT software development 
> *Subject:* Re: [wsjt-devel] r2.2.2 Minor Issue with "short" calls that
> use DX
>
> I find the discussion interesting.
> 73, Carey, WB4HXE
>
> On Wed, Aug 19, 2020 at 2:42 PM Gary McDuffie  wrote:
>
>
> > On Aug 19, 2020, at 02:21, Stephen VK3SIR  wrote:
> >
> >
> >
> --
> >
> > Why has the stream been decoded (good) and the logic allowed it to be
> identified – displayed - as coming from Morocco (bad)? The station should
> not display that it has come from Morocco in the first place as the call
> violates the rules of callsign structures for that DXCC entity. That is the
> real point I am making here !
> >
> > —
> >
>
> Good grief!  Can this thread not die?  If you don’t know the call and it
> looks bogus (yes it does) why are you even looking at it?  Dimiss it and
> move on.  There is supposed to be an operator at the keyboard to interpret
> these things.
>
> Gary - AG0N
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
>
>
> --
> Carey Fisher
> careyfis...@gmail.com
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>


-- 
Carey Fisher
careyfis...@gmail.com
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] r2.2.2 Minor Issue with "short" calls that use DX

2020-08-19 Thread Paul Randall
Actually, NO.
I've asked stupid questions on here, been pointed at the answer elsewhere and 
regretted my lack of "go find it".
What I can say is I didn't make my questions into a boxed set, to be enjoyed 
for a whole season.
If you've nothing better to do it may be a distraction but this forum is 
purposed for "WSJT Software development"
WSJT software allows us all to use some extremely clever turnkey signal 
processing software to make contacts on almost every band with potentially 
minimal equipment. It does however still require operators to have a tad more 
than minimal "pizzaz!"

A while back I saw CQs from (bogus) T3ST (bogus) - I'm sure I could have 
complained here "why did I see this?" and who could have known this was BOGUS 
(bogus callsign) BOGUS.  T3ST? who could have guessed? BOGUS

So, if you are operating CW or SSB or AM or FM or RTTY or anything else, and 
you hear a BOGUS (bogus) callsign, please don't expect your morse key, or 
electronic keyer, or balanced modulator, or any other modulator, to remove from 
you the need to identify the callsign as BOGUS (bogus) or prevent you from 
replying.

WSJT software in conjunction with PSKReporter has revolutionised our view of 
LF, VHF and UHF propagation. I worked Falklands on top band! My neighbour was 
able to record transmissions from D4VHF Cape Verde on 2M for almost every day 
in June, a path length equivalent to Europe - North America. I personally 
worked D4VHF on 70cm twice in July. Transatlantic path length on 70cm??? Really?

Let's keep this channel open and clear for input to the software development 
team for that purpose - software development, also keep in mind WSJT software 
has a specific purpose and is not intended to be a "go everywhere, do 
everything" answer for every possible scenario you might experience. Licensed 
operator is still required.

Maybe a lot of these posts might be better sent to a WSJT user forum, where 
operators can exchange experiences and gain understanding.

So,  I echo the OMs intention, let's rejoice in asking questions, but please 
re-consider the bandwidth you are occupying, is it appropriate or perhaps 
better elsewhere?

My 2p worth

Paul G3NJV






From: Carey Fisher 
Sent: 19 August 2020 20:36
To: WSJT software development 
Subject: Re: [wsjt-devel] r2.2.2 Minor Issue with "short" calls that use DX

I find the discussion interesting.
73, Carey, WB4HXE

On Wed, Aug 19, 2020 at 2:42 PM Gary McDuffie 
mailto:mcduf...@ag0n.net>> wrote:

> On Aug 19, 2020, at 02:21, Stephen VK3SIR 
> mailto:vk3...@hotmail.com>> wrote:
>
>
> --
>
> Why has the stream been decoded (good) and the logic allowed it to be 
> identified – displayed - as coming from Morocco (bad)? The station should not 
> display that it has come from Morocco in the first place as the call violates 
> the rules of callsign structures for that DXCC entity. That is the real point 
> I am making here !
>
> —
>

Good grief!  Can this thread not die?  If you don’t know the call and it looks 
bogus (yes it does) why are you even looking at it?  Dimiss it and move on.  
There is supposed to be an operator at the keyboard to interpret these things.

Gary - AG0N

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net<mailto:wsjt-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


--
Carey Fisher
careyfis...@gmail.com<mailto:careyfis...@gmail.com>

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] r2.2.2 Minor Issue with "short" calls that use DX

2020-08-19 Thread Carey Fisher
I find the discussion interesting.
73, Carey, WB4HXE

On Wed, Aug 19, 2020 at 2:42 PM Gary McDuffie  wrote:

>
> > On Aug 19, 2020, at 02:21, Stephen VK3SIR  wrote:
> >
> >
> >
> --
> >
> > Why has the stream been decoded (good) and the logic allowed it to be
> identified – displayed - as coming from Morocco (bad)? The station should
> not display that it has come from Morocco in the first place as the call
> violates the rules of callsign structures for that DXCC entity. That is the
> real point I am making here !
> >
> > —
> >
>
> Good grief!  Can this thread not die?  If you don’t know the call and it
> looks bogus (yes it does) why are you even looking at it?  Dimiss it and
> move on.  There is supposed to be an operator at the keyboard to interpret
> these things.
>
> Gary - AG0N
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>


-- 
Carey Fisher
careyfis...@gmail.com
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] r2.2.2 Minor Issue with "short" calls that use DX

2020-08-19 Thread Gary McDuffie

> On Aug 19, 2020, at 02:21, Stephen VK3SIR  wrote:
> 
> 
> --
>  
> Why has the stream been decoded (good) and the logic allowed it to be 
> identified – displayed - as coming from Morocco (bad)? The station should not 
> display that it has come from Morocco in the first place as the call violates 
> the rules of callsign structures for that DXCC entity. That is the real point 
> I am making here !
>  
> —
> 

Good grief!  Can this thread not die?  If you don’t know the call and it looks 
bogus (yes it does) why are you even looking at it?  Dimiss it and move on.  
There is supposed to be an operator at the keyboard to interpret these things.  

Gary - AG0N

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] r2.2.2 Minor Issue with "short" calls that use DX

2020-08-19 Thread Stephen VK3SIR
Claude,

Excellent suggestion. Your method set here at the point of display is the most 
efficient and generalist - but will prevent some non-standard but valid calls 
getting through. That will help me with some other projects I am working on so 
I cannot thank you enough ! For this project, memory implications of 
implementing a hashed-table validation system [ easily deployed via many C++ 
libraries ] should be negligible on modern systems - if this functionality do 
not exist or are not there already.

Neil,

It took a while to key the key issue across that the issue was far from an 
end-user error ... and the product of what is most likely a source-user-error. 
By-products were heavily observed by a group of us VK’s … We see things that 
many of you do not in your parts; we do not have the "local knowledge" that 
people have used to identify issues here. We seek DX from places that many in 
other parts of the world consider to be 'everyday' contacts. Ahhh. the 
wonders of propagation ...

This example here has been exceedingly valuable, in my opinion, to the whole AR 
programming fraternity. This is why I have continued respond and tease it out !

➢ The issue that occurred only happens if someone does not use the program 
properly, 

So questions should be raised and processes to mitigate issues considered - and 
that is the point: considered - in order to help end users without specific 
local knowledge. At the same time these processes could have potential - with 
little resource and performance trade-off - to aid heavily with false decodes 
(which has been my point for a while).

Many of us are highly technical people and see things in different contexts; 
sometimes (and I say this arrogantly) we need to step backwards and observe 
issues from the perspective of less technically adept end users to get the 
best, simplest and most robust outcomes... That has also been one of my recent 
points.

You are right in my opinion as the point has been made and sustained - with 
Claude's response proving that the point has registered across our community. 
But isn't vibrant and productive discussion that teases out issues mega 
constructive for us as a community and for our reputation?

73, and thanks to all positive contributors.

(and yes this is possibly the right time to end this thread)

Steve I
VK3VM /VK3SIR

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] r2.2.2 Minor Issue with "short" calls that use DX

2020-08-19 Thread Claude Frantz

On 8/19/20 4:12 PM, Neil Zampella wrote:


The logic would need to be able to
distinguish between a valid callsign, and something that LOOKS like a
valid callsign but isn't.


As I have mentioned previously, I'm using the following regex test in perl:

if ( $hash{"CALL"} =~ 
'^((([A-PR-Z][A-Z]*[0-9]*[A-Z]?)|([1-9][A-Z]+[0-9]*))\/)?(([A-PR-Z

][A-Z]*[0-9]+[A-Z]+)|([1-9][A-Z]+[0-9]+[A-Z]+))(\/([PMA0-9]|MM|(([A-Z]+[0-9]*[A-Z]?)|([1-9][A-Z]+[0-9]*?
$' ) {
}
else {
   say STDERR '=== Probably an erroneous callsign ', $hash{"CALL"} ;
}

This will not work well for ANY callsign, but for most ones.

Best wishes,
Claude (DJ0OT)


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] r2.2.2 Minor Issue with "short" calls that use DX

2020-08-19 Thread Neil Zampella

Since Tx5 is can be used for "Free Text", adding any sort of 'callsign
check' would be hard to implement as anything can, and often is entered
into that message box. The logic would need to be able to
distinguish between a valid callsign, and something that LOOKS like a
valid callsign but isn't.

Frankly, thread is getting out of hand.    The issue that occurred only
happens if someone does not use the program properly, which usually
means they did not take the time to read the User Guide and the sections
that cover this 7.2, and 10.5.
https://physics.princeton.edu/pulsar/K1JT/wsjtx-doc/wsjtx-main-2.2.2.html

Neil, KN3ILZ

On 8/19/2020 7:27 AM, Frode Igland wrote:

Steve,
My apologies that I hadn't noticed that Reino had already explained
the invalid call sign. I should have read all the messages this
morning before I responded to your e-mail.

I guess that we may wish that the WSJT-X algorithm for identifying the
DXCC entity should have had a checkpoint that the call sign is at all
valid (involving at least the prefix and number), prior to identifying
the DXCC entity (I guess the current method is to look at the first
2-3 characters after "CQ " from Tx6 or "CQ DX " from Tx5). As this was
a case from Tx5, we know the message after "CQ DX " must conform to
the special standards required to allow more than 13 characters, or it
will be considered free text and truncated beyond 13 characters.

As Tx5 obviously did not accept 5CT as a call sign, there must already
be some sort of "valid call sign check", at least in that message,
otherwise it would have been sent as an ordinary CQ DX message from
Tx5 with an untruncated locator. I have no idea whether a general
"valid call sign check" to avoid DXCC entity identification of invalid
call signs is a simple matter to include, or if it may slow down
decoding or have other undesirable effects in WSJT-X.

Nor do I know whether a "valid call sign check" is needed, as
identifying call signs not conforming to call sign format standards
may be something that should be left to the operator's attention and
consideration, not the computer's logic. We don't have to automate
everything just because it may be possible to do it. I guess Bill, Joe
et al. will look into the matter and decide whether this issue makes
it to the priority list.

73 Frode LA6VQ


ons. 19. aug. 2020 kl. 10:25 skrev Stephen VK3SIR mailto:vk3...@hotmail.com>>:

Frode and The Community-at-large,

Yes its invalid – the discussion has clearly identified that and I
suspected that at the first post. The community has done a great
job in clarifying this not only just for me but also lots of others.

No more discussion needed on that subject of the callsign validity
forever as it is repetitive and it has been most clearly identified ….

WSJT-X has correctly prevented Tx response to the station…. Good Job J

But… There is a point that many of you are missing here and that I
am trying to get across … So I’ll place this in a container for
clarity:


--

Why has the stream been decoded (good) and the logic allowed it to
be identified – displayed - as coming from Morocco (bad)? The
station should not display that it has come from Morocco in the
first place as the call violates the rules of callsign structures
for that DXCC entity. That is the real point I am making here !


--

There are many ways that this could be adjusted when the codebase
for r2.2.2 is examined with some methods having greater impact
than others to the codebase – If this behaviour has not been
addressed already with other tweaks that may have entered the
codebase > r2.2.2 (which we know is awaiting the Hamlib go).

There is no point posting changes to the codebase as it is closed
… what I could post may upset something else unknown to me. So
therefore we have to post “anomalies identified” and rely on the
intelligence of our core development team to consider, rate and
implement changes if necessary.

Many many many posts of mine have been about refactoring logic to
prevent and eliminate false decodes and user confusion. This is a
false lead issue reported here created a user confusion issue in a
number of stations at the time that contacted me (Remember many of
us hunt DX in packs !). I could validate the confusion issue when
it presented itself. Therefore I have a responsibility to report
the matter to the community !!!

Almost all my posts are around improving utility especially for
the “learner” and decreasing end-user confusion J

73

Steve I

VK3VM / VK3SIR

___
wsjt-devel mailing list

Re: [wsjt-devel] r2.2.2 Minor Issue with "short" calls that use DX

2020-08-19 Thread Stephen VK3SIR
Frode,

All is extremely good and productive; it has been an invigorating and 
enlightening discussion. Most of the discussion has been within the Spirit of 
HAM – Help All Mankind. ☺

All I have done is have a look at code … and taken a brief look “into the 
crystal ball” knowing that “to every action there is an opposite and equal 
reaction”. I have tried to come up with a mitigation strategy – for exploration 
- that may have the least impact upon operations and performance yet also 
enhance end user reliability … all to improve end-user experience.

73

Steve I
VK3VM / VK3SIR
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] r2.2.2 Minor Issue with "short" calls that use DX

2020-08-19 Thread Frode Igland
Steve,
My apologies that I hadn't noticed that Reino had already explained the
invalid call sign. I should have read all the messages this morning before
I responded to your e-mail.

I guess that we may wish that the WSJT-X algorithm for identifying the DXCC
entity should have had a checkpoint that the call sign is at all valid
(involving at least the prefix and number), prior to identifying the DXCC
entity (I guess the current method is to look at the first 2-3 characters
after "CQ " from Tx6 or "CQ DX " from Tx5). As this was a case from Tx5, we
know the message after "CQ DX " must conform to the special standards
required to allow more than 13 characters, or it will be considered free
text and truncated beyond 13 characters.

As Tx5 obviously did not accept 5CT as a call sign, there must already be
some sort of "valid call sign check", at least in that message, otherwise
it would have been sent as an ordinary CQ DX message from Tx5 with an
untruncated locator. I have no idea whether a general "valid call sign
check" to avoid DXCC entity identification of invalid call signs is a
simple matter to include, or if it may slow down decoding or have other
undesirable effects in WSJT-X.

Nor do I know whether a "valid call sign check" is needed, as identifying
call signs not conforming to call sign format standards may be something
that should be left to the operator's attention and consideration, not the
computer's logic. We don't have to automate everything just because it may
be possible to do it. I guess Bill, Joe et al. will look into the matter
and decide whether this issue makes it to the priority list.

73 Frode LA6VQ


ons. 19. aug. 2020 kl. 10:25 skrev Stephen VK3SIR :

> Frode and The Community-at-large,
>
>
>
> Yes its invalid – the discussion has clearly identified that and I
> suspected that at the first post. The community has done a great job in
> clarifying this not only just for me but also lots of others.
>
> No more discussion needed on that subject of the callsign validity forever
> as it is repetitive and it has been most clearly identified ….
>
>
>
> WSJT-X has correctly prevented Tx response to the station…. Good Job J
>
>
>
> But… There is a point that many of you are missing here and that I am
> trying to get across … So I’ll place this in a container for clarity:
>
>
>
>
> --
>
>
>
> Why has the stream been decoded (good) and the logic allowed it to be
> identified – displayed - as coming from Morocco (bad)? The station should
> not display that it has come from Morocco in the first place as the call
> violates the rules of callsign structures for that DXCC entity. That is the
> real point I am making here !
>
>
>
>
> --
>
>
>
> There are many ways that this could be adjusted when the codebase for
> r2.2.2 is examined with some methods having greater impact than others to
> the codebase – If this behaviour has not been addressed already with other
> tweaks that may have entered the codebase > r2.2.2 (which we know is
> awaiting the Hamlib go).
>
> There is no point posting changes to the codebase as it is closed … what I
> could post may upset something else unknown to me. So therefore we have to
> post “anomalies identified” and rely on the intelligence of our core
> development team to consider, rate and implement changes if necessary.
>
>
>
> Many many many posts of mine have been about refactoring logic to prevent
> and eliminate false decodes and user confusion. This is a false lead issue
> reported here created a user confusion issue in a number of stations at the
> time that contacted me (Remember many of us hunt DX in packs !). I could
> validate the confusion issue when it presented itself. Therefore I have a
> responsibility to report the matter to the community !!!
>
>
>
> Almost all my posts are around improving utility especially for the
> “learner” and decreasing end-user confusion J
>
>
>
> 73
>
>
>
> Steve I
>
> VK3VM / VK3SIR
> ___
> 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


Re: [wsjt-devel] r2.2.2 Minor Issue with "short" calls that use DX

2020-08-19 Thread Stephen VK3SIR
Frode and The Community-at-large,

Yes its invalid – the discussion has clearly identified that and I suspected 
that at the first post. The community has done a great job in clarifying this 
not only just for me but also lots of others.

No more discussion needed on that subject of the callsign validity forever as 
it is repetitive and it has been most clearly identified ….

WSJT-X has correctly prevented Tx response to the station…. Good Job ☺

But… There is a point that many of you are missing here and that I am trying to 
get across … So I’ll place this in a container for clarity:

--

Why has the stream been decoded (good) and the logic allowed it to be 
identified – displayed - as coming from Morocco (bad)? The station should not 
display that it has come from Morocco in the first place as the call violates 
the rules of callsign structures for that DXCC entity. That is the real point I 
am making here !

--

There are many ways that this could be adjusted when the codebase for r2.2.2 is 
examined with some methods having greater impact than others to the codebase – 
If this behaviour has not been addressed already with other tweaks that may 
have entered the codebase > r2.2.2 (which we know is awaiting the Hamlib go).

There is no point posting changes to the codebase as it is closed … what I 
could post may upset something else unknown to me. So therefore we have to post 
“anomalies identified” and rely on the intelligence of our core development 
team to consider, rate and implement changes if necessary.

Many many many posts of mine have been about refactoring logic to prevent and 
eliminate false decodes and user confusion. This is a false lead issue reported 
here created a user confusion issue in a number of stations at the time that 
contacted me (Remember many of us hunt DX in packs !). I could validate the 
confusion issue when it presented itself. Therefore I have a responsibility to 
report the matter to the community !!!

Almost all my posts are around improving utility especially for the “learner” 
and decreasing end-user confusion ☺

73

Steve I
VK3VM / VK3SIR
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] r2.2.2 Minor Issue with "short" calls that use DX

2020-08-19 Thread Frode Igland
Steve,
The issue with 5CT is that it is not a valid amateur call sign. That
requires a Prefix, a Number and a Suffix. The Prefix must have 1-2
characters of which one character must be a letter. The Suffix can be
longer, but must also have at least one letter.

If 5C is the Prefix (which belongs to Morocco), the Number is missing. If 5
is the Number, the Prefix is missing.

The invalid call sign caused WSJT-X to interpret the message as free text,
truncating anything beyond 13 characters, including the last digit of the
locator. Free text messages has no predefined format and therefore no
automatic recognition of call sign and locator, so clicking or
double-clicking does not fill the "DX Call" and "DX Grid" fields, which are
the data sources for generating standard messages and for logging.

A call sign like N7W qualifies as an amateur radio call sign and creates no
problem.

73 Frode LA6VQ

tir. 18. aug. 2020, 13:55 skrev Stephen VK3SIR :

> Frode,
>
>
>
> Thanks … By not “picking up” I was meaning you could not click,
> double-click or even use a third-party product via the UDP interface to
> force WSJT-X to place WSJT-X into a Tx2 mode that should have responded to
> the call. It’s a damn shame that I could not catch the call quickly enough
> (again) to get a recording of the stream.
>
> Recorders are on now … Hopefully someone else out there has seen this, has
> it and can supply?
>
>
>
>- I had no problem sending any of the Tx1 - Tx5 messages with 5CT in
>the DX Call field and JN0 in the DX Grid field.
>
>
>
> The problem is not sending; it’s the program being able to RESPOND through
> WSJT-X to 5CT sent as an attempted Tx1 ! It was not just me seeing this -
> which is why I responded with a report here.
>
>
>
>- First of all 5CT is not a valid call sign.
>
>
>
> It may or it may not be … It COULD have been allocated. But I have been
> responding to a number of calls that now fit this template i.e. N7C (
> https://www.qrz.com/db/n7c ) is a VERY valid and sought after call. I was
> able to make contact with that station but not this one !
>
>
>
> 73
>
>
>
> Steve I
>
> VK3VM / Vk3SIR
>
>
>
>
>
> *From:* Frode Igland 
> *Sent:* Tuesday, 18 August 2020 9:08 PM
> *To:* WSJT software development 
> *Subject:* Re: [wsjt-devel] r2.2.2 Minor Issue with "short" calls that
> use DX
>
>
>
> Steve, I guess that your statement "WSJT-X will not pick up this call"
> means that WSJT-X will not *automatically *enter this call into the "DX
> Call" field, nor the locator into the "DX Grid" field. That is true, but
> WSJT-X will certainly pick up the call and grid as decoded if you enter it
> manually into the two fields. WSJT-X does not care how the call and grid
> arrives in the two fields, but once they are there they are used as entered.
>
> I had no problem sending any of the Tx1 - Tx5 messages with 5CT in the DX
> Call field and JN0 in the DX Grid field.
>
>
>
> Secondly, and all important here, it 5CT is not in accordance with the
> WSJT-X defintions and algorithms for what constitutes a call sign as
> defined in
> https://physics.princeton.edu/pulsar/k1jt/wsjtx-doc/wsjtx-main-2.2.2.html#PROTOCOL_OVERVIEW
> . Consequently, all my messages were sent as free text messages truncated
> at 13 characters, which is just right.
>
>
>
> 73 Frode LA6VQ
>
>
>
> tir. 18. aug. 2020 kl. 08:11 skrev Stephen VK3SIR :
>
> Hi Folks,
>
> I am unsure whether this has been reported:
>
> 30m:
>
> 055130 -11  0.2 1626 ~  CQ CO8LY FL20  Cuba
> 055130 -17  0.3 1342 ~  R3BV F1LYV RR73
> 055130 -19  0.3  618 ~  CQ DX 5CT JN0  Morocco  <-- Will not allow
> this to be picked this up
> 055200 -12  0.2 1627 ~  CQ CO8LY FL20  Cuba
>
> No matter what you do or how you try to pick up this calling station and
> pick up its call (i.e. click on it, double click, even use JTAlert) WSJT-X
> will not pick up this call !
>
> I can see that this is being primarily interpreted as a text message (i.e.
> > 13 chars) ... with the call framed in a " bad" format (missing the final
> char of the maidenhead).
>
> [ It is fully understandable and understood why the logic will not allow
> this call to be picked up as the truncated maidenhead is confusing things ]
>
> Unfortunately I do not have a recording of this to post back ...
>
> The screen is going nuts here with PM's so it needs be reported.
>
> 73
>
> Steve I
> VK3VM / Vk3SIR
>
> ___
> 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
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] r2.2.2 Minor Issue with "short" calls that use DX

2020-08-18 Thread Stephen VK3SIR
Patrick and all constructive responders,

Interesting discussion ( “That’s Nice” … some behaviour that many are trying 
hard to eliminate from AR is emerging ) … The main reason that I questioned it 
as a “by design” related to the fact that WSJT-X identified it as from Morocco 
- yet later in activity blocked response. If you refer to the original post I 
expressed scepticism in the first place.

As response was blocked that indicates by-design in the logic. Perhaps the 
logic that blocked response should apply earlier and should not have permitted 
country identification?

I can foresee a refactor of logic as a way of further assisting with 
elimination of false decodes – something that I have expressed considerable 
concerns about consistently.

I wanted to try to tease that out in the discussion … I have had to come clean 
as trolling has commenced !!! ;-)

73

Steve I
VK3VM / VK3SIR

From: Patrick 9A5CW 
Sent: Wednesday, 19 August 2020 4:32 AM
To: WSJT software development 
Subject: Re: [wsjt-devel] r2.2.2 Minor Issue with "short" calls that use DX

Hi all and Steve,

It took me 5 seconds or less to solve a partial callsign. As an HF+6m and UP 
contester and DX hunter i rember well some valid very active callsigns and dxcc 
prefixes. I cant remember all grid squares but i know when is false or not or 
field is out of country or continent. It's good to take a look at world wide 
grid map and rember how are big fields placed b4 posting such question. I see 
many posts around the net and social media when people post false decodes and 
similar decoded stuff.
Sometimes I laugh and I ask myself how did they get a licence or pass the exam?
If i have free time I always try to teach or learn myself something new.
And of course try that in practice.


Your decodes are not false, it is the operator fault who did make a mistake.
It does happens ;) (leadings space, non supported character, etc..)
There is no software on the market which is not Lidsproof ;) joke

Wish you all the best,
73 Patrik 9A5CW





uto, 18. kol 2020. 16:21 Stephen VK3SIR 
mailto:vk3...@hotmail.com>> je napisao:
Enrico,

Exactly… but how do we know what currently is valid when the rules are bent by 
regulators every day? The point of the initial post was to tease out of the 
community whether this was designed behaviour or whether this was bi-product 
i.e. to draw out understanding of behaviour not only for me but others. 
Welcoming discussion has successfully achieved this.

The ”detective” work from Patrick 9A5CW was nothing short of brilliant !

But… hidden in my question was the premise that not all nations stick to the 
rules  i.e.: The recently FIXED VKxFXXX issue here in VK and “Special event” 
calls. Not all nations are recognised (i.e. D1) yet they decode.

Report what one sees as an anomaly and the supportive community is here (though 
has been very quiet of late) to promote learning, encourage and welcome others 
and their contribution. The references to documentation here (repeated) are 
extremely helpful to me and others that asked questions of me. I did not know … 
so … I asked.

The environ must always be kept open, free and conducive for contribution.


  *   little bit of know how should sit behind the monitor

That is a bit harsh; one who purports to know all can be best described as a 
fool …  Likewise “for every rule there are always exceptions” (refer to the 
i.e. above in the case of AR callsigns).

Our licenses and software that we use (such as WSJT-X) are about 
experimentation and learning; teaching – with questioning -  is vital to 
learning. Some of us came through academic environs where one’s knuckles were 
very red if we questioned – as it was seen as an attack on authority and 
“superiority”. Yet most Amateurs are subject to vastly different theory from 
our modern academic age; in most free questioning is promoted and not 
suppressed by the fear and bullying endemic of the past.

I only bite those that suppress and bully others … I bite hard when someone is 
bulled for questioning. I also bite-back at ignorance and intolerance. The 
bullies should be bitten.

HAM – help All Mankind. This discussion has helped me and others so thanks to 
all – especially with the exact references in the docs that I profess to not 
have been able to put my fingers on immediately.

73

Steve I
VK3VM / VK3SIR

From: Enrico mailto:oe1...@oevsv.at>>
Sent: Tuesday, 18 August 2020 10:50 PM
To: WSJT software development 
mailto:wsjt-devel@lists.sourceforge.net>>
Subject: Re: [wsjt-devel] r2.2.2 Minor Issue with "short" calls that use DX

Steve, a little bit of know how should sit behind the monitor.
A callsign is designated as country code + number + minimum 1 letter. So 5CT is 
definitely a false decode.
73
Enrico, OE1EQW
Holen Sie sich Outlook für Android<https://aka.ms/ghei36>


On Tue, Aug 18, 2020 at 2:41 PM +0200, "Stephen VK3SIR" 
mailto:vk3...@hotmail.com>> wrote

Re: [wsjt-devel] r2.2.2 Minor Issue with "short" calls that use DX

2020-08-18 Thread Carey Fisher
That's nice.
73, Carey, WB4HXE

On Tue, Aug 18, 2020 at 2:35 PM Patrick 9A5CW  wrote:

> Hi all and Steve,
>
> It took me 5 seconds or less to solve a partial callsign. As an HF+6m and
> UP contester and DX hunter i rember well some valid very active callsigns
> and dxcc prefixes. I cant remember all grid squares but i know when is
> false or not or field is out of country or continent. It's good to take a
> look at world wide grid map and rember how are big fields placed b4 posting
> such question. I see many posts around the net and social media when people
> post false decodes and similar decoded stuff.
> Sometimes I laugh and I ask myself how did they get a licence or pass the
> exam?
> If i have free time I always try to teach or learn myself something new.
> And of course try that in practice.
>
>
> Your decodes are not false, it is the operator fault who did make a
> mistake.
> It does happens ;) (leadings space, non supported character, etc..)
> There is no software on the market which is not Lidsproof ;) joke
>
> Wish you all the best,
> 73 Patrik 9A5CW
>
>
>
>
>
> uto, 18. kol 2020. 16:21 Stephen VK3SIR  je napisao:
>
>> Enrico,
>>
>>
>>
>> Exactly… but how do we know what currently is valid when the rules are
>> bent by regulators every day? The point of the initial post was to tease
>> out of the community whether this was designed behaviour or whether this
>> was bi-product i.e. to draw out understanding of behaviour not only for me
>> but others. Welcoming discussion has successfully achieved this.
>>
>>
>>
>> The ”detective” work from Patrick 9A5CW was nothing short of brilliant !
>>
>> But… hidden in my question was the premise that not all nations stick to
>> the rules  i.e.: The recently FIXED VKxFXXX issue here in VK and “Special
>> event” calls. Not all nations are recognised (i.e. D1) yet they decode.
>>
>>
>>
>> Report what one sees as an anomaly and the supportive community is here
>> (though has been very quiet of late) to promote learning, encourage and
>> welcome others and their contribution. The references to documentation here
>> (repeated) are extremely helpful to me and others that asked questions of
>> me. I did not know … so … I asked.
>>
>> The environ must always be kept open, free and conducive for contribution.
>>
>>
>>
>>- little bit of know how should sit behind the monitor
>>
>>
>>
>> That is a bit harsh; one who purports to know all can be best described
>> as a fool …  Likewise “for every rule there are always exceptions” (refer
>> to the i.e. above in the case of AR callsigns).
>>
>> Our licenses and software that we use (such as WSJT-X) are about
>> experimentation and learning; teaching – with questioning -  is vital to
>> learning. Some of us came through academic environs where one’s knuckles
>> were very red if we questioned – as it was seen as an attack on authority
>> and “superiority”. Yet most Amateurs are subject to vastly different theory
>> from our modern academic age; in most free questioning is promoted and not
>> suppressed by the fear and bullying endemic of the past.
>>
>>
>>
>> I only bite those that suppress and bully others … I bite hard when
>> someone is bulled for questioning. I also bite-back at ignorance and
>> intolerance. The bullies should be bitten.
>>
>>
>>
>> HAM – help All Mankind. This discussion has helped me and others so
>> thanks to all – especially with the exact references in the docs that I
>> profess to not have been able to put my fingers on immediately.
>>
>>
>>
>> 73
>>
>>
>>
>> Steve I
>>
>> VK3VM / VK3SIR
>>
>>
>>
>> *From:* Enrico 
>> *Sent:* Tuesday, 18 August 2020 10:50 PM
>> *To:* WSJT software development 
>> *Subject:* Re: [wsjt-devel] r2.2.2 Minor Issue with "short" calls that
>> use DX
>>
>>
>>
>> Steve, a little bit of know how should sit behind the monitor.
>>
>> A callsign is designated as country code + number + minimum 1 letter. So
>> 5CT is definitely a false decode.
>>
>> 73
>>
>> Enrico, OE1EQW
>>
>> Holen Sie sich Outlook für Android <https://aka.ms/ghei36>
>>
>>
>>
>>
>>
>> On Tue, Aug 18, 2020 at 2:41 PM +0200, "Stephen VK3SIR" <
>> vk3...@hotmail.com> wrote:
>>
>> Patrick,
>>
>>
>>
>>- It is F5CT in JN08.
>>
>>
>> Great detective work… and WSJT-X working as it

Re: [wsjt-devel] r2.2.2 Minor Issue with "short" calls that use DX

2020-08-18 Thread Reino Talarmo
Hi All,

The key issue is that the 5CT call sign does not fit with the source coding of 
call signs. The third character needs to be a number. The 'third' is seen as 
second in call signs commencing with K, G etc. as then the first one marked to 
be empty. See Protocol specifications at 17.1. of User Guide.

So on the source coding point of view there is no call sign and the message is 
encoded as free text (with the 13 character limit).

73, Reino OH3mA

1>I suspect its due more to the fact that he was using the Tx5 message with its 
13 character limit, and not the Tx6 which allows the addition of up to 4 
characters between the 'CQ' and the callsign, and will also include the full 4 
character grid in the transmission.

Neil, KN3ILZ

On 8/18/2020 2:34 AM, 5p1kzx Michael wrote:
> Hi Steve
>
> I don't think that 5CT is a valid callsign. A search on the Internet 
> gave no result.
>
> 73 de Michael 5p1kzx
>
>
> Den 18-08-2020 kl. 08:06 skrev Stephen VK3SIR:
>> Hi Folks,
>>
>> I am unsure whether this has been reported:
>>
>> 30m:
>>
>> 055130 -11  0.2 1626 ~  CQ CO8LY FL20  Cuba
>> 055130 -17  0.3 1342 ~  R3BV F1LYV RR73
>> 055130 -19  0.3  618 ~  CQ DX 5CT JN0  Morocco  <-- Will not 
>> allow this to be picked this up
>> 055200 -12  0.2 1627 ~  CQ CO8LY FL20  Cuba
>>
>> No matter what you do or how you try to pick up this calling station 
>> and pick up its call (i.e. click on it, double click, even use
>> JTAlert) WSJT-X will not pick up this call !
>>
>> I can see that this is being primarily interpreted as a text message 
>> (i.e. > 13 chars) ... with the call framed in a " bad" format 
>> (missing the final char of the maidenhead).
>>
>> [ It is fully understandable and understood why the logic will not 
>> allow this call to be picked up as the truncated maidenhead is 
>> confusing things ]
>>
>> Unfortunately I do not have a recording of this to post back ...
>>
>> The screen is going nuts here with PM's so it needs be reported.
>>
>> 73
>>
>> Steve I
>> VK3VM / Vk3SIR
>>
>> ___
>> 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



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] r2.2.2 Minor Issue with "short" calls that use DX

2020-08-18 Thread Patrick 9A5CW
Hi all and Steve,

It took me 5 seconds or less to solve a partial callsign. As an HF+6m and
UP contester and DX hunter i rember well some valid very active callsigns
and dxcc prefixes. I cant remember all grid squares but i know when is
false or not or field is out of country or continent. It's good to take a
look at world wide grid map and rember how are big fields placed b4 posting
such question. I see many posts around the net and social media when people
post false decodes and similar decoded stuff.
Sometimes I laugh and I ask myself how did they get a licence or pass the
exam?
If i have free time I always try to teach or learn myself something new.
And of course try that in practice.


Your decodes are not false, it is the operator fault who did make a mistake.
It does happens ;) (leadings space, non supported character, etc..)
There is no software on the market which is not Lidsproof ;) joke

Wish you all the best,
73 Patrik 9A5CW





uto, 18. kol 2020. 16:21 Stephen VK3SIR  je napisao:

> Enrico,
>
>
>
> Exactly… but how do we know what currently is valid when the rules are
> bent by regulators every day? The point of the initial post was to tease
> out of the community whether this was designed behaviour or whether this
> was bi-product i.e. to draw out understanding of behaviour not only for me
> but others. Welcoming discussion has successfully achieved this.
>
>
>
> The ”detective” work from Patrick 9A5CW was nothing short of brilliant !
>
> But… hidden in my question was the premise that not all nations stick to
> the rules  i.e.: The recently FIXED VKxFXXX issue here in VK and “Special
> event” calls. Not all nations are recognised (i.e. D1) yet they decode.
>
>
>
> Report what one sees as an anomaly and the supportive community is here
> (though has been very quiet of late) to promote learning, encourage and
> welcome others and their contribution. The references to documentation here
> (repeated) are extremely helpful to me and others that asked questions of
> me. I did not know … so … I asked.
>
> The environ must always be kept open, free and conducive for contribution.
>
>
>
>- little bit of know how should sit behind the monitor
>
>
>
> That is a bit harsh; one who purports to know all can be best described as
> a fool …  Likewise “for every rule there are always exceptions” (refer to
> the i.e. above in the case of AR callsigns).
>
> Our licenses and software that we use (such as WSJT-X) are about
> experimentation and learning; teaching – with questioning -  is vital to
> learning. Some of us came through academic environs where one’s knuckles
> were very red if we questioned – as it was seen as an attack on authority
> and “superiority”. Yet most Amateurs are subject to vastly different theory
> from our modern academic age; in most free questioning is promoted and not
> suppressed by the fear and bullying endemic of the past.
>
>
>
> I only bite those that suppress and bully others … I bite hard when
> someone is bulled for questioning. I also bite-back at ignorance and
> intolerance. The bullies should be bitten.
>
>
>
> HAM – help All Mankind. This discussion has helped me and others so thanks
> to all – especially with the exact references in the docs that I profess to
> not have been able to put my fingers on immediately.
>
>
>
> 73
>
>
>
> Steve I
>
> VK3VM / VK3SIR
>
>
>
> *From:* Enrico 
> *Sent:* Tuesday, 18 August 2020 10:50 PM
> *To:* WSJT software development 
> *Subject:* Re: [wsjt-devel] r2.2.2 Minor Issue with "short" calls that
> use DX
>
>
>
> Steve, a little bit of know how should sit behind the monitor.
>
> A callsign is designated as country code + number + minimum 1 letter. So
> 5CT is definitely a false decode.
>
> 73
>
> Enrico, OE1EQW
>
> Holen Sie sich Outlook für Android <https://aka.ms/ghei36>
>
>
>
>
>
> On Tue, Aug 18, 2020 at 2:41 PM +0200, "Stephen VK3SIR" <
> vk3...@hotmail.com> wrote:
>
> Patrick,
>
>
>
>- It is F5CT in JN08.
>
>
> Great detective work… and WSJT-X working as it should by blocking an
> invalid from being responded to !
>
>
> 73
>
>
> Steve I
>
> VK3VM / VK3SIR
>
>
> [ Ps: Sorry I almost missed the email! ]
>
>
>
> *From:* Patrick 9A5CW 
> *Sent:* Tuesday, 18 August 2020 7:35 PM
> *To:* WSJT software development 
> *Subject:* Re: [wsjt-devel] r2.2.2 Minor Issue with "short" calls that
> use DX
>
>
>
> Hi,
>
> Nothing wrong with a call ;)
>
> It is F5CT in JN08.
>
> He probably messed up his setup in WSJT-X or any other similar problem.
>
> Best regards and RR73 9A5CW
>
>
>

Re: [wsjt-devel] r2.2.2 Minor Issue with "short" calls that use DX

2020-08-18 Thread Neil Zampella

I suspect its due more to the fact that he was using the Tx5 message
with its 13 character limit, and not the Tx6 which allows the addition
of up to 4 characters between the 'CQ' and the callsign, and will also
include the full 4 character grid in the transmission.

Neil, KN3ILZ

On 8/18/2020 2:34 AM, 5p1kzx Michael wrote:

Hi Steve

I don't think that 5CT is a valid callsign. A search on the Internet
gave no result.

73 de Michael 5p1kzx


Den 18-08-2020 kl. 08:06 skrev Stephen VK3SIR:

Hi Folks,

I am unsure whether this has been reported:

30m:

055130 -11  0.2 1626 ~  CQ CO8LY FL20  Cuba
055130 -17  0.3 1342 ~  R3BV F1LYV RR73
055130 -19  0.3  618 ~  CQ DX 5CT JN0  Morocco  <-- Will not
allow this to be picked this up
055200 -12  0.2 1627 ~  CQ CO8LY FL20  Cuba

No matter what you do or how you try to pick up this calling station
and pick up its call (i.e. click on it, double click, even use
JTAlert) WSJT-X will not pick up this call !

I can see that this is being primarily interpreted as a text message
(i.e. > 13 chars) ... with the call framed in a " bad" format
(missing the final char of the maidenhead).

[ It is fully understandable and understood why the logic will not
allow this call to be picked up as the truncated maidenhead is
confusing things ]

Unfortunately I do not have a recording of this to post back ...

The screen is going nuts here with PM's so it needs be reported.

73

Steve I
VK3VM / Vk3SIR

___
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


Re: [wsjt-devel] r2.2.2 Minor Issue with "short" calls that use DX

2020-08-18 Thread Stephen VK3SIR
Enrico,

Exactly… but how do we know what currently is valid when the rules are bent by 
regulators every day? The point of the initial post was to tease out of the 
community whether this was designed behaviour or whether this was bi-product 
i.e. to draw out understanding of behaviour not only for me but others. 
Welcoming discussion has successfully achieved this.

The ”detective” work from Patrick 9A5CW was nothing short of brilliant !

But… hidden in my question was the premise that not all nations stick to the 
rules  i.e.: The recently FIXED VKxFXXX issue here in VK and “Special event” 
calls. Not all nations are recognised (i.e. D1) yet they decode.

Report what one sees as an anomaly and the supportive community is here (though 
has been very quiet of late) to promote learning, encourage and welcome others 
and their contribution. The references to documentation here (repeated) are 
extremely helpful to me and others that asked questions of me. I did not know … 
so … I asked.

The environ must always be kept open, free and conducive for contribution.


  *   little bit of know how should sit behind the monitor

That is a bit harsh; one who purports to know all can be best described as a 
fool …  Likewise “for every rule there are always exceptions” (refer to the 
i.e. above in the case of AR callsigns).

Our licenses and software that we use (such as WSJT-X) are about 
experimentation and learning; teaching – with questioning -  is vital to 
learning. Some of us came through academic environs where one’s knuckles were 
very red if we questioned – as it was seen as an attack on authority and 
“superiority”. Yet most Amateurs are subject to vastly different theory from 
our modern academic age; in most free questioning is promoted and not 
suppressed by the fear and bullying endemic of the past.

I only bite those that suppress and bully others … I bite hard when someone is 
bulled for questioning. I also bite-back at ignorance and intolerance. The 
bullies should be bitten.

HAM – help All Mankind. This discussion has helped me and others so thanks to 
all – especially with the exact references in the docs that I profess to not 
have been able to put my fingers on immediately.

73

Steve I
VK3VM / VK3SIR

From: Enrico 
Sent: Tuesday, 18 August 2020 10:50 PM
To: WSJT software development 
Subject: Re: [wsjt-devel] r2.2.2 Minor Issue with "short" calls that use DX

Steve, a little bit of know how should sit behind the monitor.
A callsign is designated as country code + number + minimum 1 letter. So 5CT is 
definitely a false decode.
73
Enrico, OE1EQW
Holen Sie sich Outlook für Android<https://aka.ms/ghei36>



On Tue, Aug 18, 2020 at 2:41 PM +0200, "Stephen VK3SIR" 
mailto:vk3...@hotmail.com>> wrote:
Patrick,


  *   It is F5CT in JN08.

Great detective work… and WSJT-X working as it should by blocking an invalid 
from being responded to !


73

Steve I
VK3VM / VK3SIR

[ Ps: Sorry I almost missed the email! ]

From: Patrick 9A5CW mailto:pat.9a...@gmail.com>>
Sent: Tuesday, 18 August 2020 7:35 PM
To: WSJT software development 
mailto:wsjt-devel@lists.sourceforge.net>>
Subject: Re: [wsjt-devel] r2.2.2 Minor Issue with "short" calls that use DX

Hi,
Nothing wrong with a call ;)
It is F5CT in JN08.
He probably messed up his setup in WSJT-X or any other similar problem.
Best regards and RR73 9A5CW

uto, 18. kol 2020. 10:05 Stephen VK3SIR 
mailto:vk3...@hotmail.com>> je napisao:
Michael,

True and very possible. I have just done the polite thing and reported 
observations - though I suspect WSJT-X behaviour is more than valid. I have 
reported this just in case its not occurring by design as that can lead to 
problems later down the track :-)

[ Yet WSJT-X will also pick up the very common station D1DX - that is not a 
recognised DXCC entity ... I am not buying into that argument !!! ].

There has been a lot of changes in postfixing and a growth of "prefix-x" and 
"prefix-xx" template calls of late (including here in VK where prefix-X will 
become available for Club/Contest stations for 12 months max only). This 
observation may offer some forewarning (if required) ...

I was in the midst of working a frenzy of EU contacts on 30m late this 
afternoon when PM's (i.e. mostly Skype) went nuts at people trying to get this 
supposed "Moroccan" station and could not get WSJT-X  to pick up the call. It 
is not a false decode as it was seen a number of times (i.e. around 10 from my 
log). Morocco is rare and highly desirable in these parts.

I verified this behaviour myself. I also run JTAlert ... and even that would 
not allow one to notionally grab "5CT" ...

The JN0 is obviously a truncation and roughly translates to the region -  and I 
STATE ROUGHLY (but not perfectly); that significantly tips evidence in the 
direction that you are suggesting !

So yes I have doubt too and had doubt before posting ! My concer

Re: [wsjt-devel] r2.2.2 Minor Issue with "short" calls that use DX

2020-08-18 Thread Enrico
Steve, a little bit of know how should sit behind the monitor. 


A callsign is designated as country code + number + minimum 1 letter. So 5CT is 
definitely a false decode.


73


Enrico, OE1EQW 




Holen Sie sich Outlook für Android







On Tue, Aug 18, 2020 at 2:41 PM +0200, "Stephen VK3SIR"  
wrote:




















Patrick,


 

It is F5CT in JN08.




Great detective work… and WSJT-X working as it should by blocking an invalid 
from being responded to !







73




Steve I


VK3VM / VK3SIR




[ Ps: Sorry I almost missed the email! ]


 



From: Patrick 9A5CW 


Sent: Tuesday, 18 August 2020 7:35 PM

To: WSJT software development 

Subject: Re: [wsjt-devel] r2.2.2 Minor Issue with "short" calls that use DX



 



Hi,



Nothing wrong with a call ;)




It is F5CT in JN08.




He probably messed up his setup in WSJT-X or any other similar problem.




Best regards and RR73 9A5CW 




 




uto, 18. kol 2020. 10:05 Stephen VK3SIR  je napisao:




Michael,



True and very possible. I have just done the polite thing and reported 
observations - though I suspect WSJT-X behaviour is more than valid. I have 
reported this just in case its not occurring by design as that can lead to 
problems later down the track :-)



[ Yet WSJT-X will also pick up the very common station D1DX - that is not a 
recognised DXCC entity ... I am not buying into that argument !!! ].



There has been a lot of changes in postfixing and a growth of "prefix-x" and 
"prefix-xx" template calls of late (including here in VK where prefix-X will 
become available for Club/Contest stations for 12 months max only). This 
observation may offer some forewarning
 (if required) ...



I was in the midst of working a frenzy of EU contacts on 30m late this 
afternoon when PM's (i.e. mostly Skype) went nuts at people trying to get this 
supposed "Moroccan" station and could not get WSJT-X  to pick up the call. It 
is not a false decode as it was
 seen a number of times (i.e. around 10 from my log). Morocco is rare and 
highly desirable in these parts.




I verified this behaviour myself. I also run JTAlert ... and even that would 
not allow one to notionally grab "5CT" ...




The JN0 is obviously a truncation and roughly translates to the region -  and I 
STATE ROUGHLY (but not perfectly); that significantly tips evidence in the 
direction that you are suggesting !



So yes I have doubt too and had doubt before posting ! My concern more the fact 
that it could not be picked up in any shape or form and responded to that 
prompted the post ... and also the knowledge of what I have posted in the 3rd 
sentence here !



73



Steve I

VK3VM / VK3SIR



-Original Message-

From: 5p1kzx Michael <5p1...@gmail.com>


Sent: Tuesday, 18 August 2020 5:35 PM

To: wsjt-devel@lists.sourceforge.net

Subject: Re: [wsjt-devel] r2.2.2 Minor Issue with "short" calls that use DX



Hi Steve



I don't think that 5CT is a valid callsign. A search on the Internet gave no 
result.



73 de Michael 5p1kzx





Den 18-08-2020 kl. 08:06 skrev Stephen VK3SIR:

> Hi Folks,

>

> I am unsure whether this has been reported:

>

> 30m:

>

> 055130 -11  0.2 1626 ~  CQ CO8LY FL20      Cuba

> 055130 -17  0.3 1342 ~  R3BV F1LYV RR73

> 055130 -19  0.3  618 ~  CQ DX 5CT JN0      Morocco  <-- Will not allow this 
> to be picked this up

> 055200 -12  0.2 1627 ~  CQ CO8LY FL20      Cuba

>

> No matter what you do or how you try to pick up this calling station and pick 
> up its call (i.e. click on it, double click, even use JTAlert) WSJT-X will 
> not pick up this call !

>

> I can see that this is being primarily interpreted as a text message (i.e. > 
> 13 chars) ... with the call framed in a " bad" format (missing the final char 
> of the maidenhead).

>

> [ It is fully understandable and understood why the logic will not 

> allow this call to be picked up as the truncated maidenhead is 

> confusing things ]

>

> Unfortunately I do not have a recording of this to post back ...

>

> The screen is going nuts here with PM's so it needs be reported.

>

> 73

>

> Steve I

> VK3VM / Vk3SIR

>

> ___

> 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





___

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


Re: [wsjt-devel] r2.2.2 Minor Issue with "short" calls that use DX

2020-08-18 Thread Reino Talarmo
Hi Steve,

5CT is not a valid RA call sign as the third character is not a number, when 
the first character is a number or one of those country codes such as N, G etc. 
 That’s why it is not source coded properly and recognized as a call sign and 
double clicking don’t work for you; message is a free text one and human beings 
are happy, but not WSJT-X. Further information in User Guide section 17.1. 

73, Reino OH3mA

 

*  First of all 5CT is not a valid call sign.

 

It may or it may not be … It COULD have been allocated. But I have been 
responding to a number of calls that now fit this template i.e. N7C ( 
https://www.qrz.com/db/n7c ) is a VERY valid and sought after call. I was able 
to make contact with that station but not this one !

 

73

 

Steve I

VK3VM / Vk3SIR

 

 

From: Frode Igland mailto:frodeigla...@gmail.com> > 
Sent: Tuesday, 18 August 2020 9:08 PM
To: WSJT software development mailto:wsjt-devel@lists.sourceforge.net> >
Subject: Re: [wsjt-devel] r2.2.2 Minor Issue with "short" calls that use DX

 

Steve, I guess that your statement "WSJT-X will not pick up this call" means 
that WSJT-X will not automatically enter this call into the "DX Call" field, 
nor the locator into the "DX Grid" field. That is true, but WSJT-X will 
certainly pick up the call and grid as decoded if you enter it manually into 
the two fields. WSJT-X does not care how the call and grid arrives in the two 
fields, but once they are there they are used as entered.

I had no problem sending any of the Tx1 - Tx5 messages with 5CT in the DX Call 
field and JN0 in the DX Grid field. 

 

Secondly, and all important here, it 5CT is not in accordance with the WSJT-X 
defintions and algorithms for what constitutes a call sign as defined in 
https://physics.princeton.edu/pulsar/k1jt/wsjtx-doc/wsjtx-main-2.2.2.html#PROTOCOL_OVERVIEW
 . Consequently, all my messages were sent as free text messages truncated at 
13 characters, which is just right.  

 

73 Frode LA6VQ

 

tir. 18. aug. 2020 kl. 08:11 skrev Stephen VK3SIR mailto:vk3...@hotmail.com> >:

Hi Folks,

I am unsure whether this has been reported:

30m:

055130 -11  0.2 1626 ~  CQ CO8LY FL20  Cuba
055130 -17  0.3 1342 ~  R3BV F1LYV RR73
055130 -19  0.3  618 ~  CQ DX 5CT JN0  Morocco  <-- Will not allow this to 
be picked this up
055200 -12  0.2 1627 ~  CQ CO8LY FL20  Cuba

No matter what you do or how you try to pick up this calling station and pick 
up its call (i.e. click on it, double click, even use JTAlert) WSJT-X will not 
pick up this call !

I can see that this is being primarily interpreted as a text message (i.e. > 13 
chars) ... with the call framed in a " bad" format (missing the final char of 
the maidenhead).

[ It is fully understandable and understood why the logic will not allow this 
call to be picked up as the truncated maidenhead is confusing things ]

Unfortunately I do not have a recording of this to post back ...

The screen is going nuts here with PM's so it needs be reported.

73

Steve I
VK3VM / Vk3SIR

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net <mailto: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


Re: [wsjt-devel] r2.2.2 Minor Issue with "short" calls that use DX

2020-08-18 Thread Stephen VK3SIR
Patrick,


  *   It is F5CT in JN08.

Great detective work… and WSJT-X working as it should by blocking an invalid 
from being responded to !

73

Steve I
VK3VM / VK3SIR

[ Ps: Sorry I almost missed the email! ]

From: Patrick 9A5CW 
Sent: Tuesday, 18 August 2020 7:35 PM
To: WSJT software development 
Subject: Re: [wsjt-devel] r2.2.2 Minor Issue with "short" calls that use DX

Hi,
Nothing wrong with a call ;)
It is F5CT in JN08.
He probably messed up his setup in WSJT-X or any other similar problem.
Best regards and RR73 9A5CW

uto, 18. kol 2020. 10:05 Stephen VK3SIR 
mailto:vk3...@hotmail.com>> je napisao:
Michael,

True and very possible. I have just done the polite thing and reported 
observations - though I suspect WSJT-X behaviour is more than valid. I have 
reported this just in case its not occurring by design as that can lead to 
problems later down the track :-)

[ Yet WSJT-X will also pick up the very common station D1DX - that is not a 
recognised DXCC entity ... I am not buying into that argument !!! ].

There has been a lot of changes in postfixing and a growth of "prefix-x" and 
"prefix-xx" template calls of late (including here in VK where prefix-X will 
become available for Club/Contest stations for 12 months max only). This 
observation may offer some forewarning (if required) ...

I was in the midst of working a frenzy of EU contacts on 30m late this 
afternoon when PM's (i.e. mostly Skype) went nuts at people trying to get this 
supposed "Moroccan" station and could not get WSJT-X  to pick up the call. It 
is not a false decode as it was seen a number of times (i.e. around 10 from my 
log). Morocco is rare and highly desirable in these parts.

I verified this behaviour myself. I also run JTAlert ... and even that would 
not allow one to notionally grab "5CT" ...

The JN0 is obviously a truncation and roughly translates to the region -  and I 
STATE ROUGHLY (but not perfectly); that significantly tips evidence in the 
direction that you are suggesting !

So yes I have doubt too and had doubt before posting ! My concern more the fact 
that it could not be picked up in any shape or form and responded to that 
prompted the post ... and also the knowledge of what I have posted in the 3rd 
sentence here !

73

Steve I
VK3VM / VK3SIR

-Original Message-
From: 5p1kzx Michael <5p1...@gmail.com<mailto:5p1...@gmail.com>>
Sent: Tuesday, 18 August 2020 5:35 PM
To: wsjt-devel@lists.sourceforge.net<mailto:wsjt-devel@lists.sourceforge.net>
Subject: Re: [wsjt-devel] r2.2.2 Minor Issue with "short" calls that use DX

Hi Steve

I don't think that 5CT is a valid callsign. A search on the Internet gave no 
result.

73 de Michael 5p1kzx


Den 18-08-2020 kl. 08:06 skrev Stephen VK3SIR:
> Hi Folks,
>
> I am unsure whether this has been reported:
>
> 30m:
>
> 055130 -11  0.2 1626 ~  CQ CO8LY FL20  Cuba
> 055130 -17  0.3 1342 ~  R3BV F1LYV RR73
> 055130 -19  0.3  618 ~  CQ DX 5CT JN0  Morocco  <-- Will not allow this 
> to be picked this up
> 055200 -12  0.2 1627 ~  CQ CO8LY FL20  Cuba
>
> No matter what you do or how you try to pick up this calling station and pick 
> up its call (i.e. click on it, double click, even use JTAlert) WSJT-X will 
> not pick up this call !
>
> I can see that this is being primarily interpreted as a text message (i.e. > 
> 13 chars) ... with the call framed in a " bad" format (missing the final char 
> of the maidenhead).
>
> [ It is fully understandable and understood why the logic will not
> allow this call to be picked up as the truncated maidenhead is
> confusing things ]
>
> Unfortunately I do not have a recording of this to post back ...
>
> The screen is going nuts here with PM's so it needs be reported.
>
> 73
>
> Steve I
> VK3VM / Vk3SIR
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net<mailto:wsjt-devel@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net<mailto:wsjt-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net<mailto: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


Re: [wsjt-devel] r2.2.2 Minor Issue with "short" calls that use DX

2020-08-18 Thread George J Molnar
JN0 is not a valid grid (you should enter at least four characters). Even so, 
2.2.2 will allow you to enter both an “invalid” call and grid in the DX Call 
and DX Grid boxes, press Generate Std Msgs, and call the station. Yo may need 
to manually step through the QSO cycle, but it WILL work.

5CT is NOT a valid callsign format, but N7C is. It’s not the length, it’s the 
format that counts. Looking through DX spots lately, I don’t see a 5CT 
operation spotted anywhere. Is it possible you had a false decode?

George/KF2T



> On Aug 18, 2020, at 7:51 AM, Stephen VK3SIR  wrote:
> 
> Frode,
>  
> Thanks … By not “picking up” I was meaning you could not click, double-click 
> or even use a third-party product via the UDP interface to force WSJT-X to 
> place WSJT-X into a Tx2 mode that should have responded to the call. It’s a 
> damn shame that I could not catch the call quickly enough (again) to get a 
> recording of the stream. 
> 
> Recorders are on now … Hopefully someone else out there has seen this, has it 
> and can supply?
>  
> I had no problem sending any of the Tx1 - Tx5 messages with 5CT in the DX 
> Call field and JN0 in the DX Grid field.
>  
> The problem is not sending; it’s the program being able to RESPOND through 
> WSJT-X to 5CT sent as an attempted Tx1 ! It was not just me seeing this - 
> which is why I responded with a report here.
>  
> First of all 5CT is not a valid call sign.
>  
> It may or it may not be … It COULD have been allocated. But I have been 
> responding to a number of calls that now fit this template i.e. N7C ( 
> https://www.qrz.com/db/n7c <https://www.qrz.com/db/n7c> ) is a VERY valid and 
> sought after call. I was able to make contact with that station but not this 
> one !
>  
> 73
>  
> Steve I
> VK3VM / Vk3SIR
>  
>  
> From: Frode Igland mailto:frodeigla...@gmail.com>> 
> Sent: Tuesday, 18 August 2020 9:08 PM
> To: WSJT software development  <mailto:wsjt-devel@lists.sourceforge.net>>
> Subject: Re: [wsjt-devel] r2.2.2 Minor Issue with "short" calls that use DX
>  
> Steve, I guess that your statement "WSJT-X will not pick up this call" means 
> that WSJT-X will not automatically enter this call into the "DX Call" field, 
> nor the locator into the "DX Grid" field. That is true, but WSJT-X will 
> certainly pick up the call and grid as decoded if you enter it manually into 
> the two fields. WSJT-X does not care how the call and grid arrives in the two 
> fields, but once they are there they are used as entered.
> I had no problem sending any of the Tx1 - Tx5 messages with 5CT in the DX 
> Call field and JN0 in the DX Grid field.
>  
> Secondly, and all important here, it 5CT is not in accordance with the WSJT-X 
> defintions and algorithms for what constitutes a call sign as defined in 
> https://physics.princeton.edu/pulsar/k1jt/wsjtx-doc/wsjtx-main-2.2.2.html#PROTOCOL_OVERVIEW
>  
> <https://physics.princeton.edu/pulsar/k1jt/wsjtx-doc/wsjtx-main-2.2.2.html#PROTOCOL_OVERVIEW>
>  . Consequently, all my messages were sent as free text messages truncated at 
> 13 characters, which is just right. 
>  
> 73 Frode LA6VQ
>  
> tir. 18. aug. 2020 kl. 08:11 skrev Stephen VK3SIR  <mailto:vk3...@hotmail.com>>:
> Hi Folks,
> 
> I am unsure whether this has been reported:
> 
> 30m:
> 
> 055130 -11  0.2 1626 ~  CQ CO8LY FL20  Cuba
> 055130 -17  0.3 1342 ~  R3BV F1LYV RR73
> 055130 -19  0.3  618 ~  CQ DX 5CT JN0  Morocco  <-- Will not allow this 
> to be picked this up
> 055200 -12  0.2 1627 ~  CQ CO8LY FL20  Cuba
> 
> No matter what you do or how you try to pick up this calling station and pick 
> up its call (i.e. click on it, double click, even use JTAlert) WSJT-X will 
> not pick up this call !
> 
> I can see that this is being primarily interpreted as a text message (i.e. > 
> 13 chars) ... with the call framed in a " bad" format (missing the final char 
> of the maidenhead).
> 
> [ It is fully understandable and understood why the logic will not allow this 
> call to be picked up as the truncated maidenhead is confusing things ]
> 
> Unfortunately I do not have a recording of this to post back ...
> 
> The screen is going nuts here with PM's so it needs be reported.
> 
> 73
> 
> Steve I
> VK3VM / Vk3SIR
> 
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net <mailto:wsjt-devel@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel 
> <https://lists.sourceforge.net/lists/listinfo/wsjt-devel>___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net <mailto:wsjt-devel@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel 
> <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


Re: [wsjt-devel] r2.2.2 Minor Issue with "short" calls that use DX

2020-08-18 Thread Stephen VK3SIR
Frode,

Thanks … By not “picking up” I was meaning you could not click, double-click or 
even use a third-party product via the UDP interface to force WSJT-X to place 
WSJT-X into a Tx2 mode that should have responded to the call. It’s a damn 
shame that I could not catch the call quickly enough (again) to get a recording 
of the stream.

Recorders are on now … Hopefully someone else out there has seen this, has it 
and can supply?


  *   I had no problem sending any of the Tx1 - Tx5 messages with 5CT in the DX 
Call field and JN0 in the DX Grid field.

The problem is not sending; it’s the program being able to RESPOND through 
WSJT-X to 5CT sent as an attempted Tx1 ! It was not just me seeing this - which 
is why I responded with a report here.


  *   First of all 5CT is not a valid call sign.

It may or it may not be … It COULD have been allocated. But I have been 
responding to a number of calls that now fit this template i.e. N7C ( 
https://www.qrz.com/db/n7c ) is a VERY valid and sought after call. I was able 
to make contact with that station but not this one !

73

Steve I
VK3VM / Vk3SIR


From: Frode Igland 
Sent: Tuesday, 18 August 2020 9:08 PM
To: WSJT software development 
Subject: Re: [wsjt-devel] r2.2.2 Minor Issue with "short" calls that use DX

Steve, I guess that your statement "WSJT-X will not pick up this call" means 
that WSJT-X will not automatically enter this call into the "DX Call" field, 
nor the locator into the "DX Grid" field. That is true, but WSJT-X will 
certainly pick up the call and grid as decoded if you enter it manually into 
the two fields. WSJT-X does not care how the call and grid arrives in the two 
fields, but once they are there they are used as entered.
I had no problem sending any of the Tx1 - Tx5 messages with 5CT in the DX Call 
field and JN0 in the DX Grid field.

Secondly, and all important here, it 5CT is not in accordance with the WSJT-X 
defintions and algorithms for what constitutes a call sign as defined in 
https://physics.princeton.edu/pulsar/k1jt/wsjtx-doc/wsjtx-main-2.2.2.html#PROTOCOL_OVERVIEW
 . Consequently, all my messages were sent as free text messages truncated at 
13 characters, which is just right.

73 Frode LA6VQ

tir. 18. aug. 2020 kl. 08:11 skrev Stephen VK3SIR 
mailto:vk3...@hotmail.com>>:
Hi Folks,

I am unsure whether this has been reported:

30m:

055130 -11  0.2 1626 ~  CQ CO8LY FL20  Cuba
055130 -17  0.3 1342 ~  R3BV F1LYV RR73
055130 -19  0.3  618 ~  CQ DX 5CT JN0  Morocco  <-- Will not allow this to 
be picked this up
055200 -12  0.2 1627 ~  CQ CO8LY FL20  Cuba

No matter what you do or how you try to pick up this calling station and pick 
up its call (i.e. click on it, double click, even use JTAlert) WSJT-X will not 
pick up this call !

I can see that this is being primarily interpreted as a text message (i.e. > 13 
chars) ... with the call framed in a " bad" format (missing the final char of 
the maidenhead).

[ It is fully understandable and understood why the logic will not allow this 
call to be picked up as the truncated maidenhead is confusing things ]

Unfortunately I do not have a recording of this to post back ...

The screen is going nuts here with PM's so it needs be reported.

73

Steve I
VK3VM / Vk3SIR

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net<mailto: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


Re: [wsjt-devel] r2.2.2 Minor Issue with "short" calls that use DX

2020-08-18 Thread Frode Igland
Steve, I guess that your statement "WSJT-X will not pick up this call"
means that WSJT-X will not *automatically *enter this call into the "DX
Call" field, nor the locator into the "DX Grid" field. That is true, but
WSJT-X will certainly pick up the call and grid as decoded if you enter it
manually into the two fields. WSJT-X does not care how the call and grid
arrives in the two fields, but once they are there they are used as entered.
I had no problem sending any of the Tx1 - Tx5 messages with 5CT in the DX
Call field and JN0 in the DX Grid field.

First of all 5CT is not a valid call sign. Secondly, and all important
here, it 5CT is not in accordance with the WSJT-X defintions and algorithms
for what constitutes a call sign as defined in
https://physics.princeton.edu/pulsar/k1jt/wsjtx-doc/wsjtx-main-2.2.2.html#PROTOCOL_OVERVIEW
. Consequently, all my messages were sent as free text messages truncated
at 13 characters, which is just right.

73 Frode LA6VQ

tir. 18. aug. 2020 kl. 08:11 skrev Stephen VK3SIR :

> Hi Folks,
>
> I am unsure whether this has been reported:
>
> 30m:
>
> 055130 -11  0.2 1626 ~  CQ CO8LY FL20  Cuba
> 055130 -17  0.3 1342 ~  R3BV F1LYV RR73
> 055130 -19  0.3  618 ~  CQ DX 5CT JN0  Morocco  <-- Will not allow
> this to be picked this up
> 055200 -12  0.2 1627 ~  CQ CO8LY FL20  Cuba
>
> No matter what you do or how you try to pick up this calling station and
> pick up its call (i.e. click on it, double click, even use JTAlert) WSJT-X
> will not pick up this call !
>
> I can see that this is being primarily interpreted as a text message (i.e.
> > 13 chars) ... with the call framed in a " bad" format (missing the final
> char of the maidenhead).
>
> [ It is fully understandable and understood why the logic will not allow
> this call to be picked up as the truncated maidenhead is confusing things ]
>
> Unfortunately I do not have a recording of this to post back ...
>
> The screen is going nuts here with PM's so it needs be reported.
>
> 73
>
> Steve I
> VK3VM / Vk3SIR
>
> ___
> 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


Re: [wsjt-devel] r2.2.2 Minor Issue with "short" calls that use DX

2020-08-18 Thread Patrick 9A5CW
Hi,
Nothing wrong with a call ;)
It is F5CT in JN08.
He probably messed up his setup in WSJT-X or any other similar problem.
Best regards and RR73 9A5CW

uto, 18. kol 2020. 10:05 Stephen VK3SIR  je napisao:

> Michael,
>
> True and very possible. I have just done the polite thing and reported
> observations - though I suspect WSJT-X behaviour is more than valid. I have
> reported this just in case its not occurring by design as that can lead to
> problems later down the track :-)
>
> [ Yet WSJT-X will also pick up the very common station D1DX - that is not
> a recognised DXCC entity ... I am not buying into that argument !!! ].
>
> There has been a lot of changes in postfixing and a growth of "prefix-x"
> and "prefix-xx" template calls of late (including here in VK where prefix-X
> will become available for Club/Contest stations for 12 months max only).
> This observation may offer some forewarning (if required) ...
>
> I was in the midst of working a frenzy of EU contacts on 30m late this
> afternoon when PM's (i.e. mostly Skype) went nuts at people trying to get
> this supposed "Moroccan" station and could not get WSJT-X  to pick up the
> call. It is not a false decode as it was seen a number of times (i.e.
> around 10 from my log). Morocco is rare and highly desirable in these
> parts.
>
> I verified this behaviour myself. I also run JTAlert ... and even that
> would not allow one to notionally grab "5CT" ...
>
> The JN0 is obviously a truncation and roughly translates to the region -
> and I STATE ROUGHLY (but not perfectly); that significantly tips evidence
> in the direction that you are suggesting !
>
> So yes I have doubt too and had doubt before posting ! My concern more the
> fact that it could not be picked up in any shape or form and responded to
> that prompted the post ... and also the knowledge of what I have posted in
> the 3rd sentence here !
>
> 73
>
> Steve I
> VK3VM / VK3SIR
>
> -Original Message-----
> From: 5p1kzx Michael <5p1...@gmail.com>
> Sent: Tuesday, 18 August 2020 5:35 PM
> To: wsjt-devel@lists.sourceforge.net
> Subject: Re: [wsjt-devel] r2.2.2 Minor Issue with "short" calls that use DX
>
> Hi Steve
>
> I don't think that 5CT is a valid callsign. A search on the Internet gave
> no result.
>
> 73 de Michael 5p1kzx
>
>
> Den 18-08-2020 kl. 08:06 skrev Stephen VK3SIR:
> > Hi Folks,
> >
> > I am unsure whether this has been reported:
> >
> > 30m:
> >
> > 055130 -11  0.2 1626 ~  CQ CO8LY FL20  Cuba
> > 055130 -17  0.3 1342 ~  R3BV F1LYV RR73
> > 055130 -19  0.3  618 ~  CQ DX 5CT JN0  Morocco  <-- Will not allow
> this to be picked this up
> > 055200 -12  0.2 1627 ~  CQ CO8LY FL20  Cuba
> >
> > No matter what you do or how you try to pick up this calling station and
> pick up its call (i.e. click on it, double click, even use JTAlert) WSJT-X
> will not pick up this call !
> >
> > I can see that this is being primarily interpreted as a text message
> (i.e. > 13 chars) ... with the call framed in a " bad" format (missing the
> final char of the maidenhead).
> >
> > [ It is fully understandable and understood why the logic will not
> > allow this call to be picked up as the truncated maidenhead is
> > confusing things ]
> >
> > Unfortunately I do not have a recording of this to post back ...
> >
> > The screen is going nuts here with PM's so it needs be reported.
> >
> > 73
> >
> > Steve I
> > VK3VM / Vk3SIR
> >
> > ___
> > 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
>
>
> ___
> 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


Re: [wsjt-devel] r2.2.2 Minor Issue with "short" calls that use DX

2020-08-18 Thread Stephen VK3SIR
Michael,

True and very possible. I have just done the polite thing and reported 
observations - though I suspect WSJT-X behaviour is more than valid. I have 
reported this just in case its not occurring by design as that can lead to 
problems later down the track :-)

[ Yet WSJT-X will also pick up the very common station D1DX - that is not a 
recognised DXCC entity ... I am not buying into that argument !!! ].

There has been a lot of changes in postfixing and a growth of "prefix-x" and 
"prefix-xx" template calls of late (including here in VK where prefix-X will 
become available for Club/Contest stations for 12 months max only). This 
observation may offer some forewarning (if required) ...

I was in the midst of working a frenzy of EU contacts on 30m late this 
afternoon when PM's (i.e. mostly Skype) went nuts at people trying to get this 
supposed "Moroccan" station and could not get WSJT-X  to pick up the call. It 
is not a false decode as it was seen a number of times (i.e. around 10 from my 
log). Morocco is rare and highly desirable in these parts. 

I verified this behaviour myself. I also run JTAlert ... and even that would 
not allow one to notionally grab "5CT" ... 

The JN0 is obviously a truncation and roughly translates to the region -  and I 
STATE ROUGHLY (but not perfectly); that significantly tips evidence in the 
direction that you are suggesting !

So yes I have doubt too and had doubt before posting ! My concern more the fact 
that it could not be picked up in any shape or form and responded to that 
prompted the post ... and also the knowledge of what I have posted in the 3rd 
sentence here !

73

Steve I
VK3VM / VK3SIR

-Original Message-
From: 5p1kzx Michael <5p1...@gmail.com> 
Sent: Tuesday, 18 August 2020 5:35 PM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] r2.2.2 Minor Issue with "short" calls that use DX

Hi Steve

I don't think that 5CT is a valid callsign. A search on the Internet gave no 
result.

73 de Michael 5p1kzx


Den 18-08-2020 kl. 08:06 skrev Stephen VK3SIR:
> Hi Folks,
>
> I am unsure whether this has been reported:
>
> 30m:
>
> 055130 -11  0.2 1626 ~  CQ CO8LY FL20  Cuba
> 055130 -17  0.3 1342 ~  R3BV F1LYV RR73
> 055130 -19  0.3  618 ~  CQ DX 5CT JN0  Morocco  <-- Will not allow this 
> to be picked this up
> 055200 -12  0.2 1627 ~  CQ CO8LY FL20  Cuba
>
> No matter what you do or how you try to pick up this calling station and pick 
> up its call (i.e. click on it, double click, even use JTAlert) WSJT-X will 
> not pick up this call !
>
> I can see that this is being primarily interpreted as a text message (i.e. > 
> 13 chars) ... with the call framed in a " bad" format (missing the final char 
> of the maidenhead).
>
> [ It is fully understandable and understood why the logic will not 
> allow this call to be picked up as the truncated maidenhead is 
> confusing things ]
>
> Unfortunately I do not have a recording of this to post back ...
>
> The screen is going nuts here with PM's so it needs be reported.
>
> 73
>
> Steve I
> VK3VM / Vk3SIR
>
> ___
> 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


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] r2.2.2 Minor Issue with "short" calls that use DX

2020-08-18 Thread 5p1kzx Michael

Hi Steve

I don't think that 5CT is a valid callsign. A search on the Internet 
gave no result.


73 de Michael 5p1kzx


Den 18-08-2020 kl. 08:06 skrev Stephen VK3SIR:

Hi Folks,

I am unsure whether this has been reported:

30m:

055130 -11  0.2 1626 ~  CQ CO8LY FL20  Cuba
055130 -17  0.3 1342 ~  R3BV F1LYV RR73
055130 -19  0.3  618 ~  CQ DX 5CT JN0  Morocco  <-- Will not allow this to 
be picked this up
055200 -12  0.2 1627 ~  CQ CO8LY FL20  Cuba

No matter what you do or how you try to pick up this calling station and pick 
up its call (i.e. click on it, double click, even use JTAlert) WSJT-X will not 
pick up this call !

I can see that this is being primarily interpreted as a text message (i.e. > 13 chars) 
... with the call framed in a " bad" format (missing the final char of the 
maidenhead).

[ It is fully understandable and understood why the logic will not allow this 
call to be picked up as the truncated maidenhead is confusing things ]

Unfortunately I do not have a recording of this to post back ...

The screen is going nuts here with PM's so it needs be reported.

73

Steve I
VK3VM / Vk3SIR

___
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


[wsjt-devel] r2.2.2 Minor Issue with "short" calls that use DX

2020-08-18 Thread Stephen VK3SIR
Hi Folks,

I am unsure whether this has been reported:

30m:

055130 -11  0.2 1626 ~  CQ CO8LY FL20  Cuba
055130 -17  0.3 1342 ~  R3BV F1LYV RR73
055130 -19  0.3  618 ~  CQ DX 5CT JN0  Morocco  <-- Will not allow this to 
be picked this up
055200 -12  0.2 1627 ~  CQ CO8LY FL20  Cuba

No matter what you do or how you try to pick up this calling station and pick 
up its call (i.e. click on it, double click, even use JTAlert) WSJT-X will not 
pick up this call !

I can see that this is being primarily interpreted as a text message (i.e. > 13 
chars) ... with the call framed in a " bad" format (missing the final char of 
the maidenhead).

[ It is fully understandable and understood why the logic will not allow this 
call to be picked up as the truncated maidenhead is confusing things ]

Unfortunately I do not have a recording of this to post back ...

The screen is going nuts here with PM's so it needs be reported.

73

Steve I
VK3VM / Vk3SIR

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel