Re: [wsjt-devel] WSJT-X 2.6.0 Error in Network Address

[Paul Bramscher via wsjt-devel]

I found this same pop-up message on 2.6.1 as well as 2.6.0 -- but never 
on previous versions.


However, I found the issue.  Namely, under Reporting -> UDP Server mine 
read "localhost" instead of an actual/numeric IP (like 127.0.0.1).


This warning pop-up appears whether or not you actually activate the UDP 
server.  So I set it to 127.0.0.1, even though I keep it toggled off, 
and the pop-up indicating an error in network address goes away.


73, KD0KZE / Paul

On 1/10/23 20:33, Paul Bramscher via wsjt-devel wrote:
A couple days ago I compiled WSJT-X 2.6.0 on Debian Linux 11 without 
issue, as per Bill's suggestions from a few years ago.  I've made 
several FT8 QSO's, no issues noted.


But I just stumbled on a weird bug:

When I click File:Settings and then cancel without making any changes 
there's a pop-up window.  It's entitled simply "WSJT-X" and contains the 
following text:



Error in Network Address
Error before first number


In case it matters:
* I've not previously run any of the RC versions on that PC.
* I've not made any config changes with 2.6.0 and clicked "save" yet.

So my config is a carry-over from 2.5.4.  Possibly an uninitialized 
variable?


73, KD0KZE / Paul


___
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] Hashed callsign collisions?

[Paul Kube via wsjt-devel]

I would not be surprised if only the main call is used to compute the hash.
Then this admittedly rare and apparently unforseen case, the same main call
being used by multiple different stations at the same time,
distinguished only by their slash "decoration", arises. Result: collisions
among W1AW slash whatever calls.

73, Paul K6PO

On Fri, Jan 20, 2023 at 1:46 PM George J Molnar via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> I had the same thing happen - as if the hash is the same for both /0 and
> /7, so they both respond.
>
>
>
> *George J Molnar, KF2T*
> FM19ma - Maryland, USA
>
>
>
>
>
>
>
> On Jan 20, 2023, at 3:56 PM, Jon Anhold via wsjt-devel <
> wsjt-devel@lists.sourceforge.net> wrote:
>
> I was just on 20m trying to work W1AW/7, and W1AW/0 answered me, twice -
> is this a known issue with longer/hashed callsigns?
>
> 
>
> 73 de KM8V Jon
> ___
> 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] WSJT-X 2.6.0 Error in Network Address

[Paul Bramscher via wsjt-devel]

A couple days ago I compiled WSJT-X 2.6.0 on Debian Linux 11 without 
issue, as per Bill's suggestions from a few years ago.  I've made 
several FT8 QSO's, no issues noted.


But I just stumbled on a weird bug:

When I click File:Settings and then cancel without making any changes 
there's a pop-up window.  It's entitled simply "WSJT-X" and contains the 
following text:



Error in Network Address
Error before first number


In case it matters:
* I've not previously run any of the RC versions on that PC.
* I've not made any config changes with 2.6.0 and clicked "save" yet.

So my config is a carry-over from 2.5.4.  Possibly an uninitialized 
variable?


73, KD0KZE / Paul


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

Re: [wsjt-devel] Hamlib errors please for RC4 #hamlib

[Paul Kube via wsjt-devel]

Hi Michael --

I have only so far seen warnings about dropped audio samples as shown
below. I guess these have nothing in particular to do with Hamlib, but if
you want more details, please let me know.  73, Paul K6PO

[SYSLOG][2022-09-15 04:46:35.661153][00:00:00.000650][info] Log Start
[SYSLOG][2022-09-15 04:46:35.661153][00:00:00.000719][info] WSJT-X - ForEW1
  v2.6.0-rc4 c35798  by K1JT et al. - Program startup
[SYSLOG][2022-09-15 04:46:35.676774][00:00:00.013098][info] locale:
language: English script: Latin country: United States ui-languages: en-US
[SYSLOG][2022-09-15 04:46:35.676774][00:00:00.013300][info] Loaded base
translation file from :/Translations based on language en
[SYSLOG][2022-09-15 04:46:35.676774][00:00:00.013336][info] Loaded
translation file from :/Translations based on language en
[SYSLOG][2022-09-15 04:46:35.723639][00:00:00.061776][info] shmem size:
48275456
[RIGCTRL][2022-09-15 04:46:35.754882][00:00:00.088692][info] Hamlib
version: Hamlib 4.5~git Sun Sep 04 16:38:41 2022 + SHA=6c746c
[SYSLOG][2022-09-15 04:46:59.410039][00:00:23.736465][warning] Detected
dropped audio source samples: 2304 (0.048 S)
[SYSLOG][2022-09-15 04:50:29.415028][00:03:53.740578][warning] Detected
dropped audio source samples: 624 (0.013 S)
[SYSLOG][2022-09-15 04:52:59.388463][00:06:23.713997][warning] Detected
dropped audio source samples: 576 (0.012 S)
[SYSLOG][2022-09-15 04:55:29.390469][00:08:53.716504][warning] Detected
dropped audio source samples: 672 (0.014 S)
[SYSLOG][2022-09-15 04:55:59.380954][00:09:23.706202][warning] Detected
dropped audio source samples: 528 (0.011 S)
...

On Wed, Sep 14, 2022 at 3:13 PM Black Michael via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> If everyone running RC4 would please check their wsjtx_syslog.log file and
> see if there are any hamlib errors I would appreciate it.  If
> errors/warning are seen please send the log to me
>
> Getting ready to release Hamlib 4.5 and would like to ensure all is
> working well.
>
> For Windows
> C:\Users\[username]\AppData\Local\WSJT-X\wsjtx_syslog.dat
> For Linux
> /home/[username]\.local\share\WSJT-X\wsjtx_syslog.dat
>
> And RC4 version is not available for MacOS so no testing for Macs is
> needed.
>
> Mike W9MDB
>
>
>
> ___
> 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] RC2 syslog file

[Paul & Mary Lou Mann via wsjt-devel]

I had 11 audio warnings in 10 seconds today. Had the same or more on previous days. Also when using 2.5.4 I am running an Icom 7300 with a Dell windows 10 box.KD2RWCOn Jul 22, 2022 11:37 AM, Black Michael via wsjt-devel  wrote:I'd appreciate if users could check their wsjtx_syslog.log file.
For Windows users it will be in C:\Users\[username]\Appdata\WSJT-X
For Linux users /[username]/.local/share/WSJT-X
Should look like this and have one warning possibly about dropped audio.  If you see any other warnings please report them.  
[SYSLOG][2022-07-09 11:40:21.572105][00:00:00.000857][info] Read logging configuration file: C:/Users/mdbla/AppData/Local/WSJT-X/wsjtx_log_config.ini
[SYSLOG][2022-07-09 11:40:21.572105][00:00:00.000922][info] WSJT-X   v2.6.0-rc1 6744bc - Program startup
[SYSLOG][2022-07-09 11:40:21.577965][00:00:00.007037][info] locale: language: English script: Latin country: United States ui-languages: en-US
[SYSLOG][2022-07-09 11:40:21.577965][00:00:00.007155][info] Loaded Qt translations for current locale from resources
[SYSLOG][2022-07-09 11:40:21.577965][00:00:00.007183][info] Loaded WSJT-X base translation file from :/Translations based on language en
[SYSLOG][2022-07-09 11:40:21.577965][00:00:00.007201][info] Loaded WSJT-X translations for current locale from resources
[SYSLOG][2022-07-09 11:40:21.686366][00:00:00.115734][info] shmem size: 48275456
[RIGCTRL][2022-07-09 11:40:21.702969][00:00:00.131819][info] Hamlib version: Hamlib 4.5~git Fri Jul 08 21:21:34 2022 + SHA=0ec962
[SYSLOG][2022-07-09 11:40:51.067872][00:00:29.488477][warning] Detected dropped audio source samples: -480 (-0.01 S)
[SYSLOG][2022-07-09 11:41:07.421339][00:00:45.836939][info] Log Finish
Mike W9MDB
___
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] Are you building WSJT-X ?

[Paul Bramscher via wsjt-devel]

Hi Joe & group--

First of all, many thanks for this amazing software.  We are doing 
things that would have been considered science fiction at one time.


Using Bill's instructions with some minor tweaks and additions, I've 
been compiling on Debian Linux for several years.


I have a B.S. CSci, and have worked in IT for over 25 years.  Mainly 
programming web and database technologies (LAMP stack), and more 
recently Python, admin and security.


I make no changes to the source, mainly I just want the most current 
version on Debian, and the ability to test multiple versions.  I wish I 
had time to study the source more, since I did coursework in c/c++ (and 
even Fortran back in the day).


73, KD0KZE / Paul

On 4/25/22 10:29, Joe Taylor via wsjt-devel wrote:
When I started work on WSJT some 21 years ago, my principal goal was to 
help bring amateur weak-signal communication techniques into the 
twenty-first century -- and in doing so, to help spread knowledge of 
modern communication theory into the amateur radio community.


By 2005 WSJT was well established but mostly used for special purposes 
like meteor scatter and EME ("moonbounce").  A stable development path 
had been established: the program was fully Open Source, licensed under 
the GNU General Public License, and it could be built by anyone from 
source code using freely available compilers and development tools.  At 
this time WSJT was coded in a combination of Python, Fortran, and C.  A 
re-write in 2012 created the present program, WSJT-X, using the Qt 
platform and C++ language in addition to Fortran and C.


To help gauge the extent to which my original educational goals are 
being met, we in the core development team are interested to know how 
many WSJT-X users are currently building the program for themselves, 
from source code.  If you are doing so, we would appreciate an email 
response -- either publicly, to this list, or in a private email to me. 
All responses will be appreciated, but particular things you might want 
to mention in your message include these:


  - Building on what platform?  Windows, Linux, macOS, or other?

  - What are your particular programming skills and interests?

  - Are you making changes to the code?  If so, toward what end?

  - What portions of the code have you studied well enough to understand?

Many thanks -- I look forward to hearing from you!

 -- 73, Joe, K1JT


___
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] The #$&% Windows 10 audio issue, and a proposal

[Paul Kube via wsjt-devel]

On Fri, Jan 7, 2022 at 1:25 AM Fons Adriaensen via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> On Thu, Jan 06, 2022 at 09:48:22PM -0800, Paul Kube via wsjt-devel wrote:
>
> > Any change to audio device availability on MS Windows is likely to
> renumber
> > the indexes of other devices, when this happens WSJT-X gets no
> notification
> > that it has happened.
>
> So does this mean that when a new audio device becomes available
> while a music app is playing some file, the output from that
> app would be redirected to some other device ?
>

No, rather it seems to be a result of what happens when an audio device in
use becomes unavailable. For example, headphones get unplugged, or an HDMI
monitor goes into sleep mode, etc. Then it kind of makes sense that Windows
would try to find another device that applications can use. Of course, it
does this badly, not always correctly restoring connections when the device
becomes available again.

Isn't the real issue here that WSJT is opening and closing the audio
> devices again and again for each RX or TX cycle ?
>

I don't think so; have you looked at the source code, or traced audio
subsystem calls?

73, Paul K6PO


>
>
>
> ___
> 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] The #$&% Windows 10 audio issue, and a proposal

[Paul Kube via wsjt-devel]

The problem is well known. As Bill G4WJS put it:

Any change to audio device availability on MS Windows is likely to renumber
> the indexes of other devices, when this happens WSJT-X gets no notification
> that it has happened.


That's an awful way to run an audio subsystem, and I'm sure it annoys more
than WSJT-X users, but we're not likely to get Microsoft to change it.

Bill goes on:

There is no practical solution that I am aware of, we get a device index
> when we initially enumerate the available devices and that index is used to
> address the selected device to send or receive audio samples. Short of
> re-enumerating audio devices just before any significant action with audio I
> don't see a solution. Note re-enumerating takes time which we do not
> usually have at the point it would be necessary.


 I suppose Bill is right that you don't want always to automatically
re-enumerate devices before each transmit cycle "just in case". But let me
suggest a practical partial solution.

There are two ways at present to force a WSJT-X re-enumeration of audio
devices that I know of: (1) Kill and restart WSJT-X, or (2) Switch WSJT-X
to another Configuration, and then switch back. Both of these really take
too much time, but then they are doing a lot more than just re-enumerating
the audio devices.

So my suggestion: add a *Reset Audio* menu item (under File or Tools, say)
that lets the operator manually trigger audio device re-enumeration, and
nothing else, when needed. Should be fast!

A small thing, sir, but my own.

73, Paul K6PO
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X 2.5.4 GA Release

[Paul Bramscher via wsjt-devel]

Thanks Joe -- we appreciate the update.  Downloaded the source tarball 
from your Princeton site, compiled without issue on Debian 11.


Previously I was running 2.5.3 with a Kenwood TS-590S and it did crash a 
few times.  No such problems seen yet with 2.5.4.


73, KD0KZE / Paul

On 1/3/22 10:54, Joe Taylor via wsjt-devel wrote:
Please welcome two new members of the core WSJT Development group: Chet 
Fennell, KG4IYS, and Uwe Risse, DG2YCB.  Each brings important skills 
and experience to the project, after the loss of Bill Somerville, G4WJS.


The newly constituted group has been working to redefine standard 
operating procedures for new releases.  WSJT-X 2.5.4, a bug-fix release 
correcting these two flaws in release 2.5.3, is now available as a 
General Availability (GA) release.


Changes from v2.5.3 are:

WSJT-X: Repair a defect that caused occasional crashes when in QSO with
stations using nonstandard callsigns.

MAP65: Correct a bug that prevented "Best-fit Delta phi" solutions from 
  being displayed to the user.


Links to WSJT-X 2.5.4 installation packages for Windows and Linux are 
available here:

http://physics.princeton.edu/pulsar/k1jt/wsjtx.html

Thanks to John Nelson, G4KLA, the installation package for macOS will be 
added soon.


You can also download the packages from our SourceForge site:
https://sourceforge.net/projects/wsjt/files/
It may take a short time for the SourceForge site to be updated.

WSJT-X is licensed under the terms of Version 3 of the GNU General 
Public License (GPL).  Development of this software is a cooperative 
project to which many amateur radio operators have contributed.  If you 
use our code, please have the courtesy to let us know about it.  If you 
find bugs or make improvements to the code, please report them to us in 
a timely fashion.


The authors and Copyright holders of WSJT-X request that derivative 
works should not publish programs based on features in WSJT-X before 
those features are made available in a General Availability (GA) release 
of WSJT-X.  We will cease making public Release Candidate (RC) 
pre-releases for testing and user early access purposes if this request 
is ignored.


Bugs should be reported by following instructions found here in the User 
Guide:


https://www.physics.princeton.edu//pulsar/K1JT/wsjtx-doc/wsjtx-main-2.5.4.html#_bug_reports 



We hope you will enjoy using WSJT-X 2.5.4.

    -- 73 from Joe, K1JT; Steve, K9AN; Nico, IV3NWV; Chet, KG4IYS; and
    Uwe, DG3YCB.


___
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 2.5.3 GA Release (Win64 only)

[Paul Bramscher via wsjt-devel]

I am very sorry to hear of Bill becoming SK.  He has helped me several 
times over the years compile WSJT-X from source on Linux, on this list 
and in e-mail.


Please don't hesitate to release the source, since Bill's instructions 
with a couple additional dependencies still work for me on the current 
Debian.  I can help out folks interested in Debian.


73, KD0KZE / Paul

On 12/8/21 12:25 PM, Joe Taylor via wsjt-devel wrote:

Dear WSJT-X Users:

As most of you know, we are mourning the recent death of our friend and 
colleague Bill Somerville, G4WJS, who since 2013 has contributed so much 
to the WSJT project.


One of Bill's many WSJT-related tasks was creating installation packages 
for Win32, Win64, Linux (Debian, Fedora, Raspberry Pi, ...), and macOS 
for each new program release.  At present we have a straightforward 
system for building the Win64 package -- the best choice for the 
majority of WSJT-X users -- but no systems in place for building Win32, 
Linux, and macOS packages.


WSJT-X 2.5.3 includes a feature of special interest to users who will 
enter the ARRL January VHF Contest (January 15-17, 2022).  For benefit 
of those users, we have decided to release WSJT-X version 2.5.3 for 
Win64 even though we have not yet made prebuilt packages for the other 
operating systems.


Differences between WSJT-X 2.5.2 and 2.5.3 are minimal and described in 
the Release Notes:

https://physics.princeton.edu//pulsar/k1jt/Release_Notes.txt

The new feature for the ARRL VHF contests is an enhanced macro facility 
for Tx messages, aimed at making it easier to ask another station to QSY 
to a new band.  The feature is described briefly here in the User Guide:
https://www.physics.princeton.edu/pulsar/K1JT/wsjtx-doc/wsjtx-main-2.5.3.html#TXMACROS 


Additional information will likely appear on VHF-contest-related forums.

A link for the Win64 installation package for WSJT-X 2.5.3 is now 
available on the WSJT-X web page:

https://physics.princeton.edu//pulsar/k1jt/wsjtx.html

Pre-built packages for Win32, Linux, and macOS will be added when we 
have created new means for creating them.


  -- 73 from Joe, K1JT; Steve, K9AN; and Nico, IV3NWV


___
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 2.5.2 GA Release

[Paul Bramscher via wsjt-devel]

Compiled and working fine here on Debian 11 the past day or so.

73, KD0KZE / Paul

On 11/4/21 1:03 PM, Joe Taylor via wsjt-devel wrote:
We are pleased to announce the General Availability (GA) release of 
WSJT-X version 2.5.2.  This is mostly a bug-fix release.  A full list of 
changes can be found in the Release Notes:

https://physics.princeton.edu//pulsar/k1jt/Release_Notes.txt

IMPORTANT: If you expect to use the JT65 or Q65 modes to make 
weak-signal QSOs that involve a nonstandard callsign, be sure to upgrade 
to WSJT-X 2.5.2!


Links to WSJT-X 2.5.2 installation packages for Windows, Linux, and 
Macintosh are available here:

http://physics.princeton.edu/pulsar/k1jt/wsjtx.html

You can also download the packages from our SourceForge site:
https://sourceforge.net/projects/wsjt/files/
It may take a short time for the SourceForge site to be updated.

WSJT-X is licensed under the terms of Version 3 of the GNU General 
Public License (GPL).  Development of this software is a cooperative 
project to which many amateur radio operators have contributed.  If you 
use our code, please have the courtesy to let us know about it.  If you 
find bugs or make improvements to the code, please report them to us in 
a timely fashion.


The authors and Copyright holders of WSJT-X request that derivative 
works should not publish programs based on features in WSJT-X before 
those features are made available in a General Availability (GA) release 
of WSJT-X.  We will cease making public Release Candidate (RC) 
pre-releases for testing and user early access purposes if this request 
is ignored.


Bugs should be reported by following instructions found here in the User 
Guide:


https://www.physics.princeton.edu//pulsar/K1JT/wsjtx-doc/wsjtx-main-2.5.2.html#_bug_reports 



We hope you will enjoy using WSJT-X 2.5.2.

  -- 73 from Joe, K1JT; Bill, G4WJS; Steve, K9AN; and Nico, IV3NWV


___
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 2.5.0 GA Release

[Paul Bramscher via wsjt-devel]

Thanks for the great work.  Compiled fine from source on Debian 11 
Linux, using my usual methodology.


I noted that the workable frequencies table got larger, but deleted the 
ones my rig is incapable of handling to avoid accidentally switching to 
one.  Good to see there's a simple way to restore to defaults (if I get 
another rig).


I didn't do any of the RC testing this go around, too busy with other 
things in life.  But will be using 2.5.0 now, looks great!


73, KD0KZE / Paul

On 9/27/2021 11:14 AM, Joe Taylor via wsjt-devel wrote:
We are pleased to announce the General Availability (GA) release of 
WSJT-X version 2.5.0.  New features are described in the WSJT-X User 
Guide here:


https://physics.princeton.edu//pulsar/k1jt/wsjtx-doc/wsjtx-main-2.5.0.html#NEW_FEATURES 



and also Release Notes:

https://physics.princeton.edu//pulsar/k1jt/Release_Notes.txt

On Windows platforms, WSJT-X 2.5 includes MAP65 3.0.0, a wideband 
polarization-matching tool intended for EME.


Links to WSJT-X 2.5.0 installation packages for Windows, Linux, and 
Macintosh are available here:

http://physics.princeton.edu/pulsar/k1jt/wsjtx.html

You can also download the packages from our SourceForge site:
https://sourceforge.net/projects/wsjt/files/
It may take a short time for the SourceForge site to be updated.

WSJT-X for Windows now ships with Hamlib built as a dynamic link library 
(DLL).  This change will allow Hamlib bug fixes to be resolved by 
replacing the DLL with an updated version.


WSJT-X is licensed under the terms of Version 3 of the GNU General 
Public License (GPL).  Development of this software is a cooperative 
project to which many amateur radio operators have contributed.  If you 
use our code, please have the courtesy to let us know about it.  If you 
find bugs or make improvements to the code, please report them to us in 
a timely fashion.


The authors and Copyright holders of WSJT-X request that derivative 
works should not publish programs based on features in WSJT-X before 
those features are made available in a General Availability (GA) release 
of WSJT-X.  We will cease making public Release Candidate (RC) 
pre-releases for testing and user early access purposes if this request 
is ignored.


Bugs should be reported by following instructions found here in the User 
Guide:


https://www.physics.princeton.edu//pulsar/K1JT/wsjtx-doc/wsjtx-main-2.5.0.html#_bug_reports 



We hope you will enjoy using WSJT-X 2.5.0.

  -- 73 from Joe, K1JT; Bill, G4WJS; Steve, K9AN; and Nico, IV3NWV


___
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] My problems while compiling from the source

[Paul Bramscher via wsjt-devel]

I have been compiling WSJT-X for a number of years now on Debian
(including Buster 10 now), occasionally with help from G4WJS, and have
had no troubles in a long while.

I don't download from the git repo, though, and instead just get the
current source .tgz from SourceForge.  Have you had success with that
method?

73, KD0KZE / Paul

On 7/16/2021 11:08 AM, Claude Frantz via wsjt-devel wrote:
> Hi Bill and all,
> 
> I'm trying to compile from the source from the git repo:
> 
> I'm here:
> 
> commit 7eac85560823e9c53ae5ed876861f73a1258c717 (HEAD -> master, tag:
> wsjtx-2.5.0-rc3, origin/master, origin/HEAD)
> Merge: df3da69d2 522f698c6
> Author: Bill Somerville 
> Date:   Mon Jul 5 20:58:15 2021 +0100
> 
>     Merge branch 'release-2.5.0'
> 
> commit 522f698c6300613532dd470f6de5f9c9ca986fbf
> Author: Bill Somerville 
> Date:   Mon Jul 5 20:48:05 2021 +0100
> 
>     Release note updates
> 
> commit f067d9472397539e9e1b9247a1d8155e7c768201
> Merge: a141b5af3 bada2dd82
> Author: Bill Somerville 
> Date:   Mon Jul 5 20:43:42 2021 +0100
> 
>     Merge branch 'release-2.5.0' of bitbucket.org:k1jt/wsjtx into
> release-2.5.0
> 
> ###
> 
> The compilation ended here:
> 
> Scanning dependencies of target message_aggregator
> [ 11%] Building CXX object
> CMakeFiles/message_aggregator.dir/UDPExamples/MessageAggregator.cpp.o
> [ 11%] Building CXX object
> CMakeFiles/message_aggregator.dir/UDPExamples/MessageAggregatorMainWindow.cpp.o
> 
> [ 11%] Building CXX object
> CMakeFiles/message_aggregator.dir/UDPExamples/DecodesModel.cpp.o
> [ 11%] Building CXX object
> CMakeFiles/message_aggregator.dir/UDPExamples/BeaconsModel.cpp.o
> [ 11%] Building CXX object
> CMakeFiles/message_aggregator.dir/UDPExamples/ClientWidget.cpp.o
> [ 11%] Building CXX object
> CMakeFiles/message_aggregator.dir/validators/MaidenheadLocatorValidator.cpp.o
> 
> [ 12%] Building CXX object
> CMakeFiles/message_aggregator.dir/qrc_message_aggregator.cpp.o
> [ 12%] Building CXX object
> CMakeFiles/message_aggregator.dir/qrc_style.cpp.o
> [ 12%] Building CXX object
> CMakeFiles/message_aggregator.dir/message_aggregator_autogen/mocs_compilation.cpp.o
> 
> [ 12%] Linking CXX executable message_aggregator
> /usr/bin/ld: /usr/lib/x86_64-linux-gnu/libthread_db.so: undefined
> reference to `ps_lsetregs'
> /usr/bin/ld: /usr/lib/x86_64-linux-gnu/libthread_db.so: undefined
> reference to `ps_pdread'
> /usr/bin/ld: /usr/lib/x86_64-linux-gnu/libthread_db.so: undefined
> reference to `ps_lsetfpregs'
> /usr/bin/ld: /usr/lib/x86_64-linux-gnu/libthread_db.so: undefined
> reference to `ps_getpid'
> /usr/bin/ld: /usr/lib/x86_64-linux-gnu/libthread_db.so: undefined
> reference to `ps_pdwrite'
> /usr/bin/ld: /usr/lib/x86_64-linux-gnu/libthread_db.so: undefined
> reference to `ps_lgetregs'
> /usr/bin/ld: /usr/lib/x86_64-linux-gnu/libthread_db.so: undefined
> reference to `ps_lgetfpregs'
> /usr/bin/ld: /usr/lib/x86_64-linux-gnu/libthread_db.so: undefined
> reference to `ps_pglobal_lookup'
> collect2: error: ld returned 1 exit status
> make[2]: *** [CMakeFiles/message_aggregator.dir/build.make:273:
> message_aggregator] Error 1
> make[1]: *** [CMakeFiles/Makefile2:140:
> CMakeFiles/message_aggregator.dir/all] Error 2
> make: *** [Makefile:152: all] Error 2
> 
> ###
> 
> What is missing or wrong ?
> 
> The system:
> Linux defi 4.19.0-17-amd64 #1 SMP Debian 4.19.194-2 (2021-06-21) x86_64
> GNU/Linux
> 
> 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] Possible feature request, time skew notification?

