Re: [wsjt-devel] Windows JTSDK 3.1 x64 Patches: Preparation for imminent release of Qt 5.15.1

[Yukio JG1APX]

Hi Steve,

I have not yet upgraded to 5.15.  It is interesting.
I noticed that "setqtver.cmd" of 0.4a is something wrong and the content
is for "build-hamlib.sh". 

73 Yukio
JG1APX


On Thu, 20 Aug 2020 01:28:34 +
Stephen VK3SIR  wrote:

> Hi Folks,
> 
> As many are aware “patches” that make the Windows JTSDK 3.1 x64 operate 
> basically to the same processes and procedures that the well-established 
> JTSDK 3.0 x86 operates to/under have been released to the JTSDK @ GROUPS.IO 
> (i.e. https://groups.io/g/JTSDK/topics ) JTSDK Tech Group.
> 
> I stated that updated patches to support Qt 5.15.1 would be released once 
> this version was released. The release of Qt 5.15.1 is imminent.
> 
> There are issues in that The Windows Qt 5.12, 5.13 and 5.14 streams are based 
> on GCC 7.3.0 ? so script-work is easy. The Windows > Qt 5.15 stream supports 
> GCC 8.1.0.
> 
> I have an “alpha” version of patches available ? that will be imperfect and 
> will need thorough and proper testing and refactoring. Note that these 
> packaged scripts have been left as close as possible to Greg KI7MT’s original 
> scripts … so please respect his IP. I will post a 0.4 alpha version of 
> patches at JTSDK @ GROUPS.IO (i.e. https://groups.io/g/JTSDK/topics ) in the 
> next few minutes.
> 
> I regret not being able to add people to the JTSDK Developers’ site but only 
> a few of us have post access there.
> 
> If you are unable to post back constructive comments and improvements to that 
> site please post comments back to me with an authorisation as to whether 
> comments can be reposted by me.
> 
> I state that this is set up and used at the moment primarily as a learning 
> base for others to understand how to package up resources to compile code 
> that is cross system ? cross platform capable.
> 
> 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

[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

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

[wsjt-devel] Windows JTSDK 3.1 x64 Patches: Preparation for imminent release of Qt 5.15.1

[Stephen VK3SIR]

Hi Folks,

As many are aware “patches” that make the Windows JTSDK 3.1 x64 operate 
basically to the same processes and procedures that the well-established JTSDK 
3.0 x86 operates to/under have been released to the JTSDK @ GROUPS.IO (i.e. 
https://groups.io/g/JTSDK/topics ) JTSDK Tech Group.

I stated that updated patches to support Qt 5.15.1 would be released once this 
version was released. The release of Qt 5.15.1 is imminent.

There are issues in that The Windows Qt 5.12, 5.13 and 5.14 streams are based 
on GCC 7.3.0 – so script-work is easy. The Windows > Qt 5.15 stream supports 
GCC 8.1.0.

I have an “alpha” version of patches available – that will be imperfect and 
will need thorough and proper testing and refactoring. Note that these packaged 
scripts have been left as close as possible to Greg KI7MT’s original scripts … 
so please respect his IP. I will post a 0.4 alpha version of patches at JTSDK @ 
GROUPS.IO (i.e. https://groups.io/g/JTSDK/topics ) in the next few minutes.

I regret not being able to add people to the JTSDK Developers’ site but only a 
few of us have post access there.

If you are unable to post back constructive comments and improvements to that 
site please post comments back to me with an authorisation as to whether 
comments can be reposted by me.

I state that this is set up and used at the moment primarily as a learning base 
for others to understand how to package up resources to compile code that is 
cross system – cross platform capable.

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

[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 rules of callsign structures for that DXCC entity. That is the real point 
> I am making here !
>
> —
>

Good grief!  Can 

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

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

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

[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

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

[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

[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

[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

[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

[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

[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

[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

[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

[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