Re: [wsjt-devel] WSJT-X & JTSDK future?

[Stephen Ireland]

Hi Bill and Greg,

I am just a little surprised, after some ongoing comms, that the JTSDK 3.0.1 is 
not the prime, standard Windows Development platform  So that everyone is 
on the same page.

Greg, the JTSDK 3.0.1 works a treat... as long as you follow the instructions 
in your main post (#435) at https://groups.io/g/JTSDK/topic/23847651 .

[ It even works with “forks” that use subversion s long as the 32-bit SlikSVN 
client found at  https://sliksvn.com/download/ overwrites the deployed version 
].

Greg, can you please perhaps put these instructions found in #435 somewhere 
clearly and cleanly and in a prominent place for all for guidance? From you it 
gains validity.

Bill, I am of the opinion, with considerable evidential backing, that Qt 5.5 is 
lacking for our needs (as some comms has conveyed); migration and 
standardisation to more contemporary Qt versions are mandated. Note – not 
“bleeding edge” versions, but contemporary versions. We then need to stick 
SOLELY with this version for a while.

Greg, I think that the AR community significantly missed your attention to us. 
Yet it is always a reminder to us all that personal interests must ALWAYS come 
first and that we in the AR community must be patient. Patience is a virtue – 
but not a virtue shared by many in the AR community ☹

If you need a hand, there are many of us here that can and are willing to help 
and contribute. Some of us (including me) may be “pains in the posterior” on 
occasion, but most in our community have their hearts in the right place.

Advancement.

73

Steve I
VK3VM / Vk3SIR

Sent from Mail for Windows 10

From: Greg Beam
Sent: Sunday, 18 November 2018 4:40 PM
To: 'WSJT software development'
Subject: Re: [wsjt-devel] WSJT-X & JTSDK future?

Hi Bill,

Understand all re: points in 1 and 2 below.

As for item 3, JTSDK-Tools (JTSDK v3) uses the Qt Installer for updates / 
adding GCC tool-chains and prebuilt-components. At present, version JTSDK-Tools 
v3.0.1 supports both Qt 5.5 and Qt 5.9. As most would agree, using the Qt 
Maintenance Tool is the preferred method of installing/updating Qt Components. 
Adding Qt 5.10 would require a minimal change to the environment script(s) and 
I may add that to version 3.0.2 to cover future needs. It appears that Qt 5.5 
thru 5.10 all use the 5.3.x GCC tool-chain which simplifies things a good bit.

Most of the JTSDK-Tools installation is manually performed by the user, as this 
allows greater flexibility with installation and updates. The addition of MSYS2 
is a major improvement over the original MSYS as it provides a powerful package 
manager (pacman, from Arch Linux) to keep utilities up to date.

JTSDK-Tools is, for the most part, geared more toward developers rather than 
casual users. The basics are there for anyone wanting to work on whatever 
project they wish. However, it is not a turn-key solution as it was in the past.

73’s
Greg, KI7MT

From: Bill Somerville 
Sent: Saturday, November 17, 2018 2:21 PM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] WSJT-X & JTSDK future?

On 17/11/2018 05:24, Greg Beam wrote:
At this point, I’ve no idea how things are working with WSJT-X builds (Win32 or 
Linux) other than what’s being formally published by the WSJT Dev team.

Hi Greg,

welcome back!

The relevant changes can be summarized as:

1) we are now using git DVCS. I think you are up to speed on this already and 
are aware of the new git repos on the WSJT SourceForge project page. The old 
svn repo is still there but for reference only, no changes have been posted to 
it for some time and it is effectively read-only and frozen.

2) The WSJT-X git repo is only being pushed once for each release shortly after 
the release is announced, we have been forced to do that by some unfortunate 
misuses of unfinished development code. Note that this still goes much further 
that the minimum requirement for Open Source applications, to make their source 
code publicly available matching any public releases, since we still make the 
full change history visible as well to anyone who cares. We realize that this 
somewhat reduces the benefit to those who like to track the latest developments 
by building from pre-release sources, but as it has proved impossible to 
control arbitrary and unauthorized redistribution of incomplete development 
works; we have taken that capability away.

3) The minimum Qt version required to build WSJT-X from WSJT-X v2.0.0 RC4 
onwards in v5.5, this has been moved on so we can take advantage of many Qt 
enhancements. We may well move on again with the minimum Qt version, perhaps to 
v5.9 or even v5.10, this may even be forced upon us to support the latest macOS 
version at some point soon. If and when this happens we will be forced to drop 
support for MS Windows XP and Vista. Continuing to support old versions of Qt 
and old operating 

Re: [wsjt-devel] WSJT-X & JTSDK future?

[Greg Beam]

Hi Bill,

 

Understand all re: points in 1 and 2 below.

 

As for item 3, JTSDK-Tools (JTSDK v3) uses the Qt Installer for updates /
adding GCC tool-chains and prebuilt-components. At present, version
JTSDK-Tools v3.0.1 supports both Qt 5.5 and Qt 5.9. As most would agree,
using the Qt Maintenance Tool is the preferred method of installing/updating
Qt Components. Adding Qt 5.10 would require a minimal change to the
environment script(s) and I may add that to version 3.0.2 to cover future
needs. It appears that Qt 5.5 thru 5.10 all use the 5.3.x GCC tool-chain
which simplifies things a good bit.

Most of the JTSDK-Tools installation is manually performed by the user, as
this allows greater flexibility with installation and updates. The addition
of MSYS2 is a major improvement over the original MSYS as it provides a
powerful package manager (pacman, from Arch Linux) to keep utilities up to
date.

 

JTSDK-Tools is, for the most part, geared more toward developers rather than
casual users. The basics are there for anyone wanting to work on whatever
project they wish. However, it is not a turn-key solution as it was in the
past.

 

73's

Greg, KI7MT

 

From: Bill Somerville  
Sent: Saturday, November 17, 2018 2:21 PM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] WSJT-X & JTSDK future?

 

On 17/11/2018 05:24, Greg Beam wrote:

At this point, I've no idea how things are working with WSJT-X builds (Win32
or Linux) other than what's being formally published by the WSJT Dev team. 

Hi Greg,

welcome back!

The relevant changes can be summarized as:

1) we are now using git DVCS. I think you are up to speed on this already
and are aware of the new git repos on the WSJT SourceForge project page. The
old svn repo is still there but for reference only, no changes have been
posted to it for some time and it is effectively read-only and frozen.

2) The WSJT-X git repo is only being pushed once for each release shortly
after the release is announced, we have been forced to do that by some
unfortunate misuses of unfinished development code. Note that this still
goes much further that the minimum requirement for Open Source applications,
to make their source code publicly available matching any public releases,
since we still make the full change history visible as well to anyone who
cares. We realize that this somewhat reduces the benefit to those who like
to track the latest developments by building from pre-release sources, but
as it has proved impossible to control arbitrary and unauthorized
redistribution of incomplete development works; we have taken that
capability away.

3) The minimum Qt version required to build WSJT-X from WSJT-X v2.0.0 RC4
onwards in v5.5, this has been moved on so we can take advantage of many Qt
enhancements. We may well move on again with the minimum Qt version, perhaps
to v5.9 or even v5.10, this may even be forced upon us to support the latest
macOS version at some point soon. If and when this happens we will be forced
to drop support for MS Windows XP and Vista. Continuing to support old
versions of Qt and old operating system versions will eventually greatly
disadvantage those running on more contemporary operating system versions
and we will only do that for a limited time.

73
Bill
G4WJS.

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

[wsjt-devel] Resolved bugs wsjt-x v2.0.0-rc4 a891ad

[Art Witmans via wsjt-devel]