[Paul Bramscher via wsjt-devel]

I was at a monthly outdoor ham event in the greater St. Paul/Minneapolis
area that's drawn loyal attendance the past few years.  An operator
setup FT8 outdoors, but had some issues getting it to decode.  We could
tell it was getting sound from his port, but there was no decoding.

He was using Windows, whereas I'm Linux only so wasn't much help.
Another ham suggested he compare his system clock with his cellphone,
and that fixed it.  I believe he said he was off by 5+ seconds.

I'm wondering whether it might be possible, algorithmically to somehow
detect that a person's clock may be out of sync and present a
notification message.  Of course there's the DT/Time Delta column when
you are able to decode.  But, presumably, he had reached the point of no
return.

I don't know how this might be possible without an accurate reference
clock -- but possibly based on the average timing of heard signals, or
some sort of signature within them, to cause a message to the user that
s/he may want to check their clock's accuracy?

Just wondering what might be possible in this regard, and I suspect it
would help portable users, especially those who've been offline for a
number of days/etc. and their system clocks had degraded.

73, KD0KZE / Paul


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

Re: [wsjt-devel] FT4 logging prompt

[Paul Kube]

>
> WSJT-X is open source.  You can make those changes you are suggesting,
> thereby customizing your station operations.


Yes I know that. But:

 However, do not be surprised if you actually loose a lot of
> confirmations... My station.  My logbook.  My rules.


Yes and so my proposal is to make the "short QSO" the default for WWDIGI.
The contest's rules, that everybody in the contest plays by. Contesters
will like the higher QSO rates. Maybe it will catch on more generally,
maybe not.

And I would be happy to implement this as a patch against 2.4.0-rc4 or
whatever version, if I had reason to think it would be accepted.

73, Paul K6PO


On Fri, May 7, 2021 at 5:34 PM Jeff Stillinger via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> WSJT-X is open source.  You can make those changes you are suggesting,
> thereby customizing your station operations.   There is no licensing
> restrictions that would stop you from doing so (see GPL 3).
>
> However, do not be surprised if you actually loose a lot of
> confirmations.   Yes, I am one of those stations that expect the basic
> exchange format as outlined in the User Guide to be completed in order to
> be confirmed.   My station.  My logbook.  My rules.   I will always
> complete any QSO regardless.  I just don't log for confirmation the ones
> that have missing pieces.  I strongly believe this helps maintain the
> integrity of awards.   But...  that is me.   Someone else may feel
> differently.   It's all good in the rf hood.
>
>
>
>
> On 5/6/21 3:28 PM, Martin Davies G0HDB wrote:
>
> The FT4 mode was introduced in WSJT-X version 2.1.0 in 2019; the release
> notes and announcements state that the mode is intended for use in HF
> digital contesting where 'quick-fire' exchanges such as those achieved
> using RTTY are desired.  I'd like to suggest a change that would help
> achieve this aim a bit better; the following applies to v2.1.0 and all
> subsequent versions up to and including v2.3.1 (I haven't yet tried any of
> the RC versions of v2.4.0).
>
> An FT4 (and an FT8!) QSO generally looks something like the following:
>
> CQ K1JT FN20
>   K1JT G0HDB IO82
> G0HDB K1JT -10
>   K1JT G0HDB R-08
> G0HDB K1JT RR73
>   K1JT G0HDB 73
>
> Currently, the logging window only pops open on my screen to prompt me to
> log the QSO when the final (Tx5) '73' message is being sent - this is to
> all extents and purposes superfluous because the QSO has been successfully
> completed when K1JT has sent his RR73 (and I've received it).  My sending
> the superfluous '73' message extends the overall duration of the QSO by
> adding a further Tx period at my end of the sequence so I can't move on to
> trying to start the next QSO.
>
> I'd like to suggest that the logging window is opened when I've *received*
> the other station's RR73 message and that sending the final Tx5 '73'
> message is either removed from the sequence altogether or is made
> optional.  This would help to improve the overall throughput of FT4 QSOs.
>
> The code to open the logging window on receipt of an incoming 'RR73'
> message and to desist from sending the Tx5 '73' message must already exist
> within the app because that's what already happens when I operate as a
> Hound in FT8 Fox & Hounds mode - when I receive the Fox's 'RR73' the
> logging window pops open and my system doesn't send the unnecessary Tx5
> '73' .
>
> I'd actually like to see the logging window open in any mode when I either
> send *or receive* an RRR or RR73 message - in my opinion that would align
> the prompting to log the QSO much more closely with the completion of the
> exchange of the essential information for the QSO and would leave the
> sending of a final '73' as an optional nicety.
>
> --
> 73, Martin G0HDB
>
>
>
> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient>
>  Virus-free.
> www.avast.com
> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient>
> <#m_6602682828413212526_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
>
> ___
> wsjt-devel mailing 
> listwsjt-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
>
> --
> Jeff Stillinger - KB6IBB
> KB6IBB Laboratories
> Wylie, Texas - United States
>
> ___
> 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] FT4 logging prompt

[Paul Kube]

I agree with Martin and others, but let me suggest a slight compromise.

Instead of changing the default sequence for all FT4 QSO's, change it for
FT8/FT4 in WWDIGI contest mode only, and advertise the change. This won't
disrupt anyone's ideas about how general FT QSO's should be done;
contesters will understand the change, and appreciate it. 2021 WWDIGI is
August 28-29; should be time enough to implement it.

In more detail:


   1. Eliminate Tx5, “73”, from the default QSO message sequence. Its use
   should be discouraged in WWDIGI (and in fact in all FT4/FT8 contests). It
   is not needed for the exchange and acknowledgement of required information,
   and – because  its use is not widely understood not to be required --  just
   leads to longer QSO’s on average, and general confusion about whether a QSO
   has been completed which increases NIL’s.

   Since in WWDIGI  the only exchange info is callsigns and grids, the
   default QSO -- exchanging and acknowledging all required information --
   could be as short as 3 transmissions. Examples:
  1. Answering a CQ:
  CQ WW W0YK DM97  Tx6
  W0YK K6PO R DM12   Tx3
  K6PO W0YK RR73 Tx4
  2. Tailending a QSO. K6PO has already copied W0YK’s grid. Then:
  W1AW W0YK RR73  Tx4
  W0YK K6PO R DM12   Tx3
  K6PO W0YK RR73 Tx4
  3. Tailending a QSO. K6PO has not yet copied W0YK’s grid. Then:
  W1AW W0YK RR73  Tx4
  W0YK K6PO DM12   Tx2
  K6PO W0YK R DM97   Tx3
  W0YK K6PO RR73 Tx4

  2. Automatically log the QSO sending *or receiving* Tx4, “RR73”. One
   reason sending Tx5, “73”, is currently in the default QSO sequence for
   WWDIGI is that this triggers automatic logging of the QSO from  WSJT-X. Tx5
   is never sent in examples 1a-1c above, and so one QSO partner would need to
   manually log the QSO in each case (i.e. hit the “Log QSO” button in WSJT-X,
   and in the case of 1b, perhaps also manually enter the copied grid). If
   automatic logging is desired, triggering it on sending *or receiving*
   Tx4 would accomplish that.

   3. Note: in some of the examples above, part of the contest exchange
   (the grid) is not explicitly sent from the first QSO partner (W0YK) to the
   second (K6PO). Some might object to this, but note that it is copied by the
   second QSO partner as part of the first partner’s CQ or other transmission,
   and so this  is as much or more in the spirit of 2-way over-the-air
   communication as commonly used contest techniques like call history files,
   giving your call only once every few QSO’s in a run, etc.


73, Paul K6PO

On Thu, May 6, 2021 at 1:34 PM Martin Davies G0HDB 
wrote:

> The FT4 mode was introduced in WSJT-X version 2.1.0 in 2019; the release
> notes and announcements state that the mode is intended for use in HF
> digital contesting where 'quick-fire' exchanges such as those achieved
> using RTTY are desired.  I'd like to suggest a change that would help
> achieve this aim a bit better; the following applies to v2.1.0 and all
> subsequent versions up to and including v2.3.1 (I haven't yet tried any of
> the RC versions of v2.4.0).
>
> An FT4 (and an FT8!) QSO generally looks something like the following:
>
> CQ K1JT FN20
>   K1JT G0HDB IO82
> G0HDB K1JT -10
>   K1JT G0HDB R-08
> G0HDB K1JT RR73
>   K1JT G0HDB 73
>
> Currently, the logging window only pops open on my screen to prompt me to
> log the QSO when the final (Tx5) '73' message is being sent - this is to
> all extents and purposes superfluous because the QSO has been successfully
> completed when K1JT has sent his RR73 (and I've received it).  My sending
> the superfluous '73' message extends the overall duration of the QSO by
> adding a further Tx period at my end of the sequence so I can't move on to
> trying to start the next QSO.
>
> I'd like to suggest that the logging window is opened when I've *received*
> the other station's RR73 message and that sending the final Tx5 '73'
> message is either removed from the sequence altogether or is made
> optional.  This would help to improve the overall throughput of FT4 QSOs.
>
> The code to open the logging window on receipt of an incoming 'RR73'
> message and to desist from sending the Tx5 '73' message must already exist
> within the app because that's what already happens when I operate as a
> Hound in FT8 Fox & Hounds mode - when I receive the Fox's 'RR73' the
> logging window pops open and my system doesn't send the unnecessary Tx5
> '73' .
>
> I'd actually like to see the logging window open in any mode when I either
> send *or receive* an RRR or RR73 message - in my opinion that would align
> the prompting to log the QSO much more closely with the completion of

[wsjt-devel] WSPR

[Paul Simon]

I have been having problems using WSPR with band hopping.  Power output 
is set at 200 mw and tune at 2.5 watts.  After a while the tune power 
will drop to output power or lower, tune does not come on after band 
change and may come on during a transmit/receive sequence on one band.


Both remember output power and tune power are checked and the tune box 
is selected in the band hop selection pop up form.  The rig is IC-7300 
and CAT control.


This happens both with Windows 10, latest update and linux, Mageia 8.

Paul Simon, W6EXT



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

Re: [wsjt-devel] WSJT-X 2.3.0-rc4

[Paul Bramscher]

I downloaded it quite shortly after it was posted on SourceForge.
Compiled fine on Debian 10 amd64, fully patched, no issues noted so far.

Keep up the great work.

73, KD0KZE / Paul

On 1/25/2021 8:45 AM, Joe Taylor wrote:
> The fourth public candidate release of WSJT-X 2.3.0 is now available for
> download and use by beta testers.  Changes from the third release
> candidate are minimal; they are described in the Release Notes here:
> 
> https://physics.princeton.edu//pulsar/k1jt/Release_Notes.txt
> 
> Links to installation packages for Windows, Linux, and Macintosh are
> available here:
> https://physics.princeton.edu/pulsar/k1jt/wsjtx.html
> 
> Scroll down to find "Candidate release:  WSJT-X 2.3.0-rc4".
> 
> You can also download the packages from our SourceForge site:
> https://sourceforge.net/projects/wsjt/files/
> It may take a short time for the SourceForge site to be updated.
> 
> We expect to make a General Availability (GA) release of WSJT-X 2.3.0
> very soon.
> 
> WSJT-X is licensed under the terms of Version 3 of the GNU General
> Public License (GPL).  Development of this software is a cooperative
> project to which many amateur radio operators have contributed.  If you
> use our code, please have the courtesy to let us know about it.  If you
> find bugs or make improvements to the code, please report them to us in
> a timely fashion.
> 
> We hope you will enjoy using this beta release of WSJT-X 2.3.0.  Please
> report bugs by following instructions found here in the User Guide:
> https://www.physics.princeton.edu/pulsar/K1JT/wsjtx-doc/wsjtx-main-2.3.0-rc4.html#_bug_reports
> 
> 
>  -- 73 from Joe, K1JT; Bill, G4WJS; Steve, K9AN; and Nico, IV3NWV
> 
> 
> ___
> 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.3.0-rc2 auto-stop TX not working?

[Paul Bramscher]

Greetings--  I may be imagining this (apologies if so), but there may be
a change of behavior between RC1 and RC2 or thereabouts with regard to
transmitting.  I'm running RC2 compiled on Debian Linux, Kenwood TS-590.

I seem to recall in the past that if:
Some station is calling CQ
You attempt to answer
They begin a QSO with some other station

Then WSJT-X's TX automatically disables, as a courtesy to the two
other stations beginning a QSO.

Seems it remains engaged now, and you need to manually turn off TX to
that station lest you step on their QSO.

Has this behavior changed, or am I imagining things?  I run only split
mode these days, if that has anything to do with it.

73, KD0KZE / Paul


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

Re: [wsjt-devel] WSJT-X 2.3.0-rc2 compile error w/Debian 10 Linux

[Paul Bramscher]

Hi Bill,

Thanks, this solved it.  I saw a thread on boost+MacOS but didn't connect the 
dots to Linux.  libboost-all-dev added about 554 MB to the dependency size, and 
it seemed the compile took longer than usual.  But it could be that there was 
some residual disk activity from bringing down these new dependencies and the 
next compile may go more swiftly.

At any rate, I'll test out rc2 now.

73, KD0KZE / Paul

> On 11/16/2020 8:42 AM Bill Somerville  wrote:
> 
> 
> On 16/11/2020 14:27, Paul Bramscher wrote:
> 
> > > I'm getting a compile error with Debian 10 Linux (amd64), 
> fully patched.  No trouble compiling 2.3.0-rc1.  But here is what fails on 
> rc2:
> > 
> > My cmake/compile commands:
> > cmake -DCMAKE_INSTALL_PREFIX=../../install/ -DWSJT_SKIP_MANPAGES=ON 
> > -DWSJT_GENERATE_DOCS=OFF ../wsjtx-2.3.0-rc2
> > cmake --build ~/wsjtx/wsjtx-2.3.0-rc2/build/wsjtx-2.3.0-rc2 
> > --target install -- -j
> > 
> > Failure points:
> > -- Performing Test COMPILER_HAS_HIDDEN_VISIBILITY
> > -- Performing Test COMPILER_HAS_HIDDEN_VISIBILITY - Success
> > -- Performing Test COMPILER_HAS_HIDDEN_INLINE_VISIBILITY
> > -- Performing Test COMPILER_HAS_HIDDEN_INLINE_VISIBILITY - Success
> > -- Performing Test COMPILER_HAS_DEPRECATED_ATTR
> > -- Performing Test COMPILER_HAS_DEPRECATED_ATTR - Failed
> > -- Performing Test COMPILER_HAS_DEPRECATED
> > -- Performing Test COMPILER_HAS_DEPRECATED - Failed
> > -- Configuring incomplete, errors occurred!
> > See also 
> > "/home/myuser/wsjtx/wsjtx-2.3.0-rc2/build/wsjtx-2.3.0-rc2/wsjtx-prefix/src/wsjtx-build/CMakeFiles/CMakeOutput.log".
> > See also 
> > "/home/myuser/wsjtx/wsjtx-2.3.0-rc2/build/wsjtx-2.3.0-rc2/wsjtx-prefix/src/wsjtx-build/CMakeFiles/CMakeError.log".
> > make[3]: *** [CMakeFiles/wsjtx-install.dir/build.make:73: 
> > wsjtx-prefix/src/wsjtx-stamp/wsjtx-configure] Error 1
> > make[2]: *** [CMakeFiles/Makefile2:361: 
> > CMakeFiles/wsjtx-install.dir/all] Error 2
> > make[1]: *** [CMakeFiles/Makefile2:432: 
> > CMakeFiles/install.dir/rule] Error 2
> > make: *** [Makefile:261: install] Error 2
> > 
> > 
> > > 
> Hi Paul,
> 
> there is a new dependency for WSJT-X v2.3.0 RC2.
> 
> sudo apt-get install libboost-all-dev
> 
> 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.3.0-rc2 compile error w/Debian 10 Linux

[Paul Bramscher]

I'm getting a compile error with Debian 10 Linux (amd64), fully patched.  No 
trouble compiling 2.3.0-rc1.  But here is what fails on rc2:

My cmake/compile commands:
cmake -DCMAKE_INSTALL_PREFIX=../../install/ -DWSJT_SKIP_MANPAGES=ON 
-DWSJT_GENERATE_DOCS=OFF ../wsjtx-2.3.0-rc2
cmake --build ~/wsjtx/wsjtx-2.3.0-rc2/build/wsjtx-2.3.0-rc2 --target install -- 
-j

Failure points:
-- Performing Test COMPILER_HAS_HIDDEN_VISIBILITY
-- Performing Test COMPILER_HAS_HIDDEN_VISIBILITY - Success
-- Performing Test COMPILER_HAS_HIDDEN_INLINE_VISIBILITY
-- Performing Test COMPILER_HAS_HIDDEN_INLINE_VISIBILITY - Success
-- Performing Test COMPILER_HAS_DEPRECATED_ATTR
-- Performing Test COMPILER_HAS_DEPRECATED_ATTR - Failed
-- Performing Test COMPILER_HAS_DEPRECATED
-- Performing Test COMPILER_HAS_DEPRECATED - Failed
-- Configuring incomplete, errors occurred!
See also 
"/home/myuser/wsjtx/wsjtx-2.3.0-rc2/build/wsjtx-2.3.0-rc2/wsjtx-prefix/src/wsjtx-build/CMakeFiles/CMakeOutput.log".
See also 
"/home/myuser/wsjtx/wsjtx-2.3.0-rc2/build/wsjtx-2.3.0-rc2/wsjtx-prefix/src/wsjtx-build/CMakeFiles/CMakeError.log".
make[3]: *** [CMakeFiles/wsjtx-install.dir/build.make:73: 
wsjtx-prefix/src/wsjtx-stamp/wsjtx-configure] Error 1
make[2]: *** [CMakeFiles/Makefile2:361: CMakeFiles/wsjtx-install.dir/all] Error 
2
make[1]: *** [CMakeFiles/Makefile2:432: CMakeFiles/install.dir/rule] Error 2
make: *** [Makefile:261: install] Error 2


Snippets from CMakeError.log:

Performing C SOURCE FILE Test HAVE_MATH failed with the following output:
Change Dir: 
/home/myuser/wsjtx/wsjtx-2.3.0-rc2/build/wsjtx-2.3.0-rc2/wsjtx-prefix/src/wsjtx-build/CMakeFiles/CMakeTmp
Run Build Command:"/usr/bin/make" "cmTC_3bcda/fast"
make[4]: Entering directory 
'/home/myuser/wsjtx/wsjtx-2.3.0-rc2/build/wsjtx-2.3.0-rc2/wsjtx-prefix/src/wsjtx-build/CMakeFiles/CMakeTmp'
/usr/bin/make -f CMakeFiles/cmTC_3bcda.dir/build.make 
CMakeFiles/cmTC_3bcda.dir/build
make[5]: Entering directory 
'/home/myuser/wsjtx/wsjtx-2.3.0-rc2/build/wsjtx-2.3.0-rc2/wsjtx-prefix/src/wsjtx-build/CMakeFiles/CMakeTmp'
Building C object CMakeFiles/cmTC_3bcda.dir/src.c.o
/usr/bin/cc -DHAVE_MATH -o CMakeFiles/cmTC_3bcda.dir/src.c.o -c 
/home/myuser/wsjtx/wsjtx-2.3.0-rc2/build/wsjtx-2.3.0-rc2/wsjtx-prefix/src/wsjtx-build/CMakeFiles/CMakeTmp/src.c
Linking C executable cmTC_3bcda
/usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_3bcda.dir/link.txt 
--verbose=1
/usr/bin/cc -DHAVE_MATH CMakeFiles/cmTC_3bcda.dir/src.c.o -o cmTC_3bcda
/usr/bin/ld: CMakeFiles/cmTC_3bcda.dir/src.c.o: in function `main':
src.c:(.text+0x11): undefined reference to `sqrt'
collect2: error: ld returned 1 exit status
make[5]: *** [CMakeFiles/cmTC_3bcda.dir/build.make:87: cmTC_3bcda] Error 1
make[5]: Leaving directory 
'/home/myuser/wsjtx/wsjtx-2.3.0-rc2/build/wsjtx-2.3.0-rc2/wsjtx-prefix/src/wsjtx-build/CMakeFiles/CMakeTmp'
make[4]: *** [Makefile:121: cmTC_3bcda/fast] Error 2
make[4]: Leaving directory 
'/home/myuser/wsjtx/wsjtx-2.3.0-rc2/build/wsjtx-2.3.0-rc2/wsjtx-prefix/src/wsjtx-build/CMakeFiles/CMakeTmp'

Also:

Run Build Command:"/usr/bin/make" "cmTC_32eb3/fast"
make[4]: Entering directory 
'/home/myuser/wsjtx/wsjtx-2.3.0-rc2/build/wsjtx-2.3.0-rc2/wsjtx-prefix/src/wsjtx-build/CMakeFiles/CMakeTmp'
/usr/bin/make -f CMakeFiles/cmTC_32eb3.dir/build.make 
CMakeFiles/cmTC_32eb3.dir/build
make[5]: Entering directory 
'/home/myuser/wsjtx/wsjtx-2.3.0-rc2/build/wsjtx-2.3.0-rc2/wsjtx-prefix/src/wsjtx-build/CMakeFiles/CMakeTmp'
Building C object CMakeFiles/cmTC_32eb3.dir/HAMLIB_OLD_CACHING.c.o
/usr/bin/cc 
-I/home/myuser/wsjtx/wsjtx-2.3.0-rc2/build/wsjtx-2.3.0-rc2/hamlib-prefix/include
 -I/usr/include/libusb-1.0 -o CMakeFiles/cmTC_32eb3.dir/HAMLIB_OLD_CACHING.c.o 
-c /home/myuser/wsjt$
/home/myuser/wsjtx/wsjtx-2.3.0-rc2/build/wsjtx-2.3.0-rc2/wsjtx-prefix/src/wsjtx-build/CMakeFiles/CheckTypeSize/HAMLIB_OLD_CACHING.c:24:22:
 error: ‘CACHE_ALL’ undeclared here (not in a function); d$
#define SIZE (sizeof(CACHE_ALL))
^
/home/myuser/wsjtx/wsjtx-2.3.0-rc2/build/wsjtx-2.3.0-rc2/wsjtx-prefix/src/wsjtx-build/CMakeFiles/CheckTypeSize/HAMLIB_OLD_CACHING.c:26:12:
 note: in expansion of macro ‘SIZE’
('0' + ((SIZE / 1)%10)),
^~~~
make[5]: *** [CMakeFiles/cmTC_32eb3.dir/build.make:66: 
CMakeFiles/cmTC_32eb3.dir/HAMLIB_OLD_CACHING.c.o] Error 1
make[5]: Leaving directory 
'/home/myuser/wsjtx/wsjtx-2.3.0-rc2/build/wsjtx-2.3.0-rc2/wsjtx-prefix/src/wsjtx-build/CMakeFiles/CMakeTmp'
make[4]: *** [Makefile:121: cmTC_32eb3/fast] Error 2
make[4]: Leaving directory 
'/home/myuser/wsjtx/wsjtx-2.3.0-rc2/build/wsjtx-2.3.0-rc2/wsjtx-prefix/src/wsjtx-build/CMakeFiles/CMakeTmp'
/home/myuser/wsjtx/wsjtx-2.3.0-rc2/build/wsjtx-2.3.0-rc2/wsjtx-prefix/src/wsjtx-build/CMakeFiles/CheckTypeSize/HAMLIB_OLD_CACHING.c:


73, KD0KZE / Paul___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] compilation using Debian Stable

