from:"Stephen VK3SIR"

Re: [wsjt-devel] WSJT-X and Windows CMAKE Versions > 3.14.4

2020-08-24 Thread Stephen VK3SIR

Gee: Grammar revisions warranted for clarity … Apology for the “further 
correspondence” but its necessary on re-reading this for the 50th time !

..

Neil is right,

Everyone please take the time to read this … and carefully … verbosity hones in 
on precision… and its lack of reading that has cause this situation.

It is most definitely time to “give it a rest” as where things are headed has 
now become abusive and divisive … But these final comments and an open apology 
to Bill needs to be made:

This account is monitored by a number of people internationally (for the person 
that sent me the vile bile in VK3 they are not my “usual associates”) … and all 
of us drew the same conclusions that I had made comments about. Many people 
have never met me … but a close mentor says that people in AR HATE me… Now how 
can that be when they have never met me, picked up the phone or Skype and had a 
chat? … Interesting psychology that some of our regulators are monitoring and 
are using against AR’s continued existence (and that is a concern of mine) and 
that a  PHd student is working on (see later).

Now as for earlier comments re start talking offline. Bill and I HAVE taken 
this offline and are talking directly and not through this “common” account … I 
feel that there is genuine progress and that we BOTH see what the real position 
is. I am in a position now to offer Bill an apology for some of what has come 
across.
I see that many issues are seen with common vision; there has just been a 
communications gaffe.

So I repeat again I offer Bill an apology – and that being a general apology.

Which brings me to the point of how Amateurs play with each other and 
background (and direct) emails…. What is happening in our own world is abysmal 
and generally destructive for AR’s reputation – as we appears as grumpy old men 
fighting to much of the world.

As for the person that made comment as to why I am banned from many forums read 
this fact:  I was involved HEAVILY in AR reform in VK – but as an independent 
(No I am not RASA or WIA). I do not go around claiming success for this and 
that, but I can assure you that my successes and gains for AR have been 
numerous ! I have been banned from many sites for that very reason; I was 
exposing corruptions that are now known as truths and not for what opinion has 
twisted. Many sites (Such as the really divisive “Amateur (HAM) Radio 
Australia” deFacebook forum) are can be claimed by some to be operated by very 
polarised figures aligned with “old guard” WIA in Australian AR – people 
seeking recognition and self-importance.

I was exposing self-service, nepotism and inequality of opportunity (And the 
WIA is now in a much better position with many better people at the helm). I 
have reform baggage and that is why I am banned from many forums… and some 
(including that bile sender) perhaps now have their “self-recognition” status 
now in question …. That is fact ! And the result is there has been HUGE changes 
in Australian AR and the way that it is seen by Government.

The way to deny free speech and to attempt to discredit corruption and corrupt 
practise is to deny access… (Sounds Like the same argument that Trump is using 
with the attack on US Postal)?

But my point is that Bill and I now, I feel, understand each other better. 
Communication should be vastly improved and more care and communication will be 
taken with communication in the open.

I will state these points categorically:


  *   I am ABOUT KEEPING OUR CORE DEVELOPERS ON THE PEDASTAL WHERE THEY BELONG. 
This as a software project is BETTER THAN WORLD CLASS and VALIDATES AR and its 
existence to most of the world. That will involve expressions of concern if 
fears of non-exemplary behaviour are suspected.


  *   I am about FREE AND OPEN EXPRESSION OF SOFTWARE – but one must stick to 
the rules (i.e. work to interfaces offered and report issues with interfaces 
rather than self-patching).


  *   I am about OPEN AND FREE SOURCING OF AMATEUR SOFTWARE so that “hidden 
surprises” (i.e. that trigger AV software) can be community understood, 
received and dealt with in unique ways that again validate us in the technical 
world (and read what I just said one bile sender).


  *   I am COMMITTED TO KEEPING THIS PROJECT AS A WORLD CLASS EFFORT IN 
SOFTWARE AND TECHNOLOGY INTEGRATION and promoting its USE AS A LEARNING 
TEMPLATE … and sometimes that has involved asking for assistance. Some have 
been VERY helpful and I am grateful for their assistance; sometimes it is taken 
explosions for communication to improve.



As examples, I have been crying out for help with the CMAKE issue (read almost 
every post since April) for the JTSDK 3.1 “patches” - yet it has taken this 
explosion to achieve clarity (or to better visionary positions).


I was challenged to make the JTSDK 3.1 work … That was achieved within 24 hours 
of the challenge. Now we as a community need to move on and concentrate on

Re: [wsjt-devel] WSJT-X and Windows CMAKE Versions > 3.14.4

2020-08-24 Thread Stephen VK3SIR

Neil is right,

Everyone please take the time to read this … and carefully … verbosity hones in 
on precision… and its lack of reading that has cause this situation.

It is most definitely time to “give it a rest” as where things are headed has 
now become abusive and divisive … But these final comments and an open apology 
to Bill needs to be made:

This account is monitored by a number of people internationally (for the person 
that sent me the vile bile in VK3 they are not my “usual associates”) … and all 
of us drew the same conclusions that I had made comments about. Many people 
have never met me … but a close mentor says that people in AR HATE me… Now how 
can that be when they have never met me, picked up the phone or Skype and had a 
chat? … Interesting psychology that some of our regulators are monitoring and 
are using against AR’s continued existence (and that is a concern of mine) and 
that a  PHd student is working on (see later).

Now as for earlier comments re start talking offline. Bill and I HAVE taken 
this offline are talking directly and not through this “common” account … I 
feel that there is genuine progress and that we BOTH see what the real position 
is. I am in a position now to offer Bill an apology for some of what has come 
across.

I many issues are seen with common vision; there has just been a communications 
gaffe.

So I repeat again I offer Bill an apology – and that being a general apology.

Which brings me to the point of how Amateurs play with each other and 
background (and direct) emails…. What is happening in our own world abysmal and 
generally destructive for AR’s reputation and appears as grumpy old men 
fighting to much of the world.

As for the person that made comment as to why I am banned from many forums read 
this fact:  I was involved HEAVILY in AR reform in VK – but as an independent 
(No I am not RASA or WIA). I do not go around claiming success for this and 
that, but I can assure you that my successes and gains for AR have been 
numerous ! I have been banned from many sites for that very reason as things 
that I was exposing corruptions that are now known as truths and not for what 
you have twisted an opinion into. Many sites (Such as the really divisive 
“Amateur (Ham) Radio Australia” deFacebook forum) are can be claimed by some to 
be operated by very polarised figures aligned with “old guard” WIA in 
Australian AR – people seeking recognition and self-importance.

I was exposing self-service, nepotism and inequality of opportunity (And the 
WIA is now in a much better position with many better people at the helm). I 
have reform baggage and that is why I am banned from many forums… and some 
(including that bile sender) perhaps now have their “self-recognition” status 
now in …. That is fact ! And the result is there has been HUGE changes in 
Australian AR and the way that it is seen by Government.

The way to deny free speech and to attempt to discredit corruption and corrupt 
practise is to deny access… (Sounds Like the same argument that Trump is using 
with the attack on US Postal)?

But my point is that Bill and I now, I feel, understand each other better. 
Communication should be vastly improved and more care and communication will be 
taken with communication in the open.

I will state these points categorically:


  *   I am ABOUT KEEPING OUR CORE DEVELOPERS ON THE PEDASTAL WHERE THEY BELONG. 
This as a software project is BETTER THAN WORLD CLASS and VALIDATES AR and its 
existence to most of the world. That will involve expressions of concern if 
fears of non-exemplary behaviour are suspected.


  *   I am about FREE AND OPEN EXPRESSION OF SOFTWARE – but one must stick to 
the rules (i.e. work to interfaces offered and report issues with interfaces 
rather than self-patching).


  *   I am about OPEN AND FREE SOURCING OF AMATEUR SOFTWARE so that “hidden 
surprises” (i.e. that trigger AV software) can be community understood, 
received and dealt with in unique ways that again validate us in the technical 
world (and read what I just said one bile sender).


  *   I am COMMITTED TO KEEPING THIS PROJECT AS A WORLD GENERALLY IN SOFTWARE 
AND TECHNOLOGY INTEGRATION and promoting its USE AS A LEARNING TEMPLATE … and 
sometimes that has involved asking for assistance. Some have been VERY helpful 
and I am grateful for their assistance; sometimes it is taken explosions for 
communication to improve.



As examples, I have been crying out for help with the CMAKE issue (read almost 
every post since April) for the JTSDK 3.1 “patches” yet its taken this 
explosion to achieve clarity (or to better visionary positions).


I was challenged to make the JTSDK 3.1 work … That was achieved within 24 hours 
of the challenge. Now we as a community need to move on and concentrate on 
keeping the tools for Windows advancing to match  advances in the same tools in 
various Linux Distros and X-Code (and that has been my aim with the JTSDK 
patches).

I need

Re: [wsjt-devel] WSJT-X and Windows CMAKE Versions > 3.14.4

2020-08-22 Thread Stephen VK3SIR

Rick,

My sentiments exactly … I and others have made approach after approach after 
approach and it has been ignored. I am not the only one in that category.

I am standing up for the many (including myself) that has not been treated with 
respect – past or present.

Yet it is also important for the entire community to realise that we need to 
keep what we do here healthy as this is the example that gives AR Hope and 
credibility.

NO MORE ON THIS SUBJECT FROM ANYONE.

73

Steve I
VK3VM / VK3SIR


From: Rick Levine 
Sent: Sunday, 23 August 2020 10:00 AM
To: WSJT software development 
Subject: Re: [wsjt-devel] WSJT-X and Windows CMAKE Versions > 3.14.4

Guys, please take this offline. You’re trying to litigate a disagreement via 
email, and failing.

Just stop. If it’s important, try talking on the phone, skype, facetime, or 
zoom.

Thanks.

Rick

KK6WHJ

***


On Aug 22, 2020, at 4:35 PM, Stephen VK3SIR 
mailto:vk3...@hotmail.com>> wrote:

Bill,


  *   Instead you choose to write long rants about the incompetence of the 
WSJT-X development team..

Long “rants” … People also said that of Washington, Adams, Franklin and 
Jefferson’s speeches and dispatches (and I am not in their league)….

I asked for assistance time and time again on the issue that prompted this 
threads.

The patches you have are V 3.17 – and that has been around for some time ago. 
Instead I and those working on supporting and learning have apparently been 
left to “hang out to dry”. The old expression “give ’em enough rope and they 
will hang themselves” … Yet this is not a visionary approach in a community 
that is craving learning and advancement.

I completely REJECT that near slander that you have put forward that I am 
questioning Core Developers Team Members’ Competence.

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

Re: [wsjt-devel] WSJT-X and Windows CMAKE Versions > 3.14.4

2020-08-22 Thread Stephen VK3SIR

Bill,


  *   Instead you choose to write long rants about the incompetence of the 
WSJT-X development team..

Long “rants” … People also said that of Washington, Adams, Franklin and 
Jefferson’s speeches and dispatches (and I am not in their league)….

I asked for assistance time and time again on the issue that prompted this 
threads.

The patches you have are V 3.17 – and that has been around for some time ago. 
Instead I and those working on supporting and learning have apparently been 
left to “hang out to dry”. The old expression “give ’em enough rope and they 
will hang themselves” … Yet this is not a visionary approach in a community 
that is craving learning and advancement.

I completely REJECT that near slander that you have put forward that I am 
questioning Core Developers Team Members’ Competence.

Quote me: You people have created a WORLD LEADING EXAMPLE software that many in 
the professional community use as the bases for their work. You produce 
something that we as Amateurs put up on a pedestal. As a result you people as 
the Core Developers are put up on a pedestal for the world … And you deserve to 
be there.

Sometimes you need support to remain on the pedestal with the BIGGER PICTURE 
being the ADVACNEMENT and REPUTATION of Amateur Radio.

I have said this often and consistently to people who PM me in the background !

What I am questioning is the way you are communicating and interacting with 
others in the HAM community that are trying to learn and get to your level … 
and hence further advance AR’s Reputation in an age when it is under threat !

I am NOT QUESTIONING COMPETENCE of The Core Development Team. You have perhaps 
the world leading project out there.

What I am questioning is attack, resist and put-down and hang out to dry of 
members of our community that are really keen to learn, assist and support. I 
am trying to reform some of the nastiness in our own community that is often 
used against us when you talk with Regulators and Politicians. Not everyone is 
a great communicator. Not everyone has your expertise.

The #1 rule of education – areas where many here have great credentials and 
experience - is to BE CONSISTENT WITH COMMUNICATION and SHOW NO FAVORITES. 
CEMETERIES are full of INDISPENSIBLE MEN (including Washington, Adams, Franklin 
and Jefferson … as well as many of our revered SK’s). That was my core that 
enabled me to survive in an academic environ for 30-odd years until my health 
failed. I always trained my replacements – yet over 30 years I saw all of them 
go 

You as a member of the Core Development team are a teacher …. And AR’s core 
reason for existence according to the ITU and many Regulatory Domains is for 
non-commercial experimentation and learning. Experimentation and learning 
requires teachers and guides. You are a teacher and a guide.


  *   It was your choice to upgrade CMake, and indeed Qt….

Ummm … Not really my choice…. There WAS AND IS NO CHOICE. It was a necessity. 
It was the choice of time and progress. The JTSDK 3.1 x64 was left over 12 
months ago partially complete.

The Linux Distros automatically deliver libraries in many cases that match what 
we are trying to match – to make available via the Windows JTSDK (and its 
patches).

I coordinated a group (under my name) that came in as “damage control” and put 
together something that completely respects Greg Bream KI7MT’s IP – in fact it 
sets him up to take control again if he returns -  yet also allows for changes 
and advancement of technologies. It is fully designed to support what the Core 
Development Team does.

It also is designed to support others outside WSJT-X that use our valuable 
resources. Many Academic Environs use the JTSDK’s as a base for their learning 


The whole idea of a SDK is to be “future proof” - to be extensible and 
expandable and capable of supporting experimentation.

I have requested for a considerable amount of time that BASE (IDEAL) 
Specifications – library versions etc. should CLEARLY be published with each 
source release. That should be the minima that The JTSDK supports. Yet it must 
be future-proof in itself and new components should seamlessly integrate. This 
is a more than reasonable community ask.

So there is really no choice … Its necessity for our HAM community … and it 
does not take vision to see that !

Anything outside these specs is advancement and experimentation. So a SDK 
having complete minimum support for the “base” is the target. Yet also being 
robust and able to cope with future enhancements only supports and enhances the 
WSJT-X project’s position and status.

Using patched custom libraries is considered very unprofessional and ties you 
to specific library/software versioning … Identifying this can be considered as 
a constructive push to keep you on your pedestal. Pushing Hamlib into 
functionality that its never really been designed to do is extremely poor 
behaviour.

The next 0.4 beta release of patches

Re: [wsjt-devel] WSJT-X and Windows CMAKE Versions > 3.14.4

2020-08-22 Thread Stephen VK3SIR

Bill,

The matters raised are FAR FROM TRIVIAL as the JTSDK’s must be tolerant and 
resilient to library and Qt version upgrades. Guidance now exists in that 
additional variables for special-purpose scripts (such as jtbuild) will now be 
incorporated into to scripts to handle FFTW and CMAKE’s introduced shortcomings 
…

The current CMAKE version is 3.18.2 with version 3.19 soon for release. The 
patches you provide for FFTW 3.3.5 are for 3.17 … so they may work now but can 
be guaranteed to not work at some stage later down the track… and who knows 
what else such patches could screw up IN THE FUTURE …

The answer is work to what is distributed … and work to the interfaces and 
libraries and their limitations that are available.

With those of us working on the JTSDK there has been exploration with key 
objectives making WSJT-X and the SDK tools FFTW and CMAKE (as well as LibUSB) 
upgrade independent…. As it should be !

It is INAPPROPRIATE and HIGHLY UNPROFESSIONAL (yes we have some standards in 
AR) to suggest patching SDK distributed and accessible libraries for one single 
purpose; in our case JTSDK is not just used by many for just WSJT-X development 
!

I’ll repeat myself: Software MUST be written to interfaces. Many of us are VERY 
UNHAPPY at the appearance of WSJT-X driving (perhaps bullying???) Hamlib into 
complex functionality that it was not really intended to perform !  Hamlib is 
not just the subservient soul of WSJT-X. It is the key to many big future 
advances in AR. If this is not the case or intent then one must review 
communication protocols.

The JTSDK must be kept to distributed releases of libraries and support tools. 
There are also good legal reasons for doing this (as you point out often and 
sometimes inappropriately accuse others of violating).

With regards to future JTSDK work such a multi-purpose SDK must work as 
generically as possible to packages as distributed and not for specific “hacks” 
of packages. If hacks of packages must be applied by end-user source then they 
should be applied as supplementaries to that which is formally distributed and 
available as you do with Hamlib. Makefiles MUST refer to these special versions 
(taking it outside of SDK support scope).

Yet please advise and early if you are doing this so that the end user and 
learning community can adapt !

Software written must also be tolerant to library upgrades and enhancements. 
That is why writing to specified interfaces is critical.

Anything that the Core Development team can do to assist the learning of others 
– those that use the JTSDK and those that develop their own Kits based off 
JTSDK learning - in reviewing the Makefiles would be highly appreciated I am 
sure by many.

We do not communicate well so discussion is best left there. But please look 
with vision at true intent of what I am conveying !

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] WSJT-X and Windows CMAKE Versions > 3.14.4

2020-08-22 Thread Stephen VK3SIR

Bill,

Thanks for the response that many of us have been seeking some guidance from on 
high with for some time …


  *   your assumptions are largely incorrect[ Meaning that the opposite to 
that is “largely correct” … splitting hairs ]

Assumptions and mitigations are now required across a number of packages. It is 
not just WSJT-X that has been impacted so therefore there is an issue for CMAKE 
developers to look at… and I am awaiting confirmation from them via a post on 
their site.