Thank you VE3FBZ!

You mentioned the hub and it triggered a memory of past issues with hubs.
The reason I used a hub is because the computer-end of the CAT cable for the 
FT897 has the interface circuit moulded in and is therefore wider than normal 
which in turn prevents the usb audio converter cable to be plugged into the 
next usb port of the laptop.

I carefully ground off enough plastic from one side of the wide plug so both 
fit in the laptop.

Result: No hub - problem gone!

Thanks again!
Best Regards,
VE7WAE,

Sent from ProtonMail Mobile

On Sat, Nov 17, 2018 at 17:36, VE3FBZ  wrote:

> Try putting a powered USB hub between.
>
>  Regards and 73s
> VE3FBZ
> London Amateur Radio Club
> www.larc.ca
>
> On Nov 17, 2018, at 6:06 PM, Art Witmans via wsjt-devel 
>  wrote:
>
>> Sent with [ProtonMail](https://protonmail.com) Secure Email.
>>
>> ‐‐‐ Original Message ‐‐‐
>> On Saturday, November 17, 2018 2:55 PM, Yahoo Groups 
>>  wrote:
>>
>>> Hello
>>>
>>> wsjt-x and js8call are really great fun to use!
>>>
>>> The problems I find is there is a frequent loss of audio link from laptop 
>>> to transceiver. It goes ok for a while and than the modulation comes out 
>>> the laptop speaker instead of going to the transceiver. Once this happends 
>>> it will ignore the settings in the preferences.
>>> The only way to restore function is by quitting and restarting the software.
>>> FT991a has additional problem having 2 codecs and you never know which one 
>>> it wants to use. If it is the "wrong" one, you have to force quitting the 
>>> software because it does not quit normally.
>>> Flrig does not have this problem
>>>
>>> Same problem found in the js8call software.
>>>
>>> Laptop used:
>>> macOS Mojave 10.14.1
>>> tranceivers used:
>>> FT-897D and FT-991A
>>>
>>> Sent with [ProtonMail](https://protonmail.com) Secure Email.
>
>>
>
>> ___
>> wsjt-devel mailing list
>> wsjt-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] Windows-based single-machine, single-rig multi-instance WSJT-X comparison configuration.

[Stephen Ireland]

Hi Folks,

I see that many are comparing “this version” to “that version” ... I am a 
little hesitant to post this but I have had lots of requests via email to post 
how to do this ... so please no “shooting the messenger” !!!

Remember that it IS possible to run multiple instances (and versions) of 
Windows WSJT-X at the same time; in fact you can pretty much run ANY software 
in parallel with – of course not without frequency exclusivity though – on the 
same machine.  through DXLab Commander and other Hamlib supported control 
software.

i.e. Those saying that RC3 was better at reception to RC4 ... well RUN BOTH AT 
THE SAME TIME. Compare. Note that there may be some distortions in true 
accuracy, but indications will be obvious.

But be forewarned

I am only providing the most basic procedure here as this can and will get many 
into strife; do not attempt unless you are familiar with "remote control” 
software such as DXLab’s commander


  *   Set up control of the radio through DXLab’s Commander and ensure that 
full Tx and information flow/control abilities are set.
  *   Set up wsjt-x as if it were talking to the radio “DXLab Commander”.
  *   The drivers for the radio’s sound interface connection must be set so 
that “Allow applications to take exclusive control of this device” and “give 
exclusive mode applications priority” is set off.
 *   This can have consequences I know...
  *   Then set up the software, setting the radio as “DXLab Commander” and 
linking all devices to the same drivers that sound comes in on.
 *   Ensure that you are using CAT control to trigger Tx.
  *   Start the first software instance.
 *   i.e.  C:\WSJT\wsjtx2\bin>wsjtx.exe
  *   Note that the second (or more) instances of wsjt-x must be started up 
with its own unique profile settings from the command prompt:
 *   i.e.  C:\WSJT\wsjtx192\bin>wsjtx.exe --rig-name=Second

This procedure has been tested and works satisfactorily. I will state 
SATISFACTORILY. It is not without foreseen peril in some instances. 
Considerable reliable processing power with considerable amounts RAM of 
availability is mandatory - as well as a highly stable (ha ha) Windows system 
is required.

I have been able to transmit on one instance at a time as well the WSJT-X 
software is smart enough to chop off reception when the other instance is 
transmitting. In fact I verified this for a final time a few minutes back with 
both a v192 and v2RC4 connection on 20m !

This methodology It is based on procedures that many use to integrate say “CW 
Skimmer” with DXLab’s “WinWarbler” for machine assisted CW.

There are also ways of doing the same with Linux and the Mac; once I have 
personally verified methodology basic procedures for the competent will be made 
available.

73,

Steve I
VK3VM / VK3SIR

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

Re: [wsjt-devel] Potential RC4 bug ? Auto Seq setting not sticky

[Gary McDuffie]

> On Nov 17, 2018, at 16:08, Mark Spencer  wrote:
> 
> Not a huge issue but thought I would mention it.
> 

Wondering if that is why you didn’t respond to me yesterday.  I tried dozens of 
times to respond to your CQs.

Gary - AG0N

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

Re: [wsjt-devel] bugs wsjt-x v2.0.0-rc4 a891ad

[VE3FBZ]

Try putting a powered USB hub between.


 Regards and 73s
VE3FBZ
London Amateur Radio Club
www.larc.ca 




> On Nov 17, 2018, at 6:06 PM, Art Witmans via wsjt-devel 
>  wrote:
> 
> 
> 
> 
> Sent with ProtonMail Secure Email.
> 
> ‐‐‐ Original Message ‐‐‐
>> On Saturday, November 17, 2018 2:55 PM, Yahoo Groups 
>>  wrote:
>> 
>> Hello
>> 
>> wsjt-x and js8call are really great fun to use!
>> 
>> The problems I find is there is a frequent loss of audio link from laptop to 
>> transceiver. It goes ok for a while and than the modulation comes out the 
>> laptop speaker instead of going to the transceiver. Once this happends it 
>> will ignore the settings in the preferences.
>> The only way to restore function is by quitting and restarting the software.
>> FT991a has additional problem having 2 codecs and you never know which one 
>> it wants to use. If it is the "wrong" one, you have to force quitting the 
>> software because it does not quit normally.
>> Flrig does not have this problem
>> 
>> Same problem found in the js8call software.
>> 
>> Laptop used:
>> macOS Mojave 10.14.1
>> tranceivers used:
>> FT-897D and FT-991A
>> 
>> 
>> Sent with ProtonMail Secure Email.
>> 
> ___
> 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] Possible Compatibility Issue WSJT-X and Mac OS 10.14.1 (Mojave) - ISSUE RESOLVED

[Robert Rearden]

John,

THANK YOU for confirming that your installation of RC4 is compatible with Mac 
OS 10.14.1. I was able to solve the issue based on your success with Mac OS 
10.14.1. 

Knowing you had successful operation in Mac OS 10.14.1, I decided to revisit my 
WSJT-X preferences. When I installed both v1.9.1 and v2.0.0-rc4, the sound card 
input was pre-populated with "USB Audio CODEC" so I did not see a need to 
change this setting at the time I installed the apps. However, your note 
convinced me the problem was probably audio related.

For both v1.9.1 and v2.0.0-rc4, I launched the app, changed the sound card 
input preference from “USB Audio CODEC” to "Built-in microphone", saved the 
preference and quit the application. I then restarted the application, changed 
the sound card input preference back to "USB Audio CODEC" and saved the 
preference. After this action, the issue of "no decode when ENABLE TX was 
enabled" was resolved and normal app behavior was restored for both versions of 
WSJT-X. 