[Paul Bramscher]

On 10/24/2020 12:03 PM, Christoph Berg wrote:
> Am 24. Oktober 2020 16:05:19 MESZ schrieb Claude Frantz
> :
> 
> Hello all,
> 
> which problems do I have to expect when trying to compile the source 
> code from the git repo using Debian STABLE ? Which are the solutions 
> available ?
> 
> Best wishes,
> Claude (DJ0OT)
> 
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel 
> <https://lists.sourceforge.net/lists/listinfo/wsjt-devel>
> 
> 
> I've recently added wsjtx 2.2.2 to buster-backports. So you can just
> install from there, or "apt build-dep wsjtx".

I've compiled WSJT-X for a number of years now on Debian without
significant issues.  I was able to resolve all dependencies from within
the regular repo.

Currently running Debian 10 Buster, fully patched to the current
version.  If you search the forum archives for my callsign you should be
able to see a couple related discussion threads with specific information.

Yesterday I compiled 2.3.0-rc1 on my Debian 10 machine that runs WSJT-X
2.2.2 and encountered no new dependency issues.  So once you get the
initial dependencies met, it becomes smoother sailing.

I am currently working 30M FT8 with a Kenwood TS-590.  No issues
encountered yet.

73, KD0KZE / Paul



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

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

[Paul Randall]

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

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


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



73,



WB0CDY



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



[External Email]

Actually, NO.

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

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

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

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



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



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



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



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



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



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



My 2p worth



Paul G3NJV













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



I find the discussion interesting.

73, Carey, WB4HXE



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

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

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

Gary - AG0N

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




--

Carey Fisher

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


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

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

[Paul Randall]

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

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

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

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

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

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

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

My 2p worth

Paul G3NJV






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

I find the discussion interesting.
73, Carey, WB4HXE

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

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

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

Gary - AG0N

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


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

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

Re: [wsjt-devel] The FT4 and FT8 Communication Protocols

[Paul Kube]

Interesting to see how FT4 outperforms FT8 (by a lot!) in the high-latitude
moderately disturbed channel model.

Question: am I understanding correctly that the standard message payload
devotes two whole bits for callsign suffixes /p and /r? (So it is
theoretically possible to have a call using both?) Since these suffixes are
so rare in practice I wonder if in retrospect you think this is a perhaps
regrettable use of the message payload.

73, Paul K6PO

On Fri, Jun 12, 2020 at 11:52 AM Joe Taylor  wrote:

> If you're interested in how the FT4 and FT8 modes work, and how they are
> implemented in WSJT-X, you can find all the technical details in a
> paper by Steve Franke, K9AN, Bill Somerville, G4WJS, and Joe Taylor,
> K1JT, published in the July/August issue of QEX.
>
> A copy has been posted on the WSJT web site here:
> https://physics.princeton.edu/pulsar/k1jt/FT4_FT8_QEX.pdf
>
> -- 73, Joe, K1JT
>
>
> ___
> 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] Trans-Atlantic 6m opening

[Paul Kube]

Needed a couple more Es hops for US west coast folks to participate! We may
have to wait for the F layer to light up for that path to work for us
though.

I appreciate your recommendation of FT4 for these snapshot openings, and
that raises a question: Does it make sense to try using ISCAT for this?
Some of the E layer patches seem so small and fast-moving it is almost like
a meteor burn.

73, Paul K6PO




On Sun, Jun 7, 2020 at 6:16 PM Joe Taylor  wrote:

> Hi all,
>
> I know that like me, some of you enjoyed today's excellent multi-hop
> sporadic E opening across the Atlantic.  It was an excellent test of the
> original design goals of FT8, and more recently also FT4.
>
> Over a span of several hours I completed 76 QSOs with European stations.
>   Of these 37 were with FT8 on 50.313 (mostly) or 50.323 MHz.  The
> remaining 39 QSOs used FT4 on 50.318, and took place in just 44 minutes.
>
> I strongly recommend that for such openings in the future you should try
> FT4.  It's twice as fast as FT8, with only a 3 dB penalty on the AWGN
> channel.  The sensitivity penalty is even less on a fading channel.
>
> Today's conditions also provided an excellent chance to take advantage
> of good operating practices.  As recommended, most European stations
> transmitted "in the "1st/Even" sequence in both FT4 nd FT8.  North
> American stations transmitted in second sequence.  This procedure
> minimizes QRN from strong local stations and helps everyone to work DX.
>
> -- 73, Joe, K1JT
>
>
> ___
> 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 2.2.0 GA release

[Paul Bramscher]

Greetings--

Compiled from source on a fully patched Linux Debian 10, Kenwood
TS-590S, running for a few hours today, no bugs noted (for me).  No new
dependencies needed for the compile since the last version.

A big thank you to the team for continuing to develop this great program!

73, KD0KZE / Paul Bramscher

On 6/2/2020 8:53 AM, Joe Taylor wrote:
> The WSJT Development Group is pleased to announce the general
> availability (GA) release of WSJT-X Version 2.2.0.  A brief summary of
> new features is provided here; for further details see the Release Notes:
> 
> http://physics.princeton.edu/pulsar/k1jt/Release_Notes.txt
> 
> ... and of course the updated WSJT-X 2.2 User Guide:
> 
> http://www.physics.princeton.edu/pulsar/K1JT/wsjtx-doc/wsjtx-main-2.2.0.html#NEW_FEATURES
> 
> 
> New Features in WSJT-X 2.2.0:
> 
>  - Significant improvements to the decoders for FT4, FT8, JT4, JT65,
>    and WSPR.
> 
>  - New format for "EU VHF Contest" Tx2 and Tx3 messages
> 
>    When "EU VHF Contest" is selected, the Tx2 and Tx3 messages (those
>    conveying signal report, serial number, and 6-character locator)
>    now use hashcodes for both callsigns.  This change is NOT backward
>    compatible with earlier versions of _WSJT-X_, so all users of EU
>    VHF Contest messages should be sure to upgrade to version 2.2.0.
> 
>  - Accessibility
> 
>    Keyboard shortcuts have been added as an aid to accessibility:
>    Alt+R sets Tx4 message to RR73, Ctrl+R sets it to RRR.
> 
>    As an aid for partial color-blindness, the "inverted goal posts"
>    marking Rx frequency on the Wide Graph's frequency scale are now
>    rendered in a darker shade of green.
> 
>  - User Interface Translations have been enabled.  Translations are
>    now available for Catalan, Spanish, Japanese, Chinese, and Hong
>    Kong Chinese.  Additiional languages will follow, when available.
> 
>    Note that UI translation is automatic, based on your system primary
>    language. If you do not want the WSJT-X UI translated to your local
>    language then start WSJT-X with the '--language=en' command line
>    option:
> 
>    wsjtx --language=en
> 
>    If you wish to contribute by authoring WSJT-X UI translations
>    please join the new discussion group wsjtx-l...@groups.io
>    (https://groups.io/g/wsjtx-l10n), where help from other translation
>    authors and coordination with the development team is available.
> 
>  - Minor enhancements and bug fixes
> 
>    "Save None" now writes no .wav files to disk, even temporarily.
> 
>    An explicit entry for "WW Digi Contest" has been added to
>    "Special operating activities" on the "Settings | Advanced" tab.
> 
>    Contest mode FT4 now always uses RR73 for the Tx4 message.
> 
>    The Status bar now displays the number of decodes found in the
>    most recent Rx sequence.
> 
>    The "Highlight Callsign" UDP message has been enhanced to allow
>    clearing of old highlighting for a specified callsign. Please note
>    a recommended restriction on the use of this message in the
>    documentation here: https://tinyurl.com/y85nc3tg
> 
>  - Hamlib - this library which we use for direct rig control has had
>    many defect repairs and enhancements, we thank the contributors to
>    that project for their work.
> 
> Upgrading from earlier versions of WSJT-X should be seamless.  There is
> no need to uninstall a previous version or move any files.
> 
> Please do not continue to use any release candidate -- that is, any beta
> release with "-rc#" in the version name.
> 
> Links to installation packages for Windows, Linux, and Macintosh are
> available here:
> http://physics.princeton.edu/pulsar/k1jt/wsjtx.html
> 
> You can also download the packages from our SourceForge site:
> https://sourceforge.net/projects/wsjt/files/
> It may take a short time for the SourceForge site to be updated.
> 
> WSJT-X is licensed under the terms of Version 3 of the GNU General
> Public License (GPL).  Development of this software is a cooperative
> project to which many amateur radio operators have contributed.  If you
> use our code, please have the courtesy to let us know about it.  If you
> find bugs or make improvements to the code, please report them to us in
> a timely fashion.
> 
> We hope you will enjoy using WSJT-X Version 2.2.0.
> 
>  -- 73 from Joe, K1JT, Steve, K9AN, and Bill, G4WJS,
>  for the entire WSJT Development Group
> 
> 
> ___
> 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] Feature Suggestion

[Paul Randall]

'morning Bill,  sun baked down here in Cornwall.  Thanks for responding.
The app I was looking at is called WSJT Monitor. It's setup instruction tells 
me to change the normal address for psk reporter,  so it's one or the other.
Pity as it would be really useful. It's Es season plus openings down to D4 but 
blink and you miss them.

The combination of the WSJT teams software plus the PSKreporter site has 
revolutionised understanding of long distance paths on vhf/uhf. Many thanks
PS if your interested I can post a map from couple of days ago - biggest Es 
event since the 80s plus a duct to D4

Best wishes Paul




Sent from my Samsung Galaxy smartphone.



 Original message 
From: Bill Somerville 
Date: 31/05/2020 12:02 (GMT+00:00)
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] Feature Suggestion

Hi Paul,

WSJT-X sends copious information via it's UDP Message Protocol, you should use 
that.

73
Bill
G4WJS.

On 31/05/2020 07:50, Paul Randall wrote:
Another feature suggestion.

Would it be possible to add the capability for WSJTx to report to a second 
external program in addition to PSKreporter? I have an Android app that lets me 
keep tabs on what the radio is seeing whilst I am around the house or garden 
but to use it means I must disconnect from PSKreporter. It would be great if 
both were connected.  I monitor VHF activity and a close eye is required to 
catch brief openings however I also have a life so cannot sit in front of the 
radio all the time.

Thanks for all the work, looking forward to the new release.
73 Paul




Sent from my Samsung Galaxy smartphone.



 Original message 
From: Jon Anhold <mailto:j...@anhold.com>
Date: 30/05/2020 16:26 (GMT+00:00)
To: WSJT software development 
<mailto:wsjt-devel@lists.sourceforge.net>
Subject: [wsjt-devel] Feature Suggestion

Add some indicator to the separator line in the band activity window to show if 
it was "even/1st" or "odd/2nd".

Also, possibly, add an option to display the separator line even if no stations 
are decoded.

73 de KM8V

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

Re: [wsjt-devel] Feature Suggestion

[Paul Randall]

Another feature suggestion.

Would it be possible to add the capability for WSJTx to report to a second 
external program in addition to PSKreporter? I have an Android app that lets me 
keep tabs on what the radio is seeing whilst I am around the house or garden 
but to use it means I must disconnect from PSKreporter. It would be great if 
both were connected.  I monitor VHF activity and a close eye is required to 
catch brief openings however I also have a life so cannot sit in front of the 
radio all the time.

Thanks for all the work, looking forward to the new release.
73 Paul




Sent from my Samsung Galaxy smartphone.



 Original message 
From: Jon Anhold 
Date: 30/05/2020 16:26 (GMT+00:00)
To: WSJT software development 
Subject: [wsjt-devel] Feature Suggestion

Add some indicator to the separator line in the band activity window to show if 
it was "even/1st" or "odd/2nd".

Also, possibly, add an option to display the separator line even if no stations 
are decoded.

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

Re: [wsjt-devel] Seeing calls from myself

[Paul Randall]

Yes, I have experienced receiving my own cq calls decoded as though they were 
another station, complete with waterfall trace. Every instance, 100%  
associated with watchdog timeout, which occurs part way through a TX period.

I appreciate a watchdog timeout needs to be far removed from normal 
communication activity of WSJT but surely, with such a time based system, there 
should be a way to synchronise start of watchdog to start of the communication 
TX sequence, so that a watchdog shutdown occurs at the end of a RX period, not 
part way through a TX period.

Thanks for all the work guys, looking forward to upgrading to the new release.
Paul

Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10

From: Christoph Berg<mailto:m...@debian.org>
Sent: 26 May 2020 17:07
To: WSJT software development<mailto:wsjt-devel@lists.sourceforge.net>
Subject: Re: [wsjt-devel] Seeing calls from myself

Re: Chris Sullivan
> I've seen this a couple of times before on RC1, Windows 10-64.
>
> I responded to a CQ from VE3VN (Hold TX set, also auto seq & call 1st). Just
> after my transmission began I halted tx because I noticed he had called CQ
> WC, which I guess isn't me. Then I saw, in red in the band activity window,
> VE3VN VE3NRT FN03. I think WSJT-X must have received my signal through from
> the monitor (K3 here) while I was transmitting.

I've seen it a few times during the final cycle when the tx timeout
timer was hitting. It's not reproducible, though.

Is there a way to run wsjtx in full-duplex mode? That would be awesome
for QO-100 satellite operation where operators are actually supposed
to be listening to their own signals.

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

Re: [wsjt-devel] calling CQ every 2nd round

[Paul Kube]

On Mon, May 25, 2020 at 3:33 PM Rik Strobbe  wrote:

>
> For now I do the manually (via the enable TX button), but if others find
> this useful as well it might be considered to add it as an option in WSJT-X?
>

In my opinion, this should be the default, for FT8 and FT4.

73, Paul K6PO

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

[Paul Bramscher]

Hi Claude,

Thanks, I'll take a look at that script.  Of course I locally keep and
backup all logs that I've ever generated.  If this tool automates these
kinds of merging issues, I'll certainly experiment with it.

73, KD0KZE / Paul

On 5/22/2020 1:06 PM, Claude Frantz wrote:
> On 5/22/20 7:22 PM, Paul Bramscher wrote:
> 
> Hi Paul & all,
> 
>> What I've done is maintain two local logs: WSJT-X's native log and XLog
>> for everything else.  fldigi will auto-ingest into XLog, and I can
>> easily enough create Phone and other entries manually in XLog.
> 
> Please note that fldigi is able to change entries in its log.
> Unfortunately such updates are not passed to Xlog.
> 
>> I periodically use TQSL to upload WSJT-X contacts to Logbook of the
>> World.  To make this more efficient, I examine my past activity date on
>> LoTW's interface and use my last upload date as the cut-off date for new
>> QSO's to upload.
> 
>> I also upload XLog logs there, so LoTW is the place where they all get
>> combined.  Then I occasionally export those and upload them into QRZ for
>> good measure.
> 
> adifmerg is an excellent program to merge ADIF log files.
> 
> Unfortunately, LoTW is not a good place to combine logs files because
> only a limited number of ADIF fields are maintained. Please remember
> that paper QSL exist too and many other things which are ignored by
> LoTW. Finally, only a locally maintained ADIF file can help to maintain
> all the information. And adifmerg can help you to do it. This is the way
> I'm going. With the optional addition of few user defined fields, such a
> locally stored ADIF file can be the base from which one an appropriate
> program can automatically generate detailed paper QSL cards. Of course,
> received QSL cards have to be mentioned in the appropriate records of
> the ADIF file.
> 
> 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] exporting from adi

[Paul Bramscher]

What I've done is maintain two local logs: WSJT-X's native log and XLog
for everything else.  fldigi will auto-ingest into XLog, and I can
easily enough create Phone and other entries manually in XLog.

I periodically use TQSL to upload WSJT-X contacts to Logbook of the
World.  To make this more efficient, I examine my past activity date on
LoTW's interface and use my last upload date as the cut-off date for new
QSO's to upload.

I also upload XLog logs there, so LoTW is the place where they all get
combined.  Then I occasionally export those and upload them into QRZ for
good measure.

73, KD0KZE / Paul

On 5/20/2020 8:17 PM, Michelle Sack via wsjt-devel wrote:
> 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

Re: [wsjt-devel] Clicking on RR73 produced wrong TX response msg

[Paul Kube]

On Wed, May 20, 2020 at 2:05 PM Gary McDuffie  wrote:

>
> If you call letting him know that you got his acknowledgement of your
> report a courtesy, I guess so.  I call it a necessity in order to allow him
> to move on.  If I don’t send the 73, it means I didn’t get his RR73.  If he
> doesn’t finish, he isn’t in the log.
>

If you didn't get his RR73 (Tx4), certainly the thing to do is to resend
your report (Tx3), no?

On the other hand, if you did get his RR73, you can consider the QSO
completed, and respond in whatever way you want. At least, that's the view
I've come to after using the FT* modes since they were invented. Was it
"really" a QSO? I'll let LoTW or the contest logcheck software sort it out.

A special case is when I see a station I've worked sending RR73 again. That
shows they're probably expecting a 73 from me and didn't get it. So in that
case I'll send 73 (Tx5, which is totally customizable, there's even a TX
Macros page in Settings that lets you create a whole library of them). But
that almost never happens anymore.

73, Paul K6PO


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

[Paul Kube]

An oddity related to this is that checking "Allow Tx Frequency Changes
While Transmitting" is required not just for Tx, but also for Rx frequency
changes while transmitting. When not checked, when transmitting, both Tx
and Rx spinners are grayed out, and left-clicking on the waterfall does
nothing. A small thing, but was there in 2.1 also.

Now 2.2.0-rc1, Windows 10 Pro 64 bit, IC-7300 via USB connection.

73, Paul K6PO



On Mon, May 18, 2020 at 9:21 PM Stephen VK3SIR  wrote:

> 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 mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X 2.2.0-rc1

[Paul Kube]

Hello Bill,


> Here is a little more data on this.
>
> Here's a screenshot showing the issue. KG8DH is transmitting in
> even periods. Red arrows show where his signal is decoded but grouped with
> the previous odd period. This I guess might just be an issue of the "80m"
> separator not being inserted before his decode is displayed. Green arrow
> shows one of his decodes correctly displayed. His signal is stronger in
> that period, and I suspect is was decoded in an earlier pass than the
> problem cases
> [image: decode07.PNG]
>
> (I think I said in an earlier email that this issue involves incorrect
> timestamps, but shown here the timestamps are correct, it's just the decode
> pane's grouping that's confused.)
>
> Another thing. Here's a screenshot of the decodes replayed from the saved
> wav files. Now KG8DH's 093130 decode is grouped correctly (first green
> arrow), but interestingly his 093230 transmission doesn't appear at all.
> Are the new 2.2 decode passes being applied during wav file replays?
>
> [image: decode07-replay.PNG]
>
> I hope this helps in some way. Those 8 wav files are too big to email to
> you via this mailing list, if you'd like them let me know how to get them
> to you.
>
> 73, Paul K6PO
>
>
> On Thu, May 14, 2020 at 3:46 AM Bill Somerville 
> wrote:
>
>> HI Paul,
>>
>> thanks for that clarification, we too are finding this issue hard to
>> reproduce so be patient, we will sort it out eventually.
>>
>> 73
>> Bill
>> G4WJS.
>>
>> On 14/05/2020 4:09, Paul Kube wrote:
>>
>> Hi Bill,
>>
>> Yes this is with v2.2.0-rc1, Win 10 64 bit.
>>
>> As I recall, it only occurred when there was just one late decode, and no
>> decodes in the following period. It happened several times in quick
>> succession, but I failed to get a screenshot or any more clues; and I
>> haven't seen it again. I apologize for such a sketchy bug report. I'll try
>> to reproduce it and let you know.
>>
>> Meanwhile, thanks for all your hard work on this. I'm liking this new
>> release a lot.
>>
>> 73, Paul K6PO
>>
>> On Tue, May 12, 2020 at 6:11 PM Bill Somerville 
>> wrote:
>>
>>> On 13/05/2020 02:01, Paul Kube wrote:
>>>
>>> On Tue, May 12, 2020 at 1:29 PM Bill Somerville 
>>> wrote:
>>>
>>>>   Most users will see ... more decodes overall with the last few maybe
>>>> only printing some time into the following period.
>>>>
>>>> On this point: When a signal is sent in a period, but decoded in the
>>> next period, I have seen the transmission appear with the "wrong" timestamp
>>> in the Band Activity pane.
>>>
>>> 73, Paul K6PO
>>>
>>> Paul,
>>>
>>> are you observing this behaviour in WSJT-X v2.2.0 RC1, or in a prior
>>> version?
>>>
>>
>> ___
>> 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 2.2.0-rc1

[Paul Kube]

Hi Bill,

Yes this is with v2.2.0-rc1, Win 10 64 bit.

As I recall, it only occurred when there was just one late decode, and no
decodes in the following period. It happened several times in quick
succession, but I failed to get a screenshot or any more clues; and I
haven't seen it again. I apologize for such a sketchy bug report. I'll try
to reproduce it and let you know.

Meanwhile, thanks for all your hard work on this. I'm liking this new
release a lot.

73, Paul K6PO

On Tue, May 12, 2020 at 6:11 PM Bill Somerville 
wrote:

> On 13/05/2020 02:01, Paul Kube wrote:
>
> On Tue, May 12, 2020 at 1:29 PM Bill Somerville 
> wrote:
>
>>   Most users will see ... more decodes overall with the last few maybe
>> only printing some time into the following period.
>>
>> On this point: When a signal is sent in a period, but decoded in the next
> period, I have seen the transmission appear with the "wrong" timestamp in
> the Band Activity pane.
>
> 73, Paul K6PO
>
> Paul,
>
> are you observing this behaviour in WSJT-X v2.2.0 RC1, or in a prior
> version?
>
> 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] WSJT-X 2.2.0-rc1

[Paul Kube]

On Tue, May 12, 2020 at 1:29 PM Bill Somerville 
wrote:

>   Most users will see ... more decodes overall with the last few maybe
> only printing some time into the following period.
>
> On this point: When a signal is sent in a period, but decoded in the next
period, I have seen the transmission appear with the "wrong" timestamp in
the Band Activity pane.

73, Paul K6PO


___
> 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] Killing the TX stream

[Paul Kube]

On Fri, Apr 3, 2020 at 1:42 PM Black Michael via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> You should not be selecting "default" for WSJT-X.  Select your rig sound
> card instead and that problem will go away.
>

One would think that would be true. But one would be wrong.

I've reported this before, and so have several others. Windows 10 sound
configuration is such a giant kludge at this point that it is obscure
whether it's a problem on WSJT-X's side or not, but it is a problem. To
wit: In WSJT-X v2.1.2, Settings Audio Soundcard, select the proper USB
codec for both Input and Output. In Windows 10, Settings Sound App volume
and device preferences, select the same USB codec for both Output and Input
for WSJT-X. Now make some change to your computer's sound devices. For
example, unplug and replug a headphone. Should have no effect on WSJT-X,
right? But WSJT-X's output is now disabled, and it needs to be restarted.


> And..your rig sound device should not be the default...when it is all your
> computer boops and beeps will go out your rig.
>