[ Its very reasonable to assume that if it worked on previous versions that it 
should work on later versions – and if it does not then a poorly communicated 
change has taken place ]

The patch provided is highly appreciated; patching specific FFTW source for 
specific CMAKE versions is not the most robust and extensible way to do things. 
Any SDK and support scripts must be made as robust as possible.

With regards to the JTSDK maintenance as there is no FFTW Windows released 
beyond 3.3.5 – with source being at 3.3.8 - at this stage. I’ll guide those of 
us working on the JTSDK patches towards sending additional variables to CMAKE. 
Rather than “patching patches of patches” its better to work at the best 
generic solution to problems.

A review of Makefiles, as requested, are perhaps things that you people as the 
experts with this can do to assist end users learning from your efforts.

There has been lots of requests for help with this; this has obviously known 
about this for a while despite the postings.

PLEASE assist the community at large by responding to progressive responses 
rather than using strategies that appear to many to leave people hung out to 
dry.  “Hanging People Out To Dry” may be good for the ego of some – but it is 
not the HAM – Help All Mankind – way.

Remember that AR’s justification to the world is that it is there for 
self-experimentation and learning.

Those of us working on “patches” to make the JTSDK work are doing so in such a 
way to teach others on how to set up the environs. Inactivity that the project 
may soon require forking efforts whether we like it or not [ i.e. nobody can be 
granted contributory access to that site at the moment and many contribute 
through me ]. Ultimately it will be the WSJT-X Core Developers’ team that may 
need to be the custodians of key passwords etc for whatever possibly emerges 
from Greg KI7MT’s work. That is why what is currently there is based on 
documentation and learning … to teach others.

If we are not teaching others that are at least trying to contribute then we 
are sending AR to an early grave !

73

Steve I
VK3VM / VK3SIR

From: Bill Somerville 
Sent: Saturday, 22 August 2020 9:08 PM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] WSJT-X and Windows CMAKE Versions > 3.14.4

Steve,

your assumptions are largely incorrect. This patch resolves the issue 
introduced by a change in CMake v3.17 to avoid system DLL files being 
inadvertently picked up by CMake find_library() invocations on Windows systems:

https://www.dropbox.com/s/v6f21xj69scc5zu/cmake-3.17_FFTW3.patch?dl=0

CMake is not broken, FindPackageHandleStandardArgs is not broken, the WSJT-X 
build scripts are not broken. This is just a requirement for a minor update to 
the custom FFTW3 finder CMake script we use to cater for the rather outdated 
file naming used by the FFTW3 packaging.

73
Bill
G4WJS.

On 22/08/2020 11:14, Stephen VK3SIR wrote:
Postscript:

The issue may not be anything to do with WSJT-X nor its Makefile construction … 
but could possibly be an unnoticed “inconsistency” post 3.14.4 that has crept 
into CMAKE’s FindPackageHandleStandardArgs handler that may need to be flagged 
with Kitware – CMAKE Windows’ distributor !

With the fact that all is well with CMAKE 3.14.4 but upgrades require 
additional parameters provides clear evidence at first glance that the issue is 
not with us. There is also concern that the same issue does not appear evident 
with Linux CMAKE versions (although I have not heavily tested there).

While we can work around issues at our end this can create cross-platform 
portability concerns and unnecessary complexity.

It may require push from “our mountain” to move “their mountain”… Only our Core 
Development Team has the credibility to report matters – if they exist.


From: Stephen VK3SIR <mailto:vk3...@hotmail.com>
Sent: Saturday, 22 August 2020 9:13 AM
To: WSJT software development 
<mailto:wsjt-devel@lists.sourceforge.net>
Subject: [wsjt-devel] WSJT-X and Windows CMAKE Versions > 3.14.4

*** REPOST – WRONG HEADING ***

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://group

Re: [wsjt-devel] WSJT-X and Windows CMAKE Versions > 3.14.4

2020-08-22 Thread Stephen VK3SIR

Postscript:

The issue may not be anything to do with WSJT-X nor its Makefile construction … 
but could possibly be an unnoticed “inconsistency” post 3.14.4 that has crept 
into CMAKE’s FindPackageHandleStandardArgs handler that may need to be flagged 
with Kitware – CMAKE Windows’ distributor !

With the fact that all is well with CMAKE 3.14.4 but upgrades require 
additional parameters provides clear evidence at first glance that the issue is 
not with us. There is also concern that the same issue does not appear evident 
with Linux CMAKE versions (although I have not heavily tested there).

While we can work around issues at our end this can create cross-platform 
portability concerns and unnecessary complexity.

It may require push from “our mountain” to move “their mountain”… Only our Core 
Development Team has the credibility to report matters – if they exist.

From: Stephen VK3SIR 
Sent: Saturday, 22 August 2020 9:13 AM
To: WSJT software development 
Subject: [wsjt-devel] WSJT-X and Windows CMAKE Versions > 3.14.4

*** REPOST – WRONG HEADING ***

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

[wsjt-devel] WSJT-X and Windows CMAKE Versions > 3.14.4

2020-08-21 Thread Stephen VK3SIR

*** REPOST – WRONG HEADING ***

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-21 Thread Stephen VK3SIR

Hi Core Developer Team,

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
.

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] Windows JTSDK 3.1 x64 Patches: Preparation for imminent release of Qt 5.15.1

2020-08-20 Thread Stephen VK3SIR via wsjt-devel

Yukio,

Fixed. It has been emailed to you personally and uploaded to JTSDK @ GROUPS.IO. 

I have no idea how that has happened - NotePad++ has been the editor used.

Can comments on this kit please either come directly to my email (vk3sir @ 
hotmail.com) or be posted at JTSDK @ GROUPS.IO if you have access there? That 
way we can contain the development process and guidance for future work in  one 
place :-).

73

Steve I
VK3VM / VK3SIR

-Original Message-
From: Yukio JG1APX  
Sent: Thursday, 20 August 2020 3:03 PM
To: WSJT software development 
Subject: Re: [wsjt-devel] Windows JTSDK 3.1 x64 Patches: Preparation for 
imminent release of Qt 5.15.1

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


___
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

2020-08-19 Thread 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

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

[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

Re: [wsjt-devel] Changes to the INSTALL file in the 2.2.2 tarball

2020-08-14 Thread Stephen VK3SIR

Bill,

Please READ My emails …. On first reading it can appear that you have a deep
misunderstanding of Linux

* there are no issues when building from source on Ubuntu 20.04. users are
building on 20.04 and several other Linux distributions and versions with
issues.
There are no issues if you have a fully deployed development environ (and set
of libraries). But there are SIGNIFICANT issues using the supplied .DEB IF you
basically do not have the programming environment deployed….

You are building packages from fully “specced-out” Linux development distros
(i.e. all the required libraries are there). i.e. The OOB (Out Of The Box)
Libraries ARE deployed OR you have made the Libraries available via deploying
the Qt SDK.

By far the majority of users – especially newbies (and I work with newbies
quite a lot being an AR Licence Assessor too) - are using Linux OOB and do not
have all the required development libraries deployed. I challenge you to do a
FRESH install of the packages and then try to deploy … You will very quickly
see my point !

* > The Qt5 packages are NOT NATIVELY delivered in Ubuntu and many other
Linux distros as they are large and volatile. I started with 18.04.4 “oob”…. My
pedigree with Linux is such that I am an early Kernel Developer (via an early
“handle”) … and I am one that that has built OS’s from scratch using Andy
Tannenbaum’s guides …
* I don't understand your comments here. Almost all Linux distributions
have the Qt tools and libraries in their repositories, including the
development packages if needed.
You have a strong history; so do I. There are no people in this conversation
that are unqualified to participate …. That is the point here.

Yes they do have the Qt 5 Libraries available. But you have to manually ask for
these to be deployed…i.e. Refer to the base of the post at
https://groups.io/g/JTSDK/topic/some_dependencies_requisites/75311015?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,75311015
(and repeated a few sentences below)

Bill, you are put up as one of the most competent programmers around … I am
gravely concerned if you do not understand what I am saying here … Repeated
again, unless you deploy the following then there is no way that MOST of the
distributions listed at https://physics.princeton.edu/pulsar/K1JT/wsjtx.html
will deploy

i.e. steps for Ubuntu 18.04.x and 20.04.x (and similar for many other
Debian-based distros) although the -dev packages and perhaps the first line
need not be deployed:

sudo apt install build-essential gfortran cmake
sudo apt install git automake subversion
sudo apt install qtcreator
sudo apt install libusb-1.0-0-dev libfftw3-dev
sudo apt install texinfo asciidoc
sudo apt install qtmultimedia5-dev qttools5-dev qttools5-dev-tools
libqt5serialport5-dev libqt5multimedia5-plugins
sudo apt install libtool libudev-dev
sudo apt install packagekit

sudo usermod -a -G adm,tty,disk,dialout,audio,video,plugdev <--
This guidance is completely ignored !

* We list the required dependencies at the top of the INSTALL documentation.
Accepted…. But there is very POOR to ZERO guidance on how to deploy required
dependencies ! There I simply and easily listed dependencies (as a guide) so
that people can compile WSJT-X on their Ubuntu 18.04.1 or 20.04.1 distros …
Perhaps similar example guidance (maybe even scripts ???) should be provided
that should be executed before the prepackaged distros are launched? [ and that
I can help with ].

* No special "environment" is required, just installing the required
packages using the distribution package management tool (apt, aptitude, dnf,
yum, ...).
I disagree and you contradict yourself in your discussion. You need the “user
libraries” [ or the “dev” libraries]. You need to have your environ PREPARED to
be able to take the software first. No guidance is provided for individual
release distros. Many man many comments on this forum relates to this !!!

Many of us would gladly assist in providing such release-specific
documentation…. As that is the HAM (Help All Mankind) way that many of us
subscribe to !

Additionally there are significant out of date examples, errors and
inconsistencies across the Multiple INSTALL files

i.e. INSTALL in wsjtx-2.2.2.tgz\wsjtx-2.2.2.tar\wsjtx-2.2.2\ (one “Small”
example from Line 75 – but more identified) :

$ cmake -D WSJTX_TAG=wsjtx-2.0.0 [ LINE 75, 111, 128, 131
] – Deprecated version referred to !

[ Line 131 is important as it refers to the NEXT error in the install file ]

These as examples are DEFINITELY not correct for the source distros and need
modification so that CLEAR GUIDANCE is provided. More serious misdirection
exist in the following:

i.e. INSTALL in
wsjtx-2.2.2.tgz\wsjtx-2.2.2.tar\wsjtx-2.2.2\src\wsjtx.tgz\wsjtx.tar\wsjtx\

References: Line 92

$ cmake -D CMAKE_PREFIX_PATH=~/hamlib-prefix ../src

SHOULD BE:

$ cmake -D -DWSJT_SKIP_MANPAGES=ON -DWSJT_GENERATE_DOCS=OFF

Re: [wsjt-devel] Changes to the INSTALL file in the 2.2.2 tarball

2020-08-14 Thread Stephen VK3SIR

Bill,

  *   that Debian package was targeted at Ubuntu 18.04, …
Yet you clearly stated that there are no issues with 20.04 … I am confused … 
and so are countless others emailing me !

The Qt5 packages are NOT NATIVELY delivered in Ubuntu and many other Linux 
distros as they are large and volatile. I started with 18.04.4 “oob”…. My 
pedigree with Linux is such that I am an early Kernel Developer (via an early 
“handle”)  … and I am one that that has built OS’s from scratch using Andy 
Tannenbaum’s guides …

I can foresee from many of your answers here that you start with systems that 
already have build-environ deployed … Most people do not ! I get queries and 
cries for help from people that cannot get it to work ON ENVIRONS that you 
certify as working. So, deploying the build environ (i.e. the JTSDK @ GROUPS.IO 
work) is basically essential for many using Linux / Unix-based environ anyway !

I’ll be blunt – your Linux .deb installers MUST pull in dependency packages. 
They currently do not (so additional scripting work is needed) …. Solving these 
issues as you know basically is easier suggesting compiling from scratch ….

  *   Again I ask to please do not obfuscate the process of building WSJT-X 
from the combined sources tarball…
Obfuscate? Obfusacate? The last response contradicts in responses !!! I am just 
repeating, trying to clarify, make sense of for others materials and in many 
cases correct instructions that are ALMOST EXACTLY WHAT YOU HAVE IN YOUR 
INSTALL FILES … INSTALL FILES IN TWO LOCATIONS THAT ARE OUT OF DATE IN PLACES 
THAT HAVE CONTRADICTIONS.

[ And yes some of my posts refer to the Development streams of Hamlib … as 
using these makes WSJTX works soo much better for many as their rigs work 
when “corrected” Hamlib source is used ].

If I was to use steps documented inside the wsjtx.tar tarball inside the 
INSTALL file steps will not compile as it lacks the MANPAGE switches. This is 
EXACTLY the same issue that I am raising if I was to use the .deb files 
distributed on Joe’s site ! i.e. Things do not work well and properly !

Please review these KEY FILES – as I have been requesting - to stop OBFUSCATING 
PROCESSS for those trying to learn and those thata re not as skilled. Aim to 
improve the skills of others (and that is where I come from).

I am more than happy to correct files myself - if they have not already been 
corrected. Yet that last point is a key issue. With the development process 
CLOSED I (or others) do not know whether issues have been fixed. Others also 
willing to contribute also do not know whether their efforts are in vain either 
!

I never get a straight answer from you as to whether some of these issues have 
been fixed !

You cannot have your cake and eat it too as I say often.

Let’s leave this discussion here as I think you are massively entrenched. But 
for The Great Maker’s sake, realise people do not comment here unless they have 
to as they fear ridicule and retribution ! Newbies also are attracted here … 
Listen and at least acknowledge the contribution from vast numbers of people 
that do suggest; always treat newbies with the respect that they deserve.

Regards to all in the WSJTX and Hamlib community.

Steve I
VK3VM / VK3SIR
Maintainer of Patches that make JTSDK 3.1 work !

On 14/08/2020 15:50, Stephen VK3SIR wrote:
Bill,

I am off the sick list again…… Ok I am going to put my “Newbie” hat on here (as 
this is the type of help request that I get by PM).


  *   One deploys Ubuntu 20.04.1 using the software at 
https://ubuntu.com/download/desktop
  *   You perform the obligatory OS update once its installed.
  *   You download 
https://physics.princeton.edu/pulsar/K1JT/wsjtx_2.2.2_amd64.deb
  *   You ATTEMPT to install it with “Software Installer” … It responds with 
‘Unable to Install “Message Aggregator”: The following packages have unmet 
dependencies:’ without further information.

I have just re-confirmed this in a virgin (but fully updated) Ubuntu 20.04.1 
x64 VM ….

[ Now both you and I can fix this in our sleep – but resolving this is 
difficult for many in our community…. So they come to people like you and me 
and this forum for help ]

A “newbie” just expects these things to work OOB … That was the whole gist of 
my points the other day. I don’t point-score as that helps nobody !

BY FAR the best and easiest way to get a system working is to compile it from 
scratch; Instructions for this (including a comment re your “official” way) are 
on the JTSDK @ GROUPS.IO forum…

That way people learn to solve their own issues … and the more that you can 
promote learning the less “annoying comments” as some may call them appear here.

There is an old-ancient proverb: give a man a fish and you feed him for a day; 
teach a man to fish and you feed him for a lifetime.

HAM – Help All mankind.

73

Steve I
VK3VM / VK3SIR


From: Bill Somerville <mailto:g4...@classdesign.com>
Sent: Wednesday, 12 August 2020 10:30 AM
To: wsjt

Re: [wsjt-devel] Changes to the INSTALL file in the 2.2.2 tarball

2020-08-14 Thread Stephen VK3SIR

Ps: The fix is around 3/4 of the way to compiling your own anyway !

From: Stephen VK3SIR 
Sent: Saturday, 15 August 2020 12:51 AM
To: WSJT software development 
Subject: Re: [wsjt-devel] Changes to the INSTALL file in the 2.2.2 tarball

Bill,

I am off the sick list again…… Ok I am going to put my “Newbie” hat on here (as 
this is the type of help request that I get by PM).

  *   One deploys Ubuntu 20.04.1 using the software at 
https://ubuntu.com/download/desktop
  *   You perform the obligatory OS update once its installed.
  *   You download 
https://physics.princeton.edu/pulsar/K1JT/wsjtx_2.2.2_amd64.deb
  *   You ATTEMPT to install it with “Software Installer” … It responds with 
‘Unable to Install “Message Aggregator”: The following packages have unmet 
dependencies:’ without further information.

I have just re-confirmed this in a virgin (but fully updated) Ubuntu 20.04.1 
x64 VM ….

[ Now both you and I can fix this in our sleep – but resolving this is 
difficult for many in our community…. So they come to people like you and me 
and this forum for help ]

A “newbie” just expects these things to work OOB … That was the whole gist of 
my points the other day. I don’t point-score as that helps nobody !

BY FAR the best and easiest way to get a system working is to compile it from 
scratch; Instructions for this (including a comment re your “official” way) are 
on the JTSDK @ GROUPS.IO forum…

That way people learn to solve their own issues … and the more that you can 
promote learning the less “annoying comments” as some may call them appear here.

There is an old-ancient proverb: give a man a fish and you feed him for a day; 
teach a man to fish and you feed him for a lifetime.

HAM – Help All mankind.

73

Steve I
VK3VM / VK3SIR

From: Bill Somerville mailto:g4...@classdesign.com>>
Sent: Wednesday, 12 August 2020 10:30 AM
To: wsjt-devel@lists.sourceforge.net<mailto:wsjt-devel@lists.sourceforge.net>
Subject: Re: [wsjt-devel] Changes to the INSTALL file in the 2.2.2 tarball

Steve,

your reply below makes no sense!

I will repeat, the combined sources tarball we release includes instructions to 
build on Linux, they are complete. Yes there are some typos and it needs 
updating for the version numbers mentioned, that is fixed for the next release, 
did you even read this email thread before suggesting that some other 
instructions should be followed?

What are you suggesting needs to be "forced" to run?

By far the simplest instructions to follow are the ones provided in the single 
INSTALL file at the root of the sources tarball. Note the singular INSTALL file.

Like many Open Source projects there are different build instructions for 
developers wishing to contribute to the project, there's nothing unusual about 
that, but those instructions are not needed for users who simply want to build 
the application to run. We provide a build script, and instructions to run it, 
just for that sort of user.

73
Bill
G4WJS.

On 12/08/2020 01:21, Stephen VK3SIR wrote:
Bill,

KISS Principle in my answer to Rob’s post …. Yes the “dropped tarball” it can 
be forced to run … but its BY FAR simpler and easier to follow the instructions 
in the INSTALL files :-D

I have had lots and lots and lots of background inquiry on Ubuntu 20.04 … 
following the steps in the install file and compiling from source is BY FAR the 
easiest way to make WSJTX work – and properly (considering there have also been 
a lot of changes to Hamlib).

By the way, has the INSTALL files been updated for the next release as they 
were a little dated and some instructions out of sync?

73

Steve I
VK3VM / VK3SIR

From: Bill Somerville <mailto:g4...@classdesign.com>
Sent: Wednesday, 12 August 2020 10:10 AM
To: wsjt-devel@lists.sourceforge.net<mailto:wsjt-devel@lists.sourceforge.net>
Subject: Re: [wsjt-devel] Changes to the INSTALL file in the 2.2.2 tarball

Steve,

there is no need to follow the build instructions in the project git repo if 
you are building to run. Maybe if you are building to contribute patches. The 
INSTALL file in the sources tarball we provide contains complete instructions 
for building a working WSJT-X for Linux. Please don't over-complicate a 
relatively simple recipe for building.

73
Bill
G4WJS.

On 12/08/2020 01:01, Stephen VK3SIR wrote:
Rob,

There is no repo that you can just “drop and run” for WSJTX 2.2.2 – You really 
need to compile your own 

Go to the JTSDK @ GROUPS.IO site. I have a post there for dependencies etc. 
needed to build your own WSJTX on Ubuntu 20.04.

i.e. 
https://groups.io/g/JTSDK/topic/some_dependencies_requisites/75311015?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,75311015

Then follow the steps inside the INSTALL files (the top level one in the repo 
and then the main set of steps inside WSJTX.TGZ)

73

Steve I
VK3VM / VK3SIR

From: Rob Robinett <mailto:r...@robinett.us>
Sent: Wednesday, 12 August 2020 8:44 AM
To: WSJT software development

Re: [wsjt-devel] Changes to the INSTALL file in the 2.2.2 tarball

2020-08-14 Thread Stephen VK3SIR

Bill,

I am off the sick list again…… Ok I am going to put my “Newbie” hat on here (as 
this is the type of help request that I get by PM).


  *   One deploys Ubuntu 20.04.1 using the software at 
https://ubuntu.com/download/desktop
  *   You perform the obligatory OS update once its installed.
  *   You download 
https://physics.princeton.edu/pulsar/K1JT/wsjtx_2.2.2_amd64.deb
  *   You ATTEMPT to install it with “Software Installer” … It responds with 
‘Unable to Install “Message Aggregator”: The following packages have unmet 
dependencies:’ without further information.

I have just re-confirmed this in a virgin (but fully updated) Ubuntu 20.04.1 
x64 VM ….

[ Now both you and I can fix this in our sleep – but resolving this is 
difficult for many in our community…. So they come to people like you and me 
and this forum for help ]

A “newbie” just expects these things to work OOB … That was the whole gist of 
my points the other day. I don’t point-score as that helps nobody !

BY FAR the best and easiest way to get a system working is to compile it from 
scratch; Instructions for this (including a comment re your “official” way) are 
on the JTSDK @ GROUPS.IO forum…

That way people learn to solve their own issues … and the more that you can 
promote learning the less “annoying comments” as some may call them appear here.

There is an old-ancient proverb: give a man a fish and you feed him for a day; 
teach a man to fish and you feed him for a lifetime.

HAM – Help All mankind.

73

Steve I
VK3VM / VK3SIR


From: Bill Somerville 
Sent: Wednesday, 12 August 2020 10:30 AM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] Changes to the INSTALL file in the 2.2.2 tarball