Thank you again for your feedback... it convinced me that I needed to go back 
and look at my WSJT-X preferences rather than suspect Mac OS of being the 
source of the issue.

ISSUE RESOLVED.

73,



Robert Rearden
ae...@att.net




On Nov 17, 2018, at 11:27 AM, John Nelson  wrote:

Robert,

I read your two messages.   For the second message, are you being too 
impatient?Your first TX must have been at 15:31:15 but you didn’t wait for 
a decode and halted transmit - why?   
Were you using Auto Seq or not?

Remember RC4 does not decode 75 bit transmissions.  At the moment there are 
only a few stations active on 20m and 40m with RC4.   So you may see much 
activity on the waterfall display with no decodes.   Perfectly normal at 
present until more stations use RC4.

I normally run 10.13 on my MacBook (SignaLink + TS-870s) but to test your 
problem I re-booted to 10.14.1 with rc4 on 40m and immediately worked a DL2 and 
OE6.   Everything is running normally and correctly.   Decoding continues when 
ENABLE TX is active (but the rig is not transmitting).

I do not believe there is any incompatability problem between RC4 and macOS 
10.14.1.

Perhaps have refresh of the Quick Start guide.

— John G4KLA___
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] Possible Compatibility Issue WSJT-X and Mac OS 10.14.1 (Mojave) - UPDATE

[Stephen Ireland]

Folks,

Just to add in some “radio issues” into the mix...

Put at a very simplistic level, many radios by design are hardware optimised 
for voice - even when locked into non-Digital modes. Such radios exhibit “sweet 
spots” and are far from linear in performance across AF frequencies that they 
work at – both modulated and received - between 0Hz – 3KHz (the upper design 
limit for most).

Mind you, when locked into Digital mode operation they SHOULD be linear... but 
are not !

Yaesu radios in particular exhibit this “effect” – they have designs that can 
be likened to FM emphasis curves with regards to both Audio and Tx 
performance

[ This is why the “Flatten” button on the waterfall is useful as it 
averages signals across the spectrum – enhancing and flattening - to provide a 
more pleasant environ for observers ].

The “sweet spots” for operating most radios are in the range of 500Hz – 2000Hz 
offsets – even with SSB modulated modes. As (again simplistic) evidence, this 
is why many ops will find that when they transmit FT8 etc. that power output 
levels will be fairly linear within these frequency ranges – yet outside these 
ranges to achieve the same power output levels (as fed to the antenna) more AF 
drive from the source program (I.e. WSJT-X) is needed.

SDR’s and other direct sampling technologies do not exhibit these same design 
issues ... as its direct sampling ... across a wider spectrum range.

Perhaps this is what is observed here?

73

Steve I
VK3VM / VK3SIR

Sent from Mail for Windows 10


From: Richard Zwirko - K1HTV 
Sent: Sunday, November 18, 2018 8:38:32 AM
To: ae...@att.net; WSJT
Subject: [wsjt-devel] Possible Compatibility Issue WSJT-X and Mac OS 10.14.1 
(Mojave) - UPDATE

Robert,
This comment is regarding your signal not being copied when you were 
transmitting with an audio tone above 2800 Hz.

 One parameter you did not list under the 'Radio' tab was the "Split Operation" 
setting. If you have it set to "None", then it is possible that your transmit 
audio tones over 2800 Hz are being adversely affected by the radios TX filter. 
If this is the case, it would explain why stations are not decoding your 
transmissions.

To confirm this, set up a schedule with a station, first transmitting in the 
normal 200 to 2000 Hz range. Then try it again with the higher 2800+ Hz TX tone 
setting. See if your transmissions are being decoded at both ends of the TX 
audio spectrum.

GL & 73,
Rich - K1HTV

= = =

From: Robert Rearden mailto:ae...@att.net>>
To: WSJT Developers List 
mailto:wsjt-devel@lists.sourceforge.net>>
Cc:
Bcc:
Date: Sat, 17 Nov 2018 10:42:13 -0600
Subject: [wsjt-devel] Possible Compatibility Issue WSJT-X and Mac OS 10.14.1 
(Mojave) - UPDATE
This is a followup to my earlier email regarding a possible compatibility issue 
between WSJT-X and Mac OS 10.14.1 while using v1.9.1 software. The issue I 
reported earlier was that decode does not occur during the receive portion of 
the T/R sequence when ENABLE TX is active.

I have since installed v2.0.0-rc4a891ad and have observed the same failed 
decode behavior that was reported in my earlier email for v1.9.1.

RC4 INSTALLED

  - In preparation for the v2.0.0-rc4 install, I deleted the v1.9.1 
application, the /library/Application Support/WSJT-X folder and contents, the 
/Library/Preferences/org.k1jt.wsjtx file, and the 
/Library/Preferences/WSJT-X.ini file to ensure I had a clean install.
  - Installation of v2.0.0rc4 appeared normal and no issues or error messages 
were encountered.

DESCRIPTION OF A FAILED QSO
  - On 11/17/2017 at 15:31:00 - 15:33:00 UTC a QSO was attempted with AA7A on 
14074.00 MHz offset 2823 Hz.
  - Input signal level adjusted to approximately 40dB in the presence of 
signals.
  - Prior to the attempted QSO decode function worked properly to decode 
messages in the MONITOR mode from several stations active at the time (i.e., 
AA7A, K4IU, N4ART, N4JBB, KT9X).
  - The waterfall displayed incoming signal activity while in MONITOR mode.
  - At 15:31:00 UTC on 14074.00 MHz offset 2823 Hz, I double-clicked in the 
band activity window on AA7A's CQ message. ENABLE TX mode was enabled and a Tx1 
standard message was transmitted (i.e., AA7A AE5UV EM12).
   - During the entire attempted QSO, the waterfall advanced displaying 
incoming signal activity during the "Rx" portion of the each T/R sequence.
   - Although the waterfall indicated AA7A was transmitting a message, no 
decoded message was received from him or any other active station on the 
waterfall.
   - At about 15:32:45 I halted transmit, decode of incoming messages resumed 
and they were displayed in the band activity window.
   - At 15:33:00, I decoded AA7A's response to my Tx1 message of a  minute 
earlier which was "AE5UV AA7A -03".
   - The QSO was a fail.

Below is information on my configuration and preference settings.

CONFIGURATION

  - Computer: MacBook Air 

Re: [wsjt-devel] Sensitivity or bad propagation

[SKI W4PPC]

Evening:
Auto Seq was selectedjust could not get together

On Sat, Nov 17, 2018 at 5:20 PM Al  wrote:

> Looks to me like one of the stations did not have Auto Seq enabled and
> wasn't pay full attention.
> I've done that myself...  several times
> AL, K0VM
>
> On 11/17/2018 4:17 PM, SKI W4PPC wrote:
>
> Afternoon:
>
> Is the attached an example of poor sensitivity or just bad HF propagation?
> Experienced this a few times earlier today.
> Running rc4 on Windows 7 Professional
>
> Respectfully:
>
> Stephen
>
>
> ___
> 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] Sensitivity or bad propagation

[Al]

Looks to me like one of the stations did not have Auto Seq enabled and 
wasn't pay full attention.

I've done that myself...  several times
AL, K0VM

On 11/17/2018 4:17 PM, SKI W4PPC wrote:

Afternoon:

Is the attached an example of poor sensitivity or just bad HF 
propagation? Experienced this a few times earlier today.

Running rc4 on Windows 7 Professional

Respectfully:

Stephen


___
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] Potential RC4 bug ? Auto Seq setting not sticky

[Mark Spencer]

Hi:

While running FT8 I have noticed that the setting of the Auto Seq
radio button is not sticky after the program has been restarted.   If I
enable Auto Seq, then exit WSJT-X and re start WSJT-X Auto Seq is not
enabled.

Not a huge issue but thought I would mention it.

Other than that, at first glance FT8 on 20M HF seems to be working well
with RC4.   Nice job.

Am running windows 7 Home Premium and an IC7300 with CAT and Fake it
enabled.

73
Mark S
VE7AFZ
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] bugs wsjt-x v2.0.0-rc4 a891ad

[Art Witmans via wsjt-devel]

Sent with [ProtonMail](https://protonmail.com) Secure Email.

‐‐‐ Original Message ‐‐‐
On Saturday, November 17, 2018 2:55 PM, Yahoo Groups  
wrote:

> Hello
>
> wsjt-x and js8call are really great fun to use!
>
> The problems I find is there is a frequent loss of audio link from laptop to 
> transceiver. It goes ok for a while and than the modulation comes out the 
> laptop speaker instead of going to the transceiver. Once this happends it 
> will ignore the settings in the preferences.
> The only way to restore function is by quitting and restarting the software.
> FT991a has additional problem having 2 codecs and you never know which one it 
> wants to use. If it is the "wrong" one, you have to force quitting the 
> software because it does not quit normally.
> Flrig does not have this problem
>
> Same problem found in the js8call software.
>
> Laptop used:
> macOS Mojave 10.14.1
> tranceivers used:
> FT-897D and FT-991A
>
> Sent with [ProtonMail](https://protonmail.com) Secure Email.___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] My Observation

[Rory Bowers]

I have installed and operated ver 2.0 rc4.  It seems to work very well
taking note of the remaining "bugs" which I am sure the development team
doesn't need to hear one more time.
I know Joe doesn't want to hear this but I still believe there will be "die
hards" stuck in their ways with ver 1.9.  I thought that ver 2.0 rc3 was
very thoughtful... give the operator the choice between 75 bit and 77 bit
by just checking the boxes.  I agree with you Joe that this will not
accomplish what you desire; to move WSJT-X forward to a 77 bit standard.
Unfortunately Pandora's Box was opened in ver 1.9.
I am convinced that 2.0 will function perfectly in it's final release.  Let
me know when it is ready and away I go :-)
73,
Rory, K5CKS
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Compatibility???

[Bill Somerville]

Hi Al,

answers below.

On 17/11/2018 22:12, Al Reeves wrote:
I'm trying to wrap my head around the latest compatibility issues with 
rc4.


I'm running version 1.9.1 (75 bit).  Am I correct in the following:

* I can complete QSOs (both ways) with all stations running 1.9.1.

So long as you have propagation both ways, yes.

* I can complete QSOs (both ways) with all stations running rc2 and rc3.
Not necessarily as they may be sending 77-bit transmissions, but no one 
should be running those obsolete release candidates any more, RC4 
supersedes them.
* I *_cannot_* complete QSOs with stations running rc4.  Is it true 
that I can decode them but they will not decode me. Or I will not 
decode them and they won't decode me.

The latter, you have no compatibility with RC4 stations using FT8.
* When the general release of version 2.0 (77 bit) is released later 
in December all stations will need to up grade otherwise, version 
1.9.1 stations will only be able to complete QSOs (both ways) _*only*_ 
with all stations running 1.9.1.

Yes.
* When the general release of version 2.0 (77 bit) is released later 
in December all stations will need to up grade otherwise, version 2.0 
stations will be able to complete QSOs (both ways) _*only*_ with 
stations running version 2.0.

Yes.


Would appreciate any clarifications.


73
Bill
G4WJS.

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

[wsjt-devel] Compatibility???

[Al Reeves]

I'm trying to wrap my head around the latest compatibility issues with rc4.

I'm running version 1.9.1 (75 bit).  Am I correct in the following:

* I can complete QSOs (both ways) with all stations running 1.9.1.
* I can complete QSOs (both ways) with all stations running rc2 and rc3.
* I *_cannot_* complete QSOs with stations running rc4.  Is it true that 
I can decode them but they will not decode me. Or I will not decode them 
and they won't decode me.
* When the general release of version 2.0 (77 bit) is released later in 
December all stations will need to up grade otherwise, version 1.9.1 
stations will only be able to complete QSOs (both ways) _*only*_ with 
all stations running 1.9.1.
* When the general release of version 2.0 (77 bit) is released later in 
December all stations will need to up grade otherwise, version 2.0 
stations will be able to complete QSOs (both ways) _*only*_ with 
stations running version 2.0.


Would appreciate any clarifications.

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

Re: [wsjt-devel] Possible Compatibility Issue WSJT-X and Mac OS 10.14.1 (Mojave) - UPDATE

[Bill Somerville]

On 17/11/2018 16:42, Robert Rearden wrote:
This is a followup to my earlier email regarding a possible 
compatibility issue between WSJT-X and Mac OS 10.14.1 while using 
v1.9.1 software. The issue I reported earlier was that decode does not 
occur during the receive portion of the T/R sequence when ENABLE TX is 
active.


I have since installed v2.0.0-rc4a891ad and have observed the same 
failed decode behavior that was reported in my earlier email for v1.9.1.



[snip]

DESCRIPTION OF A FAILED QSO
  - On 11/17/2017 at 15:31:00 - 15:33:00 UTC a QSO was attempted with 
AA7A on 14074.00 MHz offset 2823 Hz.

[snip]

  - Radio tab
        -- Rig: None

Hi Robert,

above I have picked out the salient points from your issue report. You 
are operating with a Tx audio offset of 2823Hz without rig control, this 
is a non-starter as your Tx SSB IF filter will effectively cut off your 
Tx signal. If you do not have CAT control and therefore cannot enable 
the "Settings->Radio->Split Operating" option that would allow this 
scenario to work, then you must adjust your VFO dial frequency to 
accommodate this type of QSO. For example if you set your rig's VFO dial 
frequency to 14075 kHz then set a Tx audio offset in WSJT-X of 1823Hz 
then to your QSO partners you will be in exactly the same place but with 
no attenuation of your transmitted signal which at 1823Hz is well within 
the passband of your SSB IF filter.


73
Bill
G4WJS.


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

[wsjt-devel] Possible Compatibility Issue WSJT-X and Mac OS 10.14.1 (Mojave) - UPDATE

[Richard Zwirko - K1HTV]

Robert,
This comment is regarding your signal not being copied when you were
transmitting with an audio tone above 2800 Hz.

 One parameter you did not list under the 'Radio' tab was the "Split
Operation" setting. If you have it set to "None", then it is possible that
your transmit audio tones over 2800 Hz are being adversely affected by the
radios TX filter. If this is the case, it would explain why stations are
not decoding your transmissions.

To confirm this, set up a schedule with a station, first transmitting in
the normal 200 to 2000 Hz range. Then try it again with the higher 2800+ Hz
TX tone setting. See if your transmissions are being decoded at both ends
of the TX audio spectrum.

GL & 73,
Rich - K1HTV

= = =

From: Robert Rearden 
To: WSJT Developers List 
Cc:
Bcc:
Date: Sat, 17 Nov 2018 10:42:13 -0600
Subject: [wsjt-devel] Possible Compatibility Issue WSJT-X and Mac OS
10.14.1 (Mojave) - UPDATE
This is a followup to my earlier email regarding a possible compatibility
issue between WSJT-X and Mac OS 10.14.1 while using v1.9.1 software. The
issue I reported earlier was that decode does not occur during the receive
portion of the T/R sequence when ENABLE TX is active.

I have since installed v2.0.0-rc4a891ad and have observed the same failed
decode behavior that was reported in my earlier email for v1.9.1.

RC4 INSTALLED

  - In preparation for the v2.0.0-rc4 install, I deleted the v1.9.1
application, the /library/Application Support/WSJT-X folder and contents,
the /Library/Preferences/org.k1jt.wsjtx file, and the
/Library/Preferences/WSJT-X.ini file to ensure I had a clean install.
  - Installation of v2.0.0rc4 appeared normal and no issues or error
messages were encountered.

DESCRIPTION OF A FAILED QSO
  - On 11/17/2017 at 15:31:00 - 15:33:00 UTC a QSO was attempted with AA7A
on 14074.00 MHz offset 2823 Hz.
  - Input signal level adjusted to approximately 40dB in the presence of
signals.
  - Prior to the attempted QSO decode function worked properly to decode
messages in the MONITOR mode from several stations active at the time
(i.e., AA7A, K4IU, N4ART, N4JBB, KT9X).
  - The waterfall displayed incoming signal activity while in MONITOR mode.
  - At 15:31:00 UTC on 14074.00 MHz offset 2823 Hz, I double-clicked in the
band activity window on AA7A's CQ message. ENABLE TX mode was enabled and a
Tx1 standard message was transmitted (i.e., AA7A AE5UV EM12).
   - During the entire attempted QSO, the waterfall advanced displaying
incoming signal activity during the "Rx" portion of the each T/R sequence.
   - Although the waterfall indicated AA7A was transmitting a message, no
decoded message was received from him or any other active station on the
waterfall.
   - At about 15:32:45 I halted transmit, decode of incoming messages
resumed and they were displayed in the band activity window.
   - At 15:33:00, I decoded AA7A's response to my Tx1 message of a  minute
earlier which was "AE5UV AA7A -03".
   - The QSO was a fail.

Below is information on my configuration and preference settings.

CONFIGURATION

  - Computer: MacBook Air (early 2015), 1.6Ghz processor, 256GB SSD
  - OS: Mac OS 10.14.1 (18B75)
  - Program: WSJT-X v1.9.1 r8747
  - Soundcard: SignaLink USB
  - Radio: Kenwood TS-480SAT


WSTJ-X MAIN WINDOW SETTINGS

  - Auto Seq: ON
  - Call 1st: ON

WSJT-X PREFERENCE SETTINGS

  - General tab / Station details
-- My Call: AE5UV
-- My Grid: EM12hq
-- AutoGrid: OFF
-- IARU Region: All
-- Message generation for type 2 compound callsign holders: Full
call in Tx3

  - General tab / Display settings
-- Blank line between decoding periods: ON
-- Display distance in miles: ON
-- Tx messages to Rx frequency window: ON
-- Show DXCC entity and worked before status: OFF
-- Show principal prefix instead of country name: OFF

  - General tab / Behavior settings
-- Monitor off at startup: OFF
-- Double-click on call sets Tx Enable: ON
-- Disable Tx after sending 73: ON
-- Enable VHF/UNF/Microwave features: OFF
-- Allow Tx frequency changes while transmitting: OFF
-- Single decode: OFF
-- Decode after EME delay: OFF
-- Tx watchdog: 4 minutes
-- Periodic CW ID Interval: 0

  - Radio tab
-- Rig: None
-- PTT Method: VOX
-- Poll interval: 1s

  - Audio tab
-- Input: USB Audio CODEC
-- Output: USB Audio CODEC
-- Save Directory Location:
/Users/RobertRearden/Library/Application Support/WSJT-X/save
-- AzEl Directory: /Users/RobertRearden/Library/Application
Support/WSJT-X
-- Remember power settings by band Transmit: OFF
-- Remember power settings by band Tune: OFF

  - Reporting tab / Logging
-- Prompt me to log QSO: ON
-- Convert mode to RTTY: OFF
-- dB reports to comments: OFF
-- Clear DX call and grid after logging: ON
-- Op Call: blank

  - Reporting tab / 

Re: [wsjt-devel] WSJT-X & JTSDK future?

[Bill Somerville]

On 17/11/2018 05:24, Greg Beam wrote:
At this point, I’ve no idea how things are working with WSJT-X builds 
(Win32 or Linux) other than what’s being formally published by the 
WSJT Dev team. 


Hi Greg,

welcome back!

The relevant changes can be summarized as:

1) we are now using git DVCS. I think you are up to speed on this 
already and are aware of the new git repos on the WSJT SourceForge 
project page. The old svn repo is still there but for reference only, no 
changes have been posted to it for some time and it is effectively 
read-only and frozen.