That, on the other hand is easy to fix. Mute System Sounds on that device,
and that problem will go away.

73, Paul K6PO


> On Friday, April 3, 2020, 03:30:51 PM CDT, Al  wrote:
>
>
> I don't know how much of this is windows vs WSJT-X...
>
> Assuming the WSJT-X has a properly configured output sound device and
> verified working on TX...
>
> 1) If the default windows sound device is changed after WSJT-X is started
> then there is no TX stream on TX until A) WSJT-X is restarted or B) a
> different output sound device is selected in WSJT-X
>
> 2) If the default sound device is changed while WSJT-X is transmitting the
> current TX stream will complete but there will be no TX stream on the
> following TX cycles.
>
> Given that Windows feels free to change default sound devices on its own (
> plugging/unplugging a speaker or adding removing a usb/hdmi sound device )
> ..
>
> AL, K0VM
> ___
> 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] WSJT-X+OmniRig+IC-7300 : DATA mode not set for VFO-B

[Paul Kube]

One workaround for this is to use WSJT-X's "Fake it" instead of "Rig" for
split operation. "Fake it" uses only one VFO, so it doesn't matter what the
other VFO's mode is.

"Fake it" works very well with the IC-7300; I haven't found any reason not
to use it.

73, Paul K6PO

On Wed, Mar 25, 2020 at 11:39 AM Zeev Stadler 
wrote:

> Hello All,
>
> My configuration is:
>
>- WSJT-X 2.1.2 on Windows 10 Home, "Split Operation"="Rig",
>"Mode"="Data/Pkt"
>- Icom IC-7300
>- OmniRig 1.19 with "IC-7300-DATA" rig profile
>
> I recently noticed that sometimes there is no output power when WSJT-X
> puts the rig in transmit mode.
> When starting WSJT-X after operating in "Phone" SSB mode, VFO-B remains in
> "USB" mode rather than use "USB-D" (data) mode.
> If I manually change VFO-B to "USB-D" and continue to use WSJT-X,
> transmission works as expected.
>
> Attached is and Omnirig log file saved from this scenario:
>
>- Set VFO-B to "USB" mode, turn-off split mode
>- Execute WSJT-X
>- Click "Tune"
>- Click "Tune" again
>- Exit
>
> Best regards and 73,
> Zeev
> 4X5ZS
> ___
> 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] FT4 and FT8 Contesting

[Paul Randall]

Reino, Haha Yes, but no, but yes, but no ...
For QSO purposes, I think RRR and RR73 are identical, reception of either means 
QSO complete, LOG THE QSO.

R R R 73 de Paul G3NJV

Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10


From: Reino Talarmo 
Sent: Thursday, February 27, 2020 9:13:08 PM
To: 'WSJT software development' 
Subject: Re: [wsjt-devel] FT4 and FT8 Contesting


Hi Paul

I agree your comment on RRR or RR73 being confirmation of reception ”R” ack.
There is a minor difference though RR73 is “I am fully happy and don’t expect 
any further response from you”, while RRR is usually taken to mean “I received 
you confirmation, but I want to be sure that you received my confirmation as 
well (before logging this QSO)” and then 73 from you is that confirmation of 
confirmation. Some even want a 73 to that 73 as confirmation of the 
confirmation of the confirmation!

73, Reino oh3mA



From: Paul Randall [mailto:paulfrand...@hotmail.com]
Sent: 27. helmikuuta 2020 22:46
To: k...@arrl.net; WSJT software development 
Subject: Re: [wsjt-devel] FT4 and FT8 Contesting



”..And when one QSO partner repeats either R-10 or RRR or RR73, it is
his indication that he didn't copy the ack,”



Surely that statement is wrong.

You only send RRR or RR73 to CONFIRM receiving the other stations “R” ack, 
never to indicate no copy.

Sending R -10 means you copied the other stations report, you keep sending it 
until you get RRR or RR73. Once you get it, that’s the end of the QSO. Nothing 
else required. If you don’t get it, it isn’t a QSO.

I think the WSJT message exchange protocol is based on decades old moonbounce 
and MS procedures where 73 is simply a luxury that often isn’t affordable.



Best regards Paul



Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10





From: Jim Brown mailto:k...@audiosystemsgroup.com>>
Sent: Thursday, February 27, 2020 8:25:10 PM
To: wsjt-devel@lists.sourceforge.net<mailto:wsjt-devel@lists.sourceforge.net> 
mailto:wsjt-devel@lists.sourceforge.net>>
Subject: Re: [wsjt-devel] FT4 and FT8 Contesting



On 2/27/2020 7:56 AM, Ron WV4P wrote:
> RR73 is not part of the exchange.

Wrong. The definition of a QSO is the exchange of callsign and one piece
of info by each party, and the acknowledgement of receipt by by each.
Each station must receive acknowledgement of the other's exchange. If
that "information" is the signal report, The first ack is the R in R-10,
the second, by the other station, is RRR or RR73. What is NOT required
is 73. But it IS required for each station to have copied the other's
ack. And when one QSO partner repeats either R-10 or RRR or RR73, it is
his indication that he didn't copy the ack, and the other station should
repeat the ack.

73, Jim K9YC




___
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] FT4 and FT8 Contesting

[Paul Randall]

”..And when one QSO partner repeats either R-10 or RRR or RR73, it is
his indication that he didn't copy the ack,”

Surely that statement is wrong.
You only send RRR or RR73 to CONFIRM receiving the other stations “R” ack, 
never to indicate no copy.
Sending R -10 means you copied the other stations report, you keep sending it 
until you get RRR or RR73. Once you get it, that’s the end of the QSO. Nothing 
else required. If you don’t get it, it isn’t a QSO.
I think the WSJT message exchange protocol is based on decades old moonbounce 
and MS procedures where 73 is simply a luxury that often isn’t affordable.

Best regards Paul

Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10


From: Jim Brown 
Sent: Thursday, February 27, 2020 8:25:10 PM
To: wsjt-devel@lists.sourceforge.net 
Subject: Re: [wsjt-devel] FT4 and FT8 Contesting

On 2/27/2020 7:56 AM, Ron WV4P wrote:
> RR73 is not part of the exchange.

Wrong. The definition of a QSO is the exchange of callsign and one piece
of info by each party, and the acknowledgement of receipt by by each.
Each station must receive acknowledgement of the other's exchange. If
that "information" is the signal report, The first ack is the R in R-10,
the second, by the other station, is RRR or RR73. What is NOT required
is 73. But it IS required for each station to have copied the other's
ack. And when one QSO partner repeats either R-10 or RRR or RR73, it is
his indication that he didn't copy the ack, and the other station should
repeat the ack.

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

Re: [wsjt-devel] How to set up for WSJT-X development?

[Paul Kube]

Hi Bill --



On Mon, Jan 20, 2020 at 8:53 AM Bill Somerville 
wrote:

> You could use the tarball as a starting point for casual development but
> cloning the official public git repository is best for anything other than
> the simplest of development.
>

Sounds good to me, I'd like to get that working.

> The errors you show above are due to you not having a recent version of
> Hamlib built for use with WSJT-X, the versions of Hamlib in most (probably
> all) Linux repositiories are too old. You should be able to clone the
> official Hamlib git repo and build the master branch for use with WSJT-X.
> You should configure the Hamlib build to build a static library and its
> probably best to install that locally in your own directories using the
> --prefix option of configure. Once you have a locally installed Hamlib you
> can tell the WSJT-X CMake build script where to find it using the
> configuration variable CMAKE_PREFIX_PATH which should include the root
> directory of your locally install Hamlib package.
>
Bill, I did all that. As I said, I followed your
https://sourceforge.net/p/wsjt/wsjtx/ci/master/tree/INSTALL. To wit:

$ mkdir ~/hamlib-prefix
> $ cd ~/hamlib-prefix
> $ git clone git://git.code.sf.net/u/bsomervi/hamlib src
> $ cd src
> $ git checkout integration
> $ ./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
> $ 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 ../src
> $ cmake --build .
> $ cmake --build . --target install


The next to last line, cmake --build ., dies with those unresolved symbols
in HamlibTransceiver.cpp. I've taken care not to have any other hamlib
packages installed on this machine. So it seems to me that something
in  git://git.code.sf.net/u/bsomervi/hamlib or  git://
git.code.sf.net/p/wsjt/wsjtx is wrong.

73, Paul K6PO
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] How to set up for WSJT-X development?

[Paul Kube]

A simple question: Suppose I want to do a little WSJT-X development...
experimenting with new features, bug fixing, submitting the occasional
patch. I'll be coding on Linux, but will want to compile for Windows as
well as Linux for testing. (Not particularly interested in building my own
source tarball.)  What's the best way to do this now?

I can build from
https://sourceforge.net/projects/wsjt/files/wsjtx-2.1.2/wsjtx-2.1.2.tgz
<https://sourceforge.net/projects/wsjt/files/wsjtx-2.1.2/wsjtx-2.1.2.tgz/download>
just
fine; but I've seen email saying the repository has moved to git, so I'm
not sure that tarball is up to date. On the other hand, following the
git-centric instructions at
https://sourceforge.net/p/wsjt/wsjtx/ci/master/tree/INSTALL, the build dies
with errors like:

wsjtx-prefix/src/HamlibTransceiver.cpp:590:66: error:
‘RIG_PASSBAND_NOCHANGE’ was not declared in this scope
   rig_set_mode (rig_.data (), RIG_VFO_CURR, dummy_mode_,
RIG_PASSBAND_NOCHANGE);

wsjtx-prefix/src/HamlibTransceiver.cpp:811:32: error:
‘rig_set_split_freq_mode’ was not declared in this scope
   error_check (rig_set_split_freq_mode (rig_.data (),
RIG_VFO_CURR, tx, new_mode, RIG_PASSBAND_NOCHANGE), tr ("setting split TX
frequency and mode"));

[BTW: Attempting to answer my question with a web search turns up the
promising looking WSJT Developers Guide
https://physics.princeton.edu/pulsar/k1jt/wsjtx-doc/dev-guide-main.html,
but that begins with a notice that it's obsolete, and to use
https://sourceforge.net/projects/jtsdk/ instead. OK fine, I go there, and
from there to https://sourceforge.net/projects/jtsdk/files/linux/ for the
Linux version, which page tells me the repository has been moved to github
at https://github.com/KI7MT/jtsdk-nix. There I see the announcement that
"This project is no longer under active development", "Those wishing to use
JTSDK should follow the JTSDK .Net Core cross-patform project instead."
Right, OK, but the page https://github.com/KI7MT/jtsdk-tools for that
project only says "Linux - Coming Soon!" A dead end.]

Thanks for any help,

73, Paul K6PO
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] RTTY

[Paul Kube]

On Fri, Jan 17, 2020 at 8:21 AM Frank Kirschner  wrote:

> All I suggested was that improving the software discriminator in a RTTY
> program might produce a useful improvement in noise performance.
>

Frank, in my opinion you are lobbying the wrong developers here. If there
are ideas in WSJT-X that could significantly improve 170 Hz 45.45 RTTY
decoding, it's the RTTY decoder developers who are in the best position to
implement them. WSJT-X code is GPL'd; point the RTTY folks to the relevant
parts and tell them to have at it.


> And if somebody wrote such a program, it would be useful to integrate it
> to some extent with WSJT-X to make switching modes easier.
>

Now that just seems wrong-headed. There is nothing in WSJT-X that
recommends itself as a framework for a conversational mode like RTTY.

73, Paul K6PO

On Fri, Jan 17, 2020 at 8:21 AM Frank Kirschner  wrote:

>
>
> On Wed, Jan 15, 2020 at 1:44 PM David Gilbert 
> wrote:
>
>>
>> You're assuming that the algorithms used in WSJT-X would be adaptable to
>> RTTY to give better performance than what is already out there.
>>
>
> It is certainly true that the algorithms used in WSLT-X for discriminating
> frequencies could be adapted for RTTY. Why wouldn't they? All they do is
> discriminate what frequency is being received. I'm not sure that the newest
> RTTY programs don't already use this same algorithm, but the noise
> performance of the RTTY programs I've tried so far has been pretty poor,
> and improving the algorithm used would ameliorate that.
>
>   I don't think there is any evidence of that being the case, given the
>> very rigid constraints that every single WSJT-X mode requires.
>>
>
> That has nothing to do with it. At some point in the flow of the both RTTY
> programs and WSJT-X, a decision is made: was it this frequency or that
> frequency? There's an algorithm that does this. I suspect that the writers
> of WSJT-X have used the best algorithm that would run on computers
> available, This algorithm, used in a RTTY program, would improve the noise
> performance of decoding. The integration time available for RTTY is much
> less than modes like FT8, and FT8 uses redundancies and limited code words,
> but they both need to discriminate between frequencies. The work that
> WSJT-X does over and above frequency discriminating has nothing to do with
> RTTY, and it wouldn't be in a RTTY program.
>
>
>> The appeal of RTTY for almost everyone (compared to FT8 or FT4) is its
>> free form nature.  Just go read the current dialog on the CQ-Contesting
>> reflector to see what I mean.
>>
>
> PSK-31 is much better for free-form communications than RTTY. It has
> better noise performance and can copy through fades better. I believe most
> people who operate in RTTY contests don't use a free-form mode anyway. They
> have the exchange in macros, including the QSO counter, and they never
> touch the keyboard. If there are many stations on, retyping the same info
> for every QSO would be a waste of valuable operating time. All the RTTY
> programs I've tried have macros and some sort of contesting mode.
>
>
>> If you try to turn RTTY into a 2-tone version of FT8 neither user base
>> will ever use it because it doesn't have the advantages of either mode.
>>
>
> I don't know why people keep saying that. I never suggested a change to
> RTTY. All I suggested was that improving the software discriminator in a
> RTTY program might produce a useful improvement in noise performance. And
> if somebody wrote such a program, it would be useful to integrate it to
> some extent with WSJT-X to make switching modes easier.
>
>>
>> Secondly, WSJT-X is simply a very bad contest user interface.  It was
>> designed for weak signal DXing and it does a very good job for that, but it
>> is terrible for contesting.  Again, check out the CW-Contesting reflector
>> (you can just read the archives if you aren't subscribed) to see more
>> comments on that point ... most of which have been from me.
>>
>
> No one suggested using the WSJT-X UI for a RTTY program. The discriminator
> and the UI are independent of one another. Someone could create a program
> with the same discriminator algorithm that WSJT-X uses, and give it a very
> contest-ready UI. The pace of FT8 contesting is much slower than that of CW
> or RTTY. It's very leisurely, and optimizing the UI for contesting isn't
> necessary. WSJT-X does have a number of user conveniences, like automatic
> logging, so clearly some thought has been put into making it a practical
> program, as opposed to just a test program for a lab.
>
>>
>> I really don't think you understand what you keep proposing here,
>>
>
> I ass

Re: [wsjt-devel] Not a Bug, But a PITA

[Paul Kube]

>  WSJT-X's tendency to change frequencies when you switch in or out of
contest, fox / hound mode, etc is annoying and unexpected.

Fortunately the frequency is prominently displayed in the WSJT-X window
(and on the front of my radio). I've learned to always check it after any
mode or band change, and adjust as necessary. Not hard to do, just hard to
remember to do at first.

I think Jim K9YC was complaining about a slightly different thing though:
WSJT-X decodes when displayed are only tagged with the band and audio
offset, not the exact base VFO frequency, and that would be useful
sometimes.

73, Paul K6PO


On Sat, Dec 21, 2019 at 2:17 PM Jon Anhold  wrote:

> I agree that WSJT-X's tendency to change frequencies when you switch in or
> out of contest, fox / hound mode, etc is annoying and unexpected.
>
> On Sat, Dec 21, 2019 at 3:50 PM Jim Brown 
> wrote:
>
>> This morning, I fired up to work AG6EE on 6M with MSK144 on an
>> expedition to a couple of rare grids in the desert along the US/Mexico
>> border. He was on 50.265 to stay out of the way of casual QRM, and I
>> worked him in one of those grids yesterday. This morning, online chat
>> told me he was now using NA VHF Contest mode, so I set that and returned
>> to monitoring. When I did, WSJT-X moved me to 50.260. I had a bunch of
>> decodes on the screen from before I had switched to Contest mode, and I
>> wasn't certain whether I had been on .260 or .265 when I decoded them.
>> MUCH wasted time figuring that out. PITA
>>
>> 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

Re: [wsjt-devel] USB-D on VFOB

[Paul Kube]

On Tue, Dec 17, 2019 at 2:53 PM Black Michael via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> v2.1.2
>
> We're getting an inconsistent and somewhat hard to reproduce situation
> where on an IC-7300 VFOB is not getting set to USB-D.
>

I have seen this also. My setup runs WSJT-X through N1MM+ using DX Lab
Commander radio setting, then through Win4IcomSuite to the IC-7300, and
tracking it down the culprit in that chain was taking time, so I just
changed WSJT-X to use "Fake It" instead of Split; problem solved for me.
But I could go back to Split and collect some data if it would help.

73, Paul K6PO


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

Re: [wsjt-devel] Problem with radio's audio input

[Paul Kube]

On Mon, Dec 2, 2019 at 4:34 AM Black Michael via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> Audio dropout like this is usually caused by the USB audio device
> disconnecting.
> And that is usually case by RFI.
>

I had a dropout problem where WSJT-X audio output would occasionally switch
from the desired "Speakers (5- USB Audio CODEC)" to "Headphones (High
Definition Audio Device)" when I had headphones plugged in to my Windows 10
desktop machine. This of course caused loss of transmitter modulation. Kind
of a mystery, since I had only the USB codec selected as output for WSJT-X
both in WSJT-X's settings Audio tab and in Windows sound settings; I don't
know why Windows should ever take it upon itself to re-route that.

I tried ferrites on the headphone cable to fix this. Ultimately lots of
ferrites, including 10 turns through a 3/4" I.D. mix 31. (I already have
chokes on everything else, and no RFI-like problems except for this.) It
didn't help! But unplugging the headphones does eliminate the problem, so I
now just forego watching Netflix while working FT8 :).

Anyway, if you're having problems with TX audio dropout with Windows 10,
try popping up the Volume Mixer to see which output devices are connected
to WSJT-X; maybe the operating system has switched to using something other
than the one you want.

73, Paul K6PO



On Mon, Dec 2, 2019 at 4:34 AM Black Michael via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> Audio dropout like this is usually caused by the USB audio device
> disconnecting.
> And that is usually case by RFI.  Chokes on USB cables (and all other
> cables) usually solves the problem.
> Ensure your ethernet cables are shielded too.  Newer CAT 7 or CAT 8 cables
> are already shielded.  And ground your ethernet hub too (most don't have a
> built-in ground)
> I even put chokes on all my power lines going into the breaker box to
> reduce what's riding on the power.
>
> And, if you have an outside round rod (like many I have helped) that is
> not tied to the house ground either stop using it (and use the house
> ground) or tie the outside rod to the house ground properly.  That has also
> solved many RFI problems.
>
> de Mike W9MDB
>
>
>
>
> On Monday, December 2, 2019, 05:26:25 AM CST, Claude Frantz <
> claude.fra...@bayern-mail.de> wrote:
>
>
> On 12/1/19 10:46 PM, Frederic Beaulieu wrote:
>
> Hi Frederic,
>
> > I start to notice on my IC-7300's audio scope that occasionnaly, no
> > audio was sent to the radio. The problem seems to get worse (more
> > frequent) and now I'm seeing a kind of noise at the beginning of many
> > of my transmission. Anyone knows how I could verify if it is a
> > problem with my radio, the sound card (which is embedded in the radio
> > I think) or the WSJT-X software?
> This problem of occasional no audio output has been reported here by
> various users, included myself. I have encountered it while running with
> Windows XP and using Linux, on different hardware. I cannot remember
> that an valuable diagnostic has been reported about the reasons of these
> sporadic recurrences.
>
> 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 mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Problem with radio's audio input

[Paul Randall]

It may be unrelated but a station very local to me on 2m transmits a huge 
wideband splat of noise at the start of his FT8 transmissions. I think what I 
am hearing is all the noise in his shack, the fan in his qro linear etc, all 
picked up by his microphone which presumably is still plugged in. With speech 
compression this can make a lot of power before the FT8 tones start and 
suppress it.

Paul G3NJV


From: Reino Talarmo 
Sent: 02 December 2019 14:40
To: 'WSJT software development' 
Subject: Re: [wsjt-devel] Problem with radio's audio input

The original mail stated:
"I'm seeing a kind of noise at the beginning of many of my transmission.
Anyone knows how I could verify if it is a problem with my radio, the sound
card (which is embedded in the radio I think) or the WSJT-X software?"
The video shows some kind of instability, perhaps a low frequency pulse
train generating a wide spectrum. Perhaps audio actually goes to the radio,
but causes some unwanted transient before normal operation. It even could be
an ALC issue, if the audio level is too high hitting ALC. I would not rule
out RF problems either.
73, Reino oh3mA



___
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] Callsign lockout

[Paul Randall]

When calling CQ dx on 80m at dusk (my loop is regularly heard in VK) there are 
local EU stations that give me just a single call then disappear, presumably 
just to be a PITA by triggering the "call 1st" feature on my rig. My answer is 
to switch it off. It means I have to sit in front of the radio and actually 
operate it but that is no different from any other mode.  It is easy to get 
reliant on the automation. The downside of my manual system means if i do 
respond to a caller my reaction time does usually mean a missed 30 second cycle 
and that isn't like other modes.
73 Paul.



Sent from my Samsung Galaxy smartphone.



 Original message 
From: Ron WV4P 
Date: 01/12/2019 00:18 (GMT+00:00)
To: Black Michael , WSJT software development 

Subject: Re: [wsjt-devel] Callsign lockout

This function has Desperately been needed for a long time. Ron, WV4P

On Sat, Nov 30, 2019, 4:21 PM Black Michael via wsjt-devel 
mailto:wsjt-devel@lists.sourceforge.net>> 
wrote:
Was just communicating with an Alaskan operator who was complaining about 
operators calling him in the blind.  And when you have Call First checked the 
blind callers become a PITA.

What is needed is the ability to block a callsign for an adjustable time out 
period defaulting perhaps to 15 minutes. (don't even show them in the band 
activity).  Maybe it could be done with a ctrl-click on TX 1 or some other 
better method.  Turn off Enable, clear the DXCall box and then the next valid 
decode would be able to start up.

de Mike W9MDB


___
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] WSJT-X 2.1.1 GA release

[Paul Bramscher]

Bummer about Icom bug.  For what it's worth, I compiled it fine just now on 
Debian Linux 10.x + Kenwood TS-590, split mode.  No additional dependencies 
were needed since 2.1.0.  Haven't tested much yet, but haven't seen any issues 
so far.

73, KD0KZE / Paul

> On November 25, 2019 at 6:15 PM Bill Somerville  wrote:
> 
> 
> On 25/11/2019 18:40, Joe Taylor wrote:
> > The WSJT Development Group is pleased to announce the general 
> > availability (GA) release of WSJT-X Version 2.1.1. 
> 
> Hi all WSJT-X users,
> 
> thanks for the issue reports from Icom users who have not been able to 
> use WSJT_X v2.1.1. We will get a fixed version out ASAP.
> 
> If you are experiencing an issue with a rig control error:
> 
> "Hamlib error: Command rejected by the rig while getting current 
> frequency."
> 
> with your Icom rig then for now you should revert to WSJT-X v2.1.0 
> (v2.0.1 for macOS Catalina users) which can be found here:
> 
> https://sourceforge.net/projects/wsjt/files/wsjtx-2.1.0/
> 
> (https://sourceforge.net/projects/wsjt/files/wsjtx-2.0.1/)
> 
> Apologies for the inconvenience
> 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] Fwd: 40 Meter Power USB-D issue

[Paul Randall]

Anyone who experiences peculiar behaviour from their station on some 
band/frequency/antenna/rig upon activating the transmitter should firstly 
perform this most basic test.

STEP 1A1A1 - Try to reproduce the problem with the transmitter directly 
connected to a dummy load. This test should virtually eliminate the possibility 
that simple EMI is the culprit (which it is in most cases).

Having suffered the problem myself, I know first hand that the above is 
excellent advice.

Kind regards and good DX to all,
Paul G3NJV