Steve,

your reply below makes no sense!

I will repeat, the combined sources tarball we release includes instructions to 
build on Linux, they are complete. Yes there are some typos and it needs 
updating for the version numbers mentioned, that is fixed for the next release, 
did you even read this email thread before suggesting that some other 
instructions should be followed?

What are you suggesting needs to be "forced" to run?

By far the simplest instructions to follow are the ones provided in the single 
INSTALL file at the root of the sources tarball. Note the singular INSTALL file.

Like many Open Source projects there are different build instructions for 
developers wishing to contribute to the project, there's nothing unusual about 
that, but those instructions are not needed for users who simply want to build 
the application to run. We provide a build script, and instructions to run it, 
just for that sort of user.

73
Bill
G4WJS.

On 12/08/2020 01:21, Stephen VK3SIR wrote:
Bill,

KISS Principle in my answer to Rob’s post …. Yes the “dropped tarball” it can 
be forced to run … but its BY FAR simpler and easier to follow the instructions 
in the INSTALL files :-D

I have had lots and lots and lots of background inquiry on Ubuntu 20.04 … 
following the steps in the install file and compiling from source is BY FAR the 
easiest way to make WSJTX work – and properly (considering there have also been 
a lot of changes to Hamlib).

By the way, has the INSTALL files been updated for the next release as they 
were a little dated and some instructions out of sync?

73

Steve I
VK3VM / VK3SIR

From: Bill Somerville <mailto:g4...@classdesign.com>
Sent: Wednesday, 12 August 2020 10:10 AM
To: wsjt-devel@lists.sourceforge.net<mailto:wsjt-devel@lists.sourceforge.net>
Subject: Re: [wsjt-devel] Changes to the INSTALL file in the 2.2.2 tarball

Steve,

there is no need to follow the build instructions in the project git repo if 
you are building to run. Maybe if you are building to contribute patches. The 
INSTALL file in the sources tarball we provide contains complete instructions 
for building a working WSJT-X for Linux. Please don't over-complicate a 
relatively simple recipe for building.

73
Bill
G4WJS.

On 12/08/2020 01:01, Stephen VK3SIR wrote:
Rob,

There is no repo that you can just “drop and run” for WSJTX 2.2.2 – You really 
need to compile your own 

Go to the JTSDK @ GROUPS.IO site. I have a post there for dependencies etc. 
needed to build your own WSJTX on Ubuntu 20.04.

i.e. 
https://groups.io/g/JTSDK/topic/some_dependencies_requisites/75311015?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,75311015

Then follow the steps inside the INSTALL files (the top level one in the repo 
and then the main set of steps inside WSJTX.TGZ)

73

Steve I
VK3VM / VK3SIR

From: Rob Robinett <mailto:r...@robinett.us>
Sent: Wednesday, 12 August 2020 8:44 AM
To: WSJT software development 
<mailto:wsjt-devel@lists.sourceforge.net>
Subject: Re: [wsjt-devel] Changes to the INSTALL file in the 2.2.2 tarball

Hi Bill and David,

Could I find a source tarball which builds on Ubuntu 20.04?  I have several 
wsprdaemon sites which want to move to 20.02.

My attempt to follow David's instructions have f

[wsjt-devel] Changes needed to compile under the Qt 5.15.x stream

2020-08-12 Thread Stephen VK3SIR

Hi Folks,

I can recall in a post a couple of weeks (months???) back - that I cannot 
locate - that some minor changes to WSJT-X source were required to make WSJT-X 
2.2.x compile cleanly under the Qt 5.15.x Windows stream.

Before I start work on the promised updates to the Windows JTSDK 3.1 patches - 
to support the 5.15.1 as it is scheduled for release within the next few days - 
can anyone please refresh the knowledgebase here as to changes that may be 
needed to fully support the 5.15.x stream, or are they adapted already into the 
2.2.2 source?

The next update of patches for the JTSDK 3.1 x64 will deprecate the 5.13.x 
stream that is currently supported. There are issues with some of the libraries 
as we are all aware that makes this stream's utility to our community of zero 
value.

Patches will be released as always pending further development of the JTSDK at 
JTSDK @ GROUPS.IO (Google that - and it is not an email address).

Please only constructive guidance comments back that help the whole community 
to learn, understand and hence move forward 

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] Changes to the INSTALL file in the 2.2.2 tarball

2020-08-11 Thread Stephen VK3SIR

Bill,

You have access there so post your post your own suggestions – or if you do not 
have access provide me better solutions in a clear way that solves most 
people’s problems and I will post it for you!

Much documentation is not very helpful for training “newbies” … My 
documentation is BASED for Newbies and is STRAIGHT FORWARD and solves almost 
all their issues ! Many are HAVING HAMLIB ISSUES with the outdated base 
libraries that you distribute. I provide solutions; I deducate …. many provide 
cryptics … and hence grief for themselves in p[laces like this….

Sound familiar

THINK about the majority of your target audience… They need and want to be 
brought up to your level. ….They are NOT at the same level as you ! I am basing 
response to the level of what AR is about and should be – Experimentation and 
Self training. Many responses in here treat Amateurs as fools – and on that 
subject I have been rather vocal when it has occurred.

Document and guide in a CLEARER fashion … You have written most of your 
documentation as if we were all supposed to be PHD’s

You win ! I am not arguing ! I am just responding to hours and hours of work 
working with others and overcoming their issues!

You can pee highest up the wall 

Steve I



From: Bill Somerville 
Sent: Wednesday, 12 August 2020 11:15 AM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] Changes to the INSTALL file in the 2.2.2 tarball

On 12/08/2020 02:01, Stephen VK3SIR wrote:
Folks,

I have provided a way. I have also just added a post in that provides “cut and 
paste” steps.

Some of your Linux compile steps are incomplete (so refer to mine) … as steps 
in the OVER ARCHING Install File do not match steps needed in the WSJTX.TAR 
file.

https://groups.io/g/JTSDK/topic/75311015?p=Created,,,20,2,0,0::recentpostdate/sticky,,,20,2,0,75311015

There are lots of ways, and all are good ☺ Yet some of the tarball releases 
that you provide do not work with EVERY “OOB Experience” – and I personally 
receive lots of private email requests to improve the install, deploy and 
“tinker” experience. A number of Amateurs have come to me privately to seek 
guidance. The link above provides a way that is ensured to work – and cleanly – 
and is within the framework of what the original poster requested.

This is not a “who can pee up the wall the highest” competition … The post WAS 
about HOW to make things work from source and in the cleanest way possible.

I also get lots of emails about HOW we play in here and how some people tend to 
be personally targeted…. And as many know I bite !

Remember what we do and say in here is seen by many; playing personality games 
diminishes all of us in AR. I am not playing personality games here – I am just 
helping others. Play “nicely”.

My aim here is guidance and improvement for others. Please note the changes 
needed bill in the documentation.

73

Steve I
VK3VM / VK3SIR

Steve,

you are providing instructions to build an unreleased version of Hamlib with 
WSJT-X, that's fine for your own use but please do not tout it as a "better way 
to build WSJT-X" for casual users. We provide a bundled tarball with both a 
released version of WSJT-X and an unreleased version of Hamlib that we are 
prepared to support. The last part is the important part here, until Hamlib is 
officially released with a reasonably current version we will continue to 
bundle Hamlib with WSJT-X, it may be broken but that is what we are prepared to 
support.

I note that, to my knowledge, you have never provided any contribution to the 
WSJT-X project in the form of a patch or PR, what is your intention here?

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

Re: [wsjt-devel] Changes to the INSTALL file in the 2.2.2 tarball

2020-08-11 Thread Stephen VK3SIR

Folks,

I have provided a way. I have also just added a post in that provides “cut and 
paste” steps.

Some of your Linux compile steps are incomplete (so refer to mine) … as steps 
in the OVER ARCHING Install File do not match steps needed in the WSJTX.TAR 
file.

https://groups.io/g/JTSDK/topic/75311015?p=Created,,,20,2,0,0::recentpostdate/sticky,,,20,2,0,75311015

There are lots of ways, and all are good ☺ Yet some of the tarball releases 
that you provide do not work with EVERY “OOB Experience” – and I personally 
receive lots of private email requests to improve the install, deploy and 
“tinker” experience. A number of Amateurs have come to me privately to seek 
guidance. The link above provides a way that is ensured to work – and cleanly – 
and is within the framework of what the original poster requested.

This is not a “who can pee up the wall the highest” competition … The post WAS 
about HOW to make things work from source and in the cleanest way possible.

I also get lots of emails about HOW we play in here and how some people tend to 
be personally targeted…. And as many know I bite !

Remember what we do and say in here is seen by many; playing personality games 
diminishes all of us in AR. I am not playing personality games here – I am just 
helping others. Play “nicely”.

My aim here is guidance and improvement for others. Please note the changes 
needed bill in the documentation.

73

Steve I
VK3VM / VK3SIR




From: Bill Somerville 
Sent: Wednesday, 12 August 2020 10:30 AM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] Changes to the INSTALL file in the 2.2.2 tarball

Steve,

your reply below makes no sense!

I will repeat, the combined sources tarball we release includes instructions to 
build on Linux, they are complete. Yes there are some typos and it needs 
updating for the version numbers mentioned, that is fixed for the next release, 
did you even read this email thread before suggesting that some other 
instructions should be followed?

What are you suggesting needs to be "forced" to run?

By far the simplest instructions to follow are the ones provided in the single 
INSTALL file at the root of the sources tarball. Note the singular INSTALL file.

Like many Open Source projects there are different build instructions for 
developers wishing to contribute to the project, there's nothing unusual about 
that, but those instructions are not needed for users who simply want to build 
the application to run. We provide a build script, and instructions to run it, 
just for that sort of user.

73
Bill
G4WJS.

On 12/08/2020 01:21, Stephen VK3SIR wrote:
Bill,

KISS Principle in my answer to Rob’s post …. Yes the “dropped tarball” it can 
be forced to run … but its BY FAR simpler and easier to follow the instructions 
in the INSTALL files :-D

I have had lots and lots and lots of background inquiry on Ubuntu 20.04 … 
following the steps in the install file and compiling from source is BY FAR the 
easiest way to make WSJTX work – and properly (considering there have also been 
a lot of changes to Hamlib).

By the way, has the INSTALL files been updated for the next release as they 
were a little dated and some instructions out of sync?

73

Steve I
VK3VM / VK3SIR

From: Bill Somerville <mailto:g4...@classdesign.com>
Sent: Wednesday, 12 August 2020 10:10 AM
To: wsjt-devel@lists.sourceforge.net<mailto:wsjt-devel@lists.sourceforge.net>
Subject: Re: [wsjt-devel] Changes to the INSTALL file in the 2.2.2 tarball

Steve,

there is no need to follow the build instructions in the project git repo if 
you are building to run. Maybe if you are building to contribute patches. The 
INSTALL file in the sources tarball we provide contains complete instructions 
for building a working WSJT-X for Linux. Please don't over-complicate a 
relatively simple recipe for building.

73
Bill
G4WJS.

On 12/08/2020 01:01, Stephen VK3SIR wrote:
Rob,

There is no repo that you can just “drop and run” for WSJTX 2.2.2 – You really 
need to compile your own 

Go to the JTSDK @ GROUPS.IO site. I have a post there for dependencies etc. 
needed to build your own WSJTX on Ubuntu 20.04.

i.e. 
https://groups.io/g/JTSDK/topic/some_dependencies_requisites/75311015?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,75311015

Then follow the steps inside the INSTALL files (the top level one in the repo 
and then the main set of steps inside WSJTX.TGZ)

73

Steve I
VK3VM / VK3SIR

From: Rob Robinett <mailto:r...@robinett.us>
Sent: Wednesday, 12 August 2020 8:44 AM
To: WSJT software development 
<mailto:wsjt-devel@lists.sourceforge.net>
Subject: Re: [wsjt-devel] Changes to the INSTALL file in the 2.2.2 tarball

Hi Bill and David,

Could I find a source tarball which builds on Ubuntu 20.04?  I have several 
wsprdaemon sites which want to move to 20.02.

My attempt to follow David's instructions have failed and I have so much other 
SW to work on that I don't want to reinvent the wheel.

Re: [wsjt-devel] Changes to the INSTALL file in the 2.2.2 tarball

2020-08-11 Thread Stephen VK3SIR

Bill,

KISS Principle in my answer to Rob’s post …. Yes the “dropped tarball” it can 
be forced to run … but its BY FAR simpler and easier to follow the instructions 
in the INSTALL files :-D

I have had lots and lots and lots of background inquiry on Ubuntu 20.04 … 
following the steps in the install file and compiling from source is BY FAR the 
easiest way to make WSJTX work – and properly (considering there have also been 
a lot of changes to Hamlib).

By the way, has the INSTALL files been updated for the next release as they 
were a little dated and some instructions out of sync?

73

Steve I
VK3VM / VK3SIR

From: Bill Somerville 
Sent: Wednesday, 12 August 2020 10:10 AM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] Changes to the INSTALL file in the 2.2.2 tarball

Steve,

there is no need to follow the build instructions in the project git repo if 
you are building to run. Maybe if you are building to contribute patches. The 
INSTALL file in the sources tarball we provide contains complete instructions 
for building a working WSJT-X for Linux. Please don't over-complicate a 
relatively simple recipe for building.

73
Bill
G4WJS.

On 12/08/2020 01:01, Stephen VK3SIR wrote:
Rob,

There is no repo that you can just “drop and run” for WSJTX 2.2.2 – You really 
need to compile your own 

Go to the JTSDK @ GROUPS.IO site. I have a post there for dependencies etc. 
needed to build your own WSJTX on Ubuntu 20.04.

i.e. 
https://groups.io/g/JTSDK/topic/some_dependencies_requisites/75311015?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,75311015