2) The WSJT-X git repo is only being pushed once for each release 
shortly after the release is announced, we have been forced to do that 
by some unfortunate misuses of unfinished development code. Note that 
this still goes much further that the minimum requirement for Open 
Source applications, to make their source code publicly available 
matching any public releases, since we still make the full change 
history visible as well to anyone who cares. We realize that this 
somewhat reduces the benefit to those who like to track the latest 
developments by building from pre-release sources, but as it has proved 
impossible to control arbitrary and unauthorized redistribution of 
incomplete development works; we have taken that capability away.


3) The minimum Qt version required to build WSJT-X from WSJT-X v2.0.0 
RC4 onwards in v5.5, this has been moved on so we can take advantage of 
many Qt enhancements. We may well move on again with the minimum Qt 
version, perhaps to v5.9 or even v5.10, this may even be forced upon us 
to support the latest macOS version at some point soon. If and when this 
happens we will be forced to drop support for MS Windows XP and Vista. 
Continuing to support old versions of Qt and old operating system 
versions will eventually greatly disadvantage those running on more 
contemporary operating system versions and we will only do that for a 
limited time.


73
Bill
G4WJS.

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

Re: [wsjt-devel] Falta de sensibilidad en decodificación

[Bill Somerville]

On 17/11/2018 14:29, Jesús Gutiérrez Rodríguez wrote:
I've been reading messages about problems, improvements, all referred 
to the current beta version rc4.
Really many of the improvement suggestions or problems with the new 
version that we are testing, some of them, we have alternatives like
 - Distinctive colors, secondary issue if we operate with JTAlert that 
informs us about this topic in an appropriate way.

-worked or new countries, also secondary because we want it JTAlert
-links on Eqsl or others, we have, for example, Log40M, which gives us 
many links, statistics, etc.


I want to express with this that there are many improvement issues 
that we are contributing, which is very good, but, from my experience 
in FT8 digital systems, I see as worrying that, now the program, I 
think it has lost sensitivity and this should be to address it is the 
essence of decoding in FT8


HI Jesus,

although several testers of WSJT-X v2.0.0 RC4 have reported a loss of 
sensitivity, no one has given good evidence of that actually being the 
case, recorded .WAV files for example. There are, for sure, 
complications when sharing frequencies with incompatible versions of 
WSJT-X, particularly with prior RC versions that had a dual decode 
capability that has be dropped from RC4 onwards. These have lead to 
situations where RC3 operators. for example, have set up sending 75-bit 
FT8 messages, quite rightly, because they are operating on the normal 
sub-bands (14074, 7074 etc.) and then not being able to inter-operate 
with RC4 testers above 2000Hz.


The simple answer here is that *no one should still be running WSJT-X 
v2.0.0 RC3, RC2, or RC1*. These are beta test release candidate versions 
and testing feedback, which is why you are running them, must be from 
the latest iteration to be useful to the development team. If anyone is 
still running RC3 or earlier, and wishes to continue with beta testing, 
then please upgrade to RC4; otherwise revert back to v1.9.1 and leave 
the testing program for now.