From: Jim Jennings 
Sent: 20 November 2019 16:55
To: WSJT software development 
Subject: Re: [wsjt-devel] Fwd: 40 Meter Power USB-D issue

The symptoms suggest to me RF getting into a USB cable between computer and the 
rig’s CI-V USB port.  My cousin had a similar situation with his FTDX-3000 on 
40 and 30M FT8, where the rig would abruptly quit transmitting if he tried to 
exceed about 25 watts.  The problem was solved by winding some of the “spare” 
length of the computer to CAT USB cable on a ferrite toroid (FT240-43 used in 
this case).  He can now increase to full output power of the rig (100W) without 
anything “flinching.”  Just a thought.  73,

Jim, W7XZ

From: Christopher Diederich via wsjt-devel
Sent: Wednesday, November 20, 2019 05:01
To: Paul Randall ; WSJT software development ; 
wsjt-devel-ow...@lists.sourceforge.net
Cc: Christopher Diederich
Subject: Re: [wsjt-devel] Fwd: 40 Meter Power USB-D issue

I will run it into a dummy load to check though. Thanks for the suggestion.

Chris

Get Outlook for iOS<https://aka.ms/o0ukef>



On Wed, Nov 20, 2019 at 7:53 AM -0500, "Christopher Diederich" 
 wrote:

I have not tested with a dummy load.  Other digital modes and phone don’t have 
the same issue, and SWR is 2.5:1 into OCF 80 meter dipole, which is tuned 
easily with my LDG.

Get Outlook for iOS<https://aka.ms/o0ukef>



On Wed, Nov 20, 2019 at 5:12 AM -0500, "Paul Randall" 
 wrote:

Does it do it when the rig is running into a dummy load?



Sent from my Samsung Galaxy smartphone.


 Original message 
From: Christopher Diederich via wsjt-devel 
Date: 20/11/2019 01:59 (GMT+00:00)
To: wsjt-devel@lists.sourceforge.net, wsjt-devel-ow...@lists.sourceforge.net
Cc: Christopher Diederich 
Subject: [wsjt-devel] Fwd: 40 Meter Power USB-D issue


Get Outlook for iOS<https://aka.ms/o0ukef>

From: Christopher Diederich 
Sent: Tuesday, November 19, 2019 8:26 PM
To: wsjtgr...@yahoogroups.com
Subject: 40 Meter Power USB-D issue

Good evening,

I am experiencing a recent issue that has arisen where my IC-7300 is 
transmitting on reduced power on 40 meters using FT8 with WSJT-X.  Other 
digital modes and phone work fine, and no other bands have the low power issue. 
 Also, the rig occasionally changes from USB-D to USB when keying. Any ideas?

IC-7300
Win 10 Pro 64 bit
HRD version 6.7.0.244
WSJT-X version 2.1.0

73
Chris Diederich K1LDO






___
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] Fwd: 40 Meter Power USB-D issue

[Paul Randall]

Does it do it when the rig is running into a dummy load?



Sent from my Samsung Galaxy smartphone.


 Original message 
From: Christopher Diederich via wsjt-devel 
Date: 20/11/2019 01:59 (GMT+00:00)
To: wsjt-devel@lists.sourceforge.net, wsjt-devel-ow...@lists.sourceforge.net
Cc: Christopher Diederich 
Subject: [wsjt-devel] Fwd: 40 Meter Power USB-D issue


Get Outlook for iOS

From: Christopher Diederich 
Sent: Tuesday, November 19, 2019 8:26 PM
To: wsjtgr...@yahoogroups.com
Subject: 40 Meter Power USB-D issue

Good evening,

I am experiencing a recent issue that has arisen where my IC-7300 is 
transmitting on reduced power on 40 meters using FT8 with WSJT-X.  Other 
digital modes and phone work fine, and no other bands have the low power issue. 
 Also, the rig occasionally changes from USB-D to USB when keying. Any ideas?

IC-7300
Win 10 Pro 64 bit
HRD version 6.7.0.244
WSJT-X version 2.1.0

73
Chris Diederich K1LDO


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

Re: [wsjt-devel] State QSO Parties

[Paul Kube]

On Thu, Sep 26, 2019 at 10:03 PM David Gilbert 
wrote:

>
> If WSJT used unique non-descriptive three letter/number combinations,
> there would easily be enough to cover every county in the United States and
> probably all of the rest of the world as well.  I.E.,  AAA, D9Y, 5V7,
> etc.  After all, 35x35x35 (I'll assume zero is protected) = 42,875.
>

The WSJT modes can code any Maidenhead square (well, minus RR73). There are
32,400 of those, so by using one of the available selector bits, it ought
to be possible to switch to an alternate locator scheme almost as rich as
what you propose. I'm not sure it would be rich enough to map to *all *the
counties, oblasts, prefectures, sections, districts etc. that will ever be
used in any contest exchange, but maybe it is.

Then there's the issue of how to manage the mapping between entries in that
selected WSJT table and all those political entities. The WSJT team would
want it to be universal, published and transparent to every user; otherwise
it involves too much of what Bill G4WJS calls "not passing all information
on air" -- I take it he is alluding to proscriptions against encrypted
amateur digital communication. I suppose that could be done, but I wouldn't
want to do it! ARRL has a hard enough time managing DXCC, which is a much
simpler problem.

73, Paul K6PO



> On 9/26/2019 12:55 PM, Ron WV4P wrote:
>
> Almost all US Counties, within the state, have a Number.
> Could, for the purposes of QSO Parties the designation be Hardin - HARN -
> 40 as would be the case of mine ? Would that help any, just using an
> already assigned number VS the County Name ? Ron WV4P
>
> On Thu, 26 Sep 2019 at 13:48, Bill Somerville 
> wrote:
>
>> On 26/09/2019 11:59, John Zantek wrote:
>> >
>> > ØThe bottom line is that there are still a handful of selectors
>> > available in the FT4/FT8/MSK144 message payload bits that could be
>> > used for new message schemes but nowhere near the number that would be
>> > needed to support a series of county based QSO parties or similar.
>> >
>> > But Bill, isn’t the FD message structure just that, with a lookup
>> > table that doesn’t exceed the payload ceiling?
>> >
>> > What’s the difference between the existing QRegularExpression
>> > field_day_exchange_re with a table of ARRL/RAC Sections and a proposed
>> > QRegularExpression WA_QSO_party_exchange_re of WA counties  as I had
>> > suggested at the start of this thread?
>> >
>> > 73 John W7CD
>> >
>> John,
>>
>> the source code you are referring to is the validation for GUI input
>> when entering one's state or province, it has no bearing on what is
>> packed into transmitted messages other than the selected value is used.
>> If you were to have a different set of information to pack into messages
>> then you must also pack into the message the selector to tell the
>> receiving decoder to interpret the message bits in the way that you
>> require. Even if your proposed table of counties only take the same
>> number of bits to store as the RTTY Roundup values do; you still need
>> another bit somewhere else in the payload to select that table. Extend
>> that to each and every QSO Party set of counties and you will need many
>> more bits to select the right table. That many bits are not available in
>> the FT4/FT8/MSK144 payload, it might be possible for one or maybe two
>> QSO Party formats but who decides which QSO Parties get support and
>> which ones are excluded?
>>
>> 73
>> Bill
>> G4WJS.
>>
>>
>>
>> ___
>> wsjt-devel mailing list
>> wsjt-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>
>
>
> ___
> wsjt-devel mailing 
> listwsjt-devel@lists.sourceforge.nethttps://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] Grid proposal

[Paul Kube]

>
>  Maybe so, but how many stns really do *not* send their grid ( except for
> long non-standard callsings )?
>

Quite a few. On Tab 1, Hover your mouse over  the Tx1 button to see the
option enabled with double click. Any station can enable this, not just
nonstandard callsigns.

Umm, no. The message length of FTx messages is the same whether grid
> locator is included in the message or not.
>
Any single FT8 transmission takes the same amount of time, but a QSO,
consisting of a mutually acknowledged exchange of call signs and signal
reports, can save one transmission if the caller skips Tx1 and uses Tx2
first:

CQ OH2GQC KP20
OH2GQC K6PO DM12
K6PO OH2GQC -10
OH2GQC K6PO R-12
K6PO OH2GQC RR73

vs.

CQ OH2GQC KP20
OH2GQC K6PO -12
K6PO OH2GQC R-10
OH2GQC K6PO RR73

Personally I have not noticed anyone being annoyed by either choice, but
then the FT modes aren't optimized for communicating annoyance.

73, Paul K6PO


> 
> 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] Double click on decode unresponsive?

[Paul St John]

Thank you Michael, It works great   73  Paul  NA4MM

From: Black Michael via wsjt-devel 
Sent: Friday, September 6, 2019 12:24 PM
To: WSJT software development 
Cc: Black Michael 
Subject: Re: [wsjt-devel] Double click on decode unresponsive?

Here's the patch to fix the double-click on <...>

de Mike W9MDB

*** "..\\wsjtx-2.1.0\\src\\wsjtx\\decodedtext.cpp"  2019-02-24 
21:48:37.0 -0600
--- decodedtext.cpp 2019-09-06 11:59:42.921762600 -0500
***
*** 10,16 

  namespace
  {
!   QRegularExpression words_re 
{R"(^(?:(?(?:CQ|DE|QRZ)(?:\s?DX|\s(?:[A-Z]{2}|\d{3}))|[A-Z0-9/]+)\s)(?:(?[A-Z0-9/]+)(?:\s(?[-+A-Z0-9]+)(?:\s(?(?:OOO|(?!RR73)[A-R]{2}[0-9]{2})))?)?)?)"};
  }

  DecodedText::DecodedText (QString const& the_string)
--- 10,16 

  namespace
  {
!   QRegularExpression words_re 
{R"(^(?:(?(?:CQ|DE|QRZ)(?:\s?DX|\s(?:[A-Z]{2}|\d{3}))|[\<\.\[A-Z0-9/]+)(?:\s(?[-+A-Z0-9]+)(?:\s(?(?:OOO|(?!RR73)[A-R]{2}[0-9]{2})))?)?)?)"};
  }

  DecodedText::DecodedText (QString const& the_string)




On Wednesday, September 4, 2019, 05:22:29 PM CDT, Star Light 
mailto:starlite4...@gmail.com>> wrote:


Yeah, agree.  That’s pretty much it.  And in my case (still coming up the 
learning curve), there’s time wasted making sure I didn’t do something wrong, 
didn’t accidentally miss-set a setting somewhere, aren’t trying to do something 
that’s actually not appropriate or allowed, and by the time I get down that 
logic tree and start what Mike described, it’s pretty much too late.  Yeah Joe, 
sorry - it’s frustrating.
However, it doesn’t happen very often (to me) and I sure don’t mean to make a 
big deal out of it.  I just wanted to contribute to the frequency-of-report 
statistics to be helpful.  If you guys don’t hear about things, how can you 
know about them?  Sorry if reporting frustration annoyed you.

On Sep 4, 2019, at 7:18 AM, Black Michael via wsjt-devel 
mailto:wsjt-devel@lists.sourceforge.net>> 
wrote:
Let me give an example

Running JTAlert (I don't even look at the WJST-X window anymore) you see a call 
you want...you click on it...and nothing happens.  Then JTAlert clears the 
screen for the next decode (especially in FT4) and if you're not lucky enough 
to remember the callsign have to go to WSJT-X, stop the monitoring, find the 
entry that you missed (again remembering the callsign), double-click on it (for 
those that don't know that it doesn't work), then type in the callsign to the 
DX box, enable monitoring again.

I call that frustrating IMHO.

de Mike W9MDB




On Wednesday, September 4, 2019, 08:57:51 AM CDT, Joe Taylor 
mailto:j...@princeton.edu>> wrote:


Hi Andy, Mike, Russ, ...

Yes, double-clicking on the decoded message "<...> 9M2TO -18" does not
copy 9M2TO into the DX Call entry box.  Yes, we should probably add this
capability some time.

Frustrating???  Really, I don't get it.  How hard can it be to type
"9M2TO" into the DX Call box, and then click on "Generate Std Msgs" ??

As you probably noticed, most recent programming effort has been devoted
to smooth operation of FT4/FT8 in the contesting environment.

-- Joe, K1JT

On 9/3/2019 5:02 PM, Star Light wrote:
> Had this same problem yesterday as well (different station).  Very
> frustrating...
>
> Russ, KR6W
>
>
> On Sep 3, 2019, at 9:09 AM, Black Michael via wsjt-devel
> mailto:wsjt-devel@lists.sourceforge.net>
> <mailto:wsjt-devel@lists.sourceforge.net<mailto:wsjt-devel@lists.sourceforge.net>>>
>  wrote:
>
>> This has been asked numerous times and I've never seen a reply about it.
>> I'd like to think it has been fixed but nobody knows what changes are
>> done anymore.
>>
>> de Mike W9MDB
>>
>>
>>
>>
>> On Tuesday, September 3, 2019, 11:06:35 AM CDT, Andy Durbin
>> mailto:a.dur...@msn.com> 
>> <mailto:a.dur...@msn.com<mailto:a.dur...@msn.com>>> wrote:
>>
>>
>> With WSJT-X 2.1.0 and this group of decodes displayed in "Band activity" :
>>
>> 135600  -3  0.2  991 ~  CQ KD5FOY EM12
>> 135600 -16  0.6 2207 ~  AE4CC N4HAI -04
>>  30m
>> 135615 -14  0.1 2240 ~  <...> 9M2TO -18 <<
>>  30m
>> 135630  -8  0.2  990 ~  CQ KD5FOY EM12
>> 135630 -18  0.1 1638 ~  CQ KB8SRX EN82
>>  30m
>> 135700  -8  0.2  991 ~  CQ KD5FOY EM12
>> 135700 -12  0.6 2207 ~  AE4CC N4HAI -04
>>
>> Double click on 9M2TO gives no response but double click on any other
>> decode line moves that decode to "RX Frequency", moves the RX cursor,
>> and generates appropriate messages.   Why is 9M2TO unresponsive? The
>> transmitting stations call, frequency, and 

[wsjt-devel] Debian 10 Linux WSJT-X Compile + CMake Policy Warning

[Paul Bramscher]

I've finally upgraded my last Linux PC to Debian 10, the most complex in
my shack (compiled executables for fldigi, flrig, TQSL, and of course
WSJT-X among several other apps and stacks).

Overall the process went smoothly, since I've heavily documented what
I've done previously.

Apologies if this has been mentioned in a thread already -- I did a
cursory search and found only a passing reference to it on the list.
But I noticed this warning message regarding policy settings for CMake.
Debian 10 is using cmake version 3.13.4.

Ultimately I ignored the message and it seems to have compiled perfectly
fine, but possibly the WSJT-X developers may keep an eye out on the
add_custom_target commands -- since future cmake versions might not
merely throw a warning:

cmake -DCMAKE_INSTALL_PREFIX=../../install/ -DWSJT_SKIP_MANPAGES=ON
-DWSJT_GENERATE_DOCS=OFF ../wsjtx-2.1.0

-- The C compiler identification is GNU 8.3.0
-- The CXX compiler identification is GNU 8.3.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found Git: /usr/bin/git (found version "2.20.1")
CMake Warning (dev) at CMakeLists.txt:165 (add_custom_target):
  Policy CMP0037 is not set: Target names should not be reserved and should
  match a validity pattern.  Run "cmake --help-policy CMP0037" for policy
  details.  Use the cmake_policy command to set the policy and suppress this
  warning.

  The target name "install" is reserved or not valid for certain CMake
  features, such as generator expressions, and may result in undefined
  behavior.
This warning is for project developers.  Use -Wno-dev to suppress it.



73, KD0KZE / Paul



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

Re: [wsjt-devel] 60 Hz + harmonics sidebands on FT8 signals? (Paul Kube)

[Paul Randall]

Jim, your recommendation that all shack equipment uses a single source and 
green wire, like the high quality distribution illustrated in your PDF is spot 
on, thank you. I guess weather in the UK is pretty benign, although we do have 
our moments. I remember working in Poland; in February I was surprised to see 
the lightning protection. In August I understood why.



Kind regards

Paul G3NJV



Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10




From: Jim Brown 
Sent: Wednesday, August 14, 2019 8:12:05 PM
To: WSJT software development 
Subject: Re: [wsjt-devel] 60 Hz + harmonics sidebands on FT8 signals? (Paul 
Kube)

I would certainly hope that you would want it for your personal safety,
and for the non-destruction of your home and your equipment! It also
happens that proper bonding of equipment, and obtaining power for all
interconnected equipment from outlets that share the same green wire,
minimizes hum, buzz, and RFI. That is the focus of my advice.

Another observation. The prevalence of lightning varies widely around
the world, as shown on this map. Those of living in high frequency
strike areas pay a lot more attention to it than do others.

https://geology.com/articles/lightning-map.shtml
http://lightningsafety.com/nlsi_info/lightningmaps/US_FD_Lightning.pdf
http://lightningsafety.com/nlsi_info/lightningmaps/worldlightning.html

73, Jim K9YC

On 8/14/2019 4:52 AM, Paul Randall wrote:
> There is no requirement for lightning protection in all buildings in the
> UK although there are laws which govern businesses separately. As a
> result, the lightning protection in the average domestic UK home
> approximates to “none at all”,



___
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] 60 Hz + harmonics sidebands on FT8 signals? (Paul Kube)

[Paul Randall]

Jim

There is no requirement for lightning protection in all buildings in the UK 
although there are laws which govern businesses separately. As a result, the 
lightning protection in the average domestic UK home approximates to “none at 
all”, as Douglas Adams would say.

Even with the open invitation of overhead power wire, telephone wire, satellite 
or TV aerial, installers bring the wires direct into the property with no 
ground or ground bonding. Most people get away with it and insurance companies 
make no requirements.

There are strict requirements for certification of electrical installers and 
installations and as a plain resident the general rule is “don’t mess with the 
power wiring Paul”. If I do my property may not pass the electrical inspection 
needed before it can be sold. This is apart from any other consequence and 
sadly I could find nothing in the Laws of Physics to make my trip work again if 
I bypass it.



73 Paul G3NJV



Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10




From: Jim Brown 
Sent: Tuesday, August 13, 2019 9:13:18 PM
To: WSJT software development 
Subject: Re: [wsjt-devel] 60 Hz + harmonics sidebands on FT8 signals? (Paul 
Kube)

Last I looked, the Laws of Physics still govern what happens when
lightning strikes. We have a similar issue with common practice by wired
telephone installers here in the former colonies failing to properly
bond their installations.

My recommendations are in line with those laws and the National Electric
Code, which has been adopted by local authorities through nearly all of
North America, and thus carries the force of law. If you find conflict
with my recommendations, I suggest that you may not fully understand them.

73, Jim K9YC

On 8/12/2019 7:26 PM, Paul Randall wrote:
> The advice is written and in the UK would render you liable to
> litigation in the event of an accident. That is why I say it is unwise.



___
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] 60 Hz + harmonics sidebands on FT8 signals? (Paul Kube)

[Paul Randall]

Jim, the PDF you attached has a huge amount of information thank you. However 
what I see is pages of illustrations of ground loops and how to short them out 
with big bonding straps. Does this prove they don't exist? For me it highlights 
them. Perhaps I missed something important in the language?


When utilities provide power to domestic premises their only concern is profit 
whilst complying with local safety regulations. They don't give a hoot for EMI 
or lightning protection. This is in contrast to the good engineering practice 
universally employed in professional equipment installations where all factors 
are taken into account and bonding reigns supreme.


Giving blanket advice to retrospectively interfere with domestic AC wiring and 
grounding IS risky unless you are completely appraised of all the relevant 
regulations and codes of practice that apply in every country and locality 
where people may be reading your advice. You also need to be aware of the 
requirements for certification in every country and locality that are needed to 
perform such modifications legally.


Jim, I thought your blanket ground bonding ideas in a domestic situation were 
unwise.  The advice given in the PDF on “Home Power Wiring, the green wire”  is 
clearly wrong and can be outright dangerous. Why? I checked my house wiring. 
All of the ground wires (green wires) in my house lead back to the 
switch/fuse/breaker panel where they connect to the primary safety device, a 
ground leakage circuit breaker, the other side of which goes to a PME bonded 
“ground” connection. The bonding recommended in the PDF (house ground to a 
"real" ground rod) bypasses this circuit breaker, rendering it inoperative and 
leaving the building occupants vulnerable to lethal electric shock. The advice 
is written and in the UK would render you liable to litigation in the event of 
an accident. That is why I say it is unwise.


In a professional installation the requirements for electrical safety, EMI, 
efficient RF grounding and lightning protection do not conflict. In a domestic 
situation they do. There may be no blanket solutions that apply everywhere, in 
all circumstances, in the domestic environment. This is not about good 
engineering practice, it is about how to work within electrical safety 
regulations and get as close as possible to what is needed in a good ham 
station.


My friend would turn up at locations all around the world, sometimes only 
minutes before a broadcast, armed with a battery of equipment designed to 
combat the hum and noise inducing ground loops he would surely encounter, 
without the luxury of time to re-engineer all the wiring in the vicinity.



Claude, I completely agree, a desktop will be much quieter at audio and RF and 
of course has a very obvious ground. The setup I describe had to be airline 
transportable for operating as VK2/G3NJV so I must use the (Lenovo) laptop. 
This has neither an internal chassis or a “D” connector. The only “grounded” 
metalwork visible are the HDMI and USB sockets, neither of which are accessible 
for bonding and which, upon inspection, connect to exactly the same internal 
PCB ground plane as the ground in the audio socket. Bond to a USB shell or the 
audio pin? Difference? Three inch wide copper strip to a USB or headphone on a 
laptop? Let's get real.



Let us not lose sight of the point of this discussion which is to try to 
transmit a nice clean signal without added hum and noise. In my case there was 
a simple solution to the problem I unexpectedly encountered with the isolated 
cable which was to link the gound from laptop to rig. Spectrum analyser 
software run on the computer can check for hum and noise on receive, asking a 
local ham to listen to your transmission is good on transmit.



One last point, how many people remember to disable their microphone when the 
PC is plugged to the accessory socket running WSJT-X? Listening in the FT8 
band, clearly lots of people don't.



Best regards Paul G3NJV



From: Jim Brown 
Sent: 11 August 2019 08:43
To: wsjt-devel@lists.sourceforge.net 
Subject: Re: [wsjt-devel] 60 Hz + harmonics sidebands on FT8 signals? (Paul 
Kube)

On 8/10/2019 6:09 PM, Paul Randall wrote:
> Jim
>
> Double insulated equipment like a laptop charger doesn’t have any
> physical access to a metal part that can be bonded to ground. That’s
> what double insulated means. Even if the charger has a 3 pin (hot,
> neutral and ground) AC connector there is little likelihood that the dc
> output side is connected to the ground pin.

That does not change the fact that chassis-to-chassis bonding is good
engineering practice, and audio interconnects should never be depended
on for bonding. One of the reasons that proper bonding is critical to
solve RFI and hum/buzz issies is the Pin One Problem. See my website for
a lot of detail on that, and point your broadcast engineer friend to
that, an

Re: [wsjt-devel] 60 Hz + harmonics sidebands on FT8 signals? (Paul Kube)

[Paul Randall]

Jim
Double insulated equipment like a laptop charger doesn’t have any physical 
access to a metal part that can be bonded to ground. That’s what double 
insulated means. Even if the charger has a 3 pin (hot, neutral and ground) AC 
connector there is little likelihood that the dc output side is connected to 
the ground pin. In this case using the laptop for WSJT relies on the connecting 
wire running from the laptop to the rig to provide a ground. If that wire is 
deliberately built to be isolated then it CAUSES a hum problem rather than 
avoids one. This is counter-intuitive and so even though it has nothing to do 
with software development, I felt it was worth contributing to the “bad signal” 
discussion going on in this forum.

As an aside, I think it very unwise to make a blanket statement that bonding 
everything together is good engineering practice. Someone reading that may 
unwittingly bypass a safety ground leakage circuit breaker by bonding the 
building’s safety ground to a radio antenna ground rod. Worse, large AC 
currents may flow in this connection if the power utility company uses one of a 
number of different PME (protective multiple earth) supply systems where the 
building’s safety ground is actually bonded to the neutral supply wire and only 
to “real” ground back at the supply transformer.