Then follow the steps inside the INSTALL files (the top level one in the repo 
and then the main set of steps inside WSJTX.TGZ)

73

Steve I
VK3VM / VK3SIR

From: Rob Robinett <mailto:r...@robinett.us>
Sent: Wednesday, 12 August 2020 8:44 AM
To: WSJT software development 
<mailto:wsjt-devel@lists.sourceforge.net>
Subject: Re: [wsjt-devel] Changes to the INSTALL file in the 2.2.2 tarball

Hi Bill and David,

Could I find a source tarball which builds on Ubuntu 20.04?  I have several 
wsprdaemon sites which want to move to 20.02.

My attempt to follow David's instructions have failed and I have so much other 
SW to work on that I don't want to reinvent the wheel.

Thanks,

Rob

On Mon, Aug 3, 2020 at 4:55 AM Bill Somerville 
mailto:g4...@classdesign.com>> wrote:
Hi David,

I am not ruling out portable packaging, I just don't think it should be the 
prime focus of a small and busy development team. If someone makes a portable 
package, commit to keep it up to date, and it gets some traction amongst Linux 
users of WSJT-X; then that's fine.

I assume you realize that the WSJT-X CMake build script already knows how to 
make a basic Debian or RPM package, the package target does that if run on a 
suitable machine. You would be better to use a git checkout rather than the 
combined WSJT-X sources tarball with bundled Hamlib. That would mean separately 
installing Hamlib, which is not hard and the WSJT-X repo INSTALL file 
(different from the one in the combined sources tarball) has a recipe. Making a 
package is no more than invoking `make package` or `cmake --build --target 
package`.

73
Bill
G4WJS.

On 03/08/2020 08:48, David Spoelstra wrote:
Bill-

Just got a new wsjt digest where you answered a question about Flatpak. From 
your answer, that doesn't seem to be the correct direction.

Since I like to be on the latest distro of Ubuntu, maybe I should learn to make 
a deb and give you guys that to post?

Basically I'm looking for some pointers on how to best help the project.

73,
-David, N9KT


On Sun, Aug 2, 2020 at 4:38 PM David Spoelstra 
mailto:dav...@mediamachine.com>> wrote:
Bill-

I just built 2.2.2 on Ubuntu 20.04 and noticed a few things that should be 
fixed in the INSTALL file in the 2.2.2 tarball. Some of them are cosmetic. Some 
are actual errors if you follow the steps (line 131). Just my way to try and 
help the project!

Line 13:
Copyright 2001 - 2018 by Joe Taylor, K1JT.
should be:
Copyright 2001 - 2020 by Joe Taylor, K1JT.

Line 34 (Debian name):
   Also  qtmultimedia5-dev,   libqt5libserialport5-dev,  qttools5-dev,
should be:
   Also  qtmultimedia5-dev,   libqt5serialport5-dev,  qttools5-dev,

Line 35 (Debian name):
libusb-1.0.0-dev
should be:
libusb-1.0-0-dev

Line 71:
repository  e.g.  wsjtx-1.9.1  by  specifying  it  as  a  variable  to
should be:
repository  e.g.  wsjtx-2.2.2  by  specifying  it  as  a  variable  to

Line 74:
$ cmake -D WSJTX_TAG=wsjtx-2.0.0 
should be:
$ cmake -D WSJTX_TAG=wsjtx-2.2.2 

Line 111:
$ cmake -D WSJTX_TAG=wsjtx-2.0.0 
should be:
$ cmake -D WSJTX_TAG=wsjtx-2.2.2 

Line 122:
The  above commands,  if  successful,  will produce  'wsjtx-1.9.1.tgz'
should be:
The  above commands,  if  successful,  will produce  'wsjtx-2.2.2.tgz'

Line 128:
$ tar xzf wsjtx-2.0.0.tgz
should be:
$ tar xzf wsjtx-2.2.2.tgz

Line 131:
$ cmake -DWSJT_SKIP_MANPAGES=ON

Re: [wsjt-devel] Changes to the INSTALL file in the 2.2.2 tarball

2020-08-11 Thread Stephen VK3SIR

Rob,

There is no repo that you can just “drop and run” for WSJTX 2.2.2 – You really 
need to compile your own 

Go to the JTSDK @ GROUPS.IO site. I have a post there for dependencies etc. 
needed to build your own WSJTX on Ubuntu 20.04.

i.e. 
https://groups.io/g/JTSDK/topic/some_dependencies_requisites/75311015?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,75311015

Then follow the steps inside the INSTALL files (the top level one in the repo 
and then the main set of steps inside WSJTX.TGZ)

73

Steve I
VK3VM / VK3SIR

From: Rob Robinett 
Sent: Wednesday, 12 August 2020 8:44 AM
To: WSJT software development 
Subject: Re: [wsjt-devel] Changes to the INSTALL file in the 2.2.2 tarball

Hi Bill and David,

Could I find a source tarball which builds on Ubuntu 20.04?  I have several 
wsprdaemon sites which want to move to 20.02.

My attempt to follow David's instructions have failed and I have so much other 
SW to work on that I don't want to reinvent the wheel.

Thanks,

Rob

On Mon, Aug 3, 2020 at 4:55 AM Bill Somerville 
mailto:g4...@classdesign.com>> wrote:
Hi David,

I am not ruling out portable packaging, I just don't think it should be the 
prime focus of a small and busy development team. If someone makes a portable 
package, commit to keep it up to date, and it gets some traction amongst Linux 
users of WSJT-X; then that's fine.

I assume you realize that the WSJT-X CMake build script already knows how to 
make a basic Debian or RPM package, the package target does that if run on a 
suitable machine. You would be better to use a git checkout rather than the 
combined WSJT-X sources tarball with bundled Hamlib. That would mean separately 
installing Hamlib, which is not hard and the WSJT-X repo INSTALL file 
(different from the one in the combined sources tarball) has a recipe. Making a 
package is no more than invoking `make package` or `cmake --build --target 
package`.

73
Bill
G4WJS.

On 03/08/2020 08:48, David Spoelstra wrote:
Bill-

Just got a new wsjt digest where you answered a question about Flatpak. From 
your answer, that doesn't seem to be the correct direction.

Since I like to be on the latest distro of Ubuntu, maybe I should learn to make 
a deb and give you guys that to post?

Basically I'm looking for some pointers on how to best help the project.

73,
-David, N9KT


On Sun, Aug 2, 2020 at 4:38 PM David Spoelstra 
mailto:dav...@mediamachine.com>> wrote:
Bill-

I just built 2.2.2 on Ubuntu 20.04 and noticed a few things that should be 
fixed in the INSTALL file in the 2.2.2 tarball. Some of them are cosmetic. Some 
are actual errors if you follow the steps (line 131). Just my way to try and 
help the project!

Line 13:
Copyright 2001 - 2018 by Joe Taylor, K1JT.
should be:
Copyright 2001 - 2020 by Joe Taylor, K1JT.

Line 34 (Debian name):
   Also  qtmultimedia5-dev,   libqt5libserialport5-dev,  qttools5-dev,
should be:
   Also  qtmultimedia5-dev,   libqt5serialport5-dev,  qttools5-dev,

Line 35 (Debian name):
libusb-1.0.0-dev
should be:
libusb-1.0-0-dev

Line 71:
repository  e.g.  wsjtx-1.9.1  by  specifying  it  as  a  variable  to
should be:
repository  e.g.  wsjtx-2.2.2  by  specifying  it  as  a  variable  to

Line 74:
$ cmake -D WSJTX_TAG=wsjtx-2.0.0 
should be:
$ cmake -D WSJTX_TAG=wsjtx-2.2.2 

Line 111:
$ cmake -D WSJTX_TAG=wsjtx-2.0.0 
should be:
$ cmake -D WSJTX_TAG=wsjtx-2.2.2 

Line 122:
The  above commands,  if  successful,  will produce  'wsjtx-1.9.1.tgz'
should be:
The  above commands,  if  successful,  will produce  'wsjtx-2.2.2.tgz'

Line 128:
$ tar xzf wsjtx-2.0.0.tgz
should be:
$ tar xzf wsjtx-2.2.2.tgz

Line 131:
$ cmake -DWSJT_SKIP_MANPAGES=ON -DWSJT_GENERATE_DOCS=OFF ../wsjtx-2.0.0
should be:
$ cmake -DWSJT_SKIP_MANPAGES=ON -DWSJT_GENERATE_DOCS=OFF ..


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


--
Rob Robinett
AI6VN
r...@robinett.us
mobile: +1 650 218 8896
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Rig verification

2020-07-16 Thread Stephen VK3SIR

Folks,

I am only responding here as I have had a few emails in the background ... and 
I put this out there to guide learning for some... for many this will be old 
hat news !

There has been a lot of work take place with Hamlib since R 2.2.2 was released. 
WSJTX relies heavily on Hamlib.

The packages of Hamlib used to compile and release the precompiled versions on 
release at https://physics.princeton.edu/pulsar/K1JT/wsjtx.html are built to 
versions of Hamlib that are snapshotted within the source tarball  found within 
the source distribution found at 
https://physics.princeton.edu/pulsar/K1JT/wsjtx-2.2.2.tgz . 

Bill G4WJS's maintains a repository at git://git.code.sf.net/u/bsomervi/hamlib 
that is used to standardise WSJTX development; all documentation within the 
WSJTX source tarball refers to Bill's repository. Bill's repository may or may 
not currently be synchronised with the code in the release tarball. Bill may be 
able to provide further guidance on this for those of us that are developing 
software. Yet it's a very sound programing practise to base bug-reporting off 
known snapshots of libraries.

The "Master" live development Hamlib repository can be found at 
https://git.code.sf.net/p/hamlib/code . This is "bleeding edge" code as some 
would define it.

I can foresee that Mike W9MDB and the Hamlib team are aiming to work to slating 
a formal Hamlib 4.0 release (superseding the 3.3 release around in most places).

For WSJTX the preferred repo is that which Bill G4WJS maintains at 
git://git.code.sf.net/u/bsomervi/hamlib  :-) 

Based on Mike's email (and for ongoing development, debugging, compatibility 
testing etc.) the "Master " repo should be used. You just replace references 
referred to in the WSJTX INSTALL readme file that refer to Bill's repo (i.e. 
git://git.code.sf.net/u/bsomervi/hamlib ) with those for the "Master" repo 
(i.e. https://git.code.sf.net/p/hamlib/code ).

All is easy if you are compiling with Linux and Linux variants ... But for 
Windows compiles to the latest Hamlib source the simplest way is to use Greg 
KI7MT's JTSDK's. There is complexity here as there has been no formal 
maintenance of the Windows JTSDK's for 12 months.

The JTSDK 3.0 as delivered/documented on the JTSDK download site (i.e. 
https://sourceforge.net/projects/jtsdk/ ) should compile a 32-bit Windows wsjtx 
... There are some "patches" if you review the posts on jt...@groups.io (Google 
search that as it is not an email address - i.e. https://groups.io/g/JTSDK ) if 
you want to compile your own Windows WSJTX using the "Master" repository.

JTSDK 3.1 is also available at https://sourceforge.net/projects/jtsdk/ - but in 
order to "work easily" and "behave" just like the JTSDK 3.0 it needs a series 
of "experiment" patches posted at jt...@groups.io. The README file attached 
with the "Experiment" scripts allow for configuration options to be set to be 
able to pull from the "preferred" WSJTX repo - Bill Somerville's Repository, 
the "Master" Hamlib Repository or even not to pull from a repository at all 
(and use the packaged Hamlib snapshot packaged in the WSJTX source).

The best guidance for Mike W9MDB and the Hamlib team would be provided from 
people that are compiling their own Hamlib and WSJTX (and perhaps other 
software such as the FL-software) and not those using pre-compiled software or 
standardised library snapshots. 

Can I recommend that if you are responding to Mike's call please specify if you 
are using "new" Hamlib source or if you are using packaged WSJTX source and/or 
distributions?

If you need help please ask or post here or respond directly via email. If you 
need help compiling WSJTX for yourself then please peruse the JTSDK @ GROUPS.IO 
site at https://groups.io/g/JTSDK  first [ Note: as I have been using it as a 
blog to help as many as I possibly can and to avoid repetition as many cannot 
post here due to the lack of maintenance at that site ].

HAM - Help All mankind. We are here to help and progress learning. I also hope 
that the intent of this post is clear and that it is to help.

73

Steve I
VK3VM / VK3SIR

-Original Message-
From: Christoph Berg  
Sent: Thursday, 16 July 2020 6:43 PM
To: Black Michael ; WSJT software development 

Subject: Re: [wsjt-devel] Rig verification

Re: Black Michael via wsjt-devel
>   3009  Icom                   IC-706                  20200614.0      
> Untested    RIG_MODEL_IC706

My 706 (no mk something) works flawlessly.

(I used to get "rig communication problem" popups, but these are rare now and I 
think the problem is in the USB serial adapter not coping with HF, and not in 
the rig.)

Christoph


___
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] Group Moderators

2020-07-15 Thread Stephen VK3SIR

Group Moderators,

I did not receive this email; such information is rather critical for work that 
I perform for the community on the JTSDK in the absence of the main convenors.

No the message is not in SPAM folders … This is a “Hotmail” account so there 
are not issues there.

Can you please ensure that I receive these messages in the future?

73

Steve I
VK3VM / VK3SIR

From: Al Reeves 
Sent: Thursday, 16 July 2020 2:23 PM
To: Black Michael via wsjt-devel 
Subject: Re: [wsjt-devel] Rig verification

Michael:

I have a FLEX 6400 and it works flawlessly with WSJT-X.  Let me know if there's 
anything else you need.

73
Al
W1JHU
On 7/16/2020 12:11 AM, Black Michael via wsjt-devel wrote:

If anybody has a rig out there that's in this list and you have it working with 
WSJT-X...or if you have any bugs to report working with WSJT-X please let me 
know.

Would like to promote as many of these to stable as possible and WSJT-X is one 
of a couple programs that exercises a rig pretty well.



Mike W9MDB





  Rig #  MfgModel   Version Status  
Macro

  1003  Yaesu  FT-1000D20200323.0  Beta 
   RIG_MODEL_FT1000D

  1005  Yaesu  FT-747GX20200323.0  Beta 
   RIG_MODEL_FT747

  1006  Yaesu  FT-757GX20200325.0  Beta 
   RIG_MODEL_FT757

  1016  Yaesu  FT-990  20200323.0  Alpha
   RIG_MODEL_FT990

  1017  Yaesu  FRG-100 20160409.0  Beta 
   RIG_MODEL_FRG100

  1018  Yaesu  FRG-960020160409.0  Untested 
   RIG_MODEL_FRG9600

  1019  Yaesu  FRG-880020160409.0  Untested 
   RIG_MODEL_FRG8800

  1021  Yaesu  FT-100  20200323.0  Beta 
   RIG_MODEL_FT100

  1026  Yaesu  VR-5000 20200505.0  Alpha
   RIG_MODEL_VR5000

  1027  Yaesu  FT-450  20200614.0  Beta 
   RIG_MODEL_FT450

  1030  Yaesu  FTDX-9000   20200614.0  Untested 
   RIG_MODEL_FT9000

  1031  Yaesu  FT-980  20200114.0  Alpha
   RIG_MODEL_FT980

  1032  Yaesu  FT-DX5000   20200614.0  Alpha
   RIG_MODEL_FTDX5000

  1033  Vertex StandardVX-1700 20200320.0  Alpha
   RIG_MODEL_VX1700

  1037  Yaesu  FT-DX3000   20200614.0  Beta 
   RIG_MODEL_FTDX3000

  1039  Yaesu  FT-600  20200113.0  Beta 
   RIG_MODEL_FT600

  1040  Yaesu  FT-DX101D   20200614.0  Beta 
   RIG_MODEL_FTDX101D

  2001  KenwoodTS-50S  20200624.0  Alpha
   RIG_MODEL_TS50

  2003  KenwoodTS-450S 20200624.0  Beta 
   RIG_MODEL_TS450S

  2005  KenwoodTS-690S 20200624.0  Beta 
   RIG_MODEL_TS690S

  2006  KenwoodTS-711  20200624.0  Untested 
   RIG_MODEL_TS711

  2008  KenwoodTS-811  20200624.0  Untested 
   RIG_MODEL_TS811

  2009  KenwoodTS-850  20200624.0  Beta 
   RIG_MODEL_TS850

  2010  KenwoodTS-870S 20200624.0  Beta 
   RIG_MODEL_TS870S

  2011  KenwoodTS-940S 20200624.0  Alpha
   RIG_MODEL_TS940

  2015  KenwoodR-5000  20200407.0  Alpha
   RIG_MODEL_R5000

  2017  KenwoodTH-D7A  20200701.0  Beta 
   RIG_MODEL_THD7A

  2019  KenwoodTH-F6A  20200701.0  Beta 
   RIG_MODEL_THF6A

  2020  KenwoodTH-F7E  20200701.0  Beta 
   RIG_MODEL_THF7E

  2021  Elecraft   K2  20200624.0  Beta 
   RIG_MODEL_K2

  2022  KenwoodTS-930  20200624.0  Untested 
   RIG_MODEL_TS930

  2023  KenwoodTH-G71  20200701.0  Beta 
   RIG_MODEL_THG71

  2024  KenwoodTS-680S 20200624.0  Beta 
   RIG_MODEL_TS680S

  2025  KenwoodTS-140S 20200624.0  Beta 
   RIG_MODEL_TS140S

  2026  KenwoodTM-D700 20200701.0  Beta 
   RIG_MODEL_TMD700

  2027  KenwoodTM-V7   20200701.0  Beta 
   RIG_MODEL_TMV7

  2029  Elecraft   K3  20200624.0  Beta 
   RIG_MODEL_K3

  2030  KenwoodTRC-80  20200624.0  Alpha
   RIG_MODEL_TRC80

  2032  SigFox

Re: [wsjt-devel] Issue: v2.2.2 (and earlier) Invalid Hardware frequency ranges trying to be addressed and the handling of such anomalies #bug

2020-07-13 Thread Stephen VK3SIR

Bill,


Ø  are you sure you have waited long enough…

Absolutely sure. I’ve been sitting on this for around 2 weeks now and have 
tested almost every combo possible. It has been back tested with 2.2.1 and also 
with the “model” Hamlib sources from 2.2.1 and 2.2.2… but based around the 
“master” repo as there has been a lot of work going on with the FT-8x7 series 
of radios…

The fact that this also occurs with the IC-725 (but that messages are displayed 
for this) means that a referral to you is necessary (and excuse the doctor-pun 
;-)).