With respect to your comments on worked before highlighting and JTAlert 
overlap, please remember that many WSJT-X users do not use MS Windows, 
others do not want to run multiple applications or do not use a station 
logging application that interacts smoothly with JTAlert. Also please 
consider that one of the advantages of the new FT8 and MSK144 77-bit 
message payloads is the ability to partake in digital modes during some 
contests. Contest may not be preference but for those that do enjoy that 
aspect of amateur radio, the ability to flag duplicates and multipliers 
is essential these days. The enhancements to highlight some decoded 
messages are a step towards such facilities.


As a further aside, a basic communications theory analysis of the 75-bit 
and 77-bit FT8 and MSK144 modes will show that, all other things being 
equal, there would be a loss of sensitivity due to the slightly higher 
code rate necessary to convey the extra bits in the same time frame and 
bandwidth with the same modulation scheme. But all other things are not 
equal, in fact diligent and thorough work by Steve K9AN has yielded a 
better decoder sensitivity that offsets the loss of sensitivity due to 
the higher code rate. This has been thoroughly verified in simulations 
and we are confident that this new FT8 mode in WSJT-X v2.0.0 is at least 
as sensitive as the 75-bit payload version in most usage situations. 
There is also better immunity from undetected errors (false decodes) in 
this latest decoder iteration, even though there are more possible 
message combinations, thus improving it's practical usability on a 
crowded HF band.


73
Bill
G4WJS.

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

Re: [wsjt-devel] Problems with RC4

[Hasan al-Basri]

Tnx for correction!
73

Hasan

On Sat, Nov 17, 2018, 9:16 AM Jim Nuytens  Hasan,
>
> That's not entirely correct. RC3 can decode RC4 TXs, but RC4 doesn't
> decode RC3 TXs, unless you set RC3 to 77-bit messages in settings.
>
> I have been running RC4 on and off for the last several days. I can get
> spots on PSK Reporter from stations running RC3. It's just that if they
> respond to me without setting RC3 to 77-bit, I'll never decode them.
>
> Jim
>
> On 11/17/2018 14:53, Hasan al-Basri wrote:
> >  RC4 cannot be copied by RC3 in FT8. RC3 cannot be copied by RC4 in FT8.
>
>
> ---
> This email has been checked for viruses by AVG.
> https://www.avg.com
>
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] RC 4 testa.

[Jim Shorney]

Working just the "easy ones" doesn't get you to DXCC Challenge very fast. :)

73

-Jim
NU0C


On Sat, 17 Nov 2018 13:40:44 -0500, Jim Nuytens wrote:

>-18 is perfectly acceptable here. I'll work any DX station, even if it's at 
>-23, if I need it.
>
>Sent from my iPhone
>
>> On Nov 17, 2018, at 8:44 AM, Black Michael via wsjt-devel 
>>  wrote:
>> 
>> PSKReporter shows he saw you at -18dB -- perhaps your path to him wasn't all 
>> that good.
>> I've heard a few ops say they won't work people at low SNR's as they figure 
>> the QSO will fail.
>> 
>> de Mike W9MDB

--

"Life is too short for QRP" - ETO Alpha

"DeciBels were invented to give QRPers a false sense of smugness" - NU0C
"QRO is a public service" - NU0C




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

Re: [wsjt-devel] RC 4 testa.

[Jim Nuytens]

-18 is perfectly acceptable here. I’ll work any DX station, even if it’s at 
-23, if I need it.

Sent from my iPhone

> On Nov 17, 2018, at 8:44 AM, Black Michael via wsjt-devel 
>  wrote:
> 
> PSKReporter shows he saw you at -18dB -- perhaps your path to him wasn't all 
> that good.
> I've heard a few ops say they won't work people at low SNR's as they figure 
> the QSO will fail.
> 
> de Mike W9MDB
> 
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] RC4 oddity

[Rory Bowers]

I copied your "CQ_Plus" just fine Gary.  I guessed that you wanted to work
split "up" and we completed a good QSO.  Nice test of 77 bit Gary!
73,
Rory, K5CKS

On Fri, Nov 16, 2018 at 10:54 PM Gary Hinson  wrote:

> While trying to send a “CQ PLUS” message, I somehow got WSJT-X 2.0.0-rc4
> to send, or appear to send, a hashed version of the message with
> “”, 3 times:
>
> I deleted and re-entered the “ plus” bit from the Tx6 message box
> (prematurely sending the “CQZL2IFB RF870” message in the process) but it
> again sent the hashed version … until I clicked the Tx6 button which
> started me sending the “CQ PLUS” non-hashed form as expected.
>
> If I only edit the Tx6 message to “CQ plus ZL2IFB RF80” it sends the
> hashed version: after I click the Tx6 button, it converts the message
> showing in the Tx6 box to uppercase and sends the non-hashed version.
>
> 73
> Gary  ZL2iFB
>
>
> ___
> 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] Possible Compatibility Issue WSJT-X and Mac OS 10.14.1 (Mojave) - UPDATE

[John Nelson]

Robert,

I read your two messages.   For the second message, are you being too 
impatient?Your first TX must have been at 15:31:15 but you didn’t wait for 
a decode and halted transmit - why?   
Were you using Auto Seq or not?

Remember RC4 does not decode 75 bit transmissions.  At the moment there are 
only a few stations active on 20m and 40m with RC4.   So you may see much 
activity on the waterfall display with no decodes.   Perfectly normal at 
present until more stations use RC4.

I normally run 10.13 on my MacBook (SignaLink + TS-870s) but to test your 
problem I re-booted to 10.14.1 with rc4 on 40m and immediately worked a DL2 and 
OE6.   Everything is running normally and correctly.   Decoding continues when 
ENABLE TX is active (but the rig is not transmitting).

I do not believe there is any incompatability problem between RC4 and macOS 
10.14.1.

Perhaps have refresh of the Quick Start guide.

— John G4KLA

smime.p7s
Description: S/MIME cryptographic signature
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] Possible Compatibility Issue WSJT-X and Mac OS 10.14.1 (Mojave) - UPDATE

[Robert Rearden]

This is a followup to my earlier email regarding a possible compatibility issue 
between WSJT-X and Mac OS 10.14.1 while using v1.9.1 software. The issue I 
reported earlier was that decode does not occur during the receive portion of 
the T/R sequence when ENABLE TX is active.

I have since installed v2.0.0-rc4a891ad and have observed the same failed 
decode behavior that was reported in my earlier email for v1.9.1.

RC4 INSTALLED

  - In preparation for the v2.0.0-rc4 install, I deleted the v1.9.1 
application, the /library/Application Support/WSJT-X folder and contents, the 
/Library/Preferences/org.k1jt.wsjtx file, and the 
/Library/Preferences/WSJT-X.ini file to ensure I had a clean install.
  - Installation of v2.0.0rc4 appeared normal and no issues or error messages 
were encountered.

DESCRIPTION OF A FAILED QSO
  - On 11/17/2017 at 15:31:00 - 15:33:00 UTC a QSO was attempted with AA7A on 
14074.00 MHz offset 2823 Hz.
  - Input signal level adjusted to approximately 40dB in the presence of 
signals.
  - Prior to the attempted QSO decode function worked properly to decode 
messages in the MONITOR mode from several stations active at the time (i.e., 
AA7A, K4IU, N4ART, N4JBB, KT9X). 
  - The waterfall displayed incoming signal activity while in MONITOR mode.
  - At 15:31:00 UTC on 14074.00 MHz offset 2823 Hz, I double-clicked in the 
band activity window on AA7A's CQ message. ENABLE TX mode was enabled and a Tx1 
standard message was transmitted (i.e., AA7A AE5UV EM12). 
   - During the entire attempted QSO, the waterfall advanced displaying 