Finally, my friend gave a big grin when he read that “The concept of a 
so-called "ground loop" is completely false”. He is a professional sound and 
television broadcast engineer.
Cheers Paul G3NJV



Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10

From: Jim Brown<mailto:k...@audiosystemsgroup.com>
Sent: 08 August 2019 19:20
To: wsjt-devel@lists.sourceforge.net<mailto:wsjt-devel@lists.sourceforge.net>
Subject: Re: [wsjt-devel] 60 Hz + harmonics sidebands on FT8 signals? (Paul 
Kube)

The concept of a so-called "ground loop" is completely false. It has no
basis in physics. The "buzz" we hear when equipment is not properly
bonded consists of triplen harmonics of the mains frequency, 50 or 60
Hz, depending on where you live. What DOES couple this trash is the
failure to follow proper engineering practice, which is to bond together
the chassis of every piece of equipment in a system, to bond all grounds
in a building, and to bond that combination of equipment to the
combination of building grounds. (my friends in the UK substitute the
word "earth" for "ground.") A second important part of good practice is
to get power for all interconnected equipment from mains (power) outlets
that have the same Green Wire (protected earth conductor), or whose
green wires are bonded together.

When all of this done, the station is safe for lightning, and no
"isolation" is needed.

Details of proper practice is at http://k9yc.com/GroundingAndAudio.pdf

73, Jim K9YC

On 8/8/2019 3:43 AM, Paul Randall wrote:
> The point of the isolated interface is to prevent noise/hum caused by
> ground loops but if there is no ground at all, it is not only useless
> but actually causes a big problem. I can only assume that if I saw lots
> of 50Hz spurs on receive, there was a good chance they were there on
> transmit as well.



___
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] Moving WSJT-X from Debian 9 to 10

[Paul Bramscher]

Hi Bill,

I save everything, and will restore probably 99%.  One area where I give a 
little more scrutiny is for apps that I've compiled (against older libraries).  
I'm happy to let the newly-compiled application repopulate as much as possible 
-- so long as I can avoid re-tweaking my settings.  Also, there could be 
old/obsolete files in settings-related directories that no longer apply to 
modern versions of things.

My ALL.TXT is now 1.3 GB, going back to May 2015.  Space is no issue, and I'm 
happy to preserve that for posterity.  :-)

73, KD0KZE / Paul

> On July 30, 2019 at 2:28 PM Bill Somerville  wrote:
> 
> 
> On 30/07/2019 20:21, Paul Bramscher wrote:
> > But I've got a general question with ~/.local/share/WSJT-X.  What are 
> > the minimally useful files to copy over, to preserve settings and 
> > logs?  The entire directory (except the contents of 'save') -- or is 
> > there a smaller subset?
> 
> Hi Paul,
> 
> I would transfer the whole directory and it's contents. You will also 
> want to copy the settings file which is in ~/.config/ .It will not 
> amount to a great deal of space. If you have a lot of saved .WAV files 
> you might deleted them with the "Menu->File->Delete all *.wav and *.c2 
> files in SaveDir" button before archiving the log files directory.
> 
> I don't understand why you would not simply backup and restore to the 
> new system your entire /home directory, what do you hope to gain by 
> scrapping all user files?
> 
> 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] Moving WSJT-X from Debian 9 to 10

[Paul Bramscher]

I'll soon be upgrading my Debian 9.x to 10.0 Buster.  And while it's possible 
to perform an in-place upgrade I usually take the opportunity to replace the 
hard drive and do a fresh install entirely.  I've been compiling WSJT-X for 
awhile now and have had no problems doing so.


But I've got a general question with ~/.local/share/WSJT-X.  What are the 
minimally useful files to copy over, to preserve settings and logs?  The entire 
directory (except the contents of 'save') -- or is there a smaller subset?


73, KD0KZE / Paul
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Lid operators or bad design?

[Paul Randall]

whoosh  - sharp intake of breath
Rich you are Sooo... picky,
73 = best regards
73s = more than one best regards
73's = 73, his best regards.

As I understand, 's is possesive, so "Richard's email" is shorthand for 
"Richard, his email". I'd love to be corrected.
Nice to see the new world is equally saddled with medieval language structures.
..But in a software forum, punctuation is crucial.
So you are forgiven.

My two cents worth is;-
Before I transmit I listen a lot and use the spectrum display to select slots 
that are "empty" on both time periods. I have the magic "hold tx freq" box 
checked most always. Sending CQ I use one of these frequencies and after a few 
cycles rest and check both time slots again. If I get no replies I use another 
frequency.

On every band each receiving station has an individual spectrum to deal with, 
close-in vs dx. It's impossible to know what the station on the other end is 
receiving. The only feedback is "is he replying to me?"

So, If I am calling a DX station on what I think is a clear frequency and 
getting no replies, I try another, and another. If still no success I think to 
myself, maybe he thinks like me, maybe I don't have to look for a clear 
frequency, the DX station has already done that and is CQ'ing on it, so I call 
on his frequency, unchecking the magic "hold tx freq" box. Not easy going 
forward as the software switches you off if it detects the DX is involved in 
another QSO. But sometimes it works immediately. The clever bit is to remember 
the magic box is unchecked as you go on your way afterward. At age 70 I don't 
think of myself as a LID, I have 50 years of operating experience in there 
somewhere but my usual memory addressing algorithm seems to have changed, maybe 
i missed the update, so ... I make mistakes.

Summary - I never have any expectation that this is "my" frequency, it is too 
dynamic. I run 100W to wire antennae so getting good dx QSOs without kW+ to a 
beam means being very flexible and frequency/time hopping, not just frequency 
warming. It is S done biologically hihi.

Regarding time slots, in Europe we try to obey a rule that stations beaming 
east use the odd slot (Tx even/1st check box UNCHECKED) and vice versa. I think 
this tallies with your convention.

Huge thanks to the WSJT software team

Regards,
Paul G3NJV



From: Rich Zwirko - K1HTV 
Sent: 29 July 2019 16:37
To: Mike - W9MDB Black ; WSJT 

Subject: Re: [wsjt-devel] Lid operators or bad design?

Hi Mike,
  Good on the note, but I'd correct the last line "73's".

73 means 'Best Regards'.
73's translates to "Best Regards's" (Regardses)  8-).
I know, picky, picky.

Regarding emailing 'educational' notes, I regularly do so to loud locals who 
call CQ on 6 Meter FT8 during the 1st & 3rd 15 second sequences when the band 
is open to Europe and Africa.

A TX sequencing convention for openings to Europe/Africa, has been agreed upon 
by the majority of 6M DXers. NA stations call CQ only during the 2nd & 4th 
sequences (Tx even/1st check box UNCHECKED). Very strong out of sequence 
stations cause the receiver's AGC to push very weak DX further into the noise. 
When all 6M DXers in the region are all using the same Tx sequence, we all have 
a better chance to decode weak DX signals.

Later in the day, when it looks like we have possible SSSP propagation to 
Japan, the sequencing convention is reversed. North American stations call CQ 
during the 1st & 3rd (Even) sequence. JA DXers religiously adhere to 
transmitting 2&4 to NA and 1&3 (Even) to Europe.

73,
Rich - K1HTV

= = =
On 7/28/2019 11:01 AM, Black Michael via wsjt-devel wrote:
Attribute it to inexperienceyou should contact them and help to politely 
educate them.

Something like
 Hi there OM,
Saw you in a QSO with  and after the QSO was complete you called CQ on the 
same offset.
You should consider working people in split by choosing a Tx offset that is 
clear of other signals (shift click will do that) in the waterfall and checking 
"Hold Tx Freq" to keep your offset constant.
Of course I'm sure you know that calling CQ on somebody else's frequency is a 
no-no.
73's
..

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

Re: [wsjt-devel] FT4 Frequency on 40-m

[Paul Kube]

TOK, thanks Steve. If I get inspired maybe I'll fire up ft8sim and ft4sim
and run some experiments.

73, Paul K6PO

On Mon, Jul 29, 2019 at 9:35 AM Steven Franke via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> Paul,
>
> I don’t know the answer to your question(s).
>
> In addition to frequency separation and signal strength difference, one
> would have to consider overall signal strength (not just difference), the
> DT difference between the two signals, and the delay and Doppler spread on
> each of the two channels that are involved. There are too many dimensions
> in that parameter space!
>
> Steve k9an
>
> On Jul 28, 2019, at 8:06 PM, Paul Kube  wrote:
>
> Steve --
>
> Related to this, and to another recent thread on replying to CQ's on the
> caller's frequency:
>
> What is the decoding probability a FT8 (or FT4) signal when being
> interfered with by another FT8 (or FT4) signal, as a function of frequency
> separation and signal strength difference? Seems clear that it would not be
> appropriate to model the interfering signal as additive Gaussian noise, so
> is this even something that you can solve or nicely approximate
> analytically? I'd be interested to know.
>
> 73, Paul K6PO
>
> On Sun, Jul 28, 2019 at 7:38 AM Steven Franke via wsjt-devel <
> wsjt-devel@lists.sourceforge.net> wrote:
>
>> Hi Gene,
>>
>> FT8 is WAY MORE sensitive! (~8db)
>>
>>
>> That number is not right. On the additive white Gaussian noise (AWGN)
>> channel, the 50% decode probability of FT8 occurs at SNR=-20.8 dB and the
>> 50% decode probability of FT4 occurs at SNR=-17.5 dB.  The sensitivity
>> difference is therefore 3.3 dB.
>>
>> On channels with severe Doppler spreading, the threshold SNR is higher
>> for both modes, and the difference between FT8 and FT4 will decrease
>> somewhat because FT4’s larger tone separation tends to give it an advantage
>> in those cases.
>>
>> It might be of interest to some to consider that FT8 uses symbols with
>> duration 160 ms to send 3 bits apiece. FT4 uses symbols with duration 48 ms
>> to send 2 bits apiece. For a given average transmitter power, the energy
>> that is transmitted per bit for FT8 is larger than the energy transmitted
>> per bit for FT4 by the factor (160/3)/(48/2) = 2.22. Thus, the theoretical
>> sensitivity difference (ignoring any differences in signal detection,
>> synchronization or LDPC decoding efficiency) is 10*log10(2.22) = 3.46 dB,
>> very close to the actual difference of 3.3 dB that I quoted above.
>>
>> I have no strong feelings one way or the other about your main point, but
>> I think that it’s preferable to base the discussion on accurate numbers.
>>
>>
>> FT4 is awesome for MORE contacts (i.e. contests).
>>
>> I’m sticking with FT8 for QUALITY.
>>
>> 73 de W8NET Miles / “Gene”
>> Secretary, Portage County Amateur Radio Service (PCARS)
>> 3905 Century Club - Master #47
>> DV2/W8NET in the Philippines
>> Licensed since 1974
>>
>>
>> Steve, K9AN
>>
>>
>> ___
>> 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] FT4 Frequency on 40-m

[Paul Kube]

Steve --

Related to this, and to another recent thread on replying to CQ's on the
caller's frequency:

What is the decoding probability a FT8 (or FT4) signal when being
interfered with by another FT8 (or FT4) signal, as a function of frequency
separation and signal strength difference? Seems clear that it would not be
appropriate to model the interfering signal as additive Gaussian noise, so
is this even something that you can solve or nicely approximate
analytically? I'd be interested to know.

73, Paul K6PO

On Sun, Jul 28, 2019 at 7:38 AM Steven Franke via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> Hi Gene,
>
> FT8 is WAY MORE sensitive! (~8db)
>
>
> That number is not right. On the additive white Gaussian noise (AWGN)
> channel, the 50% decode probability of FT8 occurs at SNR=-20.8 dB and the
> 50% decode probability of FT4 occurs at SNR=-17.5 dB.  The sensitivity
> difference is therefore 3.3 dB.
>
> On channels with severe Doppler spreading, the threshold SNR is higher for
> both modes, and the difference between FT8 and FT4 will decrease somewhat
> because FT4’s larger tone separation tends to give it an advantage in those
> cases.
>
> It might be of interest to some to consider that FT8 uses symbols with
> duration 160 ms to send 3 bits apiece. FT4 uses symbols with duration 48 ms
> to send 2 bits apiece. For a given average transmitter power, the energy
> that is transmitted per bit for FT8 is larger than the energy transmitted
> per bit for FT4 by the factor (160/3)/(48/2) = 2.22. Thus, the theoretical
> sensitivity difference (ignoring any differences in signal detection,
> synchronization or LDPC decoding efficiency) is 10*log10(2.22) = 3.46 dB,
> very close to the actual difference of 3.3 dB that I quoted above.
>
> I have no strong feelings one way or the other about your main point, but
> I think that it’s preferable to base the discussion on accurate numbers.
>
>
> FT4 is awesome for MORE contacts (i.e. contests).
>
> I’m sticking with FT8 for QUALITY.
>
> 73 de W8NET Miles / “Gene”
> Secretary, Portage County Amateur Radio Service (PCARS)
> 3905 Century Club - Master #47
> DV2/W8NET in the Philippines
> Licensed since 1974
>
>
> Steve, K9AN
>
>
> ___
> 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] New library required for building: qt5-linguist

[Paul Bramscher]

I successfully compiled the newest WSJT-X 2.1.0 on Debian 9.9 this morning, and 
qttools5-dev-tools was indeed the new package dependency.  In the next couple 
weeks I'll be upgrading the shack to Debian 10.

As a side note, I should really check the Debian site more often.  The first 
inkling I got that Debian 10 Buster was released was from a thread a few days 
ago in this very list.

73, KD0KZE / Paul

> On July 15, 2019 at 3:50 PM Bill Somerville  wrote:
> 
> 
> On 15/07/2019 21:39, Dave Slotter, W3DJS wrote:
> > There appears to be a new requirement to build under Ubuntu 16.xx. 
> > CMake seems to now require Qt5LinguistTools in order to build, whereas 
> > that was not required in earlier release candidate builds of 2.1.0.
> >
> > Where do I get this library to satisfy CMake? (Thanks in advance.)
> >
> Hi Dave,
> 
> I believe the required package is qttools5-dev-tools .
> 
> Apologies for the INSTALL file not being updated to reflect that new 
> requirement, it will be corrected for the next release.
> 
> 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] WSJT-X 2.1.0 64-bit GA release: TX audio level has changed

[Paul Kube]

>  Anyone else experiencing that with the 64-bit version?

Yes.

Tune power also.

IC-7300, Win 10 x64 Pro.

73, Paul K6PO


On Mon, Jul 15, 2019 at 8:52 AM DG2YCB, Uwe  wrote:

> Many thanks for the new GA version! Works well so far here on my computer
> (64-bit Windows).
> One observation: With the new 64-bit GA version I needed to increase PWR
> slider from around 50 % to now nearly 100 % to get sufficient audio level
> at
> my FT-991. Old settings resulted in a few mW TX output. Will do some
> further
> tests, but seems to be reproducible.
> Anyone else experiencing that with the 64-bit version?
>
> 73 de Uwe, DG2YCB
>
>
>
> ___
> 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] 60 Hz + harmonics sidebands on FT8 signals?

[Paul Kube]

I’ve seen various kinds of problematic  FT8 signals that I think I
understand -- “barcode” harmonics etc. – but what is going on here:


[image: multiple decode.PNG]

The “blackbox” station there (call elided, no need to name names) has
multiple sidebands on his main signal, some of them strong enough to be
separately decoded, all at multiples of 60 Hz. What is causing this?
Inadequate power supply filtering?



Pretty sure it’s not in my receive chain; I see many signals stronger than
this +12 dB one that are perfectly clean.



73, Paul K6PO
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] Band Hopping

[Paul Simon]

I would like to use band hopping with WSPR.  It is not working in a way 
I  expect.  Band switching occurs at random times at least as much as 
ten times an hour.  Also, the "tune" power setting resets to transmit 
power level after one tune operation. Transmit is at 200 mW and tuning 
of my MFJ 993b requires at least 2 Watts. Tune power is set during the 
tune cycle at 2 Watts. On the audio tab both transmit and tune power 
check boxes are set.


According to the manual, band switch to 40 M occurs at 06, 26, 46 
minutes after the hour, and band switch to 30 M occurs at 08, 28, and 48 
minutes after the hour.
Rather than list the whole log, band switching from 40 M to 30 M 
occurred at 02, 08, 16, 28, 34, 48.  Switching from 30 M to 40 M 
occurred at 06,12,24,32, 44, 54.


Can this be clarified for me?

Paul Simon W6EXT



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

Re: [wsjt-devel] S+P operation

[Paul Kube]

Joe --


> I think you'll get what you want (for contesting) if you check only
> these (top to bottom) on the Settings -> Colors tab:
>
> X  My Call in message
> X  New DXCC
> X  New Call on Band
>

Thanks, yes, that does it.


> No guarantees that we are maintaining our sanity!  Would you like to
> volunteer to organize and operate such a system?  :-)
>

Ah, probably not; too busy being retired :).

Sourceforge has its native bug ticket system
https://sourceforge.net/p/forge/documentation/Tickets/ and since you are
already hosting the project there, that might be the easiest way to go.

Personally I like Bugzilla https://en.wikipedia.org/wiki/Bugzilla. Set it
up on one of your Princeton machines; it's pretty lightweight
https://www.bugzilla.org/. Or run it in Amazon's cloud
https://aws.amazon.com/marketplace/pp/B007I8OOJ0.

But anything will have startup costs and you might not find that worth it.

73, Paul K6PO
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] S+P operation

[Paul Kube]

The documentation
http://physics.princeton.edu/pulsar/k1jt/FT4_Protocol.pdf says,
re S+P: "Here “best potential QSO partner” means “New Multiplier” (1st
priority) or “New Call on Band” (2nd priority)."

Now it seems to me that "New Call" implies "New Call on Band", and so
should qualify as a potential QSO partner.

However, in my setup, it does not. (That is, a new call on the band can
trigger the S+P response; while entirely new call, i.e. new on all bands,
doesn't.)

73, Paul K6PO

P.S. I'm posting this as a reply to George's note, since its topic fits his
subject line. Just doing my part to try to keep comments here organized a
bit. I do not know how the developers continue to maintain their sanity
without a proper bug reporting and tracking system.


On Thu, May 2, 2019 at 7:45 AM WB5JJJ  wrote:

> Trying new features with FT4 and noticed that when S+P is active during
> non-CQ (receive only) operation, it will pounce on stations using directed
> calls such as CQ DX WB5JJJ EM35.  In a contest situation, which FT4 is
> designed for, this would be fine since there will not be any directed CQ's
> typically.  So, should this option not be shown on the main UI unless a
> contest is selected since it can cause frustration to some operators that
> don't want to be bothered by local stations pouncing on their directed CQ?
>
> Judging from some comments, it appears that FT4 may be the new norm for
> those seeking their first WAS, DXCC and not just contests.
>
> WB5JJJ - George
> ___
> 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] Another observed drawback - audio input level

[Paul Kube]

Looking at this ("Microphone Properties" for the USB Audio Codec that the
IC-7300 provides and that WSJT-X uses as input):

[image: miclevel.png]

It gets set to 100% whenever WSJT-X 2.1.0-rc5 starts, and I have to set it
to 40% "by hand". WSJT-X  2.0.1 did not have this issue.

Windows 10 Pro x64 here.

73, Paul K6PO


On Tue, Apr 30, 2019 at 5:48 AM Black Michael via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> Are you guys looking at the dB level in the audio management panel?  Or
> the % level?
> WSJT-X does not touch the audio so it has to be Windows doing it.
>
> Recording audio should be at 0dB.
>
> de Mike W9MDB
>
>
>
>
> On Tuesday, April 30, 2019, 6:55:30 AM CDT, kf8my--- via wsjt-devel <
> wsjt-devel@lists.sourceforge.net> wrote:
>
>
> It also does it in Win7, audio sound recording to max on restart.
> Mike/kf8my
>
>
>
> -Original Message-
> From: Joe, LB1HI 
> To: wsjt-devel 
> Sent: Tue, Apr 30, 2019 6:46 am
> Subject: [wsjt-devel] Another observed drawback - audio input level
>
> Hi,
> Another observed  drawback is that after each WSJT-X restart, previously
> pre-set audio (Win 10 64 bit) signal input level of the sound card
> changes. It changes spontaneously. It changes to a maximum  - 100% of
> the  level setting range.
>
> 73`s Joe
>
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] GFSK for FT8?

[Paul Kube]

Bill --

empirical tests using multiple simulated FT8 signals
>

 Do you have software for us civilians that can do that? Create .wav files
with multiple FT8 signals with controllable frequencies and strengths, I
mean. SimJT doesn't, according to documentation
https://physics.princeton.edu/pulsar/k1jt/SimJT_User.pdf.

Thanks

73, Paul K6PO
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] The FT4 Protocol for Digital Contesting

[Paul Kube]

Thanks Joe, Steve, and Bill. This looks very good.

1. Where do you want folks to submit their feedback after using the RC? You
all seem to be good at dealing with the firehose of emails coming in to
wsjt-devel, but maybe you want to set up something just for this.

2. Any chance of having "Best S+P" also consider end-of-QSO messages (RR73,
etc.) as well as CQ's? Tailending, without waiting for a CQ, can really
help with rates.

3. Any chance of implementing F/H style "W1ABC 73; W0XYZ 569" call queueing?

Thanks!

73, Paul K6PO

On Mon, Apr 22, 2019 at 8:38 AM Joe Taylor  wrote:

> To:   WSJT-X users interested in testing FT4
> From: K1JT, K9AN, and G4WJS
>
> Soon after the "FT8 Roundup" held on December 1-2, 2018, we started
> serious work on a faster, more contest-friendly digital mode that can
> compete with RTTY-contesting QSO rates while preserving many of the
> benefits of FT8.  The result is FT4 -- a new digital mode specifically
> designed for radio contesting.
>
> Over the past month a small group of volunteers have been conducting
> on-the-air tests of FT4.  The early tests were very successful and
> helped us to make a number of important design decisions.  We believe
> FT4 has considerable promise for its intended purpose.
>
> We'll soon be ready for testing by a larger group.  If you might be
> interested in participating and offering your considered feedback,
> please read the descriptive document "The FT4 Protocol for Digital
> Contesting", posted here:
> http://physics.princeton.edu/pulsar/k1jt/FT4_Protocol.pdf
>
> We plan to post downloadable installation packages for WSJT-X 2.1.0-rc5
> on April 29, one week from today.  The document linked above includes
>
>   - Instructions for installing WSJT-X 2.1.0-rc5 and FT4 configuration
>
>   - Operating instructions for FT4
>
>   - Basic description of the FT4 protocol, modulation, and waveform
>
>   - Detailed sensitivity measurements for FT4 under a wide variety of
> simulated propagation conditions
>
>   - Schedule for upcoming test sessions
>
> Please consider helping us to make FT4 a successful mode for digital
> contesting
>
> With best wishes and 73,
>
> -- Joe (K1JT), Steve (K9AN), and 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] People are rude at times

[Paul Kube]

 click moves Rx, ctl-click moves both, shift click moves Tx.  I knew
> something moved them both...and sometimes I hit control instead of shift in
> the heat of he moment.
>

I think it would be better user interface design to have "move Rx" be left
click and "move Tx" to be right click, so those basic functions can each be
done with one hand. But that's another topic.

Do you have any theories on why a station gets covered by another station
> on exactly the same frequuency +/- 1-2 Hz?
>

I don't know, maybe the other station chose that frequency because it
looked clear to transmit (the weak station was weak enough that they didn't
see it). On a crowded FT8 segment, like 14.074 in the evening here, signals
are packed in like sardines and you have to do your best to find a
relatively open slot.

Or maybe he was just a lid! But IMHO it's going to be futile to try to
eliminate liddish behavior through software.

73, Paul K6PO


> On Sat, Apr 20, 2019 at 2:05 AM Paul Kube  wrote:
>
>> Jeff,
>>
>>
>>> What I think is happening is that people click on signals so they can
>>> see them in the Rx Frequency window.  They have not checked the Hold Tx
>>> Frequency and so the transmitter frequency is automatically following the
>>> Rx frequency.
>>>
>>
>> Are you talking about single-clicking in the waterfall? That only moves
>> the Rx frequency, whether or not Hold Tx Freq is checked.
>>
>> 73, Paul K6PO
>>
>>
>>> On Thu, Apr 18, 2019 at 4:41 PM James Shaver  wrote:
>>>
>>>> And speaking of S/N, I just realized this is the “devel” reflector and
>>>> not the generic WSJT Group reflector.  This really isn’t a topic suitable
>>>> for the development side, to be honest...
>>>>
>>>> 73,
>>>>
>>>> Jim S.
>>>> N2ADV (ex KD2BIP)
>>>>
>>>> > On Apr 18, 2019, at 4:34 PM, James Shaver  wrote:
>>>> >
>>>> > It never ceases to amaze me how so many hams instantly jump to the
>>>> conclusion that what they witness on the air is automatically attributed to
>>>> intentional “rudeness” or ill intent.
>>>> >
>>>> > His s/n is not really relevant - it’s very possible that even if
>>>> propagation was, to coin a phrase, putting this person in your lap, that
>>>> does not mean you’re even a weak trace on his/her end. That person may have
>>>> a very high local noise floor due to an indoor antenna or a lot of noisy
>>>> consumer electronics around them or it could even be as simple as plain old
>>>> propagation differences or it could be someone who has just jumped into
>>>> digital modes for the very first time and is not yet familiar with the
>>>> interface.
>>>> >
>>>> > If it bothers you that much, look up their email on QRZ and send them
>>>> a screen shot and *politely* ask if they even heard/saw you. If they
>>>> didn’t, offer to help them track down local noise generators or help them
>>>> optimize their receive setup.
>>>> >
>>>> > It pays to give people the benefit of the doubt. If they turn out to
>>>> be a jerk, then you can at least walk away with the satisfaction that you
>>>> tried your best to be an “Elmer” and are, at the end of the day, the better
>>>> person.
>>>> >
>>>> > And relax. It’s just ham radio. Nobody died on the table. This is
>>>> supposed to be fun.
>>>> >
>>>> > Jim S.
>>>> > N2ADV
>>>> >
>>>> > ___
>>>> > wsjt-devel mailing list
>>>> > wsjt-devel@lists.sourceforge.net
>>>> > https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>>>
>>>>
>>>> ___
>>>> wsjt-devel mailing list
>>>> wsjt-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>>>
>>> ___
>>> wsjt-devel mailing list
>>> wsjt-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>>
>> ___
>> wsjt-devel mailing list
>> wsjt-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>
> ___
> 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] People are rude at times

[Paul Kube]

Jeff,


> What I think is happening is that people click on signals so they can see
> them in the Rx Frequency window.  They have not checked the Hold Tx
> Frequency and so the transmitter frequency is automatically following the
> Rx frequency.
>

Are you talking about single-clicking in the waterfall? That only moves the
Rx frequency, whether or not Hold Tx Freq is checked.

73, Paul K6PO


> On Thu, Apr 18, 2019 at 4:41 PM James Shaver  wrote:
>
>> And speaking of S/N, I just realized this is the “devel” reflector and
>> not the generic WSJT Group reflector.  This really isn’t a topic suitable
>> for the development side, to be honest...
>>
>> 73,
>>
>> Jim S.
>> N2ADV (ex KD2BIP)
>>
>> > On Apr 18, 2019, at 4:34 PM, James Shaver  wrote:
>> >
>> > It never ceases to amaze me how so many hams instantly jump to the
>> conclusion that what they witness on the air is automatically attributed to
>> intentional “rudeness” or ill intent.
>> >
>> > His s/n is not really relevant - it’s very possible that even if
>> propagation was, to coin a phrase, putting this person in your lap, that
>> does not mean you’re even a weak trace on his/her end. That person may have
>> a very high local noise floor due to an indoor antenna or a lot of noisy
>> consumer electronics around them or it could even be as simple as plain old
>> propagation differences or it could be someone who has just jumped into
>> digital modes for the very first time and is not yet familiar with the
>> interface.
>> >
>> > If it bothers you that much, look up their email on QRZ and send them a
>> screen shot and *politely* ask if they even heard/saw you. If they didn’t,
>> offer to help them track down local noise generators or help them optimize
>> their receive setup.
>> >
>> > It pays to give people the benefit of the doubt. If they turn out to be
>> a jerk, then you can at least walk away with the satisfaction that you
>> tried your best to be an “Elmer” and are, at the end of the day, the better
>> person.
>> >
>> > And relax. It’s just ham radio. Nobody died on the table. This is
>> supposed to be fun.
>> >
>> > Jim S.
>> > N2ADV
>> >
>> > ___
>> > wsjt-devel mailing list
>> > wsjt-devel@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>
>>
>> ___
>> wsjt-devel mailing list
>> wsjt-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] People are rude at times

[Paul Kube]

I don't know what the other guy was thinking in this case, but the issue is
complicated by some FT8 experts pushing the "always work split" idea,
i.e. "*Never
call a station on his transmit frequency".* If everyone follows that, then
each station's transmit frequency should be free for someone else to use
use to transmit on the other cycle.

Obviously, a problematic idea unless everyone follows it. Kind of like
"let's some of us drive on the left side of the road and see how that
works."

73, Paul K6PO

On Thu, Apr 18, 2019 at 9:13 AM Scotty W7PSK  wrote:

> I was on the air just now when a Jerk just started CQing dead on top of
> me.  I was in the process of trying to work a new one when I lost it due to
> him.  I even posted  IN USE QSY and he just kept blasting away
>
> WTH people, have we forgotten ham courtesy ?
>
> Scotty W7PSK
>
> ___
> 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] Does the FT8 signal spike at the beginning of each transmission?

[Paul Randall]

Hi James, point taken, my comments were really aimed at traditional alc systems 
that are so prone to producing power spikes.

I have noticed many comments on this thread from people looking for software 
solutions to what look at first sight to be RFI issues. I'm not sure if it has 
been said before but a very simple test that could be recommended to anyone 
whose station is failing or performing strangely is to operate it into a dummy 
load. If the observed problem goes away this removes doubts about the software 
and the fickle finger would point directly at RFI as the culprit. Knowing this 
enables the sufferer to quickly get on the right road towards a solution.

Cheers Paul G3NJV

Sent from my Samsung Galaxy smartphone.


 Original message 
From: James Shaver 
Date: 12/04/2019 19:19 (GMT+00:00)
To: WSJT software development 
Subject: Re: [wsjt-devel] Does the FT8 signal spike at the beginning of each 
transmission?

Hi Paul,

Good info (and similar to my own line of thinking in the response I just sent 
on ALC Overshoot) but I’d recommend one minor change:

Your statement “The best way to avoid spikes in any rig using FT8...” - I’d be 
cautious with the “any rig” generalization.  Some of the popular radios on the 
market with a closed loop power system like the Elecraft K-line and KX-line 
will actually “power hunt” if the ALC meter is not showing 3-4 bars of activity 
on the ALC meter.  The first 4 bars of the ALC meter on the K/KX-line radios 
function like a vu meter and not necessarily indicate ALC action.  The radio 
itself may actually overmodulate the signal in order to get the power output 
set by the power output control and cause a transmitted signal to be quite 
poor.  I was able to test this using my K3 and KX3 into a dummy load and 
viewing the signal output with a spectrum analyzer and the term for the signal 
produced with “0” bars of “ALC” showing was “icky” at best (very technical, I 
know :) ).

Just a word of caution for anyone following this thread.

73,

Jim S.
N2ADV

On Apr 12, 2019, at 2:06 PM, Paul Randall 
mailto:paulfrand...@hotmail.com>> wrote:

Start-of- transmission power spikes will almost certainly occur on any radio 
which is using traditional alc to control output power. Spike severity is 
directly linked to the amount of gain reduction the alc is giving. For example, 
 a 100w rig with power output reduced to 5w using a power control which 
operates via the alc system can be almost relied upon to produce 100w spikes at 
start of transmission. No brainer.

The best way to avoid spikes in any rig using FT8 is to carefully adjust audio 
drive level in the software until desired power output is obtained without the 
rig applying any alc at all. In this way overall system gain is only sufficient 
to produce desired power and no more - so spikes are eliminated and you get a 
cleaner transmission.

That said, I say again that I can exactly  reproduce this problem at will on 
160m where my antenna system clearly puts large voltage onto the cable between 
the pc and the rig. My interface uses industrial quality logic isolators for 
civ and ptt together with audio isolation transformers and dozens of ferrite 
rings on tuner - rig - pc cables.  RFI still gets through and kills the usb 
connection on 160m.  To cure this I will rethink the 160m antenna which I 
suspect is the easiest way.

Regards Paul G3NJV

Sent from my Samsung Galaxy smartphone.


 Original message 
From: Bill Barrett mailto:w2pky...@gmail.com>>
Date: 12/04/2019 18:11 (GMT+00:00)
To: fr...@fkirschner.net<mailto:fr...@fkirschner.net>, WSJT software 
development 
mailto:wsjt-devel@lists.sourceforge.net>>
Subject: Re: [wsjt-devel] Does the FT8 signal spike at the beginning of each 
transmission?

>From W8JI.com<http://W8JI.com>, maybe 5000 has similar adjustments. If the IF 
>Transmit Gain was too high the 1000 would exhibit huge power spikes on key 
>down or pressing the mike PTT button.

Transmit Gain Menus

The FT-1000 MK V  has hidden transmit gain menus. They are accessed by pushing 
and holding FAST and LOCK while turning the POWER switch on. Both of my MK V's  
and every MK V serviced here has had the TX IF gain set too high. This causes 
first character clicks on CW and spits and splatter on SSB.  Here is how to 
correct the IF gain to prevent ALC clipping on leading edges of CW and voice:

Press and hold FAST and LOCK before and during initial POWER on.

Press FAST and ENT at the same time. You are now in the MENU's and the display 
should say "0-1 GrPI-cH".

Turn the VRF/MEM CH counter-clockwise to 9-2. The display should say "t iF - GA 
in" This is the transmit IF gain menu.

Turn the SUB VFO knob clockwise one position to  " t iF - 018". This is the 
1.8MHz transmit IF gain.

Press the ALC/COMP meter selector until the bar graph says "ALC".  Set RF PWR 
knob to full power.

With the radio 

Re: [wsjt-devel] Does the FT8 signal spike at the beginning of each transmission?

[Paul Randall]

Start-of- transmission power spikes will almost certainly occur on any radio 
which is using traditional alc to control output power. Spike severity is 
directly linked to the amount of gain reduction the alc is giving. For example, 
 a 100w rig with power output reduced to 5w using a power control which 
operates via the alc system can be almost relied upon to produce 100w spikes at 
start of transmission. No brainer.

The best way to avoid spikes in any rig using FT8 is to carefully adjust audio 
drive level in the software until desired power output is obtained without the 
rig applying any alc at all. In this way overall system gain is only sufficient 
to produce desired power and no more - so spikes are eliminated and you get a 
cleaner transmission.

That said, I say again that I can exactly  reproduce this problem at will on 
160m where my antenna system clearly puts large voltage onto the cable between 
the pc and the rig. My interface uses industrial quality logic isolators for 
civ and ptt together with audio isolation transformers and dozens of ferrite 
rings on tuner - rig - pc cables.  RFI still gets through and kills the usb 
connection on 160m.  To cure this I will rethink the 160m antenna which I 
suspect is the easiest way.

Regards Paul G3NJV

Sent from my Samsung Galaxy smartphone.


 Original message 
From: Bill Barrett 
Date: 12/04/2019 18:11 (GMT+00:00)
To: fr...@fkirschner.net, WSJT software development 

Subject: Re: [wsjt-devel] Does the FT8 signal spike at the beginning of each 
transmission?

>From W8JI.com, maybe 5000 has similar adjustments. If the IF Transmit Gain was 
>too high the 1000 would exhibit huge power spikes on key down or pressing the 
>mike PTT button.

Transmit Gain Menus

The FT-1000 MK V  has hidden transmit gain menus. They are accessed by pushing 
and holding FAST and LOCK while turning the POWER switch on. Both of my MK V's  
and every MK V serviced here has had the TX IF gain set too high. This causes 
first character clicks on CW and spits and splatter on SSB.  Here is how to 
correct the IF gain to prevent ALC clipping on leading edges of CW and voice:

Press and hold FAST and LOCK before and during initial POWER on.

Press FAST and ENT at the same time. You are now in the MENU's and the display 
should say "0-1 GrPI-cH".

Turn the VRF/MEM CH counter-clockwise to 9-2. The display should say "t iF - GA 
in" This is the transmit IF gain menu.

Turn the SUB VFO knob clockwise one position to  " t iF - 018". This is the 
1.8MHz transmit IF gain.

Press the ALC/COMP meter selector until the bar graph says "ALC".  Set RF PWR 
knob to full power.

With the radio on CW and a 50 ohm dummy load connected, close the key and 
adjust the MAIN VFO-A knob until the ALC display is about 75-85% of full scale 
on the illuminated bar marked "ALC".

Press the next band button (3.5), make sure the radio is still  on CW, and turn 
the SUB VFO-B knob clockwise one band to "t iF - 035".

Again adjust MAIN VFO-A until ALC is at 75-85% of full scale.

Repeat this process through all bands.

Most radios I have tested require a setting of 2 to 4 on TX IF gain, with 3 
being the most common setting.

This change will reduce SSB bandwidth and distortion. It will also reduce 
keyclicks and annoying thumps on the leading edge of each Morse character.

 Hope this helps;

Bill W2PKY

On Fri, Apr 12, 2019 at 12:38 PM Frank Kirschner 
mailto:frank.kirsch...@gmail.com>> wrote:
Some rigs, even high-end rigs including the FTdx5000, exhibit a spike on 
initial transmit. I noticed it mostly with the amp. The power would surge 
briefly, and then return to the dial value.

I suspect the combination of the surge and a bit of RFI is causing the problem. 
I suggest an opto-isolator on both ends of your CAT cable. They are available 
for RS-232 and USB. That, plus some ferrites along the run should help with the 
problem. Also, if you're using a desktop, try running several ground straps to 
the case of the computer. Consumer-grade computers aren't very resistant to 
RFI, and there is no bonding between the pieces of sheet metal.

73,
Frank
KF6E
___
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] Does the FT8 signal spike at the beginning of each transmission?

[Paul Randall]

Ed

I can reproduce this on my setup where my antenna is not good for 160m - 
causing bad RFI which crashes the USB audio link to the PC. If I start 
transmission on 160m with very low power and ease it up I get almost to full 
power before the link fails.



I’ve seen no evidence of a spike, actually my observation suggests the 
commencement of audio seems to be shaped to avoid one.



My guess is that you have RF feedback problems.



Kind regards

Paul G3NJV



Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10




From: Ed Stokes 
Sent: Friday, April 12, 2019 7:05:54 AM
To: WSJT software development
Subject: [wsjt-devel] Does the FT8 signal spike at the beginning of each 
transmission?

I’m curious about something I observe about the FT8 signal modulation.

It appears to produce a pronounced spike in the audio at the beginning of each 
15 second transmission.

When I operate on 160, 80 and 40 meters especially this spike will cause the 
program to stop producing audio.  My computer, a mac mini, is relatively close 
to the 160m dipole being used on these bands, about 50 feet.

If I throttle back to -41 dB or so I can make the transmission begin without 
stopping the audio, although the spike is still evident.

If I then gradually increase the “Pwr” slider I can increase the power without 
causing the audio to crash.

If I leave the power increased the audio will crash immediately after the next 
transmission period begins.

Is this a known problem?

73, Ed
W1KOK

___
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] Error in Sound Output Message

[Paul Randall]

Hi, as others have suggested, almost certain reason for this is during the 1 – 
2 seconds of transmit that you got, your RF took out the USB link between sound 
card and PC.

I can generate this problem on demand just by trying to operate on 160m where 
my loop antenna is extreme high impedance and the rig gets “hot” to RF.

Quit WSJT, unplug the USB interface and replug after a few moments, restart 
WSJT and if necessary use “menu-settings-audio” to direct audio connections 
back to the USB interface should get everything working on Rx.

Of course the RFI problem on TX still needs to be fixed. Check all your 
grounding and run an antenna analyser to see if anything changed out there. As 
suggested, moving stuff around, a bad ground connection, even wind and rain can 
push a marginal system over the edge. Working portable as VK2/G3NJV with a 
simple wire antenna, the dog used to run over and move the tuned radial wires 
lying on the grass and up would pop this problem even though everything worked 
fine just before.

Cheers
73s Paul G3NJV


From: Richard Solomon 
Sent: Saturday, April 6, 2019 3:30:32 PM
To: wsjt-devel
Subject: [wsjt-devel] Error in Sound Output Message

Everything was working fine yesterday, turned the rig on tday, tried to call
a station, Transmit was aborted about 1-2 seconds into the call.

This error message popped up:

[cid:b5548389-7bda-4cc5-8ef8-073d197cddd3]

Any idea on the cause ?

Tnx, Dick, W1KSZ

Sent from Outlook<http://aka.ms/weboutlook>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] VFO-B behavior

[Paul Kube]

"  perhaps there should be a note in the User Manual that, at least
for Icom rigs, the 'Fake It' split mode is preferred/recommended?"

"Rig" mode works fine with my IC-7200 and IC-7300.

73, Paul K6PO

On Mon, Mar 4, 2019 at 1:45 PM Martin Davies G0HDB 
wrote:

> On 4 Mar 2019 at 4:51, Black Michael via wsjt-devel wrote:
>
> > Both conditions need to fixed.  VFO-A needs to be set as selected VFO
> > and VFO-B set to the split freq at all times.  Otherwise a tune
> > instigated from an external source will be on the wrong frequency.And
> > yes...I know you can click Tune in WSJT-X and then VFO-B gets
> > set...but that leaves the amplifier in-line with too much power to
> > tune and for some could fry the amplifier.
> > Mike
>
> Hi Mike (and all), for what it's worth I've found that using the 'Fake It'
> split mode, rather than
> the 'Rig' mode, works best with my Icom IC-7600.
>
> Some years ago, when I first tried using the 'Rig' mode with WSJT I found
> that the time taken
> to switch VFOs (from A to B in my case) and then to re-tune the
> newly-selected VFO with the
> desired offset (eg. +1kHz) was significantly longer than just re-tuning
> the active VFO,
> presumably because there was a longer command sequence to be received,
> processed and
> then actioned by the rig.  The delay in the rig switching VFOs and then
> re-tuning was
> resulting in the transmission not starting until (IIRC) some 2-3secs into
> a Tx period.
>
> I would assume that using the 'Fake It' mode would work equally well
> irrespective of which
> VFO was the active one, so perhaps there should be a note in the User
> Manual that, at least
> for Icom rigs, the 'Fake It' split mode is preferred/recommended?
>
> --
> 73, Martin G0HDB
>
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>
>
>
> ___
> 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] VFO-B behavior

[Paul Kube]

If VFO-B is the active VFO and you switch bands on WSJT-X only VFOB gets
set...VFOA does not change..


The same is true if VFO-A is the active VFO; VFO-B does not get set with a
band change until you transmit.

I just hit WSJT-X's "Tune" button for a second when switching bands. Works
fine on the IC-7300 with tune-on-PTT enabled.

73 Paul K6PO

On Sun, Mar 3, 2019 at 12:56 PM Black Michael via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> Found an undesirable behavior that I think can be easily fixed.
>
> On ICOM rigs hamlib assumes split is always on VFOB to cover rigs without
> status commands...as does FLRig (and perhaps others).
>
> If VFO-B is the active VFO and you switch bands on WSJT-X only VFOB gets
> set...VFOA does not change...so it appears to do a reverse split and tuning
> can, of course, be way off depending on where VFOA is sitting.  Once you
> click transmit VFOA does get changed but by then it can be too late for
> your tuner.
>
> I believe all that we need to do is make VFOA the active VFO when
> switching bands before any frequencies are set.  Is there any reason not to
> make VFOA the active one?
>
> de Mike W9MDB
>
>
>
>
> ___
> 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] WD timer engages even on reply

[Paul Kube]

I've noticed this "nit" too. Consider this another vote in favor of the
change Richard proposed.

73, Paul K6PO

On Sat, Mar 2, 2019 at 5:50 AM Richard Shaw  wrote:

> Small nit...
>
> I use my WD timer to limit the number of time I try to reach a station, I
> currently have it set to 3 minutes. One thing I've noticed is that the WD
> timer still kills TX if the station responds on the cycle following the WD
> timer running out.
>
> I assume it would not be difficult to check for a response before killing
> TX?
>
> Thanks,
> Richard
> KF5OIM
> ___
> 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] Sudden call replacement

[Paul Randall]

Hi Phil, this happens to me 2 or 3 times in a session.
To be specific, all message boxes are always correctly filled with the my own 
and my qso partners callsigns. When the problem occurs, the message appears in 
the "rx frequency" window with the qso partners callsign replaced with someone 
elses.  Sometimes this completely prevents calling a particular station as the 
"wrong" callsign goes out right from the start in message 1. Other times the 
switch occurs mid qso and usually causes the qso to get stuck in an endless 
exchange of messages. It is what I described as "callsign hijacking" in my 
email of 24th January this year.
I have found the only reliable way to escape the condition is abandon the qso 
and stop trying to work that station as the condition recurs if you come back 
some time later for another try. On one occasion I was able to complete the qso 
by editing the outgoing message 5 box to swap the angle brackets <> from the 
affected callsign to the other.



73 Paul VK2/G3NJV



Sent from my Samsung Galaxy smartphone.
 Original message 
From: t...@gmx.fr
Date: 07/02/2019 03:53 (GMT+10:00)
To: wsjt devel list 
Subject: [wsjt-devel] Sudden call replacement

Hi,

I was having QSO with 3G3G.

All of a sudden the call 3G3G was replaced by IV3ONZ on the same frequency.

I tried to restore the proper call sign by clicking on the call sign in the Rx 
Frequency box. No ways!

Strangely, just after I did it, <3G3G>  ZS1/F5FDV RRR appeared in the Tx4 box 
but it was  ZS1/F5FDV RRR that was displayed in the Rx Frequency box.

Screen copy attached.

73
Phil F5FDV

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

[wsjt-devel] About that watchdog...

[Paul Kube]

I like enabling the Tx Watchdog. It is pretty much essential, in my opinion.

But there there are things that should be changed about the user interface
to it.

The watchdog can now only be adjusted in whole-minute increments. This made
sense with the one-minute transmit cycle of the older modes, but not so
much with FT8's 15 second cycle.

I'd suggest changing the Tx Watchdog units under Settings to "Tx cycles".
More intuitive to me at least, I think of it in terms of the number of the
maximum times I will try a message before giving up, rather than limiting
the time I spend doing it.

Then also the Watchdog progress output... Now it's just an integer
countdown of whole minutes in the far bottom left corner of the main
window. This should show Tx cycles remaining. A bar graph might be nice,
but it would need more horizontal space.

Anyway, just a suggestion.

73, Paul K6PO
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT Reporting to PSK Reporter

[Paul Randall]

Bill, many thanks for providing the link to that information, your suggestion 
works thank you.

I’m not sure what you mean by “ ..not bother reading..” as following the link 
you gave in your email allowed me to see your message for the first time.

My experience of trying to send own messages either by using the second tab or 
in message 5 is not good. I find juggling the drop down box, correcting the 
“enable tx” button, disabling auto sequence and retyping when the program 
overwrites what I typed before, all in 15 seconds results in lots of incorrect 
standard messages along with truncated and garbage own messages being 
transmitted.  Trying out your suggestion today I found another complication, 
after selecting my own tx macro in message 5, using the mouse to select “File – 
Settings – any tab do nothing - click OK” switches on the auto-sequence box and 
resets message 5.

Many thanks for taking the time to answer my query, my time here in Australia 
is coming to an end so with a standard callsign hopefully I will not need so 
many workarounds in future.

Best 73, Paul G3NJV




Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10


From: Bill Somerville 
Sent: Thursday, January 31, 2019 10:34:59 AM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] WSJT Reporting to PSK Reporter

On 30/01/2019 23:23, Paul Randall wrote:
Bill, in one of your messages to Phil you wrote “...You can be spotted on PSK 
Reporter using a non-standard callsign by using one of the mechanisms I stated 
above” Where can I see those mechanisms please?

Paul,

it was this message a few days back:

https://sourceforge.net/p/wsjt/mailman/message/36526197/

follow the links therein, in fact one of the links is to a reply I gave to one 
of your prior queries on this issue which apparently did not bother reading.

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

Re: [wsjt-devel] WSJT Reporting to PSK Reporter

[Paul Randall]

Hi Phil
It says in the WSJT v2 user guide section 7.5 “WSJT-X 2.0 offers no support for 
two nonstandard callsigns to work each other” so this is a well known 
limitation.

I do not understand the logic that WSJT does not give reception reports to PSK 
reporter unless a QRA and callsign exist in a single message whereas all QSOs 
made with my type B callsign are valid without any QRA locator information 
being exchanged at all?

I wonder if anyone else has experienced what I call “callsign hijacking” where 
mid way through a QSO you start transmitting the wrong “other station” 
callsign. The message boxes are all filled correctly yet the wrong callsign 
appears to be transmitted and brings the QSO to a halt. Restarting the program 
and abandoning the QSO seems to be the only way to stop it. Presumably this is 
an unwanted result of using hash codes.

As it stands v2.0.0 does a lot for “normal” callsign holders but is really 
quite tricky if you have a type B callsign.  I have used FT8 a lot whilst 
operating from Australia with simple wire antennas and it has allowed me to 
work around the globe. However, tuning across 17m this evening the band was 
absolutely empty - until I hit 18100 and the S meter almost hit the stops. For 
a weak signal mode there are a lot of powerful stations crowded into that 3kHz 
and I felt sad the popularity of FT8 seems to have emptied the band of SSB 
stations.

Paul G3NJV

Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10


From: t...@gmx.fr 
Sent: Thursday, January 24, 2019 7:26:59 PM
To: wsjt-devel@lists.sourceforge.net
Cc: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] WSJT Reporting to PSK Reporter

Hi,

Paul, I have the same issue when I use the call ZS1/F5FDV.

Since december last year I was wondering why I get only few reports from 
PSKReporter.
Your post provides a very relevant the explanation, in my opinion.

Reporting went well with revisions prior to 2.0.

It seems consistent with the statement that it is now impossible to make proper 
QSO between two type B stations (see previous posts from me to the group). I 
think that there is a weakness in the coding or decoding of type B call signs. 
Decoding maybe, because reporting of these stations by WSJT-X to PSKReporter do 
no happen.

73,

Phil F5FDV

Envoyé: jeudi 24 janvier 2019 à 03:50
De: "Paul Randall" 
À: "wsjt-devel@lists.sourceforge.net" 
Objet: [wsjt-devel] WSJT Reporting to PSK Reporter
 Hi, I got this address from the WSJT website. I am new to this group 
and not sure of the protocols. I tried emailing yesterday but am unsure if this 
was received.

I am operating as VK2/G3NJV. After upgrading to v2.0.0 I found reports of my 
transmissions almost disappeared from PSK Reporter. I now get just a handful of 
reports all from stations NOT using WSJT. Most of these come from stations 
using “Red Pitaya FT8 TRX 1.0”. I spoke to Philip Gladstone about this and he 
told me that WSJT does not send reception reports to PSK Reporter unless it 
receives callsign and locator in a single message. It is impossible for me to 
transmit a message like this. Because I have a type B callsign, all that will 
fit in a single message is “CQ VK2/G3NJV”

This seems a particularly harsh outcome for type B callsign holders upgrading 
to v2.0.0. who, like me, are often operating portable stations with makeshift 
antennas where reception reports are extremely valuable. The reports from 
stations using a Red Pitaya are perfectly acceptable and I’m not sure of the 
reasoning behind the current WSJT “callsign + QRA” rule. Would it be possible 
to modify this to allow reception reports for type B callsigns received without 
a QRA?

Many thanks for your attention.
Paul Randall
G3NJV

PS After completing this email I checked the PSK Reporter website again. Sure 
enough there were just 5 reception reports, four from monitors using Red Pitaya 
but also a single report from K1HTV  using WSJT-X v2.0.0 784f75. This is the 
only WSJT reception report seen since 10 December so now I’m not sure what is 
going on!
___ 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 Reporting to PSK Reporter

[Paul Randall]

 Hi, I got this address from the WSJT website. I am new to this group 
and not sure of the protocols. I tried emailing yesterday but am unsure if this 
was received.

I am operating as VK2/G3NJV. After upgrading to v2.0.0 I found reports of my 
transmissions almost disappeared from PSK Reporter. I now get just a handful of 
reports all from stations NOT using WSJT. Most of these come from stations 
using “Red Pitaya FT8 TRX 1.0”. I spoke to Philip Gladstone about this and he 
told me that WSJT does not send reception reports to PSK Reporter unless it 
receives callsign and locator in a single message. It is impossible for me to 
transmit a message like this. Because I have a type B callsign, all that will 
fit in a single message is “CQ VK2/G3NJV”

This seems a particularly harsh outcome for type B callsign holders upgrading 
to v2.0.0. who, like me, are often operating portable stations with makeshift 
antennas where reception reports are extremely valuable. The reports from 
stations using a Red Pitaya are perfectly acceptable and I’m not sure of the 
reasoning behind the current WSJT “callsign + QRA” rule. Would it be possible 
to modify this to allow reception reports for type B callsigns received without 
a QRA?

Many thanks for your attention.
Paul Randall
G3NJV

PS After completing this email I checked the PSK Reporter website again. Sure 
enough there were just 5 reception reports, four from monitors using Red Pitaya 
but also a single report from K1HTV  using WSJT-X v2.0.0 784f75. This is the 
only WSJT reception report seen since 10 December so now I’m not sure what is 
going on!
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] FW: WSJT-X V2.0.0 WINDOWS 10 REPORT

[Paul Randall]

Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10


From: Paul Randall
Sent: Wednesday, January 23, 2019 9:38:41 AM
To: wsjt-devel@lists.sourceforge.net
Subject: WSJT-X V2.0.0 WINDOWS 10 REPORT

Hi, I am operating as VK2/G3NJV and discover that because I am a type B 
callsign, I cannot include my callsign and QRA locator in a single message. 
This in turn prevents anyone using WSJT-X V2.0.0 from reporting to PSK 
Reporter. I have spoken to Philip Gladstone about this and he confirms that the 
current version requires callsign and locator in a message before reporting.

Using V1.9 there was not this problem. Monitor stations using Red Pitaya 
software also do not have this problem and these are the only reception reports 
that I can get – perhaps a dozen globally.

This seems a particularly harsh outcome for type B callsign holders who, like 
me, are often operating portable stations with makeshift antennas where 
reception reports are extremely valuable. I’m sure it would only take a line or 
two of code to allow class B callsigns to be reported without the QRA 
information, as Red Pitaya does.

Many thanks for your attention.
Paul Randall
G3NJV

Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986>for Windows 10

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

Re: [wsjt-devel] Short Tx inhibits decode...

[Paul Kube]

> Try turning it on its head, Paul.  Pre-decide NOT to transmit on the
*next* cycle by deselecting

> Enable Tx during the *current* cycle … unless you spot something in the
decodes that

> makes you change your mind, in which case you reselect Enable Tx.


Hi Gary, yes; but letting auto seq run works just fine most of the time.
Toggling Enable off only to toggle it on at the beginning of the next cycle
is very often superfluous. Plus it requires thinking ahead a bit, which I
find I'm not always able to do.


Anyway, I have my vote in for getting decode to work, if possible, in
cycles where transmit has been halted in the first few seconds.


Thanks!


73, Paul K6PO



On Thu, Jan 17, 2019 at 4:11 PM Gary Hinson  wrote:

> Try turning it on its head, Paul.  Pre-decide NOT to transmit on the
> *next* cycle by deselecting Enable Tx during the *current* cycle … unless
> you spot something in the decodes that makes you change your mind, in which
> case you reselect Enable Tx.
>
>
>
> Slightly delayed transmissions are generally decoded OK.  You have about 5
> seconds to make your mind up.  Beyond that, your transmissions *may* not
> be decoded (but you might still be lucky!).
>
>
>
> [Another handy thing about delayed starts is that you can see whether your
> transmit frequency is busy or clear during the periods when you would
> otherwise be transmitting.]
>
>
>
> We’re not saying your change proposal is unnecessary, unhelpful or not a
> good idea, simply offering a pragmatic workaround that gives most of the
> user benefit with none of the development costs.
>
> 73
> Gary  ZL2iFB
>
>
>
> *From:* Paul Kube 
> *Sent:* 18 January 2019 11:05
> *To:* WSJT software development 
> *Subject:* Re: [wsjt-devel] Short Tx inhibits decode...
>
>
>
> Gary and Gary,
>
>
>
> But I want to stop transmitting near the start of a cycle, and still see
> decodes from that cycle. As you point out, deselecting Enable doesn't do
> that.
>
>
>
> The problem arises when I don't know whether I want to continue
> transmitting until I see the decodes from a cycle. For examples: I called a
> station off frequency, and I see they didn't hear me and I'd rather not
> call again. Or, I'm calling CQ, see no replies, and I don't want to CQ
> again. It takes me a second or two to look at the decode list and decide I
> want to listen instead of transmit. So autosequence has me transmitting a
> little into the start of the next cycle, but I want to stop and see decodes
> in that cycle instead.
>
>
>
> Both of those examples could be handled better and faster by options
> within WSJT-X, so if that were implemented with checkboxes I'd be pretty
> happy. (Already happens with on-frequency calls to a CQing station.) Which
> might be easier than modifying the decode code to handle starting late in a
> cycle, I don't know.
>
>
>
> 73, Paul K6PO
>
>
>
> On Thu, Jan 17, 2019 at 1:43 PM Gary Hinson  wrote:
>
> Friends,
>
>
>
> Try deselecting *Enable Tx* prior to the start of the next cycle instead
> of hitting the *Halt Tx* button.  Think of the *Halt Tx* button as a big
> angry red emergency stop button that slams the brakes on and drops
> everything.  It drops the anchor.
>
>
>
> Deselecting Enable TX is not so abrupt, and not so tight on timing: if you
> deselect it at any point in a transmission, the remainder of that
> transmission continues to the end as normal but your *next* transmission
> doesn’t happen.  It’s more elegant.  More refined.  Less screeching of
> tyres.
>
>
>
> Find this and other pragmatic tips in the FT8 Operating Guide
> <http://www.g4ifb.com/FT8_Hinson_tips_for_HF_DXers.pdf>.
>
>
>
> 73,
>
> Gary   ZL2iFB
>
>
>
>
>
> *From:* WB5JJJ 
> *Sent:* 18 January 2019 10:12
> *To:* WSJT software development 
> *Subject:* Re: [wsjt-devel] Short Tx inhibits decode...
>
>
>
> I've noticed that as well.  Been this way for many versions back.  Once
> the Tx cycle has been initiated (i.e. odd or even Tx has started), and if
> you then click Halt Tx, the radio will go to receive, the WF will show the
> signals, but none are decoded for the aborted Tx cycle.  At the start of
> the next cycle, all is normal.
>
>
>
> WB5JJJ - George
>
>
>
> On Thu, Jan 17, 2019 at 3:01 PM Paul Kube  wrote:
>
>
>
> If I cancel my own transmission right at the beginning of a cycle, I see
> no decodes at all for that cycle.
>
>
>
> For example, say I'm CQing on even cycles. After a couple, I decide I want
> to stop CQing if I don't get any replies, so I hit Halt Tx as soon as I see
> the list of decodes from a just-finished odd cycle. Maybe I

Re: [wsjt-devel] is this hash error?

[Paul Kube]

Jari, This seems to be a known issue. See
https://sourceforge.net/p/wsjt/mailman/message/36518222/.

73, Paul K6PO

On Fri, Jan 18, 2019 at 5:26 AM Jari A  wrote:

> Did I experience another hash error?
>
> Had one previously, but thought it was a glitch, now I had this again:
> Just to let you know, as this is repeatable within certain conditions, but
> if I understood right, this is noted previously?
>
> Good weekend,
>
> :Jari
>
> 130930 -4 -0.2 1787 ~ CQ PA3HGL/QRP  Netherlands
>
> 130951 Tx 1787 ~  OH2FQV
>
> 131015 Tx 1787 ~  OH2FQV
>
> 131030 -4 0.1 1787 ~ OH2FQV  -03
>
> 131045 Tx 1787 ~  OH2FQV R-04
>
> 131100 -12 0.2 1787 ~  PA3HGL/QRP RR73
>
> 131115 Tx 1787 ~  OH2FQV
>
> 131145 Tx 1787 ~  OH2FQV
>
> 131200 -9 0.1 1788 ~ OH2FQV  -05
>
> 131215 Tx 1787 ~  OH2FQV R-09
>
> 131245 Tx 1787 ~  OH2FQV R-09
>
> 131300 -6 0.1 1787 ~  PA3HGL/QRP RR73
>
> 131315 Tx 1787 ~  OH2FQV
>
> 131345 Tx 1787 ~  OH2FQV
>
> 131358 Tx 1787 ~ PA3HGL/QRP  73
>
> 131418 Tx 1787 ~ DE OH2FQV 73
>
> 131500 8 0.1 1785 ~ OH2FQV  -06
>
> 131600 0 0.1 1785 ~ OH2FQV  -06
>
> 131615 Tx 1787 ~  OH2FQV R+00
>
> 131630 0 0.1 1785 ~  PA3HGL/QRP RR73
>
> 131645 Tx 1785 ~  OH2FQV
>
> 131649 Tx 1785 ~ PA3HGL/QRP  RR73
>
> 131650 Tx 1785 ~ PA3HGL/QRP  RRR
>
> 131715 Tx 1785 ~ DE OH2FQV 73
> ___
> 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] Short Tx inhibits decode...

[Paul Kube]

If I cancel my own transmission right at the beginning of a cycle, I see no
decodes at all for that cycle.

For example, say I'm CQing on even cycles. After a couple, I decide I want
to stop CQing if I don't get any replies, so I hit Halt Tx as soon as I see
the list of decodes from a just-finished odd cycle. Maybe I am transmitting
for a second or two into the adjacent even cycle; but there are never any
decodes from it at all even when lots of signals are present in the
waterfall.

Naively, it seems to me that this doesn't need to happen. I often see FT8
decodes for stations that start late -- as much as 4 seconds late -- in a
cycle. So why does missing the first second or two prevent decoding
anything?

If this could be changed, it would be nice. A few of those wasted 15
seconds add up!

Thanks, and 73,

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

Re: [wsjt-devel] Strange hash collision?

[Paul Kube]

Bill,

Then I don't understand why the hashcode for my call isn't used. It is
known, or my call wouldn't be correctly decoded in those two received
messages. Or so it seems to me.

73, Paul K6PO


On Tue, Jan 15, 2019 at 4:11 PM Bill Somerville 
wrote:

> On 16/01/2019 00:02, Paul Kube wrote:
> > But why is my call hashed wrong in my own Rx Frequency window?
>
> Hi Paul,
>
> hash codes are just numbers, what you see is a lookup of a table indexed
> by the hash code. The wrong call is being looked up and printed. There
> is nothing wrong with the hash code, just a problem with how it is
> translated to a callsign.
>
> 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] Strange hash collision?

[Paul Kube]

Have a look at this QSO between me (K6PO) and K8CHY/4:

[image: hashdecode.PNG]

The strangeness is in my transmissions at 23 and 230030, where 
appears instead of . When my QSO partner's transmissions are decoded,
 appears as it should. I guess he was able to decode my transmissions
all right. But why is my call hashed wrong in my own Rx Frequency window?

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

Re: [wsjt-devel] problem building wsjtx-2.0.0 from source on Ubuntu

[Paul Milligan]

Hi Bill,
many thanks for pointing out my mistaking that my Ubuntu has the right qt 
version.

Looks like I'll need to upgrade my Ubuntu OS.
I'm usually hesitant in upgrading because it sometimes breaks some specially built 
software that needs the older libs.


73,
Paul  K6WIS


Paul A. Milligan
mailto:millp...@sbcglobal.net
tel: 669-342-7335


Bill Somerville wrote:

On 04/01/2019 17:51, Paul Milligan wrote:
I have all the necessary prerequisite  tools and libraries installed on my Ubuntu 
14.04LTS laptop,


Hi Paul,

that is not correct, you do not have all the necessary prerequisites. Quoted from 
the WSJT-X source tarball INSTALL file:


Installation


To  build WSJT-X  from sources  you need  some prerequisite  tools and
libraries.

On Linux:

build-essentials
gcc-4.8.2 or clang-3.4 or newer
g++-4.8.2 or clang-3.4 or newer
gfortran-4.8.2 or newer
CMake-2.8.9 or newer
git
svn
asciidoc

*Qt5.5 or newer*, qt5libmultimedia-dev,  qt5libserialport-dev,  and
their  prerequisites   libfftw3-single-dev  and   its  prerequsites
libusb-0.1-dev.  Note that  these are  Debian style  package names,
other distributions  will have different package  names and package
contents.

My emphasis, the version of Qt required changed for WSJT-X v2.0.0. Ubuntu 14.04 only 
has Qt v5.2.1. I strongly suggest you upgrade you Linux version. Either 16.04 LTS or 
18.04 LTS are fine. Ubuntu 14.04 is EOL quite soon.


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] problem building wsjtx-2.0.0 from source on Ubuntu

[Paul Milligan]

I'm having a problem building the latest version wsjtx-2.0.0 from source tarball

I have all the necessary prerequisite  tools and libraries installed on my Ubuntu 
14.04LTS laptop,

and I previously built wsjtx-1.9.1 from the source tarball with no problems.

But for version 2.0.0:
No problem with the first step of cmake.
Then on the second cmake step (cmake --build .) everything was going fine, until it 
got 80% of the way, and started with the qt stuff:

Excerpt from cmake log:

 [ 80%] Building CXX object CMakeFiles/wsjt_qt.dir/MetaDataRegistry.cpp.o
In file included from 
/home/paul/Ham/software/wsjtx-2.0.0/wsjtx-prefix/src/wsjtx/models/FrequencyList.hpp:10:0,
 from 
/home/paul/Ham/software/wsjtx-2.0.0/wsjtx-prefix/src/wsjtx/MetaDataRegistry.cpp:8:
/home/paul/Ham/software/wsjtx-2.0.0/wsjtx-prefix/src/wsjtx/models/IARURegions.hpp:46:17: 
error: ISO C++ forbids declaration of ‘Q_ENUM’ with no type [-fpermissive]

   Q_ENUM (Region)

followed by 12 other similar errors.

I'm wondering if I'm the only one getting this cpp compile error, or is it 
widespread?
And what can be done to fix it?

Regards,
Paul K6WIS

--

Paul A. Milligan
mailto:millp...@sbcglobal.net
tel: 669-342-7335

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

Re: [wsjt-devel] installing v. 2.0.0 on Debian stretch

[Paul Bramscher]

> On December 18, 2018 at 7:14 PM Paul Bramscher  wrote:
> 
> 
> On 12/18/2018 10:21 AM, Rich Griffiths wrote:
> > I'd like to chat with someone who has a working install of version 2.0.0
> > on Debian stretch.  If you're interested, please contact me off-list at
> > rich-at-w2rg-dot-net.
> > 
> > 73
> > 
> > ... Rich   W2RG
> > 
> 
> Here's what I've been doing with WSJT-X 2.0.0 on Debian stretch.  These
> steps assume you'll not be compiling with local/integrated
> documentation.  That entails numerous extra dependencies (though I have
> waded through it) and more disk space.  I just use the online docs.
> 
> It also suggests a directory structure similar to what Greg's JTSDK
> employed, so you can have multiple instances for different future minor
> dot releases.  Optional, and the directory names can be changed to
> something appropriate.  The names "build" and "install" for
> subdirectories work for me.
> 
> $HOME/
>   wsjtx/
>   wsjtx-2.0.0/
>   build/
>   wsjtx-2.0.0/ (source)
>   install/ (compiled executables)
> 
> 1) Install dependencies
> 
> sudo apt install build-essential git cmake gfortran libfftw3-dev \
> qtbase5-dev libqt5serialport5-dev libqt5multimedia5-plugins \
> libqt5sql5-sqlite autoconf automake libtool texinfo libusb-1.0-0-dev \
> libudev-dev qtmultimedia5-dev
> 
> 2) Download the source .tgz file from SourceForge or the project's main
> site (my browser puts it into ~/Downloads by default).  Setup the
> directory structure, copy the source and unpack it (change for
> different/future versions as needed):
> 
> mkdir -p ~/wsjtx/wsjtx-2.0.0/build
> mkdir -p ~/wsjtx/wsjtx-2.0.0/install
> 
> cd ~/wsjtx/wsjtx-2.0.0/build
> cp ~/Downloads/wsjtx-2.0.0.tgz .
> tar xf wsjtx-2.0.0.tgz
> 
> 3) Configure the package:
> 
> cd ~/wsjtx/wsjtx-2.0.0/build/wsjtx-2.0.0
> 
> cmake -DCMAKE_INSTALL_PREFIX=../../install/ -DWSJT_SKIP_MANPAGES=ON
> -DWSJT_GENERATE_DOCS=OFF ../wsjtx-2.0.0
> 
> 4) Compile the package:
> 
> cmake --build ~/wsjtx/wsjtx-2.0.0/build/wsjtx-2.0.0 --target install -- -j
> 
> 5) Execute:
> 
> cd  ~/wsjtx/wsjtx-2.0.0/bin
> ./wsjtx

Slight correction -- it should read like this:

cd  ~/wsjtx/wsjtx-2.0.0/install/bin
./wsjtx


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

Re: [wsjt-devel] installing v. 2.0.0 on Debian stretch

[Paul Bramscher]

On 12/18/2018 10:21 AM, Rich Griffiths wrote:
> I'd like to chat with someone who has a working install of version 2.0.0
> on Debian stretch.  If you're interested, please contact me off-list at
> rich-at-w2rg-dot-net.
> 
> 73
> 
> ... Rich   W2RG
> 

Here's what I've been doing with WSJT-X 2.0.0 on Debian stretch.  These
steps assume you'll not be compiling with local/integrated
documentation.  That entails numerous extra dependencies (though I have
waded through it) and more disk space.  I just use the online docs.

It also suggests a directory structure similar to what Greg's JTSDK
employed, so you can have multiple instances for different future minor
dot releases.  Optional, and the directory names can be changed to
something appropriate.  The names "build" and "install" for
subdirectories work for me.

$HOME/
wsjtx/
wsjtx-2.0.0/
build/
wsjtx-2.0.0/ (source)
install/ (compiled executables)

1) Install dependencies

sudo apt install build-essential git cmake gfortran libfftw3-dev \
qtbase5-dev libqt5serialport5-dev libqt5multimedia5-plugins \
libqt5sql5-sqlite autoconf automake libtool texinfo libusb-1.0-0-dev \
libudev-dev qtmultimedia5-dev

2) Download the source .tgz file from SourceForge or the project's main
site (my browser puts it into ~/Downloads by default).  Setup the
directory structure, copy the source and unpack it (change for
different/future versions as needed):

mkdir -p ~/wsjtx/wsjtx-2.0.0/build
mkdir -p ~/wsjtx/wsjtx-2.0.0/install

cd ~/wsjtx/wsjtx-2.0.0/build
cp ~/Downloads/wsjtx-2.0.0.tgz .
tar xf wsjtx-2.0.0.tgz

3) Configure the package:

cd ~/wsjtx/wsjtx-2.0.0/build/wsjtx-2.0.0

cmake -DCMAKE_INSTALL_PREFIX=../../install/ -DWSJT_SKIP_MANPAGES=ON
-DWSJT_GENERATE_DOCS=OFF ../wsjtx-2.0.0

4) Compile the package:

cmake --build ~/wsjtx/wsjtx-2.0.0/build/wsjtx-2.0.0 --target install -- -j

5) Execute:

cd  ~/wsjtx/wsjtx-2.0.0/bin
./wsjtx

Optional:
I use the MATE desktop and create a launcher icon for each version that
I've compiled under ~/wsjtx/wsjtx-2.x.x/.  I just reference the wsjtx
executable (in install/bin) and pixmap icon for each version (in
install/share/pixmaps).

I've thought about tossing these steps into a script to minimize typing,
and changing the directories names a bit, but so far it works for me.
Maybe others can chime in with additional suggestions?

73, KD0KZE / Paul


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