Mike W9MDB has been into the machines a number of times; Hamlib needed to be 
eliminated as far as is possible as a cause before referring forward to WSJTX 
code.

73

Steve I

From: Bill Somerville 
Sent: Monday, 13 July 2020 7:17 PM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] Issue: v2.2.2 (and earlier) Invalid Hardware 
frequency ranges trying to be addressed and the handling of such anomalies #bug

On 13/07/2020 10:01, Stephen VK3SIR wrote:
Hi Everyone,

I have noted that when you select a frequency to operate on that hardware is 
not capable of then a Hamlib disconnect (i.e. The Settings/Radio configuration 
widgets) is thrown without any console error messages being recorded.

i.e. I run a FT-897D and an old IC-725 here… With either rig select 70Mhz first 
time … and it groans and returns to the previous state (as expected). Then 
select 70MHz again and a Hamlib disconnect without console warning traps being 
thrown on the console with both the FT-897D and the IC-725.

Note that no console messages are displayed with the FT-897D; there are some 
messages displayed with the IC-725.

Up-to-the-minute Hamlib snaps have had to be used (from the master repo) due to 
their being a lot of work going on in Hamlib with the FT8x7 range of Yaesu 
radios.

I have worked this through heavily with Mike W9MDB on both Windows x64 and 
Linux Ubuntu 20.04 and I am very sure – backed up by responses to different 
radio technologies - that the issue is not with Hamlib.

[ There is an appearance that the last state (i.e frequency, mode etc.) that 
the radio was on in WSJTX is saved rather than the last valid state. ]

Its minor; few will observe this. Concern is that "Doctor...it's hurts when I 
do thisDoctor:  then don't do that" could be responded back. That is not 
the point; as I have stated repeatedly many use this project as a template for 
programming and standards – even in the commercial world.

Therefore it is our obligation to report as this small issue could cause huge 
issues later down the track.

Thanks especially to Mike W9MDB and everyone else that has been helping and 
testing with my observations here.

73

Steve I
VK3VM / VK3SIR

Hi Steve,

are you sure you have waited long enough for an error to be shown? There are 
several retries made before an error message is displayed, this can take tens 
of seconds with with some rig models.

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

[wsjt-devel] Issue: v2.2.2 (and earlier) Invalid Hardware frequency ranges trying to be addressed and the handling of such anomalies #bug

2020-07-13 Thread Stephen VK3SIR

Hi Everyone,

I have noted that when you select a frequency to operate on that hardware is 
not capable of then a Hamlib disconnect (i.e. The Settings/Radio configuration 
widgets) is thrown without any console error messages being recorded.

i.e. I run a FT-897D and an old IC-725 here… With either rig select 70Mhz first 
time … and it groans and returns to the previous state (as expected). Then 
select 70MHz again and a Hamlib disconnect without console warning traps being 
thrown on the console with both the FT-897D and the IC-725.

Note that no console messages are displayed with the FT-897D; there are some 
messages displayed with the IC-725.

Up-to-the-minute Hamlib snaps have had to be used (from the master repo) due to 
their being a lot of work going on in Hamlib with the FT8x7 range of Yaesu 
radios.

I have worked this through heavily with Mike W9MDB on both Windows x64 and 
Linux Ubuntu 20.04 and I am very sure – backed up by responses to different 
radio technologies - that the issue is not with Hamlib.

[ There is an appearance that the last state (i.e frequency, mode etc.) that 
the radio was on in WSJTX is saved rather than the last valid state. ]

Its minor; few will observe this. Concern is that "Doctor...it's hurts when I 
do thisDoctor:  then don't do that" could be responded back. That is not 
the point; as I have stated repeatedly many use this project as a template for 
programming and standards – even in the commercial world.

Therefore it is our obligation to report as this small issue could cause huge 
issues later down the track.

Thanks especially to Mike W9MDB and everyone else that has been helping and 
testing with my observations here.

73

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

[wsjt-devel] Quick Query re Makefile for Qt 5.15.x support

2020-07-11 Thread Stephen VK3SIR

Bill,



A couple of weeks back you provided some guidance as to necessary changes to 
the Makefiles needed to build WSJTX 2.2.1 (I think it was) under the Qt 5.15.x 
stream.



Qt 5.15.1 is not far away.



Has WSJTX 2.2.2(+) source been made Qt 5.15.x friendly?

If not can you please re-post that guidance (or forward me the email via a PM 
if you still have it) as for some reason I have lost access to/cannot locate 
this guide post?

I’ll post some updates to the JTSDK “patches” for The Windows JTSDK 3.1 that 
can be found at JTSDK @ GROUPS.IO once Qt 5.15.1 is made available. Note that I 
will remove any support for the Qt 5.13.x stream as we know that this Qt 
release provides some issues for building and operating WSJTX.



73 and thanks.



Steve I

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

[wsjt-devel] Possible issues introduced when the Linux xorgxrdp package is deploed.

2020-07-08 Thread Stephen VK3SIR

Hi Everyone,

Is anyone observing possible issues when the Linux xorgxrdp packages are 
deployed?

[ Note here I am testing with FT-897D, SCU-17, Ubuntu 20.04 x64 on an old 
32-bit EFI iMac  With WSJTX 2.2.2 and “Master” repositorty Hamlib ]

Hardware and “basic OS incompatibilities” are eliminated as I have it working 
perfectly in the background … and packages are deployed onto “vanilla” Ubuntu 
20.04 as described in my post on jt...@groups.io .

I am observing issues such as intermittent data flow issues that throw Hamlib 
related errors and GUI Waterfall timing intervals basically not working, as 
well as intermittent abends.

I state here that the issue is not WSJTX or Hamlib in these cases – from my 
extensive research - as when the xorgxrdp packages are not deployed then 
everything appears to work perfectly.

As to why issues could occur its quite understandable when one thinks issues 
and the services that xorgxrdp provides through; yet coexistence of the package 
(and not direct usage of it) should not cause issues. If there are no reports 
of issues – or lots of reports of success stories – then I need direct 
experimentation elsewhere.

73

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

[wsjt-devel] FW: 2.2.2 Decoding Performance

2020-07-03 Thread Stephen VK3SIR

[ I'll resend this as its not flowed through (Which has resulted in some 
testing of late) ]

Jim,

A very appropriate comment based on some email chats here going on in the 
background.  Background discussion that I have been having relates around the 
"standards" discussion opened earlier in the week and the necessity in this 
modern day and age for standards with so many new manufacturers - especially 
from China - coming online.

The point is that JTDX is a fork ... WSJTX is "The Model". WSJT-X being open 
source provides the base from where other things can evolve and possibly 
improve (i.e JTDX, JS8CALL just to name a couple of the main "forked" and in 
some cases evolved products).

JTDX may very well have processing improvements. That is good, and can provide 
some utility for many users. Some MAY prefer its application - and that is 
well, good and highly constructive for AR.

WSJTX is the model and sets base standards. Some "enhancements" in forks MAY at 
some stages may make it into the model too as it has (i.e. the RR73 from JTDX) 
! And that is a good, constructive thing !

73

Steve I
VK3VM / VK3SIR

Ps: I still use 2.2.1 in this "antipodean" location as it does clearly provide 
some advantages, from my experience in my location, over 2.2.2 !


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

Re: [wsjt-devel] 2.2.2 Decoding Performance

2020-07-03 Thread Stephen VK3SIR

Jim,

A very appropriate comment based on some email chats here going on in the 
background.  Background discussion that I have been having relates around the 
"standards" discussion opened earlier in the week and the necessity in this 
modern day and age for standards with so many new manufacturers - especially 
from China - coming online.

The point is that JTDX is a fork ... WSJTX is "The Model". WSJT-X being open 
source provides the base from where other things can evolve and possibly 
improve (i.e JTDX, JS8CALL just to name a couple of the main "forked" and in 
some cases evolved products).

JTDX may very well have processing improvements. That is good, and can provide 
some utility for many users. Some MAY prefer its application - and that is 
well, good and highly constructive for AR.

WSJTX is the model and sets base standards. Some "enhancements" in forks MAY at 
some stages may make it into the model too as it has (i.e. the RR73 from JTDX) 
! And that is a good, constructive thing !

73

Steve I
VK3VM / VK3SIR

Ps: I still use 2.2.1 in this "antipodean" location as it does clearly provide 
some advantages, from my experience in my location, over 2.2.2 !


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

Re: [wsjt-devel] FW: CAT problems with FT817, FT857 and FT897

2020-07-02 Thread Stephen VK3SIR

Bill and Claude (and my SINCEREST apologies for hitting the “d” rather than “s” 
and referring to you as you Clause),

The “dialout” group access is needed as a minimum for USB access to device such 
as the SCU-17. As you are working primarily with a “tty” group - and for the 
purposes of being “generic” across system versions – it is always traditionally 
‘safer’ to add “tty” in when using local systems.

Access to the “audio” group is also required for access to the sound 
interfaces. As these two groups are needed its perhaps best to stack these in 
with the “usermod” command (ref to it: 
https://linuxize.com/post/how-to-add-user-to-group-in-linux/ )

I have seen some systems – past - where the “video” group is also needed for 
proper rendering within the graphics driver (weird) for some functions that 
WSJT-X uses in Qt. Again Weird !

The example I provided stacked a few “to be sure” groups onto individual users 
based on too many years of dealing with such issues. But as a minimum for most 
systems the following basic command should be enough and I would recommend  
should head into the documentation of both the “overarching” and “wsjtx source” 
INSTALL files:

i.e. 1: sudo usermod -a -G tty,dialout,audio  (then of course log out and 
back in to enact the changes).


i.e. 2: Also as a reinforcement of the earlier ask for doc review/enhancement: 
can a “sudo” please be added re the last line for the Linux install instruction 
(to /usr/local) ==> sudo cmake --build . --target install   … As documented 
this works as “root” but not as a standard user form where most can and should 
work. [ I have been growled at extensively over the years myself for working as 
“root” ]. We are all “lazy” and tend to copy from these docs when building so 
this would be of great assistance ☺

Claude I primarily run the FT-991 (not A model) here – that for all purposes is 
identical – and note that all compiles and works fine at this point with Linux 
and Windows x64 (but will not promise).

I may have put some patches together to have made the JTSDK 3.1 “functional” – 
but the true heart here back to the late 80’s/early 90’s is with BSD and Linux.

73.

Steve I
VK3VM / VK3SIR


From: Bill Somerville 
Sent: Thursday, 2 July 2020 9:25 PM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] FW: CAT problems with FT817, FT857 and FT897

Hi Claude and Steve,

the easiest command to add a user to a group on Linux is:

sudo adduser $USER dialout
then log out (log out means log out of the desktop session, not just the 
terminal window), and back in. Use the 'id' command to check membership. On 
some systems (non-Linux) the correct group is 'uucp', just look at which group 
devices are in to determine which group you need to be a member of.

73
Bill
G4WJS.

On 02/07/2020 11:17, Stephen VK3SIR wrote:

Clause,



A minor correction here: its -G



i.e. sudo usermod -a -G adm,tty,disk,dialout,audio,video,plugdev 

There is a little "over-caution" in places here !



73



Steve I

VK3VM / VK3SIR



-Original Message-

From: Claude Frantz 
<mailto:claude.fra...@bayern-mail.de>

Sent: Thursday, 2 July 2020 7:58 PM

To: wsjt-devel@lists.sourceforge.net<mailto:wsjt-devel@lists.sourceforge.net>

Subject: Re: [wsjt-devel] FW: CAT problems with FT817, FT857 and FT897



On 7/2/20 11:25 AM, Stephen VK3SIR wrote:



Many thanks, Stephen, for this very interesting information and for your tips.



i.e. sudo usermod -a G adm,tty,disk,dialout,audio,video,plugdev 

In my own environment, using Fedora, it was important to add "dialout".



Best wishes,

Claude (DJ0OT)


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

Re: [wsjt-devel] FW: CAT problems with FT817, FT857 and FT897

2020-07-02 Thread Stephen VK3SIR

Clause,

A minor correction here: its -G

> i.e. sudo usermod -a -G adm,tty,disk,dialout,audio,video,plugdev 

There is a little "over-caution" in places here !

73

Steve I
VK3VM / VK3SIR

-Original Message-
From: Claude Frantz  
Sent: Thursday, 2 July 2020 7:58 PM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] FW: CAT problems with FT817, FT857 and FT897

On 7/2/20 11:25 AM, Stephen VK3SIR wrote:

Many thanks, Stephen, for this very interesting information and for your tips.

> i.e. sudo usermod -a G adm,tty,disk,dialout,audio,video,plugdev 

In my own environment, using Fedora, it was important to add "dialout".

Best wishes,
Claude (DJ0OT)


___
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] FW: CAT problems with FT817, FT857 and FT897

2020-07-02 Thread Stephen VK3SIR

Ps:

> Also for the core developers: For the next source release, can the INSTALL 
> files 
> packaged at the top level of the tarball/within the "wsjtx.tar" tarball also 
> be made 
> consistent across the entire package i.e. update/incorporate the changes in 
> the 
> WSJT-X Linux build script shown above - referenced in the TOP LEVEL INSTALL 
> file 
> but not appearing in the INSTALL file packaged in wsjtx.tar? 

> Further to this, can some of the references in these valuable INSTALL 
> documents 
> please also be updated and made consistent with current releases (and PM me 
> back developers if you would like me to assist)?

Can you also please add a statement as to which user groups that a standard, 
non-admin user under Linux should be added to? Perhaps the WSJTX INSTALL and 
README files are both palces where this should be added? This question gets 
asked a lot in the background.

i.e. sudo usermod -a G adm,tty,disk,dialout,audio,video,plugdev 

Note the statement provided is only a guide so no picking on it (but precision 
would be best).

Steve I
VK3VM / VK3SIR


-Original Message-
From: Claude Frantz 
Sent: Thursday, 2 July 2020 6:28 PM
To: WSJT software development 
Subject: [wsjt-devel] CAT problems with FT817, FT857 and FT897

Hi all,

Can anyone here give us a short but precise description of the problems related 
to the equipment mentioned in the subject, please ?

Thanks you !

Best wishes,
Claude (DJ0OT)


___
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] CAT problems with FT817, FT857 and FT897

2020-07-02 Thread Stephen VK3SIR

Claude,

There issues in some cases are wide and various but based primarily around some 
"byte dropouts" and acknowledgement-of-commands. 

As an example, an issue that is currently being investigated relates to 
acknowledgement of commands (i.e. intermittently 3 bytes returned rather than 
the expected 5).

To quote Mike, he is like 'a dog with a bone' when it comes to understanding 
and resolving issues. Some issues may just be hardware and may only be possibly 
resolved by reporting issues to Linux and hardware developers too ! Great 
technicians and engineers are working on issues but working through issues 
can and does take time especially when you are maintaining generic libraries.

If you are having concerns with the FT-8x7 range of radios (and it seems to be 
limited at this stage to non-Windows builds) then pull Hamlib from the "master" 
repo at Github rather than the WSJTX-standardised G4WJS distribution that the 
developers here have mated the release to. 

It is critical that any issues/concerns be reported via the Hamlib lists.

Here are the build scripts needed (based on the INSTALL file packaged in 
wsjtx.tar) that just worked 100% (after dependencies were resolved for Ubuntu 
Linux 20.04:

For HAMLIB based off the MASTER Hamlib Repo (and for the intent of this forum 
use this repo ONLY if you are experiencing issues with Hamlib comms) as a test:

mkdir ~/hamlib-prefix
cd ~/hamlib-prefix
git clone https://github.com/Hamlib/Hamlib.git src  <<== Change here
cd src  <<== There is no "integration" 
distro to checkout so this is removed
./bootstrap
mkdir ../build
cd ../build
../src/configure --prefix=$HOME/hamlib-prefix \
   --disable-shared --enable-static \
   --without-cxx-binding --disable-winradio \
   CFLAGS="-g -O2 -fdata-sections -ffunction-sections" \
   LDFLAGS="-Wl,--gc-sections"
make
make install-strip

For WSJTX based off the SourceForge Repo:

mkdir -p ~/wsjtx-prefix/build
cd ~/wsjtx-prefix
git clone git://git.code.sf.net/p/wsjt/wsjtx src
cd ~/wsjtx-prefix/build
cmake -D CMAKE_PREFIX_PATH=~/hamlib-prefix -DWSJT_SKIP_MANPAGES=ON 
-DWSJT_GENERATE_DOCS=OFF ../src
cmake --build .
sudo cmake --build . --target install

Also for the core developers: For the next source release, can the INSTALL 
files packaged at the top level of the tarball/within the "wsjtx.tar" tarball 
also be made consistent across the entire package i.e. update/incorporate the 
changes in the WSJT-X Linux build script shown above - referenced in the TOP 
LEVEL INSTALL file but not appearing in the INSTALL file packaged in wsjtx.tar? 

Further to this, can some of the references in these valuable INSTALL documents 
please also be updated and made consistent with current releases (and PM me 
back developers if you would like me to assist)?

Thanks to all developers, and 73.

Steve I
VK3VM / VK3SIR


-Original Message-
From: Claude Frantz  
Sent: Thursday, 2 July 2020 6:28 PM
To: WSJT software development 
Subject: [wsjt-devel] CAT problems with FT817, FT857 and FT897

Hi all,

Can anyone here give us a short but precise description of the problems related 
to the equipment mentioned in the subject, please ?

Thanks you !

Best wishes,
Claude (DJ0OT)


___
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] Test - Again