incoming signal activity during the "Rx" portion of the each T/R sequence. 
   - Although the waterfall indicated AA7A was transmitting a message, no 
decoded message was received from him or any other active station on the 
waterfall.
   - At about 15:32:45 I halted transmit, decode of incoming messages resumed 
and they were displayed in the band activity window.
   - At 15:33:00, I decoded AA7A's response to my Tx1 message of a  minute 
earlier which was "AE5UV AA7A -03".
   - The QSO was a fail.

Below is information on my configuration and preference settings.

CONFIGURATION 

  - Computer: MacBook Air (early 2015), 1.6Ghz processor, 256GB SSD
  - OS: Mac OS 10.14.1 (18B75)
  - Program: WSJT-X v1.9.1 r8747
  - Soundcard: SignaLink USB
  - Radio: Kenwood TS-480SAT


WSTJ-X MAIN WINDOW SETTINGS

  - Auto Seq: ON
  - Call 1st: ON

WSJT-X PREFERENCE SETTINGS

  - General tab / Station details
-- My Call: AE5UV
-- My Grid: EM12hq
-- AutoGrid: OFF
-- IARU Region: All
-- Message generation for type 2 compound callsign holders: Full call 
in Tx3

  - General tab / Display settings
-- Blank line between decoding periods: ON
-- Display distance in miles: ON
-- Tx messages to Rx frequency window: ON
-- Show DXCC entity and worked before status: OFF
-- Show principal prefix instead of country name: OFF

  - General tab / Behavior settings
-- Monitor off at startup: OFF
-- Double-click on call sets Tx Enable: ON
-- Disable Tx after sending 73: ON
-- Enable VHF/UNF/Microwave features: OFF
-- Allow Tx frequency changes while transmitting: OFF
-- Single decode: OFF
-- Decode after EME delay: OFF
-- Tx watchdog: 4 minutes
-- Periodic CW ID Interval: 0

  - Radio tab
-- Rig: None
-- PTT Method: VOX
-- Poll interval: 1s

  - Audio tab
-- Input: USB Audio CODEC
-- Output: USB Audio CODEC
-- Save Directory Location: /Users/RobertRearden/Library/Application 
Support/WSJT-X/save
-- AzEl Directory: /Users/RobertRearden/Library/Application 
Support/WSJT-X
-- Remember power settings by band Transmit: OFF
-- Remember power settings by band Tune: OFF

  - Reporting tab / Logging
-- Prompt me to log QSO: ON
-- Convert mode to RTTY: OFF
-- dB reports to comments: OFF
-- Clear DX call and grid after logging: ON
-- Op Call: blank

  - Reporting tab / Network Services
-- Enable PSK Reporter Spotting: ON

  - Reporting tab / UDP Server
-- UDP Server: 127.0.0.1
-- UDP Server port number: 2237
-- Accept UDP requests: OFF
-- Notify on accepted UDP request: OFF
-- Accepted UDP request restores window: OFF

  - Reporting tab / N1MM Logger + Broadcasts
-- Enable logged contact ADIF broadcast: OFF
-- N1MM Server name or IP address: 127.0.0.1
-- N1MM Server port number: 2333

  - Advanced tab / JT65 VHF/UHF/Microwave decoding parameters
-- Random  ensure patterns: 6
-- Aggressive decoding level: 0
-- Two-pass decoding: ON

  - Advanced tab / Miscellaneous
-- Degrade S/N of .wave file: 0.0 dB
-- Receiver bandwidth 2500 Hz
-- Tx delay: 0.2 s
-- x2 Tone Spacing: OFF
-- x4 Tone Spacing: OFF

  - Advanced tab 

[wsjt-devel] Erratic decodes in RC4

[WB5JJJ]

Over the time I've used RC4, I've noticed a recurring theme.  This is
sporadic at best, but still happens a couple times a day.

I'm calling CQ above 2000 on the band.  I see a signal in the WF on my Tx
frequency that should decode, but it doesn't.  My first thought is that
it's someone not running RC4 or has Always Transmit 77bit unchecked in an
earlier RC.  So I send 77-Bit TX/RX in Tx5 (free text) box.  Still the
station keeps on trying (I assume).  I move up or down 50 or 100 and I'm
followed by this same station.  Now, I know he's copying me or trying to
QRM me since he can't copy me.

Then one of two things happen, 1) the station does a JTAlert chat box
saying he's running RC4 as well or, 2) all of the sudden he shows up in my
Rx Freq side saying he's running RC4 and the contact continues.  It's like
his response to my CQ might be corrupted on his end, but when he goes free
text, that sets things right.  I change nothing on my end except for the
frequency change.

His signal pattern in the WF has not changed much at all, but why was I not
decoding him and then all at once, things are OK?  It's not the path as the
WF, even though not perfect by a long shot, shows a similar signal pattern
from him all along.  Our reports were in -12 as received by me and -09 as
received on his end.

-- 
George Cotton, WB5JJJ
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Problems with RC4

[Jim Nuytens]

Hasan,

That's not entirely correct. RC3 can decode RC4 TXs, but RC4 doesn't 
decode RC3 TXs, unless you set RC3 to 77-bit messages in settings.


I have been running RC4 on and off for the last several days. I can get 
spots on PSK Reporter from stations running RC3. It's just that if they 
respond to me without setting RC3 to 77-bit, I'll never decode them.


Jim

On 11/17/2018 14:53, Hasan al-Basri wrote:

 RC4 cannot be copied by RC3 in FT8. RC3 cannot be copied by RC4 in FT8.



---
This email has been checked for viruses by AVG.
https://www.avg.com



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

Re: [wsjt-devel] Problems with RC4

[Hasan al-Basri]

Giuseppe,

It may appear that RC4 is less sensitive, but that is  not true. It is most
likely that you are misinterpreting what you are seeing.

The reason you see 90% fewer decodes on RC4 than RC3 is that there are 90%
fewer people using RC4 at this point. RC4 cannot be copied by RC3 in FT8.
RC3 cannot be copied by RC4 in FT8.

RC4 is decoding just fine...there just aren't that many people running RC4
on HF yet.

You appear to be attributing causation when there is none. The decrease in
decodes has NOTHING to do with the inherent sensitivity of RC3 vs RC4. It
has everything to do with the population using each mode.

The reason installing and uninstalling didn't change anything for you, is
because it shouldn't. It's not the install, it's not the sensitivity of the
software. It's cockpit trouble. :-)

73, N0AN
Hasan


On Fri, Nov 16, 2018 at 6:40 PM M Lewton  wrote:

> Hello
>
> I find this version the most sensitive vs. the older versions.  I am also
> using a IC-7300 with only a vertical antenna.
> I just worked JR3GPP calling CQ at -21 we completed the QSO with his -24
> RR73.
>
> RC4 has other problems that most people have already commented on.
> For me I miss the "Already Worked" the most.
>
> Maurice
> WA6PHR
>
> -Original Message-
> From: Giuseppe Molinaro via wsjt-devel
> Sent: Friday, November 16, 2018 9:38 AM
> To: wsjt-devel@lists.sourceforge.net
> Cc: Giuseppe Molinaro
> Subject: [wsjt-devel] Problems with RC4
>
>
> I would like to bring to your attention that I had to reinstate version
> RC3
> because for some unknown reason the RX sensitivity is extremely low when
> using RC4 (about 90% less station decoded as compared to version RC3) on a
> Icom 7300 transceiver.
>
> I reinstalled RC4 twice with identical results both times
>
> 73 Giuseppe KE8FT
>
>
>
>
>
>
>
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
>
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fwsjt-develdata=02%7C01%7C%7C7f49fd6c8bb24a07430d08d64beadd3d%7C84df9e7fe9f640afb435%7C1%7C0%7C636779869479520310sdata=gpvP%2B%2F%2BNVgS%2Fv4mzd5afNx4OCKs3SfEvhRRpmLBwSuA%3Dreserved=0
>
>
>
> ___
> 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] wrong time logged