2020-07-01 Thread Stephen VK3SIR

Testing systems yet again; upstream proxy and caching issues under diagnosis.
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] FT-897D - rig_get_vfo: Returning -8 (Protocol error) and read_ack errors with Ubuntu 20.04 running WSJTX 2.2.2

2020-07-01 Thread Stephen VK3SIR

Mike,

I tried pretty much all angles – including two reloads of the old iMac 5,1 with 
Ubuntu 20.04 and the Full “apt” deployed Qt 5.12.8 toolchain ! …. It won’t 
drive the FT-897D directly on that !

Yet all works PERFECTLY and as expected in a VMware Workstation 15.5.6 VM …

The anomaly is that the WSJT-X FLRig support (FLRig delivered by Canonical’s  
apt-delivery system) on the iMac 5,1 hardware drives the FT-897D perfectly 

[ Just to be 100% sure I’ll stick a SSD into the “lappie” that runs the VMware 
Workstation over the next few days – low priority – to completely prove 
hardware issues. ]

I do not believe further effort is needed at this point as there is obviously 
an “old (odd) hardware anomaly” somewhere.

I have (cross) posted this back to both the Hamlib and WSJT-X forums this 
research task may be of interest to others…

Thanks as always for your valuable time and effort!

73

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

[wsjt-devel] Test - Do not respond

2020-06-30 Thread Stephen VK3SIR

T E S T of a new system


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

Re: [wsjt-devel] Request for WSJT-X Feature

2020-06-30 Thread Stephen VK3SIR

My sincerest apology Dave !

No it was not directed at you !

I failed at multitasking here !

-Original Message-
From: Dave AA6YQ  
Sent: Tuesday, 30 June 2020 3:11 PM
To: 'WSJT software development' 
Subject: Re: [wsjt-devel] Request for WSJT-X Feature

+ AA6YQ comments below

On the first point, we more or less agree. A development team can focus on many 
things, true. The point Im trying to make here is that logging and weak-signal 
processing are two very different functions, and don't belong in the same 
application. If an exception is to be made here, yes, it should be loosely 
coupled.

More disagreement is found in the second point. Yes, a UDP message defined by 
the ADIF specification is an API. I do question if it's appropriate.

What I want is for the Ham Radio software generally: Let's catch up to modern 
software practices, and perhaps even return to the position of innovating. At 
some point, we seem to have lost that.

Perhaps Im wandering off the topic of the list. Im happy to continue the 
discussion in email or some other public forum if appropriate.

+ Over the past 20 years, I've seen at least 3 "let's define a standard 
+ set of APIs" efforts arise but quickly fizzle. Everyone is
happy to do it -- so long as their interfaces are the ones that get 
standardized. 

+ If you'd like to discuss this offline, I'm happy to do so.

  73,

Dave, AA6YQ

___
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] Request for WSJT-X Feature

2020-06-29 Thread Stephen VK3SIR

Dave,

Sorry I have to step in here.

> Seriously, I do think Ham Radio software does need to adopt some modern 
> architecture principles. 

ABSOLUTE GARBAGE in my opinion ... that attitude puts Amateur Radio and its 
people back into the stone age  

You move away from standards you get uncontrolled, unmanageable chaos. It is 
one of the basic rules of engineering and social sciences. Whether one likes it 
or not AR is really Amateur Applied Engineering as it crosses not only 
technical but also social boundaries.

You promote and set bad examples (not just technical - also behavioural) and 
bad examples just promulgate into fact.

Let me raise the classic "fact" example that I use all the time that is used to 
diminish AR and its people - The "Off Centre Fed Dipole". How can an dipole by 
scientific definition be fed off centre? Yet this appears time and time and 
time again in ARRL Manuals etc and this one example is OFTEN used at high 
engineering levels to put Amateur Radio and its technical competence down.

[ Ps... it is an Off-Centre-Fed Antenna not dipole ]

I will compliment Joe, Bill and Steve with WSJT-X. They have done an AMAZING 
thing and created AMAZING software under AMAZING engineering principles. As a 
simple their practise for even instantiating the objects that bring the whole 
GUI environ to live has set standards across the whole software engineering 
world. Their latest effort in compartmentalising the whole software structure 
(rather than just monolithic inside the same directory structure) is nothing 
short of pure brilliance and sets examples for the WHOLE engineering world that 
they themselves are following.

Yet.. There are some practises that can and could potentially occur that could 
drift away from good standards ... Also remember that software should work to 
interfaces; software should not DRIVE the interfaces.

This project and the people that communicate here are better than world-class. 
The associated but equally important people here are the people that work on 
Hamlib - and they are equally better than world class.

Sometimes some of us drop ideas and concepts into here (as I did the other day 
with the Software uninstall-before-new-deployment "lobby") in order to keep the 
project here as one of leading edge best example practise. It is known that 
developers do appreciate such comments as it also keeps them thinking about how 
to do things better.

Everything that we do better enhances the opinion of AR in the community - when 
AR is considered by many (including Government and Business) to be dead and 
dying and an old grumpy-man's delusional playground. It is this opinion that 
many of us are FIGHTING hard to break. With the examples set here and with 
Hamlib we go a long way to doing this.

If we want our "passion" (being AR) to survive we need to show the world that 
we are serious; we need to keep what we are doing as "serious". We need not let 
half-truths promulgate as that diminishes us all and our "passion".

Perhaps this is a subject better for a QRZ forum?

Grrr ... but 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] Request for WSJT-X Feature

2020-06-29 Thread Stephen VK3SIR

Terry,

Matters around TCP spotting has been raised a number of times (and I note a 
subsequent response from Robert AD6I).

Terry - as Bill raises - JTAlert is by FAR the most advanced tool that has the 
"potential" ...  yet at the moment lacks "capability". 

[ Laurie VK3AMA also runs his own "spotting" site https://hamspots.net that may 
be worth investigating. ]

I know that Laurie follows posts in here very keenly; it would be worthwhile 
reviewing posts if not adding supportive posts at the JTAlert support forum at 
https://hamapps.groups.io/ . Refer to chatter that may occur in this main 
developer's forum for WSJTX in any post that you make as such is always 
assistive.

WSJT-X should be kept as far as possible to minimal "external" functions with 
third-party apps providing communication and connectivity to other services. 
Perhaps even providing direct comms with PSKREPORTER is outside the scope of 
what it should be servicing (though I state is very reasonable in providing 
this currently)? The aim here with WSJTX is performance with streamlined code 
and core functionality only.

73

Steve I
VK3VM / VK3SIR

-Original Message-
From: Bill Somerville  
Sent: Tuesday, 30 June 2020 11:02 AM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] Request for WSJT-X Feature

On 30/06/2020 01:53, Terry Estes wrote:
> Many other amateur radio stations use the N3FJP Logging Software, 
> primarily for logging ARRL Field Day and Winter Field Day contests.
> The addition of Field Day exchange capabilities to WSJT-X has made the 
> use during FD of FT-8 a major improvement and has increased its use 
> for FD.
> Many stations now utilize Raspberry Pi computers running WSJT-X under 
> various forms of Linux. (Mine is Raspbian Stretch) N3FJP unfortunately 
> only runs on Windows based computers.
> Herein lies the problem - A way to export the WSJT-X log entries
> (packets) to the N3FJP software.
> WSJT-X appears to utilize UDP communications with N1MM Logging Software.
> N3FJP utilizes TCP communications to import the logging packets from 
> other communications packages such as FLDigi. N3FJP acts as a TCP 
> Server on a Windows machine and FLDigi as a TCP Client on a Linux 
> machine, interconnected either by Ethernet cable or by WiFi.
>
> Proposal:  It would make things appear seamless if WSJT-X could also 
> act as a TCP Client, running on the Linux machine, sending the 
> appropriate logging packets to the N3FJP Server on the Windows machine.
> The FLDigi implementation sends the callsign to N3FJP as it is first 
> collected by FLDigi, allowing N3FJP to check for duplication (DUPEs).
> As long as WSJT-X is checking for dupes, it may not be necessary to 
> send the call across prior to completion of the FD exchanges.
> WSJT-X can send the complete contact log information across, in proper 
> order, to N3FJP at the completion of the contact.
> Any and all information about the N3FJP software is provided by its 
> creator/owner to help further the interconnection capability and 
> utilization of his software.
>
> Thanks for your consideration,
>
> Terry Estes, W4ZQ
> w...@arrl.net

Terry,

JTAlert can nearly do this for you. Unfortunately to make setup easier JTAlert 
reads the WSJT-X settings file and also expects the WSJT-X process to be 
running on the same machine. It may be worth asking Laurie, VK3AMA, if there is 
a way for JTAlert to do without those same machine requirements. The bulk of 
JTAlert communications with WSJT-X are via the WSJT-X UDP Message Protocol, 
which will run just fine over a network connection.

73
Bill
G4WJS.

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

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

Re: [wsjt-devel] Windows Package Builds: Force previous versions uninstall before installing new Versions

2020-06-28 Thread Stephen VK3SIR

Bill,


Ø  we don't do that because users often want to install multiple versions, 
particularly with RC releases where we recommend just that.



I will have to correct your “often” to “very occasionally”… although many like 
me at the moment are using 2.2.1 and 2.2.2 in parallel !



Ø  So it's a Windows regression IMHO and should be reported to MS.



I have been there and done this in the past with front-line MS people. 
Microsoft have a cyclic argument on this subject and have always recommended 
that any developer provide uninstallers for previous versions of products OR 
maintain a universal compatibility with the previous version of the installer. 
Microsoft have stated in a number of verbal comms that I have had with people 
that I have trained in there that as “technology leaders” you should be 
demonstrating “best practise” in this area when these matters are discussed 
with them.



Ø  The install script could be updated to make the registry entries install 
location specific but that's a much more complex change.



… yet not that complex (now and with future maintenance) that it is 
unsurmountable for a good number of us here in these forums (myself included); 
guides to perform this on our own are well documented. For developers such as 
yourself bypass switches on builds are also easy to incorporate within the 
cmake configuration scripts.



With difficulty of releasing versions and concerns re redistribution of 
products that do conform to standards (as you clearly point out often) we have 
to come here and ask you folks to incorporate these to-standard changes when 
packages do not conform to as mainstream. You cannot have “your cake and eat it 
too” on this subject (as we say here in VK).



Having WSJTX as it is now, as a recognised (even by MS) world-leading 
technology application, does not provide best practise for the 99.99% of the 
community who use your products.



This is a rather heavy and well informed lobby for this functionality - but one 
that I believe is necessary not only to assist our users but also to provide 
guidance for other developers.



Please reconsider this.



73



Steve I

VK3VM / Vk3SIR




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

[wsjt-devel] Windows Package Builds: Force previous versions uninstall before installing new Versions

2020-06-28 Thread Stephen VK3SIR

Bill,

(From the next release forward) Is it possible to update the “makefile” 
sections used to build a packaged Windows version to force an uninstall of any 
previously installed WSJTX version before continuing the install?

As WSJTX installs into the same location with every packaged install users can 
end up with a long lists of previous versions in Windows “Apps” lists after an 
uninstall (or upgrade) that lead to nothing …

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] Error qt5 compiling new WSJTX 2.2.1 source file

2020-06-08 Thread Stephen VK3SIR

Marco,

What OS, Version and Qt version are you using? Is your OS fully updated? Are 
all required dependencies required to build WSJT-X as described in the WSJT-X 
INSTALL and README files deployed? Are you following the instructions to 
compile WSJT-X as described in the WSJT-X INSTALL file?

I run a Ubuntu 20.04 LTE release here that delivers Qt 5.12.8 packages 
natively; I also run the Windows JTSDK 3.1 with the "Experimental" patches 
(v.0.36). Both are pulling Hamlib from the G4WJS repository. I cannot replicate 
what you are observing.

Based on the fact that this has "abended" very early in the WSJT-X compile 
process I would suggest that the first thing that you should check is the Qt 
deployment ! We may be able to assist further once we know a little more about 
your development environment :-)

73,

Steve I
VK3VM / VK3SIR

-Original Message-
From: Marco Calistri  
Sent: Monday, 8 June 2020 1:22 PM
To: 'WSJT software development' 
Subject: [wsjt-devel] Error qt5 compiling new WSJTX 2.2.1 source file

Hello,

I noticed late tonight that a new WSJT-X release was available, then I 
downloaded and compiled 2.2.1.tgz in the same way I've done so far, but now I 
faced the following error related to a Qt5 deprecated statement:

Scanning dependencies of target wsjtx_udp-static [  0%] Building CXX object 
CMakeFiles/wsjtx_udp-static.dir/UDPExamples/MessageServer.cpp.o
/home/marco/WSJT-X_build/build/wsjtx-2.2.1/wsjtx-prefix/src/wsjtx/UDPExamples/MessageServer.cpp:
In constructor ‘MessageServer::impl::impl(MessageServer*, const QString&, const 
QString&)’:
/home/marco/WSJT-X_build/build/wsjtx-2.2.1/wsjtx-prefix/src/wsjtx/UDPExamples/MessageServer.cpp:42:75:
error: ‘void QAbstractSocket::error(QAbstractSocket::SocketError)’ is
deprecated: Use
QAbstractSocket::errorOccurred(QAbstractSocket::SocketError) instead 
[-Werror=deprecated-declarations]
   42 | connect (this, static_cast
(::error)
  |
 ^
In file included from /usr/include/qt5/QtNetwork/qhostaddress.h:48,
 from /usr/include/qt5/QtNetwork/QHostAddress:1,
 from
/home/marco/WSJT-X_build/build/wsjtx-2.2.1/wsjtx-prefix/src/wsjtx/UDPExamples/MessageServer.hpp:7,
 from
/home/marco/WSJT-X_build/build/wsjtx-2.2.1/wsjtx-prefix/src/wsjtx/UDPExamples/MessageServer.cpp:1:
/usr/include/qt5/QtNetwork/qabstractsocket.h:211:10: note: declared here
  211 | void error(QAbstractSocket::SocketError);
  |  ^
/home/marco/WSJT-X_build/build/wsjtx-2.2.1/wsjtx-prefix/src/wsjtx/UDPExamples/MessageServer.cpp:42:75:
error: ‘void QAbstractSocket::error(QAbstractSocket::SocketError)’ is
deprecated: Use
QAbstractSocket::errorOccurred(QAbstractSocket::SocketError) instead 
[-Werror=deprecated-declarations]
   42 | connect (this, static_cast
(::error)
  |
 ^
In file included from /usr/include/qt5/QtNetwork/qhostaddress.h:48,
 from /usr/include/qt5/QtNetwork/QHostAddress:1,
 from
/home/marco/WSJT-X_build/build/wsjtx-2.2.1/wsjtx-prefix/src/wsjtx/UDPExamples/MessageServer.hpp:7,
 from
/home/marco/WSJT-X_build/build/wsjtx-2.2.1/wsjtx-prefix/src/wsjtx/UDPExamples/MessageServer.cpp:1:
/usr/include/qt5/QtNetwork/qabstractsocket.h:211:10: note: declared here
  211 | void error(QAbstractSocket::SocketError);
  |  ^
cc1plus: all warnings being treated as errors

If someone could suggest me a workaround, I would be very thankful.

-- 

73 de Marco, PY1ZRJ (former IK5BCU)


___
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] WSJT-X and PSKReporter

2020-06-07 Thread Stephen VK3SIR

Hi Folks,

Interesting discussion. Peter’s overview is 100% correct. Philip (PSKReporter’s 
maintainer) states that his resource should only offer a “guide” and I must 
also highlight that.

TCP should be perhaps only used in the exception and only if uploads to 
PSKreporter are observed to not register .

As the circumstance that Phillip has made accommodation for is more for 
anomalies – the exception - possibly this functionality is best and most easily 
implemented within 3’rd party addons such as JTAlert (i.e. disable sending from 
WSJT-X and send from the 3rd party app via TCP)?

Laurie VK3AMA I believe follows this list and his comments on this will also be 
of interest; flag this in the JTAlert forums as I am sure that this is a 
facility that may be easily (and perhaps best) implemented there.

73

Steve I
VK3VM / VK3SIR

From: Peter Sumner 
Sent: Sunday, 7 June 2020 3:43 PM
To: WSJT software development 
Subject: Re: [wsjt-devel] WSJT-X and PSKReporter

Hi Adrian, messages via TCP put a requirement on the local PC to handle errors 
which all add complexity and resources to do it. The messages have to be sent, 
an answer waited for and if no answer, sent again until a time out is received, 
then handle this time out...  UDP on the other hand is a send it and move on to 
the next thing process which requires very little overhead and no error 
handling by the sender.  This is why UDP messaging is so popular as you do not 
have to worry about the outcome of a send and generally works on most networks.

Regards,
Peter, vk5pj

On Sun, Jun 7, 2020 at 3:03 PM Adrian 
mailto:vk4...@gmail.com>> wrote:

This sounds like a great idea. I am surprised it is not already done via tcp.


On 7/6/20 11:23 am, Philip Gladstone wrote:
There are a (small) number of WSJT-X users who have difficulty reporting their 
spots to pskreporter. Some of these are in "difficult" areas of network 
connectivity (e.g. Marine Mobile) and I suspect that the UDP transport is 
losing most of their packets. The general loss rate seems to be around 1%-2% 
which is somewhat higher than I would expect, but it is not unbelievable either.

It is also difficult to diagnose these sort of problems as the packets appear 
to leave the PC running WSJT-X and not arrive at my server!

PSKReporter was never supposed to be 100% reliable, but there seem to be a lot 
of people who think otherwise

In an effort to improve the situation, I have now stood up a TCP listener that 
might help. The protocol is identical -- the only difference is that you send 
the same messages as before over a TCP connection to 
report.pskreporter.info port 4739 rather than 
over a UDP connection. There is no extra framing required as the messages 
already contain a length code.

The listening server should be able to support enough connections. It will 
close a connection if an invalid message is received.

Is this change something that could be implemented? Also, currently, you send a 
bunch of packets at the same time (on the five minute expiry). You could send 
them as soon as they get "full" rather than waiting.

Thanks

Philip

___
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] RC 2.2.0 - Now Working with Yaesu FT-991

2020-06-05 Thread Stephen VK3SIR

Bill,

>  you stated the above, that is indirect evidence that you have distributed a 
> binary version of WSJT-X.

Indirect evidence - h ... Assumptions. Reminds me of Fleishman, Pons and 
their "Cold Fusion" ... 

Fact: The reference to the 891 refers to equipment at an alternate site listed 
on my licence. Fact: GNU GPLv3 has not been violated after conferring with a 
solicitor. Qualified facts here.

Binary distros of your code are flying everywhere; people are DESPERATE to 
overcome this debacle with changes forced onto Hamlib by the premature 2.2.0 
release. 

Faulty releases are still being distributed without warning hence unanswered 
posts on the Dev forum.
 
Back to the opening comment - you assumed - wrongly - and pursued with 
green-eyed venom. You targeted someone (as is not uncommon in this place) - me 
in this case - and wrongly. The behaviours demonstrated are so mixed around 
here ! As recent examples, some get lauded for posting "false decodes" - yet I 
got derided the other day. 

Variable and selective behaviours ... This is what is killing AR. People here 
as leaders should be consistent, respectful and hence setting way better 
examples.

Comments to Mike Black - one of AR's real geniuses - are also observed by many 
to be substandard 

Stop it ! Behave ! Think about how you are interacting with the community here 
! It is not about ego - it is about growth and future !

You cannot have your cake and eat it too - a Famous Aussie expression.

Grow up gentlemen. Play nicely with the kiddies. Teach, develop and nurture the 
kiddies. Otherwise the playground will get ripped apart !

Don't respond further to this in public as it only divides AR down further. I 
have only responded here as quite a number of emails have come in from many too 
"scared" to express concerns.

Steve I
VK3VM / VK3SIR


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

Re: [wsjt-devel] RC 2.2.0 - Now Working with Yaesu FT-991

2020-06-04 Thread Stephen VK3SIR

Bill,


  *   please do not redistribute WSJT-X, that is in breach of our copyright.

Now where on Earth did you get that idea from and where has this come from 
???

Can you please provide a link to code that I have distributed?

Here again is my post:


  *   Hi Folks,


  *   The FT-991 now works with WSJTX 2.2.0 with Mike and Nate’s latest patches.
  *   I have not fully tested split modes etc. yet though !



  *   I have also a background report, based off my compile, that FT-891 now 
works.
  *   Some will not directly post here.


Ahh now I see: “Based off My Compile”... So where have I openly distributed 
compiled code? A long bow has been drawn here.

Some time back I asked simple one-line question on development environments and 
got “spanked” back. These “spanks” have evolved into adapting The JTSDK 3.1 to 
work under current conditions - as it requires maintenance now under terms that 
preserve Greg Beam KI7MT’s IP as Greg is unable to contribute at the moment.

I concentrate on the HAM – Help All Mankind – ideals of teaching others how to 
use and manipulate the JTSDK and also to learn from your code (and generally to 
program for AR in Qt).

There is no open distribution of what I do as that is POINTLESS  Nobody 
learns form this ! You know this !

This statement in this context was uncalled for and is exceptionally unhelpful 
for the advancement of Amateur Radio. People contributing here are at the 
forefront of AR. People chatter by a magnitude of 10 behind the scenes as they 
see others being “spanked” in the open and fear being “spanked” themselves.

Wouldn’t leadership encouraging safety-in-contribution be better rather than 
spanking those genuinely trying to assist and advance AR?



  *   Perhaps current packaged releases should be pulled down temporarily from 
the
  *   Princeton site? [ OR at least an advisory posted that Yaesu and some 
Kenwood
  *   hardware users may experience issues … but new versions will be posted 
when

libraries stabilise ? ]

This is a fair and reasonable request. The confusion and grief created is 
considerable.

Please pull the distros down until HAMLIB is fully stabilised.

Stephen Ireland
VK3VM / VK3SIR

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

[wsjt-devel] RC 2.2.0 - Now Working with Yaesu FT-991

2020-06-03 Thread Stephen VK3SIR

Hi Folks,

The FT-991 now works with WSJTX 2.2.0 with Mike and Nate's latest patches. I 
have not fully tested split modes etc. yet though !

I have also a background report, based off my compile, that FT-891 now works. 
Some will not directly post here.

Perhaps current packaged releases should be pulled down temporarily from the 
Princeton site? [ OR at least an advisory posted that Yaesu and some Kenwood 
hardware users may experience issues ... but new versions will be posted when 
libraries stabilise ? ]

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] Corrupted WSJT-X.ini file

2020-05-29 Thread Stephen VK3SIR

Joe,

The advice that you have issued is against what any academic or trade educator 
would EVER recommend as sound practise to our trainees / clients / researchers 
etc. 

One always starts with a clean slate and then introduces changes - especially 
when testing and evaluating. That is "Scientific Method".

Yes in the case of WSJTX your advice is noted; advisories in release notes as 
to whether configuration files may need to be altered may be appreciated in the 
future by many :-)

As I said in my post "It’s a reminder  " .  Let's leave the discussion at 
this on that subject as no good for The HAM community can come from it !

Keep up the great work with the software. 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] WSJT-X 2.2.0-rc3

2020-05-29 Thread Stephen VK3SIR

Bill,

Thanks for the comments ... still working here on a Ubuntu 20.04 release

> Note that the LTS releases of Qt have little bearing on Qt open source users 
> since for them support always ends at the date of the next release. 

All Noted and :-)

BUT we are aware of some grief across toolkit versions; You have identified an 
issue with code portability with the 5.14.x stream and MacOS; Qt 5.13 has 
general issues with what we do with Windows... and despite what many say Qt 
Version 5.5 and 5.9 of the past set different sound-card levels on many 
machines (and I have proved this multiple times in the past) !

Therefore perhaps the best strategy is only to release to the latest and best 
LTE releases that obviously commercial users have had extensive feedback into?

It makes life s much easier for us all to standardise to the same toolsets. 
Many times the problems are NOT our software - but it's the toolkits themselves 
! 

Yet likewise we cannot remain static and held to one toolset as technology and 
library efficiencies often do improve (i.e. Hamlib !!!). The Linux kernel 
integration into the Windows 20.1 (and I am looking into that now) is going to 
have massive benefits for our projects and their portability !

That's my thoughts anyway. 

73 and back here to multiple projects while I cannot sleep !

Steve I
VK3VM / VK3SIR



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

Re: [wsjt-devel] Corrupted WSJT-X.ini file

2020-05-29 Thread Stephen VK3SIR

David,

It’s a good reminder for us all... New software versions (and especially 
JT-software) should start with a fresh, clean wsjtx.ini file. Yes we get used 
to our screen settings etc... but once the new "default" wsjtx.ini file is in 
place we can cut and paste across identical settings as long as they are in 
similar formats.

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] WSJT-X 2.2.0-rc3

2020-05-29 Thread Stephen VK3SIR

Joe, Bill and Steve,

A great job with rc3 ! It compiles almost without message under the Windows 3.1 
x64 JTSDK. I have yet to test it with the Ubuntu 20.04 LTE release yet.

Also I note the comments regarding releasing code under Qt 5.12.8  - required 
due to Mac-deployment issues. Qt 5.12.8 is the most "mature" version of the 
Long Term Supported Qt SDK's; in addition many distros such as Ubuntu (in their 
just released 20.04 LTE stream) release packages "native" for Qt 5.12.8 are 
supplied.

Therefore perhaps Qt 5.12.8 (or its successor in the 5.12 line) as standard 
should be used for current releases?

As information for many here, the Qt 5.15. stream has just been released. From 
a Windows perspective the main change for us that I can see at this point is to 
the deployed MingW environ with it being upgraded from Version 7.30 to 8.10.  I 
am yet to fully test these changes (that will flow into Qt v6 which has also 
just been announced) along with integration with the MSYS2-environment-build 
Hamlib (though I can foresee few issues).

Again well done team. I am testing on-air (40m) now.

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] WSJT-X 2.2.0 rc2

2020-05-26 Thread Stephen VK3SIR

Joe,

Thanks for the clarification on the supply of "false decode" recordings. There 
are multiple posts that many of us see and have requesting such files, so 
further direction has been appreciated I am sure by us all.

Firstly, I assume that no mitigation strategies for false decodes are planned 
at this point?

Personally I am one that uses and needs maximum performance; yes I have been 
lobbying for mitigation strategies for "the obvious" that would be 
exceptionally helpful for the entire community that use the "JT-modes" 
primarily for working DX. I believe that my application of the "JT-modes" is 
not in the "small minority" classification 

Secondly and perhaps more importantly I like many have received the QT 5.15 LTE 
release announcement. Each release of Qt presents its own challenges as we all 
know - and the announcement that Qt 6 is on its way is fascinating ! 

Can you foresee that this LTE release will impact upon the codebase in any 
shape or fashion - although I know that this ask is a little early?

Patches for The Windows JTSDK 3.1 "experiment" to support Qt 5.15(.x) will come 
soon; work is progressing on customisations to make scripts less hard-version 
dependent.

Lastly and also pointed at the general community, there are a number of 
glitches in CMAKE that make life somewhat challenging ! Greg KI7MT deploys 
CMAKE Version 3.14.4 - where all appears to work - yet it has migrated to  v 
3.17.2. A number of us are working on trying to understand why attempts moving 
here have been unsuccessful. Most attempts when CMAKE 3.17.2 is offered what it 
appears to want results in failure elsewhere - you solve one issue and then you 
can also upset fftw 

Can you or anyone else in the community offer some guidance? 

Thanks, and keep up the great work !

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] WSJT-X 2.2.0 rc2

2020-05-26 Thread Stephen VK3SIR

HiFolks,

There seems to be some strong evidence mounting regarding non-standard suffix 
usage – in particular /R …

Remember that we should be using Save/Save Decoded so that these can be emailed 
on request to The Core Development Team when discovered !

73

Steve I
VK3VM/VK3SIR


From: Allan VK4QG 
Sent: Tuesday, 26 May 2020 4:05 PM
To: wsjt-devel@lists.sourceforge.net
Subject: [wsjt-devel] WSJT-X 2.2.0 rc2

Gentlemen,

To start with, my system is a Dell 1650, i7 @3.40 GHz, 16GB RAM, W10 pro 64bit. 
I do not use CAT but instead use RTS on COM1 for opto-isolated PTT and XFR 
isolation for audio in and out of the sound-card, and have done so without 
issue since 2006.

Two problems : -

1. I have found with rc2 that occasionally PTT is not working at all and 
when it does there is often no TX audio present either. While monitoring 
'Radio' under 'Settings' I have noticed when this occurs, after a successful 
transmission about two seconds into the RX period the 'Test PTT' button turns 
red and from that point there is no PTT in the following TX period. After a 
time it appears to clear itself and PTT in the following period with or without 
TX audio.

2. I am still getting numerous false decodes. Most of these contain '/R' 
and '<.>'.   I am not using AP.

Many thanks,

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

Re: [wsjt-devel] WSJT-X 2.2.0-rc2 False Decode

2020-05-25 Thread Stephen VK3SIR

Bill and Joe,

As a summary for readers I have identified that MANY false decodes being 
observed were observed ESPECIALLY using the “flipping” of the bits that results 
in a /R. Subsequently there has also been a bit of chatter re field days etc. 
and the use of non-standard suffixes even in the few hours that I have been 
sleeping.

The intent of prefixes and suffixes is to satisfy overseas “reciprocal” and 
“local” short-term operating rights primarily i.e VK1/K1JT (operating 
short-term in Australian Capital Territory) … though it is more difficult with 
some region specifiers now dropped internationally. Likewise there are 
“standard aceepted” suffixes recommended internationally to indicate operation 
away from nominated base that many regulators accept and require: with the main 
suffixes being /mobile, /portable, /aeronautical mobile and /maritime mobile 
(accepted as /m, /p, /am and /mm in the CW/Digital world).

There are explosions of bastardisations of agreed callsign structures, callsign 
templates and “special calls” that create problems and issues generally (i.e. 
The VK F-call template).

Additional suffixes such as /R that are RARELY used are NON STANDARD; in fact 
such suffixes may not be acceptable to regulators here in VK and in EU.

AP Mode is a necessary fact of life for those of us in far-away places; 
many-many discussions on these forums refer to RR/73 loops. AP modes are a 
necessity to complete many transactions.

It is more than highly annoying when you are following all recommended 
operational parameters - watch the automation pick out a false decode – and 
then to have to spring into action which does not necessarily look good to 
other operators observing your QSOs….. Unnecessary noise, chatter resultant QRM 
etc.

In response to this issue and the recognition that the /R switch is being 
observed with MANY MANY false decodes, would it not be in order to apply 
mitigation strategies? I am seeing quite a number of posts re false decodes or 
potential bug reports before they head here as some have fear of how they will 
be received. I say to all POST as they need to know ! “The good, the bad and 
the ugly” must be reported !

I foresee that the “mitigation strategy” that would best suit the vast numbers 
of us that rely on AP modes to complete transactions – that would also fit 
logic and processing and performance requirements - would be to employ a hash 
table of acceptable “standard” suffixes . This hash table should loaded from 
the wsjtx.ini at load time and decodes checked against this. If it is not in 
the table its rejected by QSO-processing logic as being valid and therefore  is 
not subject to the automated handling.

For those that do use non-standard suffixes an option, not checked as default, 
may be in order to allow “non-standard suffixes” through the automated 
procedure.

I’ll keep sending these false decodes through when observed as we know (and 
both of you have said to others in private messages) that false decodes of any 
form that can be reproduced are extremely valuable.

73, and keep up the amazing work !

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

Re: [wsjt-devel] WSJT-X 2.2.0-rc2 False Decode

2020-05-25 Thread Stephen VK3SIR

Bill,

You are completely preaching to the informed here with knowledge of what, how, 
why and even some of the maths involved ☺ But thanks again.

The issue is that the software picks one of these out and then you respond, 
then abort or manually over-ride to the Tx6.

There is a clear pattern that both myself and others in backchannel comms are 
observing with the /R suffix and how that seems to be almost universally thrown 
up in the process. I cannot explain that as this “consistency” makes no sense !

Hey if we don’t report the good, the bad and the unpredictable back how can we 
get better software?

[ Back to working on some of the Mac-compile issues. For the record on that I 
am observing unpredictable behaviours through an old Mac with Ubuntu 20.04 LTE 
on it as well ! ]

73 (and I note subsequent comms but are unseen !).

Steve I
VK3VM / VK3SIR

From: Bill Somerville 
Sent: Monday, 25 May 2020 10:09 PM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] WSJT-X 2.2.0-rc2 False Decode

Steve,

please don't equate AP assisted decodes with low levels (I prefer the term weak 
signals). AP decoding techniques, like the other FEC mechanisms, allow missing 
information to be recovered. Weak signals are not the only cause of missing 
information, truncated or otherwise interrupted signals are just as likely to 
require FEC, and AP if enabled, to successfully decode them. As I said, it is 
virtually impossible to eliminate this sort of false decode without 
compromising the purpose of AP decoding, unless information not received on air 
is used to make the decisions. That's the operator's job and not something that 
we feel WSJT-X should be attempting.

Yes, examples of false decodes, along with supporting .WAV files, and settings 
necessary to reproduce them, are welcome but unless there is common cause that 
can be detected by the application, like unrealistically low SNR values 
combined with marginal sync detection and maximum FEC required, there's little 
that can be done.

73
Bill
G4WJS.

On 25/05/2020 12:54, Stephen VK3SIR wrote:

Bill,



Fully aware of that :-) Yet you have asked for reports when these occur. I am 
in a far-away land to many where low-level, low confidence signals are the norm 
and not the exception. Around 40% of the 40 contacts made today with the new 
version have been > -18dB. Without the reduced confidence in-use I'd be in 
constant RR/73 loops !



In in the last few minutes I have another  again with a /R ! You want this 
one was well?



114715 -18  0.3  825 ~  VK3VM PA6UES/R R BM44   ? a2



I'll send that one as well as its now 2 in 60-odd minutes of operation.



73



Steve I

VK3VM / VK3SIR



-Original Message-

From: Bill Somerville <mailto:g4...@classdesign.com>

Sent: Monday, 25 May 2020 9:43 PM

To: wsjt-devel@lists.sourceforge.net<mailto:wsjt-devel@lists.sourceforge.net>

Subject: Re: [wsjt-devel] WSJT-X 2.2.0-rc2 False Decode



On 25/05/2020 12:04, Stephen VK3SIR wrote:

Folks,



I just picked  up a false decode that can be replicated when played back 
through WSJT-X 2.2.0 rc2:



104945 -23 -0.5 1623 ~  VK3VM FH9ZZV/R ND49 ? a2



Research suggests this is not a genuine call and is definitely a false decode 
(i.e. ND49 = middle of Southern Ocean). I have noted that many false decodes in 
the previous version are reported with /R !



As one cannot send attachments via email I'll reforward this email plus the 
.wav file directly to Bill and Joe for further analysis.



73



Steve I

VK3VM / VK3SIR

Steve,



AP decodes flagged as low confidence ('?' marker) should always be considered 
dubious, and unless there is other evidence that the decode is genuine it 
should be ignored. Without using knowledge not obtained on air it is virtually 
impossible for the decoder to eliminate such false decodes without damaging the 
capabilities of the AP decoding mechanism.

AP decodes of the 'a2' category are only detected shortly after a CQ call IIRC.



The FT8, FT4, and MSK144 decoders give virtually every possible message equal 
weight. The message types that allow a '/P' or '/R' (grid rover

station) prefix to a standard callsign have a 50% probability per possible 
callsign that random data will unpack as one of those prefixes, so they will be 
far more common in false decodes than in genuine messages where the expected 
likelihood is far lower.



73

Bill

G4WJS.




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

Re: [wsjt-devel] WSJT-X 2.2.0-rc2 False Decode

2020-05-25 Thread Stephen VK3SIR

Bill,

Fully aware of that :-) Yet you have asked for reports when these occur. I am 
in a far-away land to many where low-level, low confidence signals are the norm 
and not the exception. Around 40% of the 40 contacts made today with the new 
version have been > -18dB. Without the reduced confidence in-use I'd be in 
constant RR/73 loops !

In in the last few minutes I have another  again with a /R ! You want this 
one was well?

114715 -18  0.3  825 ~  VK3VM PA6UES/R R BM44   ? a2  

I'll send that one as well as its now 2 in 60-odd minutes of operation.

73

Steve I
VK3VM / VK3SIR

-Original Message-
From: Bill Somerville  
Sent: Monday, 25 May 2020 9:43 PM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] WSJT-X 2.2.0-rc2 False Decode

On 25/05/2020 12:04, Stephen VK3SIR wrote:
> Folks,
>
> I just picked  up a false decode that can be replicated when played back 
> through WSJT-X 2.2.0 rc2:
>
> 104945 -23 -0.5 1623 ~  VK3VM FH9ZZV/R ND49 ? a2
>
> Research suggests this is not a genuine call and is definitely a false decode 
> (i.e. ND49 = middle of Southern Ocean). I have noted that many false decodes 
> in the previous version are reported with /R !
>
> As one cannot send attachments via email I'll reforward this email plus the 
> .wav file directly to Bill and Joe for further analysis.
>
> 73
>
> Steve I
> VK3VM / VK3SIR

Steve,

AP decodes flagged as low confidence ('?' marker) should always be considered 
dubious, and unless there is other evidence that the decode is genuine it 
should be ignored. Without using knowledge not obtained on air it is virtually 
impossible for the decoder to eliminate such false decodes without damaging the 
capabilities of the AP decoding mechanism. 
AP decodes of the 'a2' category are only detected shortly after a CQ call IIRC.

The FT8, FT4, and MSK144 decoders give virtually every possible message equal 
weight. The message types that allow a '/P' or '/R' (grid rover
station) prefix to a standard callsign have a 50% probability per possible 
callsign that random data will unpack as one of those prefixes, so they will be 
far more common in false decodes than in genuine messages where the expected 
likelihood is far lower.

73
Bill
G4WJS.

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

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

[wsjt-devel] WSJT-X 2.2.0-rc2 False Decode

2020-05-25 Thread Stephen VK3SIR

Folks,

I just picked  up a false decode that can be replicated when played back 
through WSJT-X 2.2.0 rc2:

104945 -23 -0.5 1623 ~  VK3VM FH9ZZV/R ND49 ? a2

Research suggests this is not a genuine call and is definitely a false decode 
(i.e. ND49 = middle of Southern Ocean). I have noted that many false decodes in 
the previous version are reported with /R !

As one cannot send attachments via email I'll reforward this email plus the 
.wav file directly to Bill and Joe for further analysis.

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] WSJT-X v2.2.0-rc2 Compiles beautifully under JTSDK 3.1 with the 0.35b Patches

2020-05-24 Thread Stephen VK3SIR

Folks, 

Around 8 intermittent QSO's on 17m FT8 so far (with the odd set of QSO's that 
follow on). No issues observed with Windows-10-built FT8 operation so far !

My operational environ is Windows 10 Pro Windows 1909 X64 (no virtualisation - 
fully updated) on an early 2012 Mac Mini i5 running with WSJT-X 2.2.0 rc2 into 
JTAlert 2.16.6 logged via DXKeeper 15.4.9. the transceiver is a Yaesu FT-991 
(not A version).

[ Just a minor comment: having a program timeout set 10th June sets tight 
deadlines for subsequent releases for developers :-( ]

73

Steve I
VK3VM / VK3SIR


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

[wsjt-devel] WSJT-X v2.2.0-rc2 Compiles beautifully under JTSDK 3.1 with the 0.35b Patches

2020-05-24 Thread Stephen VK3SIR

Core Development Team,

Very well done. The wsjt-x source compiles beautifully with the JTSDK 3.1 x64 
bit (with 0.35b patches applied to make it work).Some of our community have 
noted issues getting access to the "jt...@groups.io" site so email me if you 
need these.

Only one "warning" noted in the massive compile at nhash.c (in function nhash_ 
- "variable" k8 set but not used - but a pointer so unless nulled it is not 
easy to use !!).

It is also fantastic to see the development of "translations".

For reference (and the reference of others that compile their own source):

- Qt has had latest updates applied (including QtCreator and optional OpenSSL 
components that it can deliver. Thanks Bill for the lead !)

- Qt provided some updates to the mingw environ; The MSYS2 environ (for hamlib) 
has been fully pacman -Syuu updated.

- I have used build-hamlib.sh in a msys2 shell aligned to the master repo to 
develop needed hamlib libraries.

- My build of "rc2" was conducted using jtbuild package .

Now for on-air testing. I'll be on 17m and then 20m until it goes quiet in 
those parts. Propagation is not good on 17m at the moment !

73 and well done !

Steve I
VK3VM / VK3SIR




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

Re: [wsjt-devel] exporting from adi

2020-05-22 Thread Stephen VK3SIR

Correction here: 

> I personally use DXKeeper as the central logging tool and use its "Export 
> QSO's" function to "Export standard ADIF" 
> back to the "wsjtx.log" file (found in the location accessible by "File/Open 
> Log Directory").  DXKeeper has great tools 
> for managing duplicates. When all duplicates are removed periodically write 
> them back to  WSJT-X over-writing 
> previous "wsjtx.log" instances :-)

Needs be:

I personally use DXKeeper as the central logging tool and use its "Export 
QSO's" function to "Export standard ADIF" 
back to the "wsjtx_log.adi" file (found in the location accessible by 
"File/Open Log Directory").  DXKeeper has great tools 
for managing duplicates. When all duplicates are removed periodically write 
them back to  WSJT-X over-writing 
previous "wsjtx_log.adi" instances :-)

Original message corrected:

From: Stephen VK3SIR  
Sent: Saturday, 23 May 2020 6:34 AM
To: WSJT software development 
Subject: Re: [wsjt-devel] exporting from adi

Hi Michelle,

By far the best way to avoid duplicates in logs is to not set 
"Settings\Reporting\ Log automatically..." . If you come back with a RR73, auto 
log, and then a station comes back with a R-XX (what I term a "RR/73 Loop") 
then both communication and logging can lead to duplicates in logs.

Each logged entry should be manually approved (so do not check "Log 
automatically").

Some software loggers and bridges such as JTAlert (that I use and recommend 
heavily) also are not perfect. I use JTALert with DXLab's DXKeeper. No matter 
what I do sometimes (and erratically) a duplicate is logged to eQSL. These are 
issues for their support forums. Despite this forewarning  would strongly echo 
Jim's post and recommend JTAlert's use to you !

JTAlert can be found at  https://hamapps.com. DXLab can be found at 
https://dxlabsuite.com . None of these products are viruses if your AV scanner 
goes into overdrive and its safe to add these programs (and their destinations) 
as AV over-rides.

I personally use DXKeeper as the central logging tool and use its "Export 
QSO's" function to "Export standard ADIF" back to the "wsjtx_log.adi" file 
(found in the location accessible by "File/Open Log Directory"). DXKeeper has 
great tools for managing duplicates. When all duplicates are removed 
periodically write them back to WSJT-X over-writing previous "wsjtx_log.adi" 
instances :-)

More info on how to do this and set up products can be found on each product's 
support forums :-)

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] exporting from adi

2020-05-22 Thread Stephen VK3SIR

Hi Michelle,

By far the best way to avoid duplicates in logs is to not set 
"Settings\Reporting\ Log automatically..." . If you come back with a RR73, auto 
log, and then a station comes back with a R-XX (what I term a "RR/73 Loop") 
then both communication and logging can lead to duplicates in logs.

Each logged entry should be manually approved (so do not check "Log 
automatically").

Some software loggers and bridges such as JTAlert (that I use and recommend 
heavily) also are not perfect. I use JTALert with DXLab's DXKeeper. No matter 
what I do sometimes (and erratically) a duplicate is logged to eQSL. These are 
issues for their support forums. Despite this forewarning  would strongly echo 
Jim's post and recommend JTAlert's use to you !

JTAlert can be found at  https://hamapps.com. DXLab can be found at 
https://dxlabsuite.com . None of these products are viruses if your AV scanner 
goes into overdrive and its safe to add these programs (and their destinations) 
as AV over-rides.

I personally use DXKeeper as the central logging tool and use its "Export 
QSO's" function to "Export standard ADIF" back to the "wsjtx.log" file (found 
in the location accessible by "File/Open Log Directory"). DXKeeper has great 
tools for managing duplicates. When all duplicates are removed periodically 
write them back to WSJT-X over-writing previous "wsjtx.log" instances :-)

More info on how to do this and set up products can be found on each product's 
support forums :-)

73

Steve I
VK3VM / VK3SIR

-Original Message-
From: Jim Preston  
Sent: Saturday, 23 May 2020 1:15 AM
To: DX Jami via wsjt-devel 
Subject: Re: [wsjt-devel] exporting from adi

Danny,

Why not just have JTAlert (if you use it) or WSJT-X log directly to Log4OM? 
Then you wouldn't have to go through the adif import routine.

73,

Jim N6VH

On 5/20/2020 6:45 PM, DX Jami via wsjt-devel wrote:
> Michelle,
> 
> My logging program is Log4OM ver2.  I routinely import my WSJT-x adi 
> files into Log4OM with no problems.  Most logging programs import only 
> current loggings.  Ensure you click something like “do not import 
> duplicates” in your logging program as you download and you should 
> have no problems.
> 
> Good luck.
> 
>   Danny
> 
>   AH6FX/W4 - Virginia
> 
> Sent from Mail  for 
> Windows 10
> 
> *From: *Michelle Sack via wsjt-devel
> 
> *Sent: *Wednesday, May 20, 2020 9:21 PM
> *To: *WSJT software development 
> 
> *Cc: *Michelle Sack 
> *Subject: *Re: [wsjt-devel] exporting from adi
> 
> I'm new to FT8 and WSJT software. Is a way to export from the log only 
> the recent contacts? This way I don't make duplicates in my logging 
> programs but still keep contacts in the WSJT log for notifications of 
> new (preventing duplicate contacts in FT8).
> 
> Thanks
> 
> Michelle N3YRZ
> 
> 
> 
> ___
> 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] Clicking on RR73 produced wrong TX response msg

2020-05-20 Thread Stephen VK3SIR

Ed,

There is a strange anomaly that makes no sense yet many of us that (especially) 
work weak DX observe frequently ... Sometimes when you end up in a R -XX/RR73 
loop ("RR/73 loop" or "ACK dance" as you term it) with a station anecdotally 
and observationally sometimes sending 73 sequences back manually appears to 
break the loop-cycle. 

Why ? it makes no sense when logic is analysed or informed thought is applied 
to the observation.

Note that it is not restricted to Weak DX - but is more often observed when 
both ends have desperation to complete the QSO.

Yet from my direct observation, experimentation and simulation conducted a 
couple of back (when on "down time" with research that I was on - and using 
earlier on earlier FT8 releases and the "main fork") it is able to be 
replicated - yet inconsistently. 

There are "theories" that if the data stream is changed slightly then QRM/QRN 
effects that interact with signals passed over the decoder can change and 
therefore decoding impasses can be broken ...

More likely the observation is just a statistical/probability anomaly. Yet some 
Amateurs SWEAR by this method to break impasses; I also admit that I have often 
found it to be observationally useful operationally to break a RR/73 loop !

A "revert and hold" over-ride over Tx4 sequencing when Tx5 is selected may be 
useful. Yet without mathematical or statistical justification for it - just 
observation and anecdote - it will be hard to convince the core developers of 
mitigation strategies that can and will consume valuable signal processing 
resources.

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] 2.2.0 rc1 - Allow Tx Frequency Changes While Transmitting

2020-05-20 Thread Stephen VK3SIR

Ps: The JPEG's supplied show changes in Tx frequency when the "Tx spinner-box" 
widget has its "up" control selected while transmitting !

-Original Message-
From: Stephen VK3SIR  
Sent: Thursday, 21 May 2020 7:24 AM
To: WSJT software development 
Subject: Re: [wsjt-devel] 2.2.0 rc1 - Allow Tx Frequency Changes While 
Transmitting

Joe and the Core Development Team,

Test environ: The Main FT-991 connected to a 80m Doublet (v2.2 rc1); Second 
environ is a FT-897D with SCU-17 into a dummy load (v2.1.2). Test band is 20m.

I can confirm as that on FT8 transmissions that frequency changes on Tx are 
blocked. 

But... 

Yet the Tx function may not be blocked on all modes and universally. 

- The spinner control does permit frequency changes while Tune is selected 
(minor). See attached Tune.jpg
- Of considerable concern is that frequency changes are permitted on JT65. See 
attached JT65.jpg.

No further modes are tested due to time constraints.

As suggested, perhaps the and simplest way to implement a common fix across all 
modes for the future enhancement may be to disable input to the control during 
any Tx cycles?

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] 2.2.0 rc1 - Allow Tx Frequency Changes While Transmitting

2020-05-20 Thread Stephen VK3SIR

Joe and the Core Development Team,

Test environ: The Main FT-991 connected to a 80m Doublet (v2.2 rc1); Second 
environ is a FT-897D with SCU-17 into a dummy load (v2.1.2). Test band is 20m.

I can confirm as that on FT8 transmissions that frequency changes on Tx are 
blocked. 

But... 

Yet the Tx function may not be blocked on all modes and universally. 

- The spinner control does permit frequency changes while Tune is selected 
(minor). See attached Tune.jpg
- Of considerable concern is that frequency changes are permitted on JT65. See 
attached JT65.jpg.

No further modes are tested due to time constraints.

As suggested, perhaps the and simplest way to implement a common fix across all 
modes for the future enhancement may be to disable input to the control during 
any Tx cycles?

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] 2.2.0 rc1 - Allow Tx Frequency Changes While Transmitting

2020-05-19 Thread Stephen VK3SIR

Joe,

Thanks for the clarification. Also thanks for the notification for us all in 
posts to others that rc2 is imminent.

Thanks also for the reminder to everyone participating that we should head to 
the documentation before posting. I was aware of the documentation having been 
there first before posting (as all should do).

There is a subsequent possible observation and hence question that is thrown 
up; I'll try to put this as simply as possible as you have considerably more 
important tasks to perform:

Behaviours that I have observed do not necessarily relate solely to CAT-code 
sending - more the "offset" of the transmitted audio stream and its frequency 
to the transceiver.

Are changes to the frequency of any audio stream than can be adjusted through 
the "Audio Tx Widget" also blocked during a Tx cycle?

[ If not, perhaps then they should be? I could foresee the simplest way to 
overcome this could be disabling the "Audio Tx Widget" for input during a Tx 
and while "Allow Tx Frequency Changes..." is not checked ]

Thanks Joe to you and the core development team; GREAT work. RC candidate 
software release time can be soul destroying but is highly necessary ...

73 

Steve I
VK3VM / VK3SIR


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

[wsjt-devel] 2.2.0 rc1 - Allow Tx Frequency Changes While Transmitting

2020-05-18 Thread Stephen VK3SIR

Hi Folks,

Does the "Allow Tx Frequency Changes While Transmitting" (File/Settings/General 
Tab) when not-checked function as intended?

My expectation would be that if disabled that any frequency changes observed in 
the Tx spin-box widget on the Main Window should be delayed until the end of 
the cycle and should not be immediate (or perhaps these boxes disabled until 
the end of the cycle) under this circumstance.

I just performed a slight frequency change on 20m while transmitting and noted 
that in the "Rx Frequency Window" that a frequency change during the Tx cycle 
from 851 to 899 to 900 Hz was noted.

035400  Tx   851 ~  CQ VK3VM QF11
035405  Tx   851 ~  CQ VK3VM QF11
035408  Tx   851 ~  CQ VK3VM QF11
035410  Tx   899 ~  CQ VK3VM QF11
035430  Tx   900 ~  CQ VK3VM QF11
035500  Tx   900 ~  CQ VK3VM QF11

I have also observed some frequency shifts on waterfalls that may or may not be 
related to this. 

I cannot recall any inquiry on this so far and if I have missed it my apologies.

73

Steve I
VK3VM / VK3SIR


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

[wsjt-devel] Suggestion re OpenSSL

2020-05-17 Thread Stephen VK3SIR

Hi Gents,

As a suggestion is it possible to direct the installer scripts on a Windows 
build to auto-deploy the Appropriate Win32 or Win64 OpenSSL Lite package?

Should the SDK's and package requirements be looked at with regards to 
providing access to these libraries available for the future?

I can only foresee utility for this package set increasing in the future.

Thanks and 73.

Steve I
VK3VM / VK3SIR

-Original Message-
From: Ari Paananen  
Sent: Monday, 18 May 2020 5:36 AM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] WSJT-X 2.2.0-rc1 - Waterfall Palette

Hi Jim,

I've noticed the same thing and it happens when the focus is in the WSJT-X 
waterfall window and you press enter twice while thinking the focus is in some 
other window.

73 de Ari OH2ECG

On 17.5.2020 22:14, Jim Brown wrote:
> I use the ZL1FZ palette. Running FT8, the setting occasionally changes 
> to User Defined with no "trigger" that I've been able to identify as 
> the cause. I know it's happened because the traces change to white 
> from the multi-color ZL1FZ palette. This has happened several times in 
> the 6 days I've been running the beta.
> 
> 73, Jim K9YC
> 
> 
> ___
> 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

75 matches

Mail list logo