[Don Hill AA5AU]

FWIW - Just yesterday, it was brought to my attention that an FT8 contact using 
RC3 was logged with the wrong time. I found the contact was logged from WSJT-X 
via JTAlert into DXKeeper with the wrong start time. The end time was correct. 
Unfortunately I have no details of how it could have happened. I had stopped 
operating and an hour later I restarted. The first contact I made after 
restarting had a start time of when I stopped  an hour earlier.

 

Don AA5AU

 

From: m...@handgunrepairshop.com [mailto:m...@handgunrepairshop.com] 
Sent: Friday, November 16, 2018 10:38 PM
To: WSJT software development
Subject: Re: [wsjt-devel] wrong time logged

 

Hi all,

First a disclaimer, I have no programming knowledge, or any clue to the 
solution. My setup is V2.0.0-rc4 on Windows 10 Pro, JTAlert feeding Log4OM & 
OmniRig for CAT control, SignaLink USB, TS-2000.

 

I am also seeing issues with wrong QSO time logged, particularly after using F4 
or Esc keys to abort a QSO that did not complete. I seem to recall similar 
issues sporadically with previous versions as well. I am using copy/paste to 
include text from the RX Frequency frame and wsjtx.log file below.

 

223345 Tx 2498 ~ CQ KV4ZY EN91 

223400 -16 0.1 2499 ~ KV4ZY WD5DHK EM12

223400 -4 0.0 2716 ~ KV4ZY AJ4F EL29

223419 Tx 2498 ~ WD5DHK KV4ZY -16 

223430 -13 0.2 2499 ~ KV4ZY WD5DHK R-07

223445 Tx 2498 ~ WD5DHK KV4ZY RR73 

223500 -17 0.2 2499 ~ KV4ZY WD5DHK 73

223516 Tx 2498 ~ AJ4F KV4ZY -04 

223530 -9 0.1 2716 ~ VA7VJ AJ4F EL29

223545 Tx 2498 ~ AJ4F KV4ZY -04 

223615 Tx 2498 ~ AJ4F KV4ZY -04 

223630 -8 0.1 2716 ~ KV4ZY AJ4F -06

223700 -7 0.1 2716 ~ KV4ZY AJ4F -06

223730 -3 0.0 2715 ~ KV4ZY AJ4F -06

022315 Tx 2080 ~ CQ KV4ZY EN91 

022330 -12 0.1 2080 ~ KV4ZY WA4GLH EM75

022345 Tx 2080 ~ WA4GLH KV4ZY -12 

022415 Tx 2080 ~ WA4GLH KV4ZY -12 

022445 Tx 2080 ~ WA4GLH KV4ZY -12 

022500 -17 0.1 2080 ~ KV4ZY WA4GLH R-05

022515 Tx 2080 ~ WA4GLH KV4ZY RR73 

022545 Tx 2080 ~ CQ KV4ZY EN91 

 

When the QSO with WD5HDK ended I double clicked on AJ4F to try to pick him up. 
He was already calling VA7VJ and did not respond to my calls, I can not recall 
whether I used F4 or Esc to abort the QSO. Just then the XYL arrived home from 
getting groceries so I had to leave the operating position. XYL & I had supper 
& watched a DVD movie before I returned to operating position around 02:20Z. 
The next QSO with WA4GLH was logged with the incorrect start time as shown in 
the resulting wsjtx.log entries:

 

2018-11-16,22:34:15,2018-11-16,22:34:45,WD5DHK,EM12,14.076498,FT8,-16,-07,20,TS-2000
 & H-6BTV,
2018-11-16,22:35:15,2018-11-17,02:25:15,WA4GLH,EM75,7.076080,FT8,-12,-05,20,TS-2000
 & H-6BTV,

 

I use JTAlert to send logging to Log4OM automatically. Log4OM uses the start 
times to sort the entries, thus the 11-17-18 02:23 QSO was logged as 11-16-18 
22:35. As many others probably do, I have Log4OM set up to automatically upload 
QSOs to online logs like QRZ, EQSL, etc. Wrong day and 4 hours difference in 
QSO time will not match up very well for verifications.

 

By the way I have not had any issues with losing the check on auto seq & call 
1st when changing bands as some others have reported.

 

 

 73 de Doug KV4ZY

 Original Message 
Subject: [wsjt-devel] wrong time logged
From: Al 
Date: Wed, November 14, 2018 2:54 pm
To: wsjt-devel@lists.sourceforge.net

( RC4 )
2018-11-14,19:12:15,2018-11-14,19:17:00,K1HK,FN42,14.076397,FT8,-01,+06,40,FT8  
Sent: -01  Rcvd: +06,
2018-11-14,19:17:33,2018-11-14,19:42:00,W8NNX,EL98,14.076377,FT8,-09,+06,40,FT8 
 Sent: -09  Rcvd: +06,

In the contact with W8NNX the start time should have been 19:41:15 ..

After the QSO with K1HK I called CQ for 3 minutes.. and then was idles until 
again calling QSO at 19:41 when W8NNX answered.

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

Re: [wsjt-devel] RC 4 testa.

[Stephen Ireland]

Folks,

I am now up on “main area” 40m  at around 40m at 2250 hz offset ... Thanks 
again to Shiro JA9CAC again as my only contact so far!

The issue is that I can see a very strong station – i.e

112230 -6 0.6 1226 ~ JK1VXE KH2JU -15

This station has been as strong as +00 ... I should be making it to this 
station; likewise I should have had a response as it has spent a lot of time 
calling CQ. Propagation to the US from Oz (generally) is there.

I have made REPEATED attempts to get back with no success.

I will spend the next hour or so calling up here (from 11:30 GMT 17th Nov 2018) 
– so if you see me please come back !

If you see a problem with my sig please email back and/or report here for 
diagnostics !

73

Steve I
VK3VM / VK3SIR

Sent from Mail for Windows 10


From: Krzysztof Krzemiński 
Sent: Saturday, November 17, 2018 9:01:29 PM
To: Bob via wsjt-devel
Subject: [wsjt-devel] RC 4 testa.

Ladies and gentelmen, HAMs,

Where is the ham spirit?

Quite nobody WW is using RC4.

Let's start and run RC4, nobody will do it in your name.

Even if new, super contact "do not change colour on your log".

Help Joe and his team.

Kris, SP5NOH


Wysłano z TypeApp
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] RC 4 testa.

[Stephen Ireland]

I could not agree more !

I am on 30m now and will be most of the night... 2050Hz offset directly !

See you all there !

Sent from Mail for Windows 10


From: Krzysztof Krzemiński 
Sent: Saturday, November 17, 2018 9:01:29 PM
To: Bob via wsjt-devel
Subject: [wsjt-devel] RC 4 testa.

Ladies and gentelmen, HAMs,

Where is the ham spirit?

Quite nobody WW is using RC4.

Let's start and run RC4, nobody will do it in your name.

Even if new, super contact "do not change colour on your log".

Help Joe and his team.

Kris, SP5NOH


Wysłano z TypeApp
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] RC 4 testa.

[Krzysztof Krzemiński]

Ladies and gentelmen, HAMs,

Where is the ham spirit?

Quite nobody WW is using RC4.

Let's start and run RC4, nobody will do it in your name.

Even if new, super contact "do not change colour on your log".

Help Joe and his team.

Kris, SP5NOH


⁣Wysłano z TypeApp ​___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel