Re: [wsjt-devel] Flex slice handling

[Jay Hainline]

Exactly what issues Mike? I am using a Flex 6500 and frequently run multi 
instances of WSJTX connected to slices using TCP ports. The only issue I have 
seen is if i set WSJTX to use Fake It for split operation. Then some times the 
radio will not transmit audio. It seems to be a timing issue where the slice is 
being moved to center the transmit audio when the radio is keyed and the audio 
is trying to be sent before the slice is set. I dont know if thats a WSJTX 
issue or a Flex Smartsdr issue.I have found setting WSJTX split operation to 
None so the slice doesnt move bypasses the problem and I dont have any missing 
transmit audio issues. 73 Jay KA9CFDSent from my  U.S.Cellular© Smartphone
 Original message From: Black Michael via wsjt-devel 
 Date: 2/22/21  08:58  (GMT-06:00) To: WSJT 
Software Development  Cc: Black Michael 
 Subject: [wsjt-devel] Flex slice handling Been seeing 
some discussion on the inability of handling slices well with Flex rigs.I'd 
like propose that WSJT-X add a new message when the window is activated -- same 
logic as the watchdog timer does when you click on the window.  External apps 
could use that for many purposes like this.The message would say the windows 
has been activated -- and maybe a window handle for the OS or some other 
germane object?  Any app could use this info do things like set the active 
slice, adjust antennas, tune, etc.Could also add a new function in hamlib so 
WSJT-X could send a set_conf("flex_slice", params.flex_slice.toLatin1 ().data 
()););I know this would require another parameter for the rig config window -- 
and would only seem to apply to Flex TCP connections tooI still have to get 
a Flex user to test the capability.Better ideas for how to do this are more 
than welcome.Mike W9MDB___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] F Low and High boxes turn red

[Jay Hainline]

Thanks for responding Bill. Good to know and probably something to be
published in the user guide for sure.

 

73 Jay KA9CFD

 

From: Bill Somerville  
Sent: Thursday, October 1, 2020 11:54
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] F Low and High boxes turn red

 

On 01/10/2020 12:29, Jay Hainline wrote:

Using the Windows 64 bit version of WSJT-X 2.3.0-rc1

 

When monitoring FST4 mode on 630m, I have F Low at 600 and F High at 1400.
Wide graph is using Bins/Pixel 4 with Start at 100 Hz. If I increase T/R
from 60 seconds to 300, my F Low and F High boxes turn red. If I increase F
Low to 1000, then the red disappears. Is this expected?

 

73 Jay KA9CFD

Hi Jay,

as the T/R period increases with FST4 and FST4W modes the bandwidth narrows.
The consequence is that the Rx filters in the decoder are closer together
and far more candidate signals per Hertz can be detected. The red background
is a reminder that the analysis bandwidth is unnecessarily wide and may lead
to increased false decodes, and certainly will increase the CPU resource
required to decode. The thresholds vary according to the T/R period
selected.

73
Bill
G4WJS.

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

[wsjt-devel] F Low and High boxes turn red

[Jay Hainline]

Using the Windows 64 bit version of WSJT-X 2.3.0-rc1

 

When monitoring FST4 mode on 630m, I have F Low at 600 and F High at 1400.
Wide graph is using Bins/Pixel 4 with Start at 100 Hz. If I increase T/R
from 60 seconds to 300, my F Low and F High boxes turn red. If I increase F
Low to 1000, then the red disappears. Is this expected?

 

73 Jay KA9CFD

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

Re: [wsjt-devel] Release Candidate: WSJT-X 2.3.0-rc1

[Jay Hainline]

Thanks for the update Bill. I have been monitoring 630m with the new modes and 
it seems to work quite well with decodes. VK4YB is coming in again just before 
sunrise. I need to play around with the NB setting to see how it performs. 73 
Jay KA9CFDSent from my  U.S.Cellular© Smartphone
 Original message From: Bill Somerville  
Date: 9/29/20  06:10  (GMT-06:00) To: wsjt-devel@lists.sourceforge.net Subject: 
Re: [wsjt-devel] Release Candidate: WSJT-X 2.3.0-rc1 
On 28/09/2020 13:39, Bill Somerville
  wrote:

On
  28/09/2020 13:01, Jay Hainline wrote:
  
  Hello All.


I have downloaded the new Windows 10 64 bit 2.3.0-rc1 and have
installed it

on my Windows 10 64 bit computer. First impressions are very
good with the

new modes. Received VK4YB who was using FST4 120 sec periods and
also on

FST4W 120 sec periods this morning on 630 meters.


I noticed one bug in the settings/Colors tab. In the Decode
Highlighting

section, If I try and left click and drag one of the color
highlighting

settings up or down the list, it disappears rather than set it
at the new

position to try and prioritize the colorization.


Thanks and 73,


Jay KA9CFD

  
  
  Hi Jay,
  
  
  thanks for the issue report on the decode highlight list
  drag'n'drop, I confirm this is a regression. For now I recommend
  resetting the whole table and only enable the options you want, it
  will be fixed for the next release.
  
  
  73
  
  Bill
  
  G4WJS.

Hi Jay,
an update on this issue. I have tracked it down to a regression
  in the latest Qt framework version. I have raised an issue with
  the Qt developers. For our next release I will revert to a prior
  Qt version.
Note also that this issue does not affect the 32-bit Windows
  version of WSJT-X.
73
  Bill
  G4WJS.

  

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

Re: [wsjt-devel] Release Candidate: WSJT-X 2.3.0-rc1

[Jay Hainline]

Hello All. 

I have downloaded the new Windows 10 64 bit 2.3.0-rc1 and have installed it
on my Windows 10 64 bit computer. First impressions are very good with the
new modes. Received VK4YB who was using FST4 120 sec periods and also on
FST4W 120 sec periods this morning on 630 meters. 

I noticed one bug in the settings/Colors tab. In the Decode Highlighting
section, If I try and left click and drag one of the color highlighting
settings up or down the list, it disappears rather than set it at the new
position to try and prioritize the colorization. 

Thanks and 73,

Jay KA9CFD

-Original Message-
From: Joe Taylor  
Sent: Sunday, September 27, 2020 20:23
To: WSJT software development 
Subject: [wsjt-devel] Release Candidate: WSJT-X 2.3.0-rc1

The first public candidate release of WSJT-X 2.3.0 is now available for
download and use by beta testers.  This release is your first chance to try
two new modes designed especially for use on the LF and MF bands, and to
provide feedback to the WSJT Development Team.  The new modes are:

  - FST4, for 2-way QSOs.  Options for sequence lengths from 15 seconds
to 30 minutes, with threshold sensitivities from -20.7 to -43.2 dB in
a 2500 Hz reference bandwidth.

  - FST4W, for WSPR-like transmissions.  Sequence lengths from 2 minutes
to 30 minutes, threshold sensitivities from -32.8 to -44.8 dB.

FST4-60 is about 1.7 dB more sensitive than JT9, largely because it uses
multi-symbol block detection where appropriate. With AP decoding in FST4 the
advantage can be as much as 4.7 dB. Additional sensitivity details with
respect to path Doppler spread are illustrated in the following graph
comparing JT9 and FST4-60:
https://physics.princeton.edu/pulsar/k1jt/jt9_vs_fst4.pdf

FST4W-120 is about 1.4 dB more sensitive than WSPR, and FST4W submodes with
longer transmissions have proportionally better sensitivity. 
Decoding probabilities are plotted as a function of SNR on the additive
white Gaussian noise (AWGN) channel for WSPR and all FST4W submodes
here: https://physics.princeton.edu/pulsar/k1jt/wspr_vs_fst4w.pdf

Tests over the past several months have shown FST4 and FST4W frequently
spanning intercontinental distances on the 2200 m and 630 m bands. 
Further details and operating hints can be found in the "Quick-Start Guide
to FST4 and FST4W":

https://physics.princeton.edu/pulsar/k1jt/FST4_Quick_Start.pdf

We strongly recommend that users of JT9 and WSPR on the LF and MF bands
should migrate to the more sensitive modes FST4 and FST4W.


Links to installation packages for Windows, Linux, and Macintosh are 
available here:
http://physics.princeton.edu/pulsar/k1jt/wsjtx.html
Scroll down to find "Candidate release:  WSJT-X 2.3.0-rc1".

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 this beta release of WSJT-X 2.3.0.  Please 
report bugs by following instructions found here in the User Guide:
http://www.physics.princeton.edu/pulsar/K1JT/wsjtx-doc/wsjtx-main-2.3.0-rc1.
html#_bug_reports

  -- 73 from 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] WSJT-X 2.2.1 GA Release

[Jay Hainline]

Thank you for the update. I am able to connect with my Yaesu FT991 direct
again to control the radio. 

73 Jay KA9CFD

-Original Message-
From: Joe Taylor  
Sent: June 6, 2020 17:44
To: WSJT software development 
Subject: [wsjt-devel] WSJT-X 2.2.1 GA Release

WSJT-X 2.2.1 is a bug-fix release that addresses several regressions or
defects in version 2.2.0.

Most importantly, v2.2.1 incorporates a revised Hamlib version that properly
controls the Yaesu FT-891 and FT-991 radios.  A list of all program changes
since WSJT-X 2.2.0 can be found in the cumulative Release Notes here:
http://physics.princeton.edu/pulsar/k1jt/Release_Notes.txt

Upgrading from earlier versions of WSJT-X should be seamless.  There is no
need to uninstall a previous version or move any files.

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.
Follow instructions in the WSJT-X User Guide here:
http://www.physics.princeton.edu/pulsar/K1JT/wsjtx-doc/wsjtx-main-2.2.0.html
#SUPPORT

We hope you will enjoy using WSJT-X Version 2.2.1.

  -- 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] Hamlib error with GA release

[Jay Hainline]

No Bill. Receive seems ok. I can select none for the radio and set up and use 
the standard com port for PTT RTS. That works ok if done that way. It will 
transmit. It is just the CAT enhanced com port that it does not see. I am using 
the 64 bit version.  Computer is Windows 10 64 bit. Hope that helps. Let me 
know what else you might need.73 Jay. KA9CFDSent from my  U.S.Cellular© 
Smartphone
 Original message From: Bill Somerville  
Date: 6/2/20  12:34  (GMT-06:00) To: wsjt-devel@lists.sourceforge.net Subject: 
Re: [wsjt-devel] Hamlib error with GA release 
Hi Jay,


is this issue also associated with no
  receive audio to WSJT-X?


73
  Bill
  G4WJS.


On 02/06/2020 17:50, Jay Hainline
  wrote:


  Same issue with my FT991.
  
  
  Hamlib error: Invalid parameter while getting
current frequency.
  
  
  Jay KA9CFD
  
  
  
  
  
  
  
Sent from my
  U.S.Cellular© Smartphone
  
  
  
  
  
  
 Original message 
From: Bill  
Date: 6/2/20 11:44 (GMT-06:00) 
To: WSJT software development
   
Subject: Re: [wsjt-devel] Hamlib error with GA release 


  
  I have run into the same issue. Just installed the
2.2.0 GA on Windows 10 and receive "Hamlib error: Invalid
parameter while getting current frequency". Radio - FT991A.
Also, no display on the waterfall but shows activity in the
decode list. Previous versions worked fine and JTDX still works
normally. 


Bill - AK6A
  
  
  
On Tue, Jun 2, 2020 at 9:38 AM
  Kim gross  wrote:

Windows 
  64 bit, upgraded to GA release I get a hamlib error and can
  not 
  do anything.   Reinstalled RC3, system works fine. FT991A.

  



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

Re: [wsjt-devel] Hamlib error with GA release

[Jay Hainline]

Same issue with my FT991.Hamlib error: Invalid parameter while getting current 
frequency.Jay KA9CFDSent from my  U.S.Cellular© Smartphone
 Original message From: Bill  Date: 
6/2/20  11:44  (GMT-06:00) To: WSJT software development 
 Subject: Re: [wsjt-devel] Hamlib error with 
GA release I have run into the same issue. Just installed the 2.2.0 GA on 
Windows 10 and receive "Hamlib error: Invalid parameter while getting current 
frequency". Radio - FT991A. Also, no display on the waterfall but shows 
activity in the decode list. Previous versions worked fine and JTDX still works 
normally. Bill - AK6AOn Tue, Jun 2, 2020 at 9:38 AM Kim gross 
 wrote:Windows  64 bit, upgraded to GA release I get a 
hamlib error and can not 
do anything.   Reinstalled RC3, system works fine. FT991A.




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

[Jay Hainline]

Sorry for the bandwidth. Please disregard the message. It was caught in a draft 
folder and accidentally released.

 

73 Jay KA9CFD

 

From: Jay Hainline  
Sent: January 17, 2020 11:44
To: wsjt-devel@lists.sourceforge.net
Subject: [wsjt-devel] Fwd: Re: WSJT-X 2.1.1 GA release

 

 

 

 

 

Sent from my U.S.Cellular© Smartphone

 

 Original message 

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

Date: 11/25/19 18:15 (GMT-06:00) 

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

Subject: Re: [wsjt-devel] WSJT-X 2.1.1 GA release 

 

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

[wsjt-devel] Fwd: Re: WSJT-X 2.1.1 GA release

[Jay Hainline]

Sent from my  U.S.Cellular© Smartphone
 Original message From: Bill Somerville  
Date: 11/25/19  18:15  (GMT-06:00) To: wsjt-devel@lists.sourceforge.net 
Subject: Re: [wsjt-devel] WSJT-X 2.1.1 GA release 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 
inconvenience73BillG4WJS.___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

Re: [wsjt-devel] Dsec control for WSJT-X

[Jay Hainline]

OK Bill. It was just a thought and I knew the feature had been available
before. Getting people to get their computer clocks accurate is like herding
cats. Thanks and GL.

 

Jay KA9CFD

 

From: Bill Somerville  
Sent: May 6, 2019 11:36
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] Dsec control for WSJT-X

 

On 06/05/2019 11:49, Jay Hainline wrote:

In the older WSJT 10 program, there is a control labeled Dsec where the
user’s UTC clock reading can be adjusted to manually synchronize with your
QSO partner’s computer. I wonder if this feature would be useful in WSJT-X
to help with FT8 decodes if your attempted QSO partner’s computer clock
appears to be off. It could be helpful if they are starting transmit too
early. Might be something for the developers could look at.

 

73 Jay

 

Jay Hainline KA9CFD

Colchester, IL  EN40om

Hi Jay,

WSJT-X is an Open Source application, considered contributions are welcome
but there are no guarantees of acceptance. Such a change is possible
although quite complex given that time is read in several places and it
would be disruptive of an already complex application to maintain a separate
source of time consistently. TBH we would prefer that users take the
relatively simple steps necessary to keep their PC time synchronized to UTC,
within a few milliseconds, automatically. The new FT4 mode requires tighter
control of time synchronization, currently ±0.5 S, so manual setting is not
really sufficient.

73
Bill
G4WJS.

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

[wsjt-devel] Dsec control for WSJT-X

[Jay Hainline]

In the older WSJT 10 program, there is a control labeled Dsec where the
user's UTC clock reading can be adjusted to manually synchronize with your
QSO partner's computer. I wonder if this feature would be useful in WSJT-X
to help with FT8 decodes if your attempted QSO partner's computer clock
appears to be off. It could be helpful if they are starting transmit too
early. Might be something for the developers could look at.

 

73 Jay

 

Jay Hainline KA9CFD

Colchester, IL  EN40om

 

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

Re: [wsjt-devel] Flex Split Operation Setup with WSJT-X

[Jay Hainline]

Bill, Mike and others,

 

You do realize that JA on 160 meters is restricted to using FT8 at 1908 khz? 
Practice has been for JA to call for DX at their allocation and listen for NA 
stations transmitting at 1840. Widening the bandwidth window is not very 
eloquent. Surely using a split VFO option with 2 slices would be more feasible. 
My 2 cents…

 

73 Jay KA9CFD

 

From: Bill Somerville  
Sent: October 27, 2018 10:50
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] Flex Split Operation Setup with WSJT-X

 

Hi Russ,

why do you want to use WSJT-X split operating mode with your SDR? I thought the 
FlexRadio Tx bandwidth could be set as wide as the Rx bandwidth, that should 
obviate the need for using SPLIT since you are employing an all digital audio 
chain.

73
Bill
G4WJS.

On 27/10/2018 08:04, Star Light wrote:

Thanks for the response. 

 

As I mentioned in my post, it doesn’t work just fine on one slice.  That’s one 
of the reasons I posted the question.

 

Does anybody have any actual knowledge about this?

 

Thanks, Russ

 

 

 

Sent from my iPhone


On Oct 25, 2018, at 9:16 PM, Black Michael via wsjt-devel 
mailto:wsjt-devel@lists.sourceforge.net> > 
wrote:

I don't know why you would need separate slices to work split in WSJT-X.  
Aren't slices really for different frequency ranges?

Split in WSJT-X is all inside the audio band pass of one slice.  It just 
adjusts the frequency so that the audio is always in the 1500-2000Hz offset.

Split is really designed for rigs (or operators) that have harmonics on their 
signal (usually from incorrect audio settings).

As long as you aren't hitting the ALC on your Flex your signal would be clean 
and split is not needed.

But it should work just fine on one slice.

 

de Mike W9MDB

 

 

 

 

On Thursday, October 25, 2018, 5:55:03 PM CDT, Star Light 
mailto:starlite4...@gmail.com> > wrote: 

 

 

 

Hello, I have WSJT-X (v1.9.1) set up with my Yaseu FTdx9000 to operate full 
(not “fake") split and it works great.  WSJT-X seems to always listen on the A 
side and set Tx on the B side (no matter how it’s set initially) and moves the 
B side Tx freq around in a logical way.

 

I’m not sure how to set up the corresponding configuration on my Flex.  At 
present I have it set to the A slice and listening through DAX 1 on the B slice 
(to be “split”).  It makes odd freq adjustments that don’t make sense on the A 
Tx slice, never changes Tx to the B slice and never moves the DAX slice choice 
no matter how I set it up.  I don’t know what it is assuming and can’t see any 
way to “tell it” it’s listening on the B slice.  I don’t know if it assumes 
that in setup or something else but seems to work best when set up this way 
from a simply making contacts point of view.

 

If I set Tx and DAX audio both on the A slice (always choosing split in 
config), it will actually activate the B slice from time to time but never 
set’s DAX audio output from it, or Tx to it.  So it can’t actually be using the 
B slice for anything.  Then shortly after it activates it, it deactivates it.

 

Flex is a drop-down option so I know WSTJ-X “knows” about it, I just know how 
it expects the physical radio to be set up to use it in split mode.  Any advice 
would be appreciated!  Thanks, Russ KR6W

 

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

Re: [wsjt-devel] VP6D on wrong time slot

[Jay Hainline]

I am seeing this too George as of 1415z on 14090. I remember where this could 
happened in an earlier version but thought it had been fixed. 
Jay KA9CFD


Sent from my  U.S.Cellular© Smartphone
 Original message From: WB5JJJ  Date: 
10/22/18  09:01  (GMT-06:00) To: wsjt-devel@lists.sourceforge.net Subject: 
[wsjt-devel] VP6D on wrong time slot 
Right now on 20m (14.090) VP6D is transmitting on the ODD time slot.  About 
half of the callers are on EVEN and the others on ODD.  How is the happening?  
He's using DX Fox according to what I'm seeing from him.  

-- 
George Cotton, WB5JJJ

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

[wsjt-devel] Minor Bug report WSJT-X 2.0.0-RC3

[Jay Hainline]

Using WSJT-X 2.0.0-RC3 with Windows 10 64 bit.

 

Using NA VHF Contest mode for meteor scatter contacts on 2m. TX1 is grayed
out as it should be. However when changing contest setting in the advance
tab back to None, TX1 stays grayed out until you double click on it. This
appears to be a minor bug.

 

73 Jay

 

Jay Hainline KA9CFD

Colchester, IL  EN40om

 

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

Re: [wsjt-devel] Candidate release WSJT-X 2.0.0-rc2

[Jay Hainline]

Trying out the new RC2 release. In MSK144 mode, double clicking on a CQ call
in the Band Activity window to respond to a caller does not populate the
standard messages or turn on Enable TX. Works OK on FT8 mode. And responding
to a TX2 or TX4 message in msk144 mode works ok if double clicking on the
message. Only seems to be TX1 in msk144 where double clicking does not work.
This is on Windows 10 64 bit.

73 Jay KA9CFD

-Original Message-
From: Joe Taylor  
Sent: September 25, 2018 16:22
To: WSJT software development 
Subject: [wsjt-devel] Candidate release WSJT-X 2.0.0-rc2

A second candidate release of WSJT-X 2.0,  is now available for download and
use by beta testers.  Changes in WSJT-X 2.0.0-rc2 relative to -rc1 include
the following:

  - Corrected a flaw that encoded a message's first callsign as
hexadecimal telemetry data if the call consisted only of letters
A-F and digits 0-9.

  - Corrected program logic that failed to identify certain callsigns
as "nonstandard".

  - Fixed a bug that color-highlighted bare CQ messages (no grid
locator) as "New DXCC".

  - Fixed a bug that failed to log Report Sent if MyCall is a
nonstandard call.

  - Fixed a bug that generated incorrect MSK144 tones for certain
messages and caused a "memory" effect on stations receiving the
incorrect tones.

  - Fixed several bugs that could cause certain Tx messages to crash
the program.

  - Suppressed the display of certain illogical false decodes.

The "Quick-Start Guide to WSJT-X 2.0" has been updated.  If you plan to use
the beta-test release candidate, be sure to read this entire guide
first:
http://physics.princeton.edu/pulsar/k1jt/Quick_Start_WSJT-X_2.0.pdf


New features and enhancements in WSJT-X 2.0 relative to Version 1.9.1 are
summarized here:

http://physics.princeton.edu/pulsar/k1jt/New_Features_WSJT-X_2.0.txt

Download links for Windows, Linux, and macOS installation packages can be
found on the WSJT-X web site

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

We look forward to your feedback on WSJT-X 2.0-rc2.  Reports should be sent
to the wsjt-devel email list, wsjt-devel@lists.sourceforge.net. You must
subscribe to the list to post there.

Reminder: A "mock contest" using FT8 mode and ARRL RTTY Roundup contest
exchanges will be held tomorrow evening, NA time:
Thursday, 27 September 0200-0259 UTC (Wednesday evening, NA time)

A separate announcement about the mock contest will follow this one.

 -- 73, Joe, K1JT (for the 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] Use of sourceforge.net

[Jay Hainline]

OK Ria. I have not even seen the WSJT-X 2.0-RC1 posted on Sourceforge, yet
it's available on the WSJT web site.

73 Jay KA9CFD

-Original Message-
From: rjai...@gmail.com  
Sent: September 24, 2018 16:13
To: WSJT software development 
Subject: Re: [wsjt-devel] Use of sourceforge.net

See below from Joe:

Joe Taylor j...@princeton.edu via lists.sourceforge.net

Tue 10 Jul, 10:39
to wsjt-devel
One of the changes associated with moving source code for WSJT and related
programs from SVN to Git is a change in policy regarding development code
and the frequency of "commits" to the public repository.

Code development now takes place in limited-access git repositories.
New code is made publicly available when we consider it stable; we then do a
"push" to the relevant Git repository on SourceForge. These events will be
less frequent than our commits to SVN have been in the past.

There are several reasons why this policy change is necessary and desirable.
One is to prevent wasted time caused by people carelessly using development
code on the air before new developments are finished and tested.  Some users
have even distributed untested, unauthorized program builds that contain
significant errors -- which only compounds the problem.

A more serious issue has been the appearance of our ideas, algorithms,
protocols, GUI features, and source code in "copycat software" even before
we have frozen the design and released the new ideas in our own software.
We are very much in favor of cooperative development of open-source code,
with a bi-directional exchange of ideas.  We believe this model fits very
well into the cooperative nature of the Amateur Radio hobby.  We are not
favorably disposed to a one-way flow of ideas:
in particular, to separate efforts that "take" liberally, but do not "gave
back" at all.

WSJT-X and its sister programs remain open-source software.  Our released
General Availability (GA) program versions are licensed under version 3 of
the GNU General Public License (GPLv3).  Full source code for these versions
is always publicly available.

Development code, or "work in progress", is shared among those working on it
and contributing to it.  In general such code is not made publicly available
until design parameters are frozen and thorough testing has been done, and
new code is merged into the Git "master" branch.

-- 73, Joe, K1JT
On Mon, 24 Sep 2018 at 12:10, Jay Hainline  wrote:
>
> Has Sourceforge been abandoned for posting new revisions that can be
build? I have not seen any updates posted since July 2. Just wondering.
>
>
>
> 73,
>
> Jay Hainline KA9CFD
>
> Colchester, IL  EN40om
>
>
>
> ___
> 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] Use of sourceforge.net

[Jay Hainline]

Ok thanks for the info Bill. I am waiting on RC2 to come out. Interested to
see how the new msk144 will work on 2 meters with its shorter meteor pings.

 

73 Jay KA9CFD

 

From: Bill Somerville  
Sent: September 24, 2018 16:20
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] Use of sourceforge.net

 

On 24/09/2018 16:41, Jay Hainline wrote:

Has Sourceforge been abandoned for posting new revisions that can be build?
I have not seen any updates posted since July 2. Just wondering.

 

73,

Jay Hainline KA9CFD

Colchester, IL  EN40om

Hi Jay,

no it hasn't but not much is being pushed there while we are at early stages
of a major release. Once things have stabilized a bit then bug fix updates
will be pushed there more regularly for those that can't wait for a formal
bug fix release. Misuse of early R work by others has forced us to use a
private repository for such work with only source code of final releases
being pushed out at the point of release. We have yet to hit the sweet spot
of R in public and having others take advantage before we have released
packages ourselves.

73
Bill
G4WJS.

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

[wsjt-devel] Use of sourceforge.net

[Jay Hainline]

Has Sourceforge been abandoned for posting new revisions that can be build?
I have not seen any updates posted since July 2. Just wondering.

 

73,

Jay Hainline KA9CFD

Colchester, IL  EN40om

 

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

Re: [wsjt-devel] Tx/Rx

[Jay Hainline]

Replace the arrows with the word "to" and then it makes sense. At least it does 
to me. ;-)
73 Jay. KA9CFD


Sent from my  U.S.Cellular© Smartphone
 Original message From: Al Pawlowski  Date: 
7/3/18  10:38  (GMT-06:00) To: wsjt-devel@lists.sourceforge.net Subject: Re: 
[wsjt-devel] Tx/Rx 
If a count was taken, I bet it would be 10 to 1 or more that think the 
button arrows are backwards.


> Date: Tue, 03 Jul 2018 14:08:57 +0100
> From: Barry Smith 
> To: wsjt-devel@lists.sourceforge.net
> Subject: Re: [wsjt-devel] Tx/Rx
> 
> ...There are as many people who think the sense is
>> correct as there are that think it is reversed.

-- 
Al Pawlowski Los Osos, CA USA

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] working stations over 10000 km on 6m

[Jay Hainline]

I think that might be a good solution Bill as NA contest mode is pretty much a 
"VHF/UHF/Microwave feature".
73 Jay. KA9CFD


Sent from my  U.S.Cellular© Smartphone
 Original message From: Bill Somerville  
Date: 5/31/18  12:08  (GMT-06:00) To: wsjt-devel@lists.sourceforge.net Subject: 
Re: [wsjt-devel] working stations over 1 km on 6m 

On 31/05/2018 17:43, Joe Taylor wrote:


On
  5/31/2018 12:22 PM, Jay Hainline wrote:
  

  Joe, is it
possible to use one of the extra FT8 bits as a flag that you are
transmitting in contest mode or not? Would that be useful to
keep the program on the receiving end from being confused?




73 Jay KA9CFD


  
  

  Of course this could be done in FT8.  But as I emphasized in a
  previous email, we did not want to use a different solution for
  FT8 and MSK144.
  

  As currently implemented, MSK144 has no spare bits.
  

  

  Casual operators can get confused enough with type of "NA VHF
  Contest: mode, let alone two different ones.
  

  

  -- Joe, K1JT
  


Hi Joe and Jay,
perhaps we should only have the automatic detection of NA contest
  mode messages when "Enable VHF/UHF/Microwave features" is enabled.
  That way user could set up a configuration for 6m multi-hop Es
  operating that will not get confused by such long DX.
73

  Bill

  G4WJS.


  --
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] working stations over 10000 km on 6m

[Jay Hainline]

Joe, is it possible to use one of the extra FT8 bits as a flag that you are 
transmitting in contest mode or not? Would that be useful to keep the program 
on the receiving end from being confused?
73 Jay KA9CFD


Sent from my  U.S.Cellular© Smartphone
 Original message From: Joe Taylor  Date: 
5/31/18  10:34  (GMT-06:00) To: WSJT software development 
 Subject: Re: [wsjt-devel] working stations 
over 1 km on 6m 
Hi Jay, Ned, and all,

On 5/30/2018 8:57 PM, Jay Hainline KA9CFD wrote:
> We had a big opening to JA today on 6m. Some of the contacts were over
> 10,000 km and I have heard some ops report their WSJT-X software would hang
> up asking if they want to switch to contest mode. Apparently the program
> sees the grid from JA and thinks they are in contest mode? I don't have much
> more details. Maybe someone can chime in or advise if this would be a bug
> that needs fixed.
> 
> Jay Hainline  KA9CFD

Ned AA7A wrote:
> This happened to me at the most inopportune time. I was sending a signal 
> report to DS4AOW for a ATNO on 6m and it sent a NA Contest TX3 exchange 
> instead of what was expected. The only way I could clear the problem was to 
> change the mode to to anything other than FT8 and then back to get the right 
> TX3 message. While I was sorting that all out, the band faded and I did not 
> complete.
> 
> It's rare to hear stations over 10 KM, so this is a hard thing to test.

Jay KA9CFD wrote:
>  Hopefully the developers will have some insight. I never have like the idea 
>of using the opposite side of the world grid to represent an R-grid contest 
>report. Causes confusion for non-contesters, and some bad side effects 
>apparently. :-)

Contesters pleaded for an easy way to send "R+grid" rather than "R+rpt" 
in the message sequence.  They wanted this feature in both MSK144 and 
FT8.  FT8 has three extra information bits in its message payload, not 
all of which are (yet) used.  MSK144 does not have these extra bits. 
There is no foolproof, satisfy-everybody, mode-independent way to 
squeeze "R+grid" messages along with all other standard message features 
in a 72-bit packet.

We therefore decided to use the "antipode grid" method of conveying 
"R+grid".  QSOs on VHF bands over distances greater than 10,000 kkm 
using MSK144 and FT8 are expected to be rare.

When you're lucky enough to be working East Asia on 6m, using WSJT-X 
v1.9, just hit "No" when asked if you should be in contest mode.

In any future (or possibly enhanced) modes we will most likely reserve a 
few additional bits for message types that solve this problem (as well 
as Rover callsigns and a few other nagging issues of message structure) 
in a better way.  The necessary price will be a small (less than 1 dB) 
loss of sensitivity.

-- 73, Joe, K1JT

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] working stations over 10000 km on 6m

[Jay Hainline]

Hi Ned. I was wondering if you have VHF/UHF features enabled in the settings? I 
wonder if this issue exists if that box is unchecked?
Sorry about the DS. I was able to work 17 JA's but never saw him.
73 Jay KA9CFD


Sent from my  U.S.Cellular© Smartphone
 Original message From: Ned  Date: 5/30/18  20:30 
 (GMT-06:00) To: wsjt-devel@lists.sourceforge.net Subject: Re: [wsjt-devel] 
working stations over 1 km on 6m 
Jay,

This happened to me at the most inopportune time. I was sending a signal 
report to DS4AOW for a ATNO on 6m and it sent a NA Contest TX3 exchange 
instead of what was expected. The only way I could clear the problem was 
to change the mode to to anything other than FT8 and then back to get 
the right TX3 message. While I was sorting that all out, the band faded 
and I did not complete.

It's rare to hear stations over 10 KM, so this is a hard thing to test.

Ned / AA7A


On 5/31/2018 12:57 AM, Jay Hainline wrote:
> We had a big opening to JA today on 6m. Some of the contacts were over
> 10,000 km and I have heard some ops report their WSJT-X software would hang
> up asking if they want to switch to contest mode. Apparently the program
> sees the grid from JA and thinks they are in contest mode? I don't have much
> more details. Maybe someone can chime in or advise if this would be a bug
> that needs fixed.
>
> Jay Hainline  KA9CFD
> Colchester, IL
> EN40om
>
>
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] working stations over 10000 km on 6m

[Jay Hainline]

We had a big opening to JA today on 6m. Some of the contacts were over
10,000 km and I have heard some ops report their WSJT-X software would hang
up asking if they want to switch to contest mode. Apparently the program
sees the grid from JA and thinks they are in contest mode? I don't have much
more details. Maybe someone can chime in or advise if this would be a bug
that needs fixed.

Jay Hainline  KA9CFD
Colchester, IL
EN40om




--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] FT8 CQ Fox block possible?

[Jay Hainline]

Isnt this addressed in r8647?
Jay KA9CFD


Sent from my  U.S.Cellular© Smartphone
 Original message From: Black Michael via wsjt-devel 
 Date: 5/9/18  09:40  (GMT-06:00) To: WSJT 
Software Development  Cc: Black Michael 
 Subject: [wsjt-devel] FT8 CQ Fox block possible? 
There apparently was somebody on 20M FT8 last night in Fox mode from a 
relatively rare location and caused a mess on 14.074.  Everybody though he was 
calling simple CQ but was Fox so wasn't hearing them and users were crowding 
the lower end of 20M trying to get him making even the the Fox/Hound exchange 
problematic.
I don't think we can leave this up to "operator responsibility" as there are 
just too many out there.
So throwing out a few ideas to hopefully open up the discussion
#1 Active solution -- Add a "Fox" setting to the frequency list which is 
hard-coded for the "standard" bands and would prevent enabling Fox or Hound 
mode on those entries with an appropriate message.#2 Passive solution -- Detect 
Fox/Hound messages during decode and don't display them at all unless you have 
the modes enabled.  This would not stop older versions from seeing the decoding 
though.#3 Simple solution -- Whenever Fox mode is selected a big warning 
message comes up about band usage.  

de Mike W9MDB--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] RX messages when using msk144 mode

[Jay Hainline]

Not sure if my message got through so will try again. 

 

Jay KA9CFD

 

From: Jay Hainline <ka9...@mtcnow.net> 
Sent: April 12, 2018 12:30
To: wsjt-devel@lists.sourceforge.net
Subject: [wsjt-devel] RX messages when using msk144 mode

 

Running WSJT-X v1.9.0-rc3 r8609 with Windows 10 64 bit. It has been brought
to my attention that the receive messages are no longer populating the right
side tx messages window when running with a station in msk144 mode. I made a
couple of meteor scatter contacts on 6 meters and see this behavior.  This
seems to be happening in the 1.9.0 RC versions. 1.8.0 works as before with
receive messages of your qso partner populating the right side window.
Please take a look. The left side band activity window can get very busy
when there are lots of stations on meteor scatter and your QSO partner's
messages will scroll off the top before you know it.

 

73 Jay

 

Jay Hainline KA9CFD

Colchester, IL  EN40om

 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] RX messages when using msk144 mode

[Jay Hainline]

Running WSJT-X v1.9.0-rc3 r8609 with Windows 10 64 bit. It has been brought
to my attention that the receive messages are no longer populating the right
side tx messages window when running with a station in msk144 mode. I made a
couple of meteor scatter contacts on 6 meters and see this behavior.  This
seems to be happening in the 1.9.0 RC versions. 1.8.0 works as before with
receive messages of your qso partner populating the right side window.
Please take a look. The left side band activity window can get very busy
when there are lots of stations on meteor scatter and your QSO partner's
messages will scroll off the top before you know it.

 

73 Jay

 

Jay Hainline KA9CFD

Colchester, IL  EN40om

 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X v1.9.0-rc3: Testing of FT8 DXpedition Mode

[Jay Hainline]

That's a touchy one Joe. The JA's have been using 1908 for their FT8 window.
Anything above 1845 you start running into SSB stations. Maybe 1838 to be
just above the WSPR. I know you will run into the established 1840 FT8 but a
compromise will be needed. Another choice maybe is 1833 for dxpedition mode.
Maybe that might work. I hope some other TB dxers could chime in.

Jay KA9CFD

-Original Message-
From: Joe Taylor <j...@princeton.edu> 
Sent: March 29, 2018 13:58
To: WSJT software development <wsjt-devel@lists.sourceforge.net>
Subject: Re: [wsjt-devel] WSJT-X v1.9.0-rc3: Testing of FT8 DXpedition Mode

Hi Jay,

On 3/29/2018 6:52 AM, Jay Hainline KA9CFD wrote:
> Is the suggested Dxpedition frequency 1.8265 a typo? That would put it
right in the middle of the CW DX window on 160m. Surely a frequency of 1.836
would be a better choice IMHO.

Thanks for catching this error.  Not a typo, exactly, but 1.8265 is the
likely CW (not FT8) frequency for the KH1 DXpedition.  They are not
currently planning to use FT8 on 160m.

For now, I will simply delete 1.8265 from the list of suggested FT8
DXpedition frequencies.  Do you have a suggestion for something else for
160m?  1.836 would clobber the WSPR sub-band.  1.843 or thereabouts might be
OK, except for JA.  JA will need something like 1.900, I believe.
-- 73, Joe, K1JT


--
Check out the vibrant tech community on one of the world's most engaging
tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel




--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X v1.9.0-rc3: Testing of FT8 DXpedition Mode

[Jay Hainline]

Is the suggested Dxpedition frequency 1.8265 a typo? That would put it right in 
the middle of the CW DX window on 160m. Surely a frequency of 1.836 would be a 
better choice IMHO.

Jay KA9CFD

-Original Message-
From: Joe Taylor  
Sent: March 28, 2018 17:36
To: WSJT software development 
Subject: Re: [wsjt-devel] WSJT-X v1.9.0-rc3: Testing of FT8 DXpedition Mode

The second public test of FT8 DXpedition mode will be conducted on April 7, a 
little over a week from now.  You are cordially invited to join us for this 
test.  See the original announcement (copied below) for details.

Even if you read it before, be sure to read the latest revision of the
*FT8 DXpedition Mode User Guide.* It is dated March 28 and is available
here:
http://physics.princeton.edu/pulsar/k1jt/FT8_DXpedition_Mode.pdf
There are some changes from previously posted instructions!

I draw your particular attention to the following sentences found on page 1:

Please note: DXpedition Mode is not yet ready for “production” use. 
Until WSJT-X v1.9.0 is fully released, this mode should be used only in 
controlled test situations.  Please remember to send us your test results.

...

Subject to future revision, we are temporarily suggesting the following 
frequencies for testing DXpedition mode: 1.8265, 3.567, 7.066, 10.1405, 14.105, 
18.095, 21.067, 24.911, 28.067 MHz.


The first warning is included because several operators or groups have been 
trying, against our advice, to use the not-yet-complete DXpedition Mode in real 
pileup situations.  This misuse of a WSJT-X beta release (or of code taken from 
the WSJT-X development branch) has been counter-productive, to say the least.

The second item copied above is the result of early efforts to identify 
suggested FT8 DXpedition Mode operating frequencies for each HF band that will 
minimize interference with other modes.  We will welcome thoughtful suggestions 
that might improve this list of suggested frequencies.

We hope to see you in the pileups calling W1/KH7Z and W7/KH7Z on 14.105 MHz, 
1400-1600 UTC on April 7!

-- 73, Joe, K1JT

On 3/19/2018 10:09 AM, Joe Taylor wrote:
> The WSJT Development Group is pleased to announce a third Release 
> Candidate of WSJT-X Version 1.9.0.  A second release candidate, 
> v1.9.0-rc2, has been tested in the field over the past three weeks, 
> including a public test of FT8 DXpedition Mode conducted on March 6-7.
> 
> A General Availability (GA) release of v1.9.0 will be announced at a 
> suitable time, probably in the near future.  After that time you 
> should stop using any -rc# release candidate.
> 
> Here’s a short list of features and capabilities added to WSJT-X since 
> Version 1.9.0-rc2:
> 
> 1. Corrected a number of flaws in Fox behavior, FT8 DXpedition Mode
> 
> 2. Allow Hounds to use compound callsigns in FT8 DXpedition Mode
> 
> 3. Write debugging information to FoxQSO.txt
> 
> 4. Fix the "Blue Decode Button" bug
> 
> 5. Allow partial processing of incoming UDP Reply messages so that
> non-CQ/QRZ decodes can be processed. The processing is the same as
> double-clicking the same decoded message within WSJT-X except that
> "Enable Tx" will not be enabled.
> 
> 6. Send DX grid locator to wsjt_status.txt, for use by applications 
> like
> PstRotatorAZ
> 
> 7. Correct the display of DXCC status of KG4 calls
> 
> 8. Updated copy of cty.dat
> 
> 9. Updates to documentation
> 
> 10. Updated Hamlib functionality including changes to the Yaesu FT-817
> back end that allows the uBITx kit transceiver to be CAT 
> controlled
> by WSJT-X.
> 
> 10. Other minor bug fixes
> 
> 
> ##
> #
> 
>*Second Public Test of FT8 DXpedition Mode*
>---
> 
> If you decide to install v1.9.0-rc3, please help us by participating 
> in the second public test of FT8 DXpedition Mode scheduled for April 7.
> Once again, the goal is to simulate a rare-DXpedition pileup by having 
> many stations ("Hounds") calling and trying to work a designated 
> pseudo-DXpedition station ("Fox").  Note that everyone participating 
> in the test *MUST* use WSJT-X v1.9.0-rc3.  In addition, you must read, 
> understand, and carefully follow the instructions posted here:
> http://physics.princeton.edu/pulsar/k1jt/FT8_DXpedition_Mode.pdf
> 
> Please be sure to read this document carefully, again.  A few of its 
> details are different from the previous version.
> 
> If you have legitimate access to more than one callsign (spouse, club 
> call, or whatever) please feel free to call and work the Fox more than 
> once. We want the test pileup to be as deep as possible.
> 
> The scheduled test will take place as 

[wsjt-devel] using tune button while in FT8 Hound mode

[Jay Hainline]

Currently I am using WSJT-X 1.9.0-rc3 r8581 with Windows 10 64 bit computer.

 

I happened to notice when I place the program into FT8 Hound mode, the Tune
button does not function when a DX Call has NOT been entered and no standard
messages have been created. As soon as I enter a callsign in the DX Call
field and generate the messages, the Tune button works normally. Unchecking
Hound, the Tune button works normally with or without a DX Call and messages
being generated.

 

Checking a little further, when in normal FT8 mode, I see that the tune
button does not work if the Next button happens to be highlighted on a blank
standard message field. And I guess that was what was happening in Hound
mode as well. If I click the button to highlight TX6 where my CQ call grid
message is located, then the tune button functions.

 

I don't know if this is by design or a bug but thought I would mention it.

 

73 Jay

 

Jay Hainline KA9CFD

Colchester, IL  EN40om

 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Public test of FT8 DXpedition mode March 6-7

[Jay Hainline]

My observations.

I was only able to participate during the first 20 minutes of the 20 meter
test at 2300z. Joe was decoding around -18 during the time and I was calling
using barefoot power. According to pskreporter, Joe heard me but I was never
called.

So my question is why I was never called? Does my callsign get pushed down
the list when new calls are decoded? What sort order was Joe using at the
time? Is there a "first come, first serve" sort order to the queue of hounds
to be called?

Judging by comments I have seen, the lack of RR73 message being sent causing
hounds to send R-report over and over, there is still work to be done before
it is dxpedition ready. I hope there are more tests and I will be able to
participate fully.

Thank you to the developers for putting this all together. It is very
interesting!

73 Jay KA9CFD

-Original Message-
From: Joe Taylor  
Sent: March 4, 2018 23:44
To: WSJT software development 
Subject: [wsjt-devel] Public test of FT8 DXpedition mode March 6-7

Hi all,

I write to remind you of the public test of *FT8 DXpedition Mode* scheduled
for March 6-7.  The more participants, the better!
The main goal is to simulate pileups in which many "Hounds" call and attempt
to work a desirable rare DX station, the  "Fox", and to maximize the
resulting QSO rate.  We hope you can be there and work each of our Foxes on
each band.

All participating stations must use program version WSJT-X v1.9.0-rc2. 
If you don't yet have it, download links are available here:
https://physics.princeton.edu/pulsar/k1jt/wsjtx.html

Detailed instructions for Fox and Hound stations are posted here:
http://physics.princeton.edu/pulsar/k1jt/FT8_DXpedition_Mode.pdf
It's important to read and follow these instructions carefully!  Don't just
try to wing it.

Each hour during the test has a designated frequency and Fox callsign,
"Fox_A" in the following table.

Date   UTCFreq  Fox_AFox_B   NSlots
---
Mar 6 2300  14.080  K1JT W7/KH7Z3
Mar 7   10.141  W1/KH7Z  K9AN   5
Mar 7 0100   7.080  W7/KH7Z  K1JT   4
Mar 7 0200   3.585  K9AN W1/KH7Z3

As you will know after reading the FT8 DXpedition Mode User Guide, Fox can
conduct up to "NSlots" QSOs simultaneously.  W7/KH7Z will be operated by
AA7A, and W1/KH7Z by N1DG.

Fox_A will operate for the full hour if plenty of Hounds keep calling. 
Fox_B is on standby reserve.  If the QSO rate for Fox_A approaches zero at
the half-hour mark, Fox_A will stop transmitting and Fox_B will call CQ.

If you (as a Hound) can legitimately use more than one callsign -- your
spouse's call, club call, etc. -- please try to work each Fox multiple
times.  No dupe QSOs with the same call and same band, though.

Real-time liaison will be available via the "Ping Jockey Relief" chat page
(PJB), https://www.pingjockey.net/cgi-bin/pingtalkB .  Everyone should
monitor this page for possible announcements of frequency changes or
switch-overs from Fox_A to Fox_B.  To ensure that announcements from Fox
stations are easily visible, Hounds should monitor PJB but not post messages
there during the test.

The deepest pileups will help us to tune the final-release software version
for optimum performance on both Fox and Hound sides.  After the test, please
post any comments you feel will be helpful to one of our two email forums,
wsjtgr...@yahoogroups.com or wsjt-devel@lists.sourceforge.net .  You will
need to be subscribed to the list in order to post there.

We sincerely hope you can join us for this test, working each Fox on each
band!

 -- 73, Joe, K1JT (for the WSJT Development Group)


--
Check out the vibrant tech community on one of the world's most engaging
tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel




--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] minor Fast Graph time scale bug msk144 mode

[Jay Hainline]

Gary, you didn’t follow the correct sequence of events to see the bug.

Open WSJT-X, change to msk144 mode.
Set T/R to 15 seconds. Fast Graph should also show 15 second time scale.
Switch WSJT-X to another mode from the Mode Menu, say FT8. 
Close WSJT-X
Reopen WSJT-X. It should be in FT8 mode.
Switch mode from the Mode Menu to msk144
T/R will show 15 seconds but the Fast Graph time scale will show 0-30 seconds 
instead. 
Changing T/R to 10 or 30 seconds and back to 15 seconds will force the Fast 
Graph time scale to follow along and all is OK.

Mike posted a fix. So hopefully it will be placed into 1.9.0-RC1 before its 
released to everyone to try.

Thanks and 73,
Jay KA9CFD

-Original Message-
From: Gary McDuffie [mailto:mcduf...@ag0n.net] 
Sent: February 12, 2018 15:30
To: WSJT software development <wsjt-devel@lists.sourceforge.net>
Subject: Re: [wsjt-devel] minor Fast Graph time scale bug msk144 mode



> On Feb 12, 2018, at 5:59 AM, Jay Hainline <ka9...@mtcnow.net> wrote:
> 
> This only seems to happen when first opening WSJT-X. The bug does not appear 
> again once it is open and have switched to other modes and back to msk144.

It doesn’t do it here….  BUT! …  I use a different configuration for most 
mode/band changes.  It loads every time I switch configs.

I just tried it this way:  I loaded MSK144 config and then closed the program.  
When I opened it again, it was in 15 second mode.  I then changed it to 30 sec 
mode, closed it and reopened it, and it was in 30 sec mode.  I went back to 15 
sec mode, closed, reopened, and it was in 15 sec mode.  Seems to be fine here - 
can’t make it fail the way I use it.

Gary - AG0N
--
Check out the vibrant tech community on one of the world's most engaging tech 
sites, Slashdot.org! http://sdm.link/slashdot 
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] minor Fast Graph time scale bug msk144 mode

[Jay Hainline]

This is a minor thing and has been occurring for several revisions. I was
wondering if anyone one has seen this. When I first open WSJT-X and its in
another mode besides msk144, when I switch to msk144 mode, the Fast Graph
scale seems to default to 30 seconds even though T/R is set to 15 seconds.
The scrolling waterfall appears to be correct, but the time scale is wrong.
It's a simple matter of switching T/R to another setting and then back to 15
seconds and the time scale on the fast graph will follow along and be
correct then. This only seems to happen when first opening WSJT-X. The bug
does not appear again once it is open and have switched to other modes and
back to msk144.

 

Thought I would mention it.

 

73,

 

Jay Hainline KA9CFD

Colchester, IL  EN40om

 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] JT9 AP request

[Jay Hainline]

I remember seeing last spring before the FT8 craze some development work on a 
new mode called WSPR-LF. Are there any plans to start development again?
73 Jay KA9CFD


Sent from my U.S. Cellular® Smartphone
 Original message From: Eric NO3M  Date: 
10/16/17  07:27  (GMT-06:00) To: wsjt-devel@lists.sourceforge.net Subject: 
[wsjt-devel] JT9 AP request 
630M opened up to some US Amateurs this past weekend.  FT8 may have 
killed JT65 / JT9 for the most part on HF, but down on 630 JT9 is still 
king.  We need to dig deep for weak (5W EIRP) signals amidst harsh 
noise, etc.  I'd like to request that AP ("a priori") be integrated into 
JT9 for additional sensitivity.

Thanks for considering.

73 Eric NO3M

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] NA VHF Contest Mode

[Jay Hainline]

Larry K0TPP and I made another test this morning. We were both using r8111.
We ran on both msk144 and ft8 on 6 meters. The window pop up appears to be
working correctly now when the CQ station is in contest mode and the
answering station is not. 

We also ran where the station CQing is not in contest mode and the answering
station is. When I received Larry's signal report, I sent R EN40. Then Larry
got the pop up message asking to switch to contest mode. So I think it is
working as it should. 

73 Jay KA9CFD

-Original Message-
From: Joe Taylor [mailto:j...@princeton.edu] 
Sent: September 22, 2017 17:50
To: WSJT software development 
Subject: Re: [wsjt-devel] NA VHF Contest Mode

Hi Jay, Larry, George, and all,

Revision r8105 is another attempt at eliminating all potential causes of
confusion when one party has checked NA VHF Contest Mode and the other has
not.

Please find someone else with whom you can test this feature and report you
results here -- if possible, using both MSK144 and FT8.  Both stations must
be running r8105.

-- Joe, K1JT


--
Check out the vibrant tech community on one of the world's most engaging
tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel




--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] NA VHF Contest Mode

[Jay Hainline]

Yes we were both using 8101 and msk144 mode. We did not try ft8. Sorry I forgot 
to mention it.
Jay KA9CFD


Sent from my U.S. Cellular® Smartphone
 Original message From: Joe Taylor  Date: 
9/22/17  07:16  (GMT-06:00) To: WSJT software development 
, Steven Franke  
Subject: Re: [wsjt-devel] NA VHF Contest Mode 
Hi Steve,

On 9/22/2017 8:12 AM, Steven Franke wrote:
> Hi Joe,
> 
> Recall that MSK144 is configured such that fix_contest_msg is *always* 
> called, independent of whether or not the contest box is checked. Won’t this 
> prevent the contest-mode prompt from being triggered in that mode?

Yes, it seems that must be so.  Maybe Jay and Larry were using MSK144?

-- Joe

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] NA VHF Contest Mode

[Jay Hainline]

I ran a test with K0TPP. K0TPP called CQ with VHF Contest box checkmarked. I
answered him with it unchecked sending TX1. The program decoded his R EM48
ok but I did not receive a pop up window prompt and the auto sequence did
not advance beyond sending TX1.

73 Jay KA9CFD



-Original Message-
From: Joe Taylor [mailto:j...@princeton.edu] 
Sent: September 20, 2017 19:48
To: WSJT Software Development 
Subject: [wsjt-devel] NA VHF Contest Mode

Hi all,

As an experiment, code revision r8101 in the WSJT-X development branch
includes several changes to the way *NA VHF Contest Mode* is implemented.
The goal is to obviate any cause for confusion (e.g., implausible grid
squares being diaplayed) when one station uses Contest Mode and the QSO
partner does not.

Here are a few details.

1. First, remember that NA VHF Contest Mode applies only to the FT8 and
MSK144 protocols, where speed in completing a minimal QSO is especially
important.  (Of course, you can also make contest QSOs using JT4, JT9, JT65,
or QRA64, but they generally take longer.)

2. The checkbox to activate Contest Mode has been moved from the *Settings
-> Advanced* tab to the main screen.

3. If you're operating in FT8 or MSK144 mode on a VHF+ band and the locator
in a decoded message seems to imply a distance greater than
10,000 km, the program will prompt you to activate Contest Mode.

   - Click *YES* if you're making a contest QSO but forgot to activate
 Contest Mode.

   - Click NO if you really are luck enough to be working a JA, VK, or
 whatever.

The program will prompt you only once.

If you are interested in VHF contesting and able to build WSJT-X for
yourself, please give it a try and report your findings here.

-- Joe, K1JT


--
Check out the vibrant tech community on one of the world's most engaging
tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel




--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] NA VHF Contest Mode

[Jay Hainline]

Ok Joe. Thanks for the explanation.
73 Jay KA9CFD


Sent from my U.S. Cellular® Smartphone
 Original message From: Joe Taylor <j...@princeton.edu> Date: 
9/21/17  12:39  (GMT-06:00) To: WSJT software development 
<wsjt-devel@lists.sourceforge.net> Subject: Re: [wsjt-devel] NA VHF Contest 
Mode 
Hi Jay,

On 9/20/2017 5:08 PM, Jay Hainline wrote:
> Joe and all. Curious because I am not a big contester. My understanding is 
> the reason for the extra coding is for producing the message sent for TX3 
> with both calls plus R Grid. If it’s a problem with extra characters 
> involved, why can't you just condense the standard message to send a single 
> call of the station you are working with R Grid? Wouldn’t this save the 
> effort of having to use extra coding in the software for converting an odd 
> ball grid to something that makes sense? Then no matter if you are in contest 
> mode or not, everyone would see the same message.
> 
> Example:
> 
> Current TX3 message in contest mode:  K1JT KA9CFD R EN40
> 
> Replace TX3 message transmitted by KA9CFD:  K1JT R EN40
> 
> Rational: A CQ with one call has already been sent, and response has been 
> received with both calls and a grid by the time TX3 is ready to be sent.

Yes, we could co it that way.  But...

1. The message "K1JT R EN40" is not a standard JT-style structured 
message.  It will be transmitted as free text, but the MSK144/FT8 
auto-sequencer will not process it correctly.  To avoid other potential 
problems, it insists on finding both calls in a valid auto-sequenced 
message.

2. MSK144 QSOs often take place on a time-shared channel with pings from 
several different stations being decoded in the same 15 s interval.  As 
many as several dozen FT8 transmissions are often decoded in a single 
interval.  When both callsigns appear in nearly every transmission it's 
easy to keep track of what's going on, and who's working whom.  With 
just one callsign in a message this is much harder -- both for those 
listening in and for the auto-sequencer.

-- Joe, K1JT

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] NA VHF Contest Mode

[Jay Hainline]

Joe and all. Curious because I am not a big contester. My understanding is the 
reason for the extra coding is for producing the message sent for TX3 with both 
calls plus R Grid. If it’s a problem with extra characters involved, why can't 
you just condense the standard message to send a single call of the station you 
are working with R Grid? Wouldn’t this save the effort of having to use extra 
coding in the software for converting an odd ball grid to something that makes 
sense? Then no matter if you are in contest mode or not, everyone would see the 
same message.

Example:

Current TX3 message in contest mode:  K1JT KA9CFD R EN40

Replace TX3 message transmitted by KA9CFD:  K1JT R EN40

Rational: A CQ with one call has already been sent, and response has been 
received with both calls and a grid by the time TX3 is ready to be sent.

Thanks again for an amazing piece of software.

On a side note, I received for the first time this morning a VK4 on 630m WSPR 
just right before my Sunrise. Wow! I was wondering if any plans are coming to 
continue work on a WSPR-LF mode that I saw in the spring before the FT8 craze. 

73 Jay KA9CFD

-Original Message-
From: Joe Taylor [mailto:j...@princeton.edu] 
Sent: September 20, 2017 19:48
To: WSJT Software Development 
Subject: [wsjt-devel] NA VHF Contest Mode

Hi all,

As an experiment, code revision r8101 in the WSJT-X development branch includes 
several changes to the way *NA VHF Contest Mode* is implemented.  The goal is 
to obviate any cause for confusion (e.g., implausible grid squares being 
diaplayed) when one station uses Contest Mode and the QSO partner does not.

Here are a few details.

1. First, remember that NA VHF Contest Mode applies only to the FT8 and
MSK144 protocols, where speed in completing a minimal QSO is especially 
important.  (Of course, you can also make contest QSOs using JT4, JT9, JT65, or 
QRA64, but they generally take longer.)

2. The checkbox to activate Contest Mode has been moved from the *Settings -> 
Advanced* tab to the main screen.

3. If you're operating in FT8 or MSK144 mode on a VHF+ band and the locator in 
a decoded message seems to imply a distance greater than
10,000 km, the program will prompt you to activate Contest Mode.

   - Click *YES* if you're making a contest QSO but forgot to activate
 Contest Mode.

   - Click NO if you really are luck enough to be working a JA, VK, or
 whatever.

The program will prompt you only once.

If you are interested in VHF contesting and able to build WSJT-X for yourself, 
please give it a try and report your findings here.

-- Joe, K1JT

--
Check out the vibrant tech community on one of the world's most engaging tech 
sites, Slashdot.org! http://sdm.link/slashdot 
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel




--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT on DXpedition

[Jay Hainline]

Yes, the DX station should stay on one frequency. 
How do you handle dupes? If the same station continues to call after working 
the DX, would the program continue to call the dupe if the DX station has Call 
1st checkmarked? Just thinking...
73 Jay KA9CFD


Sent from my U.S. Cellular® Smartphone
 Original message From: Joe Taylor  Date: 
8/17/17  14:45  (GMT-06:00) To: WSJT software development 
 Subject: Re: [wsjt-devel] WSJT on DXpedition 
Hi Alex, Iztok, and all,

Thanks for your comments and suggestions for optimizing FT8 QSO rates in 
pileup conditions.

In my message posted yesterday I kept things simple and did not go into 
any detail about what to do when things do not go exactly "by the book". 
  Of course you are right to emphasize that these issues must be 
addressed.

How best to keep busted or difficult QSOS from dreadfully slowing down a 
run?  After further thought, I've begun to like something close to 
Alex's original suggestion.  Suppose we define five new standard message 
formats that start with the fragments "73 NOW ", "73 CQ ", "73 CQ UP ",
"NIL NOW ", and "NIL CQ UP ".  Example messages would look like these:

  73 NOW W9XYZ R QH72
  73 CQ VK9MA QH72
  73 CQ UP VK9MA QH72
  NIL NOW W9XYZ R QH72
  NIL CQ UP VK9MA QH72

The first three types tell the previously worked station that she's in 
the log.  The last two terminate a failed QSO attempt, tell that 
operator he is NOT in the log, and attempt to start a new QSO.

A series of QSOs made from VK9MA might then look something like this:

1.  CQ UP VK9MA QH72
2.  VK9MA K1ABC FN42, K9MA W9XYZ EN37, VK9MA WB6DEF CM88, ...
3.  K1ABC VK9MA R QH72
4.  VK9MA K1ABC RRR
5.  73 NOW W9XYZ R QH72
6a. VK9MA W9XYZ RRR   (not copied at VK9MA)
6b. VK9MA W9XYZ EN37  (W9XYZ did not copy #5, he calls again)
7.  W9XYZ VK9MA R QH72    (try him again)
8.  VK9MA W9XYZ RRR
9.  73 NOW WB6DEF R QH72
10. VK9MA WB6DEF RRR  (not copied at VK9MA)
11. WB6DEF VK9MA R QH72   (try him again)
12. VK9MA WB6DEF RRR  (still not copied at VK9MA)
13a. NIL NOW G4AAA R QH72 (on to the next one...)
13b. NIL CQ UP VK9MA QH72 (nobody in the queue, call CQ again)

Do you see any situations not adequately covered by this scheme?

Offhand, I do not like the idea of the DXpedition station jumping around 
in frequency.  (No doubt that could be made to work, but it seems better 
to me that he should stay put.)  Maybe if he transmits, say, on 14.070 
he should respond only to calls between 14.071 and 14.075, or something 
like that.

-- 73, Joe, K1JT

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] User Guide updates for WSJT-X Version 1.8

[Jay Hainline]

Another thing I am just thinking of and maybe I missed it, but maybe a mention 
of a priori with a description of what it is.

Just had a series 5 decodes of CT1HZE here CQing on FT8 mode on 6 meters. His 
last decode was at -23 with a1 showing on the side. That made me think of it. 

73 Jay KA9CFD

-Original Message-
From: Joe Taylor [mailto:j...@princeton.edu] 
Sent: August 2, 2017 21:21
To: WSJT software development <wsjt-devel@lists.sourceforge.net>
Subject: Re: [wsjt-devel] User Guide updates for WSJT-X Version 1.8

Hi Jay,

Thanks for the feedback.

On 8/2/2017 5:01 PM, Jay Hainline KA9CFD wrote:
> 2 things I noticed about the User Guide.
> 
> 1. In Section 16.2 Slow Modes, FT8 is listed. Should it be listed in 
> the Fast modes instead?

The X Fast modes in WSJT-X send their messages repeatedly in a single Tx 
sequence.  The single-frame message duration is generally much less than the 
T/R sequence length.

FT8 sends transmits its basic message frame exactly once in a Tx interval.  It 
is therefore deemed to be a slow mode.  (It's just not as "slow" as the 
one-minute slow modes.)

> 2. There is no mention in the User Guide about the Frequency 
> Calibration mode feature. There should be a write up on how to use and 
> maybe how to edit the frequency list for your own taste.

This is still TBD.  The User Guide is *never* finished, hi.

-- Joe, K1JT

--
Check out the vibrant tech community on one of the world's most engaging tech 
sites, Slashdot.org! http://sdm.link/slashdot 
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel




--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] r7969: AP: calls out of the blue

[Jay Hainline]

Will this information be placed in the User Guide? I think it would be an 
excellent reference on what the indicators mean.

 

73 Jay KA9CFD

 

From: Steven Franke [mailto:s.j.fra...@icloud.com] 
Sent: July 29, 2017 14:33
To: Joe Taylor 
Subject: Re: [wsjt-devel] r7969: AP: calls out of the blue

 

Hi Richard and Bill,

Adding to what BIll has said.

(i) The attached screenshot of the waterfall shows that the false decode at 
1055 Hz was produced based on a signal that existed for less than half of the 
interval.

 



Thus, at least half of the symbols were missing. Nevertheless, the signal was 
strong enough so that sync was achieved - probably on the basis of only the 
tail-end group of sync symbols.

(ii) The “a3” indicator tells us that for this decode the decoder hypothesized 
that the first 28-bits (the “MyCall” bits) of the 87-bit message frame were 
known, and were equal to your callsign, G4DYA. This is what Bill means by 
“masking” — we “mask” the 28 MyCall bits and temporarily fix them at “known” 
values. We then let the decoder do its thing and see if it can come up with a 
codeword that contains the hypothetical AP bits and that has few differences 
from the rest of the received bits. Any codeword that is produced as a result 
of this operation is going to have MyCall bits that map to G4DYA, because those 
bits were “hardwired” for the decoding attempt in question.

For the hypothetical bits we use only information that is known intrinsically 
(MyCall) or that is gathered during an ongoing QSO when applying AP decoding. 
Such information includes DxCall and the current state of the QSO. For example, 
after we have sent a “R-20” report, we know that a likely response is RRR, 73, 
or RR73. No reference is made to any other information.

For reference, here is the table of possible AP decoding types:

iaptype

  1CQ ??????
  2DE ??????
  3MyCall ??????
  4MyCall DxCall ???
  5MyCall DxCall RRR
  6MyCall DxCall 73
  7MyCall DxCall RR73
  8???DxCall ???

At present, types 2 and 8 are not used. The “a3” designator says that an AP 
type 3 attempt produced the decode. As already noted, type 3 looks for decodes 
of the form “MyCall ??? ???”. Thus, any decode that is produced as a result of 
a type 3 attempt is going to contain “MyCall”. Similarly, any decode that 
results from a type 4, 5, 6, or 7 attempt is going to contain MyCall and 
DxCall, where DxCall is whatever callsign is currently in the Dx Call box. In 
fact, an AP type 5 decode will always be of the form “MyCall DxCall RRR”, etc.

Back to the "? a3” decode in question. A type 3 AP decoding attempt does not 
use any information from the DX Call box. Thus, the DXCall found in a false 
“a3” decode is usually implausible and rarely corresponds to the printed 
4-digit locator. Richard's example is a rare case, indeed, as both the callsign 
and grid locator were plausible. I would wager that VE3SMB, if s/he exists, was 
not transmitting at the time that this decode was produced. Instead, in this 
case, the printed DxCall is a spectre, produced by random chance, along with 
the plausible grid locator.

As to why we might be willing to tolerate these potentially confusing false 
decodes; it is inevitable that when we dig deepest to decode the weakest (or 
most garbled by interference or truncation) received words the ratio of good to 
bad decodes is going to go down. For regular “non-AP” decodes, that ratio is 
very large, maybe 10^5 or even larger. Down near the decoding threshold, when 
the deep decoder and AP are in use, the good/bad ratio may fall to 100 or so. 
Nevertheless, eliminating the AP decoding attempts would remove hundreds of 
good decodes for every bad decode that is removed. Rather than do that, we 
provide the “?” quality indicator. The presence of the “?” in the decode tells 
you to watch out — it should be interpreted as meaning that this decode has a 
higher-than-you-are-used-to chance of being incorrect, and that you should 
consider context, the “type” of AP that was in use, and any other available 
information (such as the appearance of the signal on the waterfall) to decide 
whether or not to trust the decode.  When in doubt, you may want to wait for a 
second decode from the station in question before transmitting in response to a 
questionable AP decode. 

I’ll end this with an example showing a QSO that I made last night that 
benefited from the use of AP:



In this example, the “Roger” and “73” messages from VA6SP had SNRs of -20 dB 
and -22 dB, respectively. The “RRR” decode was obtained using AP type 4, 
meaning that the decoder used the known values of MyCall and DxCall, and it 
found a codeword that was consistent with these values *and* that contained an 
RRR. It did not assume that “RRR” would be present. There was no “?” printed, 
so this means that the decoder was 

Re: [wsjt-devel] new FT8 mode decoding

[Jay Hainline]

Thank you for looking at the files Joe. If more files are needed, let me
know. 

Yes, I have noticed major impacts on decoding especially on single hop with
meteor pings and doppler mixed in. Also very picky on timing. I try to keep
my computer clock very close but if someone's time is off, no decode.

All of my listening has been on 50313. I feel that's where it needs to be
developed rather than the HF bands for real world QSB that is so typical of
6 meter multihop sporadic e.

73 Jay KA9CFD

-Original Message-
From: Joe Taylor [mailto:j...@princeton.edu] 
Sent: July 3, 2017 20:19
To: WSJT software development <wsjt-devel@lists.sourceforge.net>; Jay
Hainline <ka9...@mtcnow.net>
Subject: Re: [wsjt-devel] new FT8 mode decoding

Hi again Jay,

On 6/29/2017 4:02 PM, Jay Hainline wrote:
> My message got bounced for being too large. So posting again with 2 
> wav files instead of 3. Recorded from 50313. Please check the signal 
> around
> 1050 hz. I was not able to decode.

The first of your two files, 170629_194730.wav, decodes correctly in WSJT-X
7780:

194700 -17  0.3 1061 ~  K9AN KB7IJ R-18

I did not try it in any earlier code revision.

The signal's appearance on the waterfall shows that it's not much above the
decoding threshold.

Note that when we say "the 50% decoding threshold is -21 dB", that refers to
signals with no Doppler spread, no QSB, and only AWGN (additive white
gaussian noise).  Real-world signals propagated by ionospheric reflection
have Doppler spread and QSB.  The reported S/N estimate is an average over
the full transmission.

        -- Joe, K1JT


> 73 Jay
> 
> Jay Hainline KA9CFD
> 
> Colchester, IL  EN40om
> 
> 
> 
> --
>  Check out the vibrant tech community on one of the world's 
> most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> 
> 
> 
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> 




--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] 6 meter opening to EI3KD

[Jay Hainline]

Yes Bill I was.

 

Jay KA9CFD

 

From: Bill Barrett [mailto:w2pky...@gmail.com] 
Sent: July 3, 2017 15:49
To: WSJT software development <wsjt-devel@lists.sourceforge.net>
Subject: Re: [wsjt-devel] 6 meter opening to EI3KD

 

Hello Jay-

 

Were you on 50.313?

 

Thanks;

 

Bill

W2PKY

 

On Mon, Jul 3, 2017 at 10:33 AM, Jay Hainline <ka9...@mtcnow.net 
<mailto:ka9...@mtcnow.net> > wrote:

Worked EI3KD using the new mode FT8 on 6 meters this morning!

 

Attached are wav files from his last decoded CQ at 1412:30 and another that did 
not decode at 1413:00. Hope this helps with improving the decoding. His signal 
ranged from -17 to -1. Using WSJT-X 1.7.1 r on a Windows 10 64 bit computer.

 

73 Jay

 

Jay Hainline KA9CFD

Colchester, IL  EN40om

 


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net <mailto:wsjt-devel@lists.sourceforge.net> 
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] FT8 notes

[Jay Hainline]

Just some food for thought. 

Some of these development builds could be compiled into a exe install
package once in a while and made available from the sourceforge site or
maybe a link from the WSJT home page or wsjtx.net for those who want to try
the new mode but are intimidated at installing JTSDK and building their own.
If you make it available from an "official" site, maybe it will discourage
3rd party users of doing it on their own.

73 Jay KA9CFD

-Original Message-
From: David Tiller [mailto:dtil...@captechconsulting.com] 
Sent: June 30, 2017 14:57
To: WSJT software development 
Subject: Re: [wsjt-devel] FT8 notes

All,

Since Joe mentioned revision 7754, I unofficially built it for OSX 10.9+ and
uploaded it here:
https://drive.google.com/open?id=0B4DphHV_ItCZbjZDdmt2NnR2cHc

If you're a macOS user, I'll try to keep recent builds in the same directory
(if that's ok w/ Joe, et al, re: unofficial builds).

--
David Tiller
Sr. Architect/Lead Consultant | CapTech
(804) 304-0638 | dtil...@captechconsulting.com



On Jun 30, 2017, at 10:45 AM, Joe Taylor  wrote:

> Hi Steve,
> 
> Yes, 40 iterations for bp.
> 
> With norder=2 hardwired for everything I still get 574 good decodes.  So
at least in jt9.exe, with no attempt to move nfqso around, using norder=3
produces no more decodes.
> 
> Here are the timer results with norder=2:
> 
> Name Time  Frac dTime dFracCalls
> --
> jt933.832  1.00 0.691  0.021
>  read_wav   0.164  0.00 0.164  0.0027404
>  decft832.977  0.97 0.055  0.00  527
>   sync8 4.148  0.12 4.148  0.12  527
>   ft8b 28.773  0.85 0.090  0.00 2821
>bpd174   1.641  0.05 1.641  0.05 2821
>osd174  27.043  0.8027.043  0.80 2210
> --
>33.832  1.00
> 
>   -- Joe
> 
> On 6/30/2017 10:34 AM, Steven Franke wrote:
>> Joe,
>> Were these results obtained with 40 iterations for bp and norder = 3 for
signals at or within 10 Hz of nfqso? If so, it might be interesting to see
how the numbers would change if you dropped back to norder=2 for all
signals.
>> Steve
>>> On Jun 30, 2017, at 9:25 AM, Joe Taylor  wrote:
>>> 
>>> Hi all,
>>> 
>>> Thanks for a busy ~20 hours of many people testing FT8.  I now have
accumulated a directory with 527 *.wav files, each of which has at least one
visible FT8 signal.  The files were recorded at K1JT at either 14.079 or
50.313 MHz.
>>> 
>>> Running the r7753 stand-alone slow-mode decoder jt9[.exe] on this
collection of files produces 574 valid decodes and 0 false decodes with
total execution time 39.8 s.  The average time to process a 15 s Rx sequence
on this machine (Core i7-6700 @ 3.4 GHz) is thus 39.8/527 = 0.076 s.  Not
bad!
>>> 
>>> Here's the detailed execution-time breakdown from timer.out:
>>> 
>>> Name Time  Frac dTime dFracCalls
>>> --
>>> jt939.828  1.00 0.734  0.021
>>>  read_wav   0.121  0.00 0.121  0.0027404
>>>  decft838.973  0.98 0.133  0.00  527
>>>   sync8 4.191  0.11 4.191  0.11  527
>>>   ft8b 34.648  0.87 0.051  0.00 2821
>>>bpd174   1.480  0.04 1.480  0.04 2821
>>>osd174  33.117  0.8333.117  0.83 2210
>>> --
>>>39.828  1.00
>>> 
>>> Note that 83% of the execution time is spent in routine osd174, 11% in
sync8, and 4% in bpd174 (a contraction for subroutine name bpdecode174).
>>> 
>>> It turns out that only 14 of the 574 decodes were produced by osd174,
the "ordered statistics" decoder.  The rest came from bpd174.  With osd174
deactivated, timer.out looks like this:
>>> 
>>> Name Time  Frac dTime dFracCalls
>>> --
>>> jt9 6.641  1.00 0.891  0.131
>>>  read_wav   0.168  0.03 0.168  0.0327404
>>>  decft8 5.582  0.84 0.094  0.01  527
>>>   sync8 3.887  0.59 3.887  0.59  527
>>>   ft8b  1.602  0.24 0.109  0.02 2821
>>>bpd174   1.492  0.22 1.492  0.22 2821
>>>osd174   0.000  0.00 0.000  0.00 2210
>>> --
>>> 6.641  1.00
>>> 
>>> Now the average execution time for a 15 s Rx sequence is just 13 ms!
>>> 
>>> We need to keep decoding time very short -- say, well under 1 s -- so
that auto-sequencing, if not the human operator, can select proper responses
to 

Re: [wsjt-devel] FT8: Potential new mode for fast QSOs

[Jay Hainline]

Joe, I tried again and it seemed to work ok. I had my cursor on 1000 hz and 
N8JX called at 2000 hz and I decoded ok. False alarm I think. There might have 
been some meteor doppler or multipath playing when I tried the first time.

73 Jay

-Original Message-
From: Joe Taylor [mailto:j...@princeton.edu] 
Sent: June 29, 2017 18:15
To: WSJT software development <wsjt-devel@lists.sourceforge.net>
Subject: Re: [wsjt-devel] FT8: Potential new mode for fast QSOs

Hi Jay,

On 6/29/2017 2:02 PM, Jay Hainline wrote:
> I made my first QSO with the new mode with N8JX. It seems to work smoothly.
> One thing noticed it does not seem that bandpass decoding is available yet?
> I could not decode until I placed the marker on top of his signal.
> 
> 73 Jay KA9CFD

That should not be true.  It's *definitely* not true for me.

Did you save some *.wav files to experiment with?  If not, try the one attached 
to this email.  See the attached screen shot for decoding results.
-- Joe, K1JT



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] FT8: Potential new mode for fast QSOs

[Jay Hainline]

I made my first QSO with the new mode with N8JX. It seems to work smoothly.
One thing noticed it does not seem that bandpass decoding is available yet?
I could not decode until I placed the marker on top of his signal.

73 Jay KA9CFD

-Original Message-
From: Joe Taylor [mailto:j...@princeton.edu] 
Sent: June 29, 2017 15:33
To: WSJT software development 
Subject: [wsjt-devel] FT8: Potential new mode for fast QSOs

Dear Development Colleagues,

Steve (K9AN) and I have developed a potential new mode for WSJT-X. 
We're calling the mode "FT8" (Franke-Taylor design, 8-FSK modulation).

FT8 is designed for situations like multi-hop Es where signals may be weak
and fading, openings may be short, and you want fast completion of reliable,
confirmable QSOs.

Important characteristics of FT8:

   - T/R sequence length: 15 s
   - Message length: 75 bits + 12-bit CRC
   - FEC code: LDPC(174,87)
   - Modulation: 8-FSK, keying rate = tone spacing = 5.86 Hz
   - Waveform: Continuous phase, constant envelope
   - Occupied bandwidth: 47 Hz
   - Synchronization: three 7x7 Costas arrays (start, middle, end of Tx)
   - Transmission duration: 79*2048/12000 = 13.48 s
   - Decoding threshold: -20 dB (perhaps -24 dB with AP decoding, TBD)
   - Operational behavior: similar to HF usage of JT9, JT65
   - Multi-decoder: finds and decodes all FT8 signals in passband
   - Auto-sequencing after manual start of QSO

*Comparison with slow modes JT9, JT65, QRA64:*  FT8 is a few dB less
sensitive but allows completion of QSOs four times faster.  Bandwidth is
greater than JT9, but about 1/4 of JT65A and less than 1/2 QRA64.

*Comparison with fast modes JT9E-H:*  FT8 is significantly more sensitive,
has much smaller bandwidth, uses the vertical waterfall, and offers
multi-decoding over the full displayed passband.

*Still to come, not yet implemented:*  We plan to implement signal
subtraction, two-pass decoding, and use of "a priori" (already known)
information as it accumulates during a QSO.

Three extra bits are available in the message payload, with uses yet to be
defined.  We have in mind special message formats that might be used in
contests, and the like.  Your considered suggestions for use of these bits
are very welcome!

K1JT, K9AN, and G4WJS have conducted on-the-air tests of FT8 with excellent
results.  We're now at a stage where tests under a wider range of conditions
are desirable.  If you can build WSJT-X from source code revision r7750 or
later, and would like to help, please do so and report your results to us!
Pre-built installation packages will be made available after further testing
is completed.

Suggestions for FT8 setup and examples of use can be found in a screen shot
posted here: http://physics.princeton.edu/pulsar/k1jt/ft8.png

We look forward to receiving your feedback.

-- 73, Joe, K1JT


--
Check out the vibrant tech community on one of the world's most engaging
tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel




--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X: Working frequency suggestions

[Jay Hainline]

I know Joe and the group are working  on a better mode to take better advantage 
of 6 meter multihop sporadic e openings. It would be good if a seperate 
frequency for continent-continent communications could be agreed upon by the 
band planners prior to implementation. Then it could be added to your list for 
the program.
73 Jay KA9CFD


Sent from my U.S. Cellular® Smartphone
 Original message From: Bill Somerville <g4...@classdesign.com> 
Date: 6/26/17  12:27  (GMT-06:00) To: wsjt-devel@lists.sourceforge.net Subject: 
Re: [wsjt-devel] WSJT-X: Working frequency suggestions 
On 26/06/2017 18:16, Jay Hainline wrote:
> In NA, the 6 meter msk144 calling frequency has been moved down to 
> 50260 to get away from the JT65 users.
>
> 50290 is being used for JT9E, JT9H fast modes for North America to 
> Europe contacts.
>
> This is what I have observed this season on 6 meters. Good Luck!

Hi Jay,

thanks for that.

To give an example of what we face, the current IARU region 1 band plan 
requires all MGM activity to be between 50300 and 50400 so expecting to 
run transatlantic QSOs on 6m JT9E/H on 50290 or indeed JT65/JT9 on 50276 
is going to cause the region 1 band police a problem. With MSK144 it is 
less so as no one expects to make transatlantic MS QSOs although I 
expect there are inter-region opportunities between OX and TF as well as 
KL7 and Asiatic Russia.

73
Bill
G4WJS.


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X: Beware if building from development sources

[Jay Hainline]

Thanks Bill. Will give it a try.
Jay KA9CFD


Sent from my U.S. Cellular® Smartphone
 Original message From: Bill Somerville <g4...@classdesign.com> 
Date: 6/10/17  08:39  (GMT-06:00) To: wsjt-devel@lists.sourceforge.net Subject: 
Re: [wsjt-devel] WSJT-X: Beware if building from development sources 
On 10/06/2017 12:14, Jay Hainline wrote:
> I need some tutoring on how to build 7703 without going beyond using JTSDK.
> Maybe someone can email me the steps on how.

Hi Jay,

I am not sure JTSDK has a direct facility to revert the sources to a 
particular revision, I'm sure Greg, KI7MT, will chip in if there is. It 
is pretty simple using the command shell provided by JTSDK, change 
directory to the root of the checked out source tree and type:

svn update -r 7703

then build. Obviously do not choose the build options that do a fresh 
update ;)

73
Bill
G4WJS.


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X: Beware if building from development sources

[Jay Hainline]

I need some tutoring on how to build 7703 without going beyond using JTSDK.
Maybe someone can email me the steps on how.

Thanks,
Jay KA9CFD
Ka9cfd at mtcnow dot net

-Original Message-
From: Bill Somerville [mailto:g4...@classdesign.com] 
Sent: June 9, 2017 12:45
To: WSJT software development 
Subject: [wsjt-devel] WSJT-X: Beware if building from development sources

Hi All,

I have noticed that there are some Tx modulation issues with revisions later
than r7703. Only use revisions later than r7703 on air if you are sure that
they are working correctly.

73
Bill
G4WJS.



--
Check out the vibrant tech community on one of the world's most engaging
tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel




--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Default WSPR frequency on 60 m

[Jay Hainline]

What a can of worms! Its not only wspr mode, but JT65 mode on 60 meters as
well. I have not seen a single USA station transmit exactly in the center of
the channel straddling the 1500 hz audio tone as stated in the rules using
JT65. I can't imagine what people are doing with wspr on that band.  Good
luck in figuring this out.

73 Jay KA9CFD 

-Original Message-
From: Joe Taylor [mailto:j...@princeton.edu] 
Sent: February 14, 2017 17:28
To: wsjt-devel@lists.sourceforge.net
Subject: [wsjt-devel] Default WSPR frequency on 60 m

Hi all,

Current WSJT-X code has the default frequency for WSPR mode on the 60 m band
set to 5.2872 MHz.  If US hams use this frequency they will be transmitting
on 5288700 +/- 100 Hz, which does not conform to our (rather odd) FCC
regulations for this band.

I think this issue has been discussed before, but I'm not sure what the
result was.  What's our best policy for WSJT-X?  Should we delete the
default WSPR frequency, and caution users to do the right thing, themselves,
depending on their local regulations?

-- Joe, K1JT


--
Check out the vibrant tech community on one of the world's most engaging
tech sites, SlashDot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel




--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] FreqCal Mode

[Jay Hainline]

Thanks for confirming it is on the air Joe. I am hearing it this afternoon
on 3330 KHz.

 

73 Jay KA9CFD

 

From: Joe [mailto:n...@mwt.net] 
Sent: January 10, 2017 15:00
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] FreqCal Mode

 

At 15:00Z here in SW Wisconsin they are S-5,
But I'm not sure what mode.

On AM Barely Understandable,
On LSB forget it, just a mess.
On USB perfect audio, just like I remember from my SWL days on the 7.3xx
freq. AM

Joe WB9SBD


The Original Rolling Ball Clock
Idle Tyme
Idle-Tyme.com
 <http://www.idle-tyme.com> http://www.idle-tyme.com

On 1/10/2017 8:53 AM, Joe Taylor wrote:

Hi Jay,
 
On 1/10/2017 8:44 AM, Jay Hainline wrote:

Can anyone confirm CHU at 3330 is actually on the air? I do not hear it here
and suspect it no longer is.
 
73 Jay KA9CFD

 
I'd like to know the answer to your question, too!  I find no indication 
on the NRC web site that 3330 is no longer used; but I haven't heard the 
signal here, recently.
 
  -- Joe, K1JT
 

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net <mailto:wsjt-devel@lists.sourceforge.net> 
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
 
 
 

 

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Prompt to log QSO when either RRR or 73 is sent

[Jay Hainline]

Hello Bill. I did not uncheck "Auto Seq". Just the "Disable TX after sending
73" box in the Settings. I still have "Prompt me to log QSO" checkmarked but
the program does not stop TX after sending RRR now. It continues on to TX5
sending the 73 message. I have to click on the "Enable TX" button to make it
stop now as it stays red. Hope that make sense.

 

73 Jay KA9CFD

 

From: Bill Somerville [mailto:g4...@classdesign.com] 
Sent: January 2, 2017 13:54
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] Prompt to log QSO when either RRR or 73 is sent

 

On 02/01/2017 13:40, Jay Hainline wrote:

I figured out my issue with the auto sequencing stopping at RRR. It does not
have anything to do with with prompt to log pop up. I had Disable TX after
sending 73 checkmarked in Settings/General tab. For some reason, it is
disabling TX after sending RRR instead.

Hi Jay,

the disabling of auto Tx and the automatic pop up of the logging dialog are
currenty linked. I believe the thinking was that if you are able to log then
you should stop sending. IMHO this is only true for the caller as the
station running the frequency is obliged to keep sending RRR until they are
sure that the caller has seen it, even though their end of the QSO is
compete and they can log it. This made sense when the logging reminder only
came up for 73 messages, now it also does for RRR messages and that is
causing the problem here.

Maybe we should pop up the log QSO dialog but only disable auto Tx once the
Ok has been clicked. Another option might be to split the setting into two
options like "Prompt to Log QSO" and "Disable auto Tx *after* logging", the
latter maybe only applying if the message that prompted logging was a 73
message.

There must be a way of doing this that satisfies all modes and operating
methods.

73 & HNY
Bill
G4WJS.

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Prompt to log QSO when either RRR or 73 is sent

[Jay Hainline]

I figured out my issue with the auto sequencing stopping at RRR. It does not 
have anything to do with with prompt to log pop up. I had Disable TX after 
sending 73 checkmarked in Settings/General tab. For some reason, it is 
disabling TX after sending RRR instead.

 

 

73 Jay KA9CFD

 

From: Jay Hainline [mailto:ka9...@mtcnow.net] 
Sent: January 1, 2017 22:08
To: 'Black Michael' <mdblac...@yahoo.com <mailto:mdblac...@yahoo.com> >; 'WSJT 
software development' <wsjt-devel@lists.sourceforge.net 
<mailto:wsjt-devel@lists.sourceforge.net> >
Subject: RE: [wsjt-devel] Prompt to log QSO when either RRR or 73 is sent

 

I don’t know for certain why this was changed in the first place except the 
JT65 HF crowd is always looking for a way to sidestep a sequence to shorten the 
time for a QSO. This does not work in the meteor scatter VHF world where you 
are relying on random data bits to fly in on a meteor for less than 1 second 
and you are trying to decode just what the guy on the other end has received. 
If it aint broke, don’t fix it.

 

I hope I don’t get black balled for being negative like the Ham Radio Deluxe 
people do to users of their software. Lol ;-)

 

73 Jay KA9CFD

 

From: Black Michael [ <mailto:mdblac...@yahoo.com> mailto:mdblac...@yahoo.com] 
Sent: Sunday, January 1, 2017 3:39 PM
To: WSJT software development < <mailto:wsjt-devel@lists.sourceforge.net> 
wsjt-devel@lists.sourceforge.net>
Subject: Re: [wsjt-devel] Prompt to log QSO when either RRR or 73 is sent

 

I think the consensus solution would be to make it a user option.

Seems the meteor scatter people have the most problems with it since they were 
quick to speak up.

 

I had proposed at one time to make the "Prompt me to log QSO" a tri-state box 
so one could check 73, 73+RRR, or none.  But seems the binary choice is clearer 
and there are no other tri-state checkboxes in WSJT-X.

 

So this patch makes it optional with an added option line below the current 
prompt option.  All worlds should be happy with this.

 

 <https://www.dropbox.com/s/s5xwpc39bubmzxx/rrr_option.patch?dl=1> 
https://www.dropbox.com/s/s5xwpc39bubmzxx/rrr_option.patch?dl=1

 

 

de Mike W9MDB

 

 

  _  

From: Seb < <mailto:w...@miamisky.com> w...@miamisky.com>
To: WSJT software development < <mailto:wsjt-devel@lists.sourceforge.net> 
wsjt-devel@lists.sourceforge.net> 
Sent: Sunday, January 1, 2017 1:26 PM
Subject: Re: [wsjt-devel] Prompt to log QSO when either RRR or 73 is sent

 

IMHO the introduction of the log QSO prompt when you are sending RRR does not 
solve or help anything.  

 

It is useless when you are doing meteor scatter. If I’m sending Tx3 and the 
other station hears that and sends Tx4 and then logs the contact, it is not a 
valid QSO because I have no idea if the other station has heard my report.  I 
will end up sending Tx3 several times until I just give up on the contact.

 

73 de Sebastian, W4AS



 

On Jan 1, 2017, at 9:38 AM, Jay Hainline < <mailto:ka9...@mtcnow.net> 
ka9...@mtcnow.net> wrote:

 

This was introduced in r7431. I think its bad form to get a prompt to log the 
QSO when you are sending RRR. How do you know if your QSO partner has received 
it if he does not send 73 back to you??

 

Jay Hainline KA9CFD

Colchester, IL  EN40om

 

 

 

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org!  <http://sdm.link/slashdot> 
http://sdm.link/slashdot

 

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

 

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Prompt to log QSO when either RRR or 73 is sent

[Jay Hainline]

I don’t know for certain why this was changed in the first place except the 
JT65 HF crowd is always looking for a way to sidestep a sequence to shorten the 
time for a QSO. This does not work in the meteor scatter VHF world where you 
are relying on random data bits to fly in on a meteor for less than 1 second 
and you are trying to decode just what the guy on the other end has received. 
If it aint broke, don’t fix it.

 

I hope I don’t get black balled for being negative like the Ham Radio Deluxe 
people do to users of their software. Lol ;-)

 

73 Jay KA9CFD

 

From: Black Michael [mailto:mdblac...@yahoo.com] 
Sent: Sunday, January 1, 2017 3:39 PM
To: WSJT software development <wsjt-devel@lists.sourceforge.net>
Subject: Re: [wsjt-devel] Prompt to log QSO when either RRR or 73 is sent

 

I think the consensus solution would be to make it a user option.

Seems the meteor scatter people have the most problems with it since they were 
quick to speak up.

 

I had proposed at one time to make the "Prompt me to log QSO" a tri-state box 
so one could check 73, 73+RRR, or none.  But seems the binary choice is clearer 
and there are no other tri-state checkboxes in WSJT-X.

 

So this patch makes it optional with an added option line below the current 
prompt option.  All worlds should be happy with this.

 

https://www.dropbox.com/s/s5xwpc39bubmzxx/rrr_option.patch?dl=1



 

 

de Mike W9MDB

 

 

  _  

From: Seb <w...@miamisky.com <mailto:w...@miamisky.com> >
To: WSJT software development <wsjt-devel@lists.sourceforge.net 
<mailto:wsjt-devel@lists.sourceforge.net> > 
Sent: Sunday, January 1, 2017 1:26 PM
Subject: Re: [wsjt-devel] Prompt to log QSO when either RRR or 73 is sent

 

IMHO the introduction of the log QSO prompt when you are sending RRR does not 
solve or help anything.  

 

It is useless when you are doing meteor scatter. If I’m sending Tx3 and the 
other station hears that and sends Tx4 and then logs the contact, it is not a 
valid QSO because I have no idea if the other station has heard my report.  I 
will end up sending Tx3 several times until I just give up on the contact.

 

73 de Sebastian, W4AS




 

On Jan 1, 2017, at 9:38 AM, Jay Hainline <ka9...@mtcnow.net 
<mailto:ka9...@mtcnow.net> > wrote:

 

This was introduced in r7431. I think its bad form to get a prompt to log the 
QSO when you are sending RRR. How do you know if your QSO partner has received 
it if he does not send 73 back to you??

 

Jay Hainline KA9CFD

Colchester, IL  EN40om

 

 

 

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

 

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

 

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Prompt to log QSO when either RRR or 73 is sent

[Jay Hainline]

That's not happening here Steve. If I CALL CQ and someone responds back with
TX1, auto sequence then sends TX2. My QSO partner then responds with TX3. As
soon as I receive that, autosequence sends TX4 and I get the prompt to log.
Enable TX then goes back to gray and autosequence stops. I have to click on
Enable TX to send TX4 again if I don't receive anything.

 

I am also using r7436 working 6 meter msk144 mode.

 

Jay KA9CFD

 

From: Steven Franke [mailto:s.j.fra...@icloud.com] 
Sent: January 1, 2017 14:59
To: Joe Taylor <wsjt-devel@lists.sourceforge.net>
Subject: Re: [wsjt-devel] Prompt to log QSO when either RRR or 73 is sent

 

Autosequencing works fine here r7436, even after the logging box has
appeared.

Steve k9an

 

On Jan 1, 2017, at 2:49 PM, Jay Hainline <ka9...@mtcnow.net
<mailto:ka9...@mtcnow.net> > wrote:

 

Yes it also stops the auto sequencing. I have to keep clicking on Enable TX
to keep sending RRR.

 

73 Jay KA9CFD

 

From: Black Michael [ <mailto:mdblac...@yahoo.com>
mailto:mdblac...@yahoo.com] 
Sent: January 1, 2017 14:47
To: WSJT software development < <mailto:wsjt-devel@lists.sourceforge.net>
wsjt-devel@lists.sourceforge.net>
Subject: Re: [wsjt-devel] Prompt to log QSO when either RRR or 73 is sent

 

The idea is that you don't click OK until you're happy with the QSO...but
you've got the logging box there to remind you to do it.  I think some
operating habits are hard to change.  

 

Maybe it should be an option.  But is there a reason you can't just let the
dialog box sit there until you're ready to log it?  It doesn't interrupt
operations at all, does it?

 

de Mike W9MDB

 


  _  


From: Jay Hainline < <mailto:ka9...@mtcnow.net> ka9...@mtcnow.net>
To:  <mailto:wsjt-devel@lists.sourceforge.net>
wsjt-devel@lists.sourceforge.net 
Sent: Sunday, January 1, 2017 8:38 AM
Subject: [wsjt-devel] Prompt to log QSO when either RRR or 73 is sent

 

This was introduced in r7431. I think its bad form to get a prompt to log
the QSO when you are sending RRR. How do you know if your QSO partner has
received it if he does not send 73 back to you??

 

Jay Hainline KA9CFD

Colchester, IL  EN40om

 



--
Check out the vibrant tech community on one of the world's most 
engaging tech sites,  <http://slashdot.org/> SlashDot.org!
<http://sdm.link/slashdot> http://sdm.link/slashdot
___
wsjt-devel mailing list
 <mailto:wsjt-devel@lists.sourceforge.net> wsjt-devel@lists.sourceforge.net
 <https://lists.sourceforge.net/lists/listinfo/wsjt-devel>
https://lists.sourceforge.net/lists/listinfo/wsjt-devel





--
Check out the vibrant tech community on one of the world's most 
engaging tech sites,  <http://slashdot.org/> SlashDot.org!
<http://sdm.link/slashdot___>
http://sdm.link/slashdot___
wsjt-devel mailing list
 <mailto:wsjt-devel@lists.sourceforge.net> wsjt-devel@lists.sourceforge.net
 <https://lists.sourceforge.net/lists/listinfo/wsjt-devel>
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

 

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Prompt to log QSO when either RRR or 73 is sent

[Jay Hainline]

Yes it also stops the auto sequencing. I have to keep clicking on Enable TX to 
keep sending RRR.

 

73 Jay KA9CFD

 

From: Black Michael [mailto:mdblac...@yahoo.com] 
Sent: January 1, 2017 14:47
To: WSJT software development <wsjt-devel@lists.sourceforge.net>
Subject: Re: [wsjt-devel] Prompt to log QSO when either RRR or 73 is sent

 

The idea is that you don't click OK until you're happy with the QSO...but 
you've got the logging box there to remind you to do it.  I think some 
operating habits are hard to change.  

 

Maybe it should be an option.  But is there a reason you can't just let the 
dialog box sit there until you're ready to log it?  It doesn't interrupt 
operations at all, does it?

 

de Mike W9MDB

 

  _  

From: Jay Hainline <ka9...@mtcnow.net <mailto:ka9...@mtcnow.net> >
To: wsjt-devel@lists.sourceforge.net <mailto:wsjt-devel@lists.sourceforge.net>  
Sent: Sunday, January 1, 2017 8:38 AM
Subject: [wsjt-devel] Prompt to log QSO when either RRR or 73 is sent

 

This was introduced in r7431. I think its bad form to get a prompt to log the 
QSO when you are sending RRR. How do you know if your QSO partner has received 
it if he does not send 73 back to you??

 

Jay Hainline KA9CFD

Colchester, IL  EN40om

 


--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net <mailto:wsjt-devel@lists.sourceforge.net> 
https://lists.sourceforge.net/lists/listinfo/wsjt-devel



--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] Prompt to log QSO when either RRR or 73 is sent

[Jay Hainline]

This was introduced in r7431. I think its bad form to get a prompt to log
the QSO when you are sending RRR. How do you know if your QSO partner has
received it if he does not send 73 back to you??

 

Jay Hainline KA9CFD

Colchester, IL  EN40om

 

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Adding WSPR-15 mode to WSJT-X

[Jay Hainline]

Thank you Joe for responding. I like your idea of developing a "wspr-msk"
mode that could be used and hopefully be able receive a decode faster than
the 15 minutes that wspr-15 now provides. 

>From what I can tell in the past, wspr-15 did seem to provide decodes at
lower s/n than wspr-2. I have received Germany in the past on wspr-15 at
2200m but no transatlantic what so ever at the 630m wspr-2 band from my
location here in Western Illinois. I would love to see that changed!

73 Jay KA9CFD

-Original Message-
From: Joe Taylor [mailto:j...@princeton.edu] 
Sent: December 19, 2016 21:04
To: WSJT software development <wsjt-devel@lists.sourceforge.net>
Subject: Re: [wsjt-devel] Adding WSPR-15 mode to WSJT-X

Hi Jay,

On 12/19/2016 3:38 PM, Jay Hainline wrote:
> Since WSJT-X 1.7.0 has now been released for general availability, I 
> would like to request WSPR-15 be added to the list of modes in WSJT-X. 
> There are still a number of experimenters in the Lowfer community that 
> still would like to use this mode. However its only available in 
> WSPR-X which has some age to it and is very buggy. My version tends to 
> stop running and freeze up after a period of time and is very 
> unreliable on my Windows 10 64 bit computer. How difficult would it be to
add this mode to WSJT-X?
>
> Is there a competing digital mode that would be better to use for the 
> lowfer experimenters that would give the same sensitivity given the 
> bandwidth restrictions that is available in the low frequency and very 
> low frequency range of the radio spectrum? One of these days, the FCC 
> is going to authorize amateur use of the 630m and 2200m bands. It 
> would be nice if the WSJT suite is ready for it.

I have received similar requests from a few others.  We should probably
address this perceived need before too long.  I would like to retire WSPR-X,
anyway, and do further development within WSJT-X.

I am not persuaded that WSPR-15 is really the best way to go.  Here are some
potentially important questions:

1. Is it clear that in practice WSPR-15 provides LF/MF decodes at lower S/N
than WSPR-2?  If so, ho much lower?

2. Could an equivalent gain in performance be achieved by having the decoder
average several consecutive, properly synchronized WSPR-2 transmissions?

3. If a more sensitive WSPR-like mode is truly needed for LF/MF
experimentation, would it be better to create something that for now I'll
call "WSPR-MSK", which (like MSK144) uses OQPSK (Offset Quadrature
Phase-Shift Keying), a constant-envelope waveform, coherent demodulation,
and an LDPC code?  Steve (K9AN) and I have discussed such a possible mode,
and we might be more motivated to develop that rather than going "back" to
WSPR-15.  I suspect WSPR-MSK could be made as sensitive (or better) than
WSPR-15, even with transmissions shorter than
15 minutes.

-- 73, Joe, K1JT


--
Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon
Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/intel
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel




--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/intel
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] Adding WSPR-15 mode to WSJT-X

[Jay Hainline]

Since WSJT-X 1.7.0 has now been released for general availability, I would
like to request WSPR-15 be added to the list of modes in WSJT-X. There are
still a number of experimenters in the Lowfer community that still would
like to use this mode. However its only available in WSPR-X which has some
age to it and is very buggy. My version tends to stop running and freeze up
after a period of time and is very unreliable on my Windows 10 64 bit
computer. How difficult would it be to add this mode to WSJT-X?

 

Is there a competing digital mode that would be better to use for the lowfer
experimenters that would give the same sensitivity given the bandwidth
restrictions that is available in the low frequency and very low frequency
range of the radio spectrum? One of these days, the FCC is going to
authorize amateur use of the 630m and 2200m bands. It would be nice if the
WSJT suite is ready for it.

 

73 Jay

 

Jay Hainline KA9CFD

Colchester, IL  EN40om

 

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/intel___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] error on building WSJT-x with JTSDK

[Jay Hainline]

I switched to qt55 and r7380 built just fine. If I remember right, I had a
problem with qt55 when you guys first made it available and I went back to
qt52 and had no problems building from there. I suspect the issue I had
previously with qt55 has been fixed and will start using it now.

73 Jay KA9CFD

-Original Message-
From: Bill Somerville [mailto:g4...@classdesign.com] 
Sent: December 12, 2016 19:02
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] error on building WSJT-x with JTSDK

On 12/12/2016 18:58, Jay Hainline wrote:
> Bill should I be using a more newer version of Qt?

Hi Jay,

not necessarily, I should be checking on more than one version before I
commit changes :(

73
Bill
G4WJS.



--
Check out the vibrant tech community on one of the world's most engaging
tech sites, SlashDot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel




--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] error on building WSJT-x with JTSDK

[Jay Hainline]

Bill should I be using a more newer version of Qt?
73 Jay KA9CFD


Sent from my U.S. Cellular® Smartphone
 Original message From: Bill Somerville <g4...@classdesign.com> 
Date: 12/12/16  12:27  (GMT-06:00) To: wsjt-devel@lists.sourceforge.net 
Subject: Re: [wsjt-devel] error on building WSJT-x with JTSDK 
On 12/12/2016 12:50, Jay Hainline wrote:
> Attached is an error message I received this morning when trying to 
> build to the latest version of WSJT-x 1.7.0-rc3.

Hi Jay,

sorry about that, a small issue compatibility with older versions of Qt. 
Should be ok as of r7380.

73
Bill
G4WJS.


--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] auto choosing correct sequence in msk144 mode

[Jay Hainline]

Just a thought and I haven’t tried to see, we have been using 15 second T/R 
with msk144. Does the issue continue when using 30 sec T/R? Maybe its related 
to where its set in reference to printing the wrong time and going "off 
sequence".

Jay KA9CFD

-Original Message-
From: Steven Franke [mailto:s.j.fra...@icloud.com] 
Sent: September 15, 2016 12:54
To: Joe Taylor <wsjt-devel@lists.sourceforge.net>
Subject: Re: [wsjt-devel] auto choosing correct sequence in msk144 mode

Hi Jay and all,

I’ve observed this behavior too - but I have attributed it to the fact that 
click-to-decodes are printed with the wrong time. This is an issue that is 
known and is “on the list” of things to address. The click-to-decodes are 
printed with the time of the previously completed sequence, and not the current 
sequence. As such, if you click on a decode that came from a “click-to-decode”, 
the wrong sequence will be chosen.

It would be useful to know whether or not your observations are consistent with 
mine, or if you find that clicking on a regular end-of-cycle decode results in 
the wrong sequence being chosen.

Steve k9an

> On Sep 15, 2016, at 6:55 AM, Jay Hainline <ka9...@mtcnow.net> wrote:
> 
> One thing I have noticed and wish it would be implemented is when double 
> clicking on a callsign in the band activity window, the program does not 
> automatically pick the correct sequence to transmit on like it does in 
> JT65+JT9 mode. You have to check or uncheck the Tx even/1st box manually to 
> put your radio in the correct sequence. It would be nice if the program would 
> do this automatically so you are not accidentally transmitting at the wrong 
> time.
>  
> Using WSJT-X v1.7.0-rc1 r7083, Windows 10 64 bit.
>  
> 73 Jay
>  
> Jay Hainline KA9CFD
> Colchester, IL  EN40om
>  
> --
>  ___
> 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] auto choosing correct sequence in msk144 mode

[Jay Hainline]

I think it is consistent with what you are seeing Steve. 

73 Jay KA9CFD

-Original Message-
From: Steven Franke [mailto:s.j.fra...@icloud.com] 
Sent: September 15, 2016 12:54
To: Joe Taylor <wsjt-devel@lists.sourceforge.net>
Subject: Re: [wsjt-devel] auto choosing correct sequence in msk144 mode

Hi Jay and all,

I’ve observed this behavior too - but I have attributed it to the fact that 
click-to-decodes are printed with the wrong time. This is an issue that is 
known and is “on the list” of things to address. The click-to-decodes are 
printed with the time of the previously completed sequence, and not the current 
sequence. As such, if you click on a decode that came from a “click-to-decode”, 
the wrong sequence will be chosen.

It would be useful to know whether or not your observations are consistent with 
mine, or if you find that clicking on a regular end-of-cycle decode results in 
the wrong sequence being chosen.

Steve k9an

> On Sep 15, 2016, at 6:55 AM, Jay Hainline <ka9...@mtcnow.net> wrote:
> 
> One thing I have noticed and wish it would be implemented is when double 
> clicking on a callsign in the band activity window, the program does not 
> automatically pick the correct sequence to transmit on like it does in 
> JT65+JT9 mode. You have to check or uncheck the Tx even/1st box manually to 
> put your radio in the correct sequence. It would be nice if the program would 
> do this automatically so you are not accidentally transmitting at the wrong 
> time.
>  
> Using WSJT-X v1.7.0-rc1 r7083, Windows 10 64 bit.
>  
> 73 Jay
>  
> Jay Hainline KA9CFD
> Colchester, IL  EN40om
>  
> --
>  ___
> 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] auto choosing correct sequence in msk144 mode

[Jay Hainline]

I may have used the wrong verbage Joe. I didn't mean the TX1 to TX6 messages
but the actual time to transmit controlled by the TX even/1st box that is
checked or unchecked.

Jay KA9CFD

-Original Message-
From: Joe Taylor [mailto:j...@princeton.edu] 
Sent: September 15, 2016 12:57
To: WSJT software development <wsjt-devel@lists.sourceforge.net>
Subject: Re: [wsjt-devel] auto choosing correct sequence in msk144 mode

Hi Jay,

I don't understand your comment.  It seems to me that in MSK144 mode, as in
all others, double-clicking on a line of decoded text does set the proper Tx
sequence for calling that station.

I do not understand why this might not be working for you.  Please
elaborate.

-- Joe, K1JT

On 9/15/2016 7:55 AM, Jay Hainline wrote:
> One thing I have noticed and wish it would be implemented is when 
> double clicking on a callsign in the band activity window, the program 
> does not automatically pick the correct sequence to transmit on like 
> it does in
> JT65+JT9 mode. You have to check or uncheck the Tx even/1st box 
> JT65+manually to
> put your radio in the correct sequence. It would be nice if the 
> program would do this automatically so you are not accidentally 
> transmitting at the wrong time.
>
>
>
> Using WSJT-X v1.7.0-rc1 r7083, Windows 10 64 bit.
>
>
>
> 73 Jay
>
>
>
> Jay Hainline KA9CFD
>
> Colchester, IL  EN40om
>
>
>
>
>
>
>
> --
> 
>
>
>
> ___
> 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] auto choosing correct sequence in msk144 mode

[Jay Hainline]

One thing I have noticed and wish it would be implemented is when double
clicking on a callsign in the band activity window, the program does not
automatically pick the correct sequence to transmit on like it does in
JT65+JT9 mode. You have to check or uncheck the Tx even/1st box manually to
put your radio in the correct sequence. It would be nice if the program
would do this automatically so you are not accidentally transmitting at the
wrong time.

 

Using WSJT-X v1.7.0-rc1 r7083, Windows 10 64 bit.

 

73 Jay

 

Jay Hainline KA9CFD

Colchester, IL  EN40om

 

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

Re: [wsjt-devel] WSJT-X User Guide for v1.7

[Jay Hainline]

The one thing that sticks out to me is the outdated pictures of the settings
tabs. The advanced tab is missing and no mention of it. Maybe that's
intentional. :-)

73 Jay KA9CFD

-Original Message-
From: Joe Taylor [mailto:j...@princeton.edu] 
Sent: September 8, 2016 17:11
To: WSJT software development 
Subject: [wsjt-devel] WSJT-X User Guide for v1.7

Hi all,

I've made some progress on updating the WSJT-X User Guide for Version 1.7.
Intermediate results have been committed to SourceForge, and the updated
guide (as it now stands) is posted here for user access:

http://www.physics.princeton.edu/pulsar/K1JT/wsjtx-doc/wsjtx-main-1.7.0-rc1.
html

Changes so far are in Sections 1 and 8.  Additional changes will be needed
in Sections 8.3 - 8.6, Section 15, and perhaps elsewhere.

Please let me know of things you think need to be added, deleted, improved,
or ???

-- 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] Azimuth/Elevation calculator in WSJT-X

[Jay Hainline]

Mike. If I add my full grid EN40om to my My Grid, then enter EN00 to the DX 
Grid field, it still shows zeros for the AZ and miles. If I add 2 more 
characters to the DX Grid, example EN00aa, it will calculate out. HOWEVER, if I 
use EN00mm for the center of the grid, it shows zeros again. Changing My Grid 
back to EN40 makes no difference. EN00mm still shows zeros while any other 6 
digit grid combination calculates out.

 

Jay KA9CFD

 

 

 

From: Black Michael [mailto:mdblac...@yahoo.com] 
Sent: August 29, 2016 14:03
To: WSJT software development <wsjt-devel@lists.sourceforge.net>
Subject: Re: [wsjt-devel] Azimuth/Elevation calculator in WSJT-X

 

Add the 2 char suffix to your grid, test, then remove it and test again.

I was able to reproduce your problem.  I already had a 6-char grid and saw the 
same problemremoved the 2-chars and the problem went away.  Added the 2 
chars back and no problem.

 

So I'm wondering if there's some subtle thing going on.  See what happens for 
you and I'll try and duplicate again.

 

de Mike W9MDB

 

 

  _  

From: Jay Hainline <ka9...@mtcnow.net <mailto:ka9...@mtcnow.net> >
To: 'WSJT software development' <wsjt-devel@lists.sourceforge.net 
<mailto:wsjt-devel@lists.sourceforge.net> > 
Sent: Monday, August 29, 2016 8:52 AM
Subject: Re: [wsjt-devel] Azimuth/Elevation calculator in WSJT-X


No Joe, I am talking about other grids in the EN field. I am in EN40. If I
put EN00 grid in the dx grid field, it comes up zeros.

Jay KA9CFD

-Original Message-
From: Joe Taylor [mailto:j...@princeton.edu <mailto:j...@princeton.edu> ] 
Sent: August 29, 2016 13:50
To: WSJT software development <wsjt-devel@lists.sourceforge.net 
<mailto:wsjt-devel@lists.sourceforge.net> >
Subject: Re: [wsjt-devel] Azimuth/Elevation calculator in WSJT-X

Hi Jay,

KA9CFD wrote:

> Using WSJT-X v1.7.0-rc1 r7036 this morning on msk144.
>
> Noticed that the az/el calculator will not work if I enter a DX grid 
> square that happens to be in my grid field EN. I am located in EN40. 
> If I try and work a station in an EN grid field, the AZ and miles show up
as zero.

What would you want the program to do?  Its only information for calculating
distance and bearing is what you give it.

If you say you're in EN50 and DX Grid is set to EN50, it will necessarily
compute the distance as zero.  (The azimuth is formally undefined, but will
be displayed as zero.)

If you use a 4-character locator, the program uses the center of that
locator, for example EN50mm.

If you want accurate distances and bearings, especially for short-haul work,
you must use 6-character locators.

-- 73, Joe, K1JT


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






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

 

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

Re: [wsjt-devel] Azimuth/Elevation calculator in WSJT-X

[Jay Hainline]

No Joe, I am talking about other grids in the EN field. I am in EN40. If I
put EN00 grid in the dx grid field, it comes up zeros.

Jay KA9CFD

-Original Message-
From: Joe Taylor [mailto:j...@princeton.edu] 
Sent: August 29, 2016 13:50
To: WSJT software development 
Subject: Re: [wsjt-devel] Azimuth/Elevation calculator in WSJT-X

Hi Jay,

KA9CFD wrote:

> Using WSJT-X v1.7.0-rc1 r7036 this morning on msk144.
>
> Noticed that the az/el calculator will not work if I enter a DX grid 
> square that happens to be in my grid field EN. I am located in EN40. 
> If I try and work a station in an EN grid field, the AZ and miles show up
as zero.

What would you want the program to do?  Its only information for calculating
distance and bearing is what you give it.

If you say you're in EN50 and DX Grid is set to EN50, it will necessarily
compute the distance as zero.  (The azimuth is formally undefined, but will
be displayed as zero.)

If you use a 4-character locator, the program uses the center of that
locator, for example EN50mm.

If you want accurate distances and bearings, especially for short-haul work,
you must use 6-character locators.

-- 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] Azimuth/Elevation calculator in WSJT-X

[Jay Hainline]

I am sorry, I meant to say Azimuth and distance calculator is not working
for Grids that happen to be in my field. 

 

Jay KA9CFD

 

From: Jay Hainline [mailto:ka9...@mtcnow.net] 
Sent: August 29, 2016 13:33
To: 'wsjt-devel@lists.sourceforge.net' <wsjt-devel@lists.sourceforge.net>
Subject: Azimuth/Elevation calculator in WSJT-X

 

Using WSJT-X v1.7.0-rc1 r7036 this morning on msk144.

 

Noticed that the az/el calculator will not work if I enter a DX grid square
that happens to be in my grid field EN. I am located in EN40. If I try and
work a station in an EN grid field, the AZ and miles show up as zero.

 

Jay Hainline KA9CFD

Colchester, IL  EN40om

 

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

[wsjt-devel] Azimuth/Elevation calculator in WSJT-X

[Jay Hainline]

Using WSJT-X v1.7.0-rc1 r7036 this morning on msk144.

 

Noticed that the az/el calculator will not work if I enter a DX grid square
that happens to be in my grid field EN. I am located in EN40. If I try and
work a station in an EN grid field, the AZ and miles show up as zero.

 

Jay Hainline KA9CFD

Colchester, IL  EN40om

 

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

Re: [wsjt-devel] MSK144 transmit audio

[Jay Hainline]

Using r7032, this issue "appears" to be resolved. I did not notice this 
behavior when I ran a couple of stations this morning and used Auto Sequencing.

73 Jay KA9CFD

-Original Message-
From: Steven Franke [mailto:s.j.fra...@icloud.com] 
Sent: August 13, 2016 13:30
To: Joe Taylor <wsjt-devel@lists.sourceforge.net>
Subject: Re: [wsjt-devel] MSK144 transmit audio

Hi Jay,

Steve, K5DOG and Randy, WB8ART have reported this behavior too. The entire 
spectrum is shifted up by 500 Hz when this happens. I have seen it happen on 
Steve’s signal, and I have a wav file that illustrates the behavior. 

The answers to the following questions will help us figure out what’s going on:

Are you using Joe’s “official” alpha release of WSJT-X 1.7?

I think that both Steve and Randy were running Windows XP when they experienced 
this problem. What OS are you using? 

Does the freq shift only happen when you use autosequence? 

Does it happen if you use click-to-decode to advance the sequencer before the 
end of the cycle? 

Any other details, or, ideally, a prescription for reproducing the behavior 
reliably, would be helpful.

Thanks for the report!

Steve k9an

> 
> On Aug 13, 2016, at 7:50 AM, Jay Hainline <ka9...@mtcnow.net> wrote:
> 
> I have been working a few people using MSK144 mode. We have noticed there is 
> a slight upward change in the audio frequency that is transmitted when the 
> next transmit sequence is automatically selected using Auto sequencing.  Then 
> the next time it transmits, the transmit audio is back to normal. Has anyone 
> else noticed this and is this normal behavior?
>  
> Jay Hainline KA9CFD
> Colchester, IL  EN40om
>  
> --
>  What NetFlow Analyzer can do for you? Monitors network 
> bandwidth and traffic patterns at an interface-level. Reveals which 
> users, apps, and protocols are consuming the most bandwidth. Provides 
> multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make 
> informed decisions using capacity planning reports. 
> http://sdm.link/zohodev2dev___
> 
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel


--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic 
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning 
reports. http://sdm.link/zohodev2dev 
___
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 square last digit being cut off in msk144

[Jay Hainline]

I was able to reproduce it easily and saved the wav files. What address
should I send it to?

Jay KA9CFD

-Original Message-
From: Joe Taylor [mailto:j...@princeton.edu] 
Sent: August 16, 2016 12:47
To: WSJT software development <wsjt-devel@lists.sourceforge.net>
Subject: Re: [wsjt-devel] Grid square last digit being cut off in msk144

Hi Jay and all,

That certainly looks like a bug -- thanks for catching and reporting it. 
  It leaves me wondering why I've never seen it here.

I hope you had "Save all" checked during this run, and can retrieve and send
us one of the files that produced truncated output.  (If not, could you
please try to create the anomaly again, and send us the example file?)

Which prompts me to remind everyone: During this testing phase of WSJT-X
v1.7-rc1, please run always with "Save all".  These days, we mostly have
plenty of available disk storage.  You can always select "File | Delete all
*.wav & *.c2 files in SaveDir" to clean things out, from time to time.

Fair warning: I'll be away from tomorrow through Aug 27, so will not be able
to look into this until after that.

-- 73, Joe, K1JT

On 8/16/2016 8:00 AM, Jay Hainline wrote:
> Using WSJT-X v1.7.0-rc1 r7032, Windows 10 64 bit.
>
> I have noticed when a station is calling me on msk144 mode that 
> sometimes the last digit in the grid square is cut off as received in 
> the Rx Frequency window. When that happens, the program auto sequence 
> wants to hop to TX 3 to transmit instead of TX 2. I have had to force 
> the program to transmit TX 2.
>
> Here is an example:
>
> 114700 -4 4.0 1446 & KA9CFD WA4PGM FM07
>
> 114721 Tx 1446 & WA4PGM KA9CFD -04
>
> 114745 0 1.1 1445 & KA9CFD WA4PGM FM0
>
> 114800 Tx 1445 & WA4PGM KA9CFD R+00
>
> 114804 Tx 1445 & WA4PGM KA9CFD +00
>
> 114745 24 0.9 1447 & KA9CFD WA4PGM FM0
>
> 114830 Tx 1447 & WA4PGM KA9CFD +24
>
> 114815 0 0.9 1447 & KA9CFD WA4PGM FM0
>
> 114830 Tx 1447 & WA4PGM KA9CFD R+00
>
> 114832 Tx 1447 & WA4PGM KA9CFD +00
>
> 114845 0 14.3 1447 & KA9CFD WA4PGM RRR
>
> 114900 Tx 1447 & WA4PGM KA9CFD 73
>
> Jay Hainline KA9CFD
>
> Colchester, IL EN40om
>
>
>
> --
> 
>
>
>
> ___
> 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] Grid square last digit being cut off in msk144

[Jay Hainline]

Using WSJT-X v1.7.0-rc1 r7032, Windows 10 64 bit.

 

I have noticed when a station is calling me on msk144 mode that sometimes
the last digit in the grid square is cut off as received in the Rx Frequency
window. When that happens, the program auto sequence wants to hop to TX 3 to
transmit instead of TX 2. I have had to force the program to transmit TX 2.

 

Here is an example:

 


114700  -4  4.0 1446 & KA9CFD WA4PGM FM07

 


114721  Tx  1446 &  WA4PGM KA9CFD -04

 


114745   0  1.1 1445 & KA9CFD WA4PGM FM0

 


114800  Tx  1445 &  WA4PGM KA9CFD R+00

 


114804  Tx  1445 &  WA4PGM KA9CFD +00

 


114745  24  0.9 1447 & KA9CFD WA4PGM FM0

 


114830  Tx  1447 &  WA4PGM KA9CFD +24

 


114815   0  0.9 1447 & KA9CFD WA4PGM FM0

 


114830  Tx  1447 &  WA4PGM KA9CFD R+00

 


114832  Tx  1447 &  WA4PGM KA9CFD +00

 


114845   0 14.3 1447 & KA9CFD WA4PGM RRR

 


114900  Tx  1447 &  WA4PGM KA9CFD 73

 

 

 

Jay Hainline KA9CFD

Colchester, IL  EN40om

 

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

Re: [wsjt-devel] MSK144 transmit audio

[Jay Hainline]

I am not running split. Split operation is set to None. I am set up using DX
Lab Commander for radio control and PTT. Radios is a Flex 6500 for 6 meters
and a Yaesu FT-991 for 2 meters. I have noticed this audio shift in both
radios.

73 Jay KA9CFD

-Original Message-
From: Bill Somerville [mailto:g4...@classdesign.com] 
Sent: August 13, 2016 13:36
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] MSK144 transmit audio

On 13/08/2016 14:30, Steven Franke wrote:
> Any other details, or, ideally, a prescription for reproducing the
behavior reliably, would be helpful.

Hi Jay, Steve & all,

Do you have "Settings->Radio->Split Operating" set to something other than
"None"? It is possible that the logic to keep HF Tx signals centred on the
rigs Tx SSB passband is kicking in when it should not. Setting "Split
Operating" to "None" should stop that happening.

73
Bill
G4WJS.



--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are

consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. http://sdm.link/zohodev2dev
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel




--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. http://sdm.link/zohodev2dev
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] MSK144 transmit audio

[Jay Hainline]

I am currently using r7026 that I built from sourceforge using JTSDK. Using 
Windows 10 64 bit.

I will have to monitor a bit to answer your other questions.

73 Jay KA9CFD

-Original Message-
From: Steven Franke [mailto:s.j.fra...@icloud.com] 
Sent: August 13, 2016 13:30
To: Joe Taylor <wsjt-devel@lists.sourceforge.net>
Subject: Re: [wsjt-devel] MSK144 transmit audio

Hi Jay,

Steve, K5DOG and Randy, WB8ART have reported this behavior too. The entire 
spectrum is shifted up by 500 Hz when this happens. I have seen it happen on 
Steve’s signal, and I have a wav file that illustrates the behavior. 

The answers to the following questions will help us figure out what’s going on:

Are you using Joe’s “official” alpha release of WSJT-X 1.7?

I think that both Steve and Randy were running Windows XP when they experienced 
this problem. What OS are you using? 

Does the freq shift only happen when you use autosequence? 

Does it happen if you use click-to-decode to advance the sequencer before the 
end of the cycle? 

Any other details, or, ideally, a prescription for reproducing the behavior 
reliably, would be helpful.

Thanks for the report!

Steve k9an

> 
> On Aug 13, 2016, at 7:50 AM, Jay Hainline <ka9...@mtcnow.net> wrote:
> 
> I have been working a few people using MSK144 mode. We have noticed there is 
> a slight upward change in the audio frequency that is transmitted when the 
> next transmit sequence is automatically selected using Auto sequencing.  Then 
> the next time it transmits, the transmit audio is back to normal. Has anyone 
> else noticed this and is this normal behavior?
>  
> Jay Hainline KA9CFD
> Colchester, IL  EN40om
>  
> --
>  What NetFlow Analyzer can do for you? Monitors network 
> bandwidth and traffic patterns at an interface-level. Reveals which 
> users, apps, and protocols are consuming the most bandwidth. Provides 
> multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make 
> informed decisions using capacity planning reports. 
> http://sdm.link/zohodev2dev___
> 
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel


--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic 
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning 
reports. http://sdm.link/zohodev2dev 
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel



--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. http://sdm.link/zohodev2dev
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] MSK144 transmit audio

[Jay Hainline]

I have been working a few people using MSK144 mode. We have noticed there is
a slight upward change in the audio frequency that is transmitted when the
next transmit sequence is automatically selected using Auto sequencing.
Then the next time it transmits, the transmit audio is back to normal. Has
anyone else noticed this and is this normal behavior?

 

Jay Hainline KA9CFD

Colchester, IL  EN40om

 

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. http://sdm.link/zohodev2dev___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] JTSDK-Win32 Upgrade Available - (Import Update)

[Jay Hainline]

Greg I get this pop up window when I run update/upgrade. This is on a
Windows 10 64 bit machine.

 

Jay KA9CFD

 

-Original Message-
From: Greg Beam [mailto:ki7m...@gmail.com] 
Sent: December 25, 2015 19:38
To: WSJT software development ;
wsjtgr...@yahoogroups.com; ws...@yahoogroups.com
Subject: Re: [wsjt-devel] JTSDK-Win32 Upgrade Available - (Import Update)

 

Hello All,

 

A few users reported svn errors when finding or executing svn where the full
path to svn.exe was not stated. Why this is a requirement now, where it was
not before is still a mystery. I did not see these errors on either of my
Win-10 boxes, but, I believe the issue is resolve with the latest
postinstall script update.

 

I also corrected the svn version number that is displayed in the Title Bars
for JTSDK-QT and JTSDK-PY, and added a search for Asciidoctor in JTSDK-QT.

 

Attached is what should be shown when the update run is successful. If
anyone is still seeing svn errors please report it to the dev-list.

 

 

73's

Greg, KI7MT

 

On 12/24/2015 15:03, Greg Beam wrote:

> Hello All,

> 

> First, Happy Hols to everyone !!

> 

> JTSDK-Win32 Upgrade (4) is a small but important update. It moves user

> updates off development ^/trunk/win32 and onto a more stable released

> branch, in this case ^/tags/jtsdk-win-2.03.

> 

> *TO UPGRADE*

> - Close All JTSDK Terminals, QT, PY, MSYS, Maint and DOC.

> - Download: JTSDK-2.0.0-u4-win32.exe

> - Link:

>

http://sourceforge.net/projects/jtsdk/files/win32/2.0.0/JTSDK-2.0.0-u4-win32
.exe/download

> - MD5: 57576d5277c51bbfabfc9bccef94440e

> - SHA: 1b8e908310d63a1b29a69472bcbd40425d89aa92

> - Run the installer, accept the defaults, exit.

> - Open JTSDK-Maint, then:

> 

> update

> upgrade

> 

> - Close then re-open JTSDK-Maint,

> 

> *LIST VERSION INFO*

> - After re-opening JTSDK-Maint, type:

> 

> version

> 

> You should then see a display close to the following::

> * Version: JTSDK-Win32 2.0.3

> * Last Changed Rev: 543

> * URL:

https://svn.code.sf.net/p/jtsdk/jtsdk/jtsdk-win/tags/jtsdk-win-2.0.3

> * Last Changed Date: 2015-12-24 13:47:39 -0700 (Thu, 24 Dec 2015)

> 

> 

> If you have any trouble with the Upgrade or Builds after the upgrade,

> report them to the dev-list.

> 

> I'm off to an Xmas party with the XYL, but will check to see if there

> are any hot issues later this evening.

> 

> 

> Hope everyone has a Safe and Happy Xmas / New Years.

> 

> 

> 73's

> Greg, KI7MT

> 

>

--

> ___

> 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: Fortran runtime error

[Jay Hainline]

Hello Joe. I did have the start spinner set to 0. I changed it to 100 hz and 
that seemed to fix the problem. This had not been a problem until r5970. I 
am using build r5977 now.

Jay Hainline KA9CFD
Colchester, IL EN40om

-Original Message- 
From: Joe Taylor
Sent: Monday, October 19, 2015 17:17
To: WSJT software development
Subject: Re: [wsjt-devel] Fwd: Fortran runtime error

Thanks to those reporting the Fortran bounds error in sync65.f90.  It's
fixed in code revision 5977.

The reason why some observed it and others (including me) did not is
simple: the error occurred only if you had the Wide Graph's "Start xxx
Hz" spinner set to 0.  (It's worth noting that in general this is not a
good idea.  Your passband response most likely rolls off steeply below
something 200 Hz or so, and if you include even lower frequencies in the
waterfall display the "Flatten" feature will be compromised.)

I will also repeat my usual warning to anyone using a development
version of our programs on the air -- whether you built it yourself or
it was built by some third party not part of the WSJT development team:

If you choose to run bleeding-edge code, we assume that you can handle
unexpected program errors on your own.  You also have a responsibility
to make useful contributions to the development process (e.g., by
carefully documenting and reporting bugs).

Otherwise, you will likely waste your time and ours by trying to use a
program built from unreleased code.

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

[wsjt-devel] auto sequence problem

[Jay Hainline]

I am having an issue with the auto sequence in WSJTX 1.6.1 r5903. I copied 
below the Rx Frequency window while running JTMSK on 6 meters. As you can 
see at 120645, the last digit of the grid sent by WB4JWM was left off. The 
auto sequence then hopped to TX3 instead of sending TX2 again. I don’t know 
if anyone else has this problem or not. Thought I would mention it.

120630  Tx  1500 & CQ KA9CFD EN40
120615   4 13.1 1500 & KA9CFD WB4JWM EM83
120631  Tx  1500 & WB4JWM KA9CFD +04
120645   4  6.4 1500 & KA9CFD WB4JWM EM8
120700  Tx  1500 & WB4JWM KA9CFD R+04
120709  Tx  1500 & WB4JWM KA9CFD +04
120730  Tx  1500 & WB4JWM KA9CFD +04
120715   3  0.8 1500 & KA9CFD WB4JWM RRR
120730  Tx  1500 & WB4JWM KA9CFD 73
120745   2  9.7 1500 & KA9CFD WB4JWM 73
120800  Tx      1500 & WB4JWM KA9CFD 73

73 Jay

Jay Hainline KA9CFD
Colchester, IL EN40om



--
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991=/4140
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] CQ Rx bug

[Jay Hainline]

I build WSJTX 1.6.1 r5892 from sourceforge this morning. Using a Yaesu 
FT-2000 and DXLabs Commander for CAT. I have 50.280 set in the Working 
Frequencies list for JTMSK mode. When I put a checkmark in the box to 
activiate the CQ RX 285, the radio goes to 50.285 as it should. But when I 
Enable Tx to CQ, the radio stays on 50.285 instead of switching back to 
50.280 on transmit. It makes no difference if I have split operation set to 
none or Rig in the settings and the Rx frequency offset with "CQ nnn..." is 
check marked.

73 Jay

Jay Hainline KA9CFD
Colchester, IL EN40om



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

Re: [wsjt-devel] CQ Rx bug

[Jay Hainline]

Yes Joe. It appears to be a problem between Dxlabs Commander and WSJT-X. I 
sent a debugging file created by Commander to Bill. Hope that helps in 
tracking down the issue. I know a few people on Ping Jockey this morning 
were having a similar problem. But I don’t know if they also use Commander 
or not.

73 Jay

Jay Hainline KA9CFD
Colchester, IL EN40om

-Original Message- 
From: Joe Taylor
Sent: Monday, September 14, 2015 15:26
To: WSJT software development
Subject: Re: [wsjt-devel] CQ Rx bug

Hi Jay,

I checked operation of the "CQ nnn ..." transmission on the FT-2000 at
W2PU this morning, and it seems to be OK.  I was using "Rig" split mode,
and no Commander in the loop.

I see that you have now got this same result.

-- Joe, K1JT

On 9/14/2015 9:07 AM, Jay Hainline wrote:
> I build WSJTX 1.6.1 r5892 from sourceforge this morning. Using a Yaesu
> FT-2000 and DXLabs Commander for CAT. I have 50.280 set in the Working
> Frequencies list for JTMSK mode. When I put a checkmark in the box to
> activiate the CQ RX 285, the radio goes to 50.285 as it should. But when I
> Enable Tx to CQ, the radio stays on 50.285 instead of switching back to
> 50.280 on transmit. It makes no difference if I have split operation set 
> to
> none or Rig in the settings and the Rx frequency offset with "CQ nnn..." 
> is
> check marked.
>
> 73 Jay
>
> Jay Hainline KA9CFD
> Colchester, IL EN40om
>
>
>
> --
> ___
> 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] sending RR73 message on JT9H with auto sequencer

[Jay Hainline]

I had a small issue this morning working a station on 6 meters using 
WSJTX-devel r5808 using JT9H mode and auto sequencing. The station I was 
running with sent calls followed by RR73 programmed in the TX4 message 
button. The auto sequencer on my end got confused by this and went back to 
TX2 to send the report again. I was wondering if this is something where the 
auto sequencer can be programmed to be a little more flexible? I think if I 
copy either RRR or RR73, it should go to transmit TX5 which I have as 
sending calls and 73.

The station I ran with says he is using version r5803 and claims RR73 was 
pre-set for TX4 inside that particular version he downloaded. My WSJTX 1.6.1 
copy has always had TX4 programmed with calls and RRR.

73 Jay

Jay Hainline KA9CFD
Colchester, IL EN40om



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

Re: [wsjt-devel] sending RR73 message on JT9H with auto sequencer

[Jay Hainline]

I am not the one that sent RR73. I just try and get along and use common 
sense to complete the contact. :-)

It's too bad the world cant agree on a global standard for the sequences 
which is the base of the issue. People think they want to tinker with it. I 
just thought it might be good to think about how the auto sequence works.

Nevermind if I stepped on a toe.

73 Jay KA9CFD

-Original Message- 
From: Bill Ockert - ND0B
Sent: Monday, August 24, 2015 3:40 PM
To: WSJT software development
Subject: Re: [wsjt-devel] sending RR73 message on JT9H with auto sequencer

Jay,

I do not view it as harsh.  Harsh was when I went off HF JT modes completely
for well over a year
because of it.   I am one of about five stations in ND that are on JT HF
modes, one
of about three on both JT HF modes and LOTW and one of  one on JT HF modes,
LOTW
and 12 and 160 meters.I get on about twice a year to help folks with
WAS,  I am
not a fan of HF period so it is generally not an enjoyable experience and I
get a
resentful when folks start counting teeth...  I already know I am about
ready for McDonalds
or the glue factory.

Both the WSJT and WSJTX manual clearly state what is considered a minimal
QSO
and I am in complete agreement with it.   A QSO is complete when all of the
essential elements of if are complete and that includes one station
receiving an RRR.

If others choose to use a different format that is purely their business
just as it
is mine to choose not to accept less than the published minimal contact.
At one point
I had a much more lenient policy about that which included sending TX3 a
second
time then emailing the station letting them know what the issue was and
offering a
retry.   However I was point blank told that I had no right to tell other
stations what
to transmit, I capitulated completely and now have a policy where I
terminate the contact
immediately upon deviation from the minimal QSO and do not offer a retry.
The person
who was doing the complaining called me a crazy old ^%$#$% when I made the
change
so it must have been exactly the right thing to do.

As a personal side note I was hoping to make it to 60 before that happened
but oh well...

I believe if there is going to be an auto sequencer one of its functions
should be to
enforce the minimal QSO and not facilitate less than minimal QSOs.   That is
both
for integrity of the QSO reasons and because it would be a pain to program
all of the
variations that are floating around out there.   The only question mark
there should
be for an auto sequencer is how to gracefully shut down the contact.  There
is a catch 22 in the logic to handle 73's that I believe is handled
reasonably well in the WSJT
ISCAT auto sequencer that I hope to move over the WSJTX.

For those users who feel otherwise they can always override the auto
sequencer and advance
if they feel the auto sequencer was being too strict.

73 de Bill ND0B


-Original Message- 
From: Jay Hainline
Sent: Monday, August 24, 2015 2:13 PM
To: WSJT software development
Subject: Re: [wsjt-devel] sending RR73 message on JT9H with auto sequencer

Not logging it? That seems a little harsh. The sequencing was correct up to
that point. He had already received my R-signal report from me and just
bunched the RR73 into one transmit sequence. All I wanted to do was send the
73 transmission but for QSO purposes, it was complete at that point. I did
manually send the 73 sequence and the QSO was logged.

73 Jay

Jay Hainline KA9CFD
Colchester, IL EN40om

-Original Message- 
From: Bill Ockert - ND0B
Sent: Monday, August 24, 2015 15:54
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] sending RR73 message on JT9H with auto sequencer

The auto sequencer, while it should not have gone back to TX2, actually
acted in a
benign manner compared to what I would have done manually, namely ended the
contact
without the  benefit of logging it.

73 de Bill ND0B


-Original Message- 
From: Jay Hainline
Sent: Monday, August 24, 2015 6:56 AM
To: wsjt-devel@lists.sourceforge.net
Subject: [wsjt-devel] sending RR73 message on JT9H with auto sequencer

I had a small issue this morning working a station on 6 meters using
WSJTX-devel r5808 using JT9H mode and auto sequencing. The station I was
running with sent calls followed by RR73 programmed in the TX4 message
button. The auto sequencer on my end got confused by this and went back to
TX2 to send the report again. I was wondering if this is something where the
auto sequencer can be programmed to be a little more flexible? I think if I
copy either RRR or RR73, it should go to transmit TX5 which I have as
sending calls and 73.

The station I ran with says he is using version r5803 and claims RR73 was
pre-set for TX4 inside that particular version he downloaded. My WSJTX 1.6.1
copy has always had TX4 programmed with calls and RRR.

73 Jay

Jay Hainline KA9CFD
Colchester, IL EN40om

Re: [wsjt-devel] Fw: sending RR73 message on JT9H with auto sequencer

[Jay Hainline]

Just to clarify, the line contained both calls and RR73. This was AFTER reports 
had been sent both ways. So I don't know what the difference would be in 
receiving 2 Rogers instead of 3. :-)


Jay KA9CFD 
Sent from my U.S. Cellular® Smartphone

 Original message 
From: George J Molnar geo...@molnar.com 
Date: 08/24/2015  5:23 PM  (GMT-06:00) 
To: Bill Ockert - ND0B n...@ockert.us, WSJT software development 
wsjt-devel@lists.sourceforge.net 
Subject: Re: [wsjt-devel] Fw: sending RR73 message on JT9H with auto
sequencer 

Agree, Bill. Auto-sequence should be the same as manual, and RR73 isn't a good 
way to complete, nor is anything else that fails to include your callsign.


George J Molnar, CEM, CHPPNevada Statewide Interoperability Coordinator
@GJMolnar | KF2T | AFA9GM
On Aug 24, 2015, at 3:18 PM, Bill Ockert - ND0B n...@ockert.us wrote:








Mike,
 
No   I do treat RRR 73 as a valid ending when I handle it 
manually.  I treat RR73 as improper in both in content and in white 
space.  
 
Bill



 

From: Michael Black 
Sent: Monday, August 24, 2015 4:53 PM
To: Bill Ockert 
- ND0B ; WSJT software development 

Subject: Re: [wsjt-devel] sending RR73 message on JT9H with auto 
sequencer
 



Just curious Bill -- do you treat RR73 as a valid QSO 
ending?
About 7% of users use that according to my 
logs.

Mike W9MDB


 
On Mon, Aug 24, 2015 at 3:40 PM, Bill Ockert - ND0B n...@ockert.us wrote:

Jay,

I 
  do not view it as harsh.  Harsh was when I went off HF JT modes 
  completely
for well over a year
because of it.   I am one of 
  about five stations in ND that are on JT HF
modes, one
of about three on 
  both JT HF modes and LOTW and one of  one on JT HF modes,
LOTW
and 
  12 and 160 meters.    I get on about twice a year to help folks 
  with
WAS,  I am
not a fan of HF period so it is generally not an 
  enjoyable experience and I
get a
resentful when folks start counting 
  teeth...  I already know I am about
ready for McDonalds
or the glue 
  factory.

Both the WSJT and WSJTX manual clearly state what is 
  considered a minimal
QSO
and I am in complete agreement with 
  it.   A QSO is complete when all of the
essential elements of if 
  are complete and that includes one station
receiving an RRR.

If 
  others choose to use a different format that is purely their business
just 
  as it
is mine to choose not to accept less than the published minimal 
  contact.
At one point
I had a much more lenient policy about that which 
  included sending TX3 a
second
time then emailing the station letting 
  them know what the issue was and
offering a
retry.   However I 
  was point blank told that I had no right to tell other
stations what
to 
  transmit, I capitulated completely and now have a policy where I
terminate 
  the contact
immediately upon deviation from the minimal QSO and do not 
  offer a retry.
The person
who was doing the complaining called me a 
  crazy old ^%$#$% when I made the
change
so it must have been 
  exactly the right thing to do.

As a personal side note I was hoping to 
  make it to 60 before that happened
but oh well...

I believe if there 
  is going to be an auto sequencer one of its functions
should be 
  to
enforce the minimal QSO and not facilitate less than minimal 
  QSOs.   That is
both
for integrity of the QSO reasons and 
  because it would be a pain to program
all of the
variations that are 
  floating around out there.   The only question mark
there 
  should
be for an auto sequencer is how to gracefully shut down the 
  contact.  There
is a catch 22 in the logic to handle 73's that I 
  believe is handled
reasonably well in the WSJT
ISCAT auto sequencer that 
  I hope to move over the WSJTX.

For those users who feel otherwise they 
  can always override the auto
sequencer and advance
if they feel the auto 
  sequencer was being too strict.

73 de Bill 
  ND0B


-Original Message-
From: Jay Hainline
Sent: 
  Monday, August 24, 2015 2:13 PM
To: WSJT software development
Subject: 
  Re: [wsjt-devel] sending RR73 message on JT9H with auto sequencer

Not 
  logging it? That seems a little harsh. The sequencing was correct up 
  to
that point. He had already received my R-signal report from me and 
  just
bunched the RR73 into one transmit sequence. All I wanted to do was 
  send the
73 transmission but for QSO purposes, it was complete at that 
  point. I did
manually send the 73 sequence and the QSO was 
  logged.

73 Jay

Jay Hainline KA9CFD
Colchester, IL 
  EN40om

-Original Message-
From: Bill Ockert - ND0B
Sent: 
  Monday, August 24, 2015 15:54
To: wsjt-devel@lists.sourceforge.net
Subject: 
  Re: [wsjt-devel] sending RR73 message on JT9H with auto sequencer

The 
  auto sequencer, while it should not have gone back to TX2, actually
acted 
  in a
benign manner compared to what I would have done manually, namely 
  ended the
contact
without the  benefit of logging it.

73 de 
  Bill ND0B


-Original Message-
From

Re: [wsjt-devel] Fw: sending RR73 message on JT9H withauto sequencer

[Jay Hainline]

Ah, now I understand that although I doubt if I will be working anyone in 
that grid in the Arctic Ocean anytime soon.

73 Jay

Jay Hainline KA9CFD
Colchester, IL EN40om

-Original Message- 
From: George J Molnar
Sent: Monday, August 24, 2015 23:06
To: WSJT software development
Subject: Re: [wsjt-devel] Fw: sending RR73 message on JT9H withauto 
sequencer

RR73 is also a valid grid square and could cause confusion in software.




George J Molnar
KF2T | AFA9GM
Twitter: @GJMolnar

SUPPORT HR-1301  S-1685
http://www.arrl.org/amateur-radio-parity-act





On Aug 24, 2015, at 15:40, Jay Hainline ka9...@mtcnow.net wrote:


Just to clarify, the line contained both calls and RR73. This was AFTER 
reports had been sent both ways. So I don't know what the difference would 
be in receiving 2 Rogers instead of 3. :-)



Jay KA9CFD

Sent from my U.S. Cellular® Smartphone


 Original message 
From: George J Molnar geo...@molnar.com
Date: 08/24/2015 5:23 PM (GMT-06:00)
To: Bill Ockert - ND0B n...@ockert.us, WSJT software development 
wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] Fw: sending RR73 message on JT9H with auto 
sequencer


Agree, Bill. Auto-sequence should be the same as manual, and RR73 isn't a 
good way to complete, nor is anything else that fails to include your 
callsign.



George J Molnar, CEM, CHPP
Nevada Statewide Interoperability Coordinator

@GJMolnar | KF2T | AFA9GM

On Aug 24, 2015, at 3:18 PM, Bill Ockert - ND0B n...@ockert.us wrote:


Mike,

No   I do treat RRR 73 as a valid ending when I handle it manually.  I treat 
RR73 as improper in both in content and in white space.

Bill


From: Michael Black
Sent: Monday, August 24, 2015 4:53 PM
To: Bill Ockert - ND0B ; WSJT software development
Subject: Re: [wsjt-devel] sending RR73 message on JT9H with auto sequencer

Just curious Bill -- do you treat RR73 as a valid QSO ending?
About 7% of users use that according to my logs.

Mike W9MDB

On Mon, Aug 24, 2015 at 3:40 PM, Bill Ockert - ND0B n...@ockert.us wrote:
Jay,

I do not view it as harsh.  Harsh was when I went off HF JT modes completely
for well over a year
because of it.   I am one of about five stations in ND that are on JT HF
modes, one
of about three on both JT HF modes and LOTW and one of  one on JT HF modes,
LOTW
and 12 and 160 meters.I get on about twice a year to help folks with
WAS,  I am
not a fan of HF period so it is generally not an enjoyable experience and I
get a
resentful when folks start counting teeth...  I already know I am about
ready for McDonalds
or the glue factory.

Both the WSJT and WSJTX manual clearly state what is considered a minimal
QSO
and I am in complete agreement with it.   A QSO is complete when all of the
essential elements of if are complete and that includes one station
receiving an RRR.

If others choose to use a different format that is purely their business
just as it
is mine to choose not to accept less than the published minimal contact.
At one point
I had a much more lenient policy about that which included sending TX3 a
second
time then emailing the station letting them know what the issue was and
offering a
retry.   However I was point blank told that I had no right to tell other
stations what
to transmit, I capitulated completely and now have a policy where I
terminate the contact
immediately upon deviation from the minimal QSO and do not offer a retry.
The person
who was doing the complaining called me a crazy old ^%$#$% when I made the
change
so it must have been exactly the right thing to do.

As a personal side note I was hoping to make it to 60 before that happened
but oh well...

I believe if there is going to be an auto sequencer one of its functions
should be to
enforce the minimal QSO and not facilitate less than minimal QSOs.   That is
both
for integrity of the QSO reasons and because it would be a pain to program
all of the
variations that are floating around out there.   The only question mark
there should
be for an auto sequencer is how to gracefully shut down the contact.  There
is a catch 22 in the logic to handle 73's that I believe is handled
reasonably well in the WSJT
ISCAT auto sequencer that I hope to move over the WSJTX.

For those users who feel otherwise they can always override the auto
sequencer and advance
if they feel the auto sequencer was being too strict.

73 de Bill ND0B


-Original Message-
From: Jay Hainline
Sent: Monday, August 24, 2015 2:13 PM
To: WSJT software development
Subject: Re: [wsjt-devel] sending RR73 message on JT9H with auto sequencer

Not logging it? That seems a little harsh. The sequencing was correct up to
that point. He had already received my R-signal report from me and just
bunched the RR73 into one transmit sequence. All I wanted to do was send the
73 transmission but for QSO purposes, it was complete at that point. I did
manually send the 73 sequence and the QSO was logged.

73 Jay

Jay Hainline KA9CFD
Colchester, IL EN40om

-Original

Re: [wsjt-devel] Fw: sending RR73 message on JT9H withauto sequencer

[Jay Hainline]

Bill I know what constitutes a QSO. I always use the standard messages 
myself. However this QSO was using the JT9H mode with FEC. There is no 
mistake in what was sent and received. There is no partials involved like 
there is in ISCAT or FSK441 modes. It's either all or nothing. I think that 
needs to be considered. If it is such a big deal, then why isnt WSJTX 
hardcoded with the standard messages so they cannot be changed?

This is the final word from me on this subject. Time to move on.

73 Jay

Jay Hainline KA9CFD
Colchester, IL EN40om

-Original Message- 
From: Bill Ockert - ND0B
Sent: Monday, August 24, 2015 23:27
To: WSJT software development
Subject: Re: [wsjt-devel] Fw: sending RR73 message on JT9H withauto 
sequencer


Jay,

From the WSJTX manual...

By longstanding tradition, a minimal valid QSO requires the exchange of 
callsigns, a signal report or some other information, and acknowledgments. 
WSJT-X is designed to facilitate making such minimal QSOs using short, 
formatted messages. The process works best if you use them and follow 
standard operating practices. The recommended basic QSO goes something like 
this:

1. CQ K1ABC FN42
2. K1ABC G0XYZ IO91
3. G0XYZ K1ABC –19
4. K1ABC G0XYZ R-22
5. G0XYZ K1ABC RRR
6. K1ABC G0XYZ 73

The messages suggested and in fact the messages that WSJTX (and WSJT) 
generate reflect RRR as the long standing minimal acknowledgement.

The manual is clear, the software is clear and the effort to do it that was 
is actually less than doing it the other way... no messages to change every 
time you change modes.

Bill


From: Jay Hainline
Sent: Monday, August 24, 2015 5:40 PM
To: WSJT software development
Subject: Re: [wsjt-devel] Fw: sending RR73 message on JT9H withauto 
sequencer

Just to clarify, the line contained both calls and RR73. This was AFTER 
reports had been sent both ways. So I don't know what the difference would 
be in receiving 2 Rogers instead of 3. :-)



Jay KA9CFD

Sent from my U.S. Cellular® Smartphone


 Original message 
From: George J Molnar geo...@molnar.com
Date: 08/24/2015 5:23 PM (GMT-06:00)
To: Bill Ockert - ND0B n...@ockert.us, WSJT software development 
wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] Fw: sending RR73 message on JT9H with auto 
sequencer


Agree, Bill. Auto-sequence should be the same as manual, and RR73 isn't a 
good way to complete, nor is anything else that fails to include your 
callsign.



George J Molnar, CEM, CHPP
Nevada Statewide Interoperability Coordinator

@GJMolnar | KF2T | AFA9GM

On Aug 24, 2015, at 3:18 PM, Bill Ockert - ND0B n...@ockert.us wrote:


Mike,

No   I do treat RRR 73 as a valid ending when I handle it manually.  I treat 
RR73 as improper in both in content and in white space.

Bill


From: Michael Black
Sent: Monday, August 24, 2015 4:53 PM
To: Bill Ockert - ND0B ; WSJT software development
Subject: Re: [wsjt-devel] sending RR73 message on JT9H with auto sequencer

Just curious Bill -- do you treat RR73 as a valid QSO ending?
About 7% of users use that according to my logs.

Mike W9MDB

On Mon, Aug 24, 2015 at 3:40 PM, Bill Ockert - ND0B n...@ockert.us wrote:
Jay,

I do not view it as harsh.  Harsh was when I went off HF JT modes completely
for well over a year
because of it.   I am one of about five stations in ND that are on JT HF
modes, one
of about three on both JT HF modes and LOTW and one of  one on JT HF modes,
LOTW
and 12 and 160 meters.I get on about twice a year to help folks with
WAS,  I am
not a fan of HF period so it is generally not an enjoyable experience and I
get a
resentful when folks start counting teeth...  I already know I am about
ready for McDonalds
or the glue factory.

Both the WSJT and WSJTX manual clearly state what is considered a minimal
QSO
and I am in complete agreement with it.   A QSO is complete when all of the
essential elements of if are complete and that includes one station
receiving an RRR.

If others choose to use a different format that is purely their business
just as it
is mine to choose not to accept less than the published minimal contact.
At one point
I had a much more lenient policy about that which included sending TX3 a
second
time then emailing the station letting them know what the issue was and
offering a
retry.   However I was point blank told that I had no right to tell other
stations what
to transmit, I capitulated completely and now have a policy where I
terminate the contact
immediately upon deviation from the minimal QSO and do not offer a retry.
The person
who was doing the complaining called me a crazy old ^%$#$% when I made the
change
so it must have been exactly the right thing to do.

As a personal side note I was hoping to make it to 60 before that happened
but oh well...

I believe if there is going to be an auto sequencer one of its functions
should be to
enforce the minimal QSO and not facilitate less than minimal QSOs.   That is
both
for integrity of the QSO reasons and because

Re: [wsjt-devel] WSJT Experimental Release r5755 Available

[Jay Hainline]

Is this new version of WSJT available through JTSDK-PY? When I try and 
build, I get an error message that a file cannot be found.

73 Jay

Jay Hainline KA9CFD
Colchester, IL EN40om

-Original Message- 
From: Bill Ockert - ND0B
Sent: Wednesday, August 05, 2015 20:45
To: WSJT Developers ; wsjtgr...@yahoogroups.com ; K1JT
Subject: [wsjt-devel] WSJT Experimental Release r5755 Available


Good Afternoon/Morning/Evening Everyone

WSJT Experimental Release r5755 and associated manual are now available on 
the shared google drive

https://drive.google.com/folderview?id=0B42rF4Jby8-vfjd0dl9udXNTOVlOa1hnQldVeFg2c05LZkhIOUhONEprdExiYndwaFJCZkUusp=sharing

As has been the norm for these experimental versions this is a zip of the 
directory not an installer.   Most folks find it works well to replace
the bin directory in their current WSJT 10.0 installation with the bin 
directory from this experimental release.   Be sure to keep a copy of
your old bin directory in a safe place and always be sure to preserver your 
call3.txt file.

This version contains the following fixes / enhancements over r5639 the 
previous experimental release:

1.  A few minor ISCAT cosmetic changes.
2.  The ISCAT auto sequencer now looks for the strongest matching decode and 
reports that instead of the first one it finds.
3.  ISCAT auto configuration now only occurs if the information block itself 
is clicked on.   Clicking on the call will only update To Radio
and not the system parameters.   Clicking on the information block updates 
everything.
4.  This version includes a variation of FSK441 called FSK315.   FSK315 is 
legal on 10m under the current FCC rules.

If you have any questions or comments please contact me either on the lists 
or directly at n...@ockert.us

73 de Bill ND0B






--






___
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] Building Hamlib3 question

[Jay Hainline]

Thanks for the reply Bill. I will heed your advice and not worry about it 
for now. I am able to build the various WSJT programs without any issues.

73 Jay

Jay Hainline KA9CFD
Colchester, IL EN40om

-Original Message- 
From: Bill Somerville
Sent: Wednesday, June 24, 2015 12:57
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] Building Hamlib3 question

On 24/06/2015 13:50, Jay Hainline wrote:

Hi Jay,
 pwd gives me this:

 /home/Jay Hainline

 I assume this means the software is looking for just Jay for the 
 directory
 name rather than my full name which is what my Windows 7 computer uses. Is
 there an easy way to change directory names without having to do a 
 complete
 uninstall/install??
Looks like there is insufficient quoting of directory paths in that part
of the JTSDK scripts, this causes paths with spaces to be misinterpreted
as multiple tokens where they should be treated as one token. I would
think that the required changes to the script are fairly trivial so I
would hold off reinstalling or creating a new account on your machine
for now.

Attempting to change the home directory path is probably tricky and I
would not recommend doing that as you will probably be plagued with
downstream problems :(

 73 Jay

 Jay Hainline KA9CFD
 Colchester, IL EN40om
73
Bill
G4WJS.
 -Original Message-
 From: Michael Black
 Sent: Tuesday, June 23, 2015 18:22
 To: 'WSJT software development'
 Subject: Re: [wsjt-devel] Building Hamlib3 question

 What you start JTSDK-MSYS do a pwd and see what directory you are in.
 Sounds like you may need to either update or reinstall JTSDK.


 -Original Message-
 From: Jay Hainline [mailto:ka9...@mtcnow.net]
 Sent: Tuesday, June 23, 2015 10:40 AM
 To: wsjt-devel@lists.sourceforge.net
 Subject: [wsjt-devel] Building Hamlib3 question

 Following the readme instructions, it says I should re-build hamlib3 often
 as it receives frequent updates. When I try to do build-hamlib3 from
 JTSDK-MSYS, I get a message that says:

 /scripts/msys-build-hamlib3.sh: line 124: cd: /home/Jay: No such file or
 directory

 Does this mean there is nothing to upgrade or is there a problem with my
 install, or has something been changed and the readme file has not been
 updated?

 I have had no problem in building WSJT-X from JTSDK-QT.

 73 Jay

 Jay Hainline KA9CFD
 Colchester, IL EN40om


--
Monitor 25 network devices or servers for free with OpManager!
OpManager is web-based network management software that monitors
network devices and physical  virtual servers, alerts via email  sms
for fault. Monitor 25 devices for free with no restriction. Download now
http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel



--
Monitor 25 network devices or servers for free with OpManager!
OpManager is web-based network management software that monitors 
network devices and physical  virtual servers, alerts via email  sms 
for fault. Monitor 25 devices for free with no restriction. Download now
http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Building Hamlib3 question

[Jay Hainline]

I still get no file or folder found when I try and run JTSDK-DOC.

Thanks for your help Greg. I think we made some progress.

Jay Hainline KA9CFD
Colchester, IL EN40om

-Original Message- 
From: KI7MT
Sent: Wednesday, June 24, 2015 17:53
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] Building Hamlib3 question

Hi Jay,

I just updated the script in SVN.

To test, do another JTSDK update, close / re-open JTSDK-MSYS, and try to
build Hamlib3 again.

73's
Greg, KI7MT


On 06/24/2015 11:49 AM, Jay Hainline wrote:
 I don’t know how to edit that or where. I am not a programmer!


 Jay Hainline KA9CFD
 Colchester, IL EN40om

 -Original Message- 
 From: Michael Black
 Sent: Wednesday, June 24, 2015 17:20
 To: 'WSJT software development'
 Subject: Re: [wsjt-devel] Building Hamlib3 question

 All the $HOME references should be $HOME in the shell scripts
 I do believe that will fix the problem.

 Jay..there are two $HOME references in msys-build-hamlib3.sh which you can
 change to $HOME and test to see if it works for you.

 73
 Mike W9MDB

 -Original Message-
 From: KI7MT [mailto:ki...@yahoo.com]
 Sent: Wednesday, June 24, 2015 12:07 PM
 To: wsjt-devel@lists.sourceforge.net
 Subject: Re: [wsjt-devel] Building Hamlib3 question

 Hi Jay,

 Is your Windows username Jay or Jay Hainline with a space ? If it's 
 the
 the latter, I'll have to research how to work around this, as path names
 with a space in them are a bit of a pain when using *Nix based apps on
 Windows.JTSDK-QT/PY are all Windows shell scripts, whereas, JTSDK-DOC / 
 MSYS
 are not.

 73's
 Greg, KI7MT

 On 06/24/2015 09:11 AM, Jay Hainline wrote:
 Sorry Greg, it did not fix it. When I type build-hamlib3, I get this:


 /scripts/msys-build-hamlib3.sh: line 124: cd: /home/Jay: No such file
 or directory


 Jay Hainline KA9CFD
 Colchester, IL EN40om

 -Original Message-
 From: KI7MT
 Sent: Wednesday, June 24, 2015 14:53
 To: wsjt-devel@lists.sourceforge.net
 Subject: Re: [wsjt-devel] Building Hamlib3 question

 Hi Jay,

 The problem was an issue in one of the updates I had made. It has been
 corrected and you should be able to update JTSDK to correct it.

 To Update:

 Got Start  Programs  JTSDK  Tools  Maintenance

 At the prompt, type: update followed by upgrade

 Then re-launch JTSDK-MSYS to rebuild Hamlib3.

 If this doesn't resolve it for you, let me know and I'll have a closer
 look.

 73's
 Greg, KI7MT


 On 06/24/2015 07:02 AM, Jay Hainline wrote:
 Thanks for the reply Bill. I will heed your advice and not worry
 about it for now. I am able to build the various WSJT programs without
 any issues.

 73 Jay

 Jay Hainline KA9CFD
 Colchester, IL EN40om

 -Original Message-
 From: Bill Somerville
 Sent: Wednesday, June 24, 2015 12:57
 To: wsjt-devel@lists.sourceforge.net
 Subject: Re: [wsjt-devel] Building Hamlib3 question

 On 24/06/2015 13:50, Jay Hainline wrote:

 Hi Jay,
 pwd gives me this:

 /home/Jay Hainline

 I assume this means the software is looking for just Jay for the
 directory name rather than my full name which is what my Windows 7
 computer uses.
 Is
 there an easy way to change directory names without having to do a
 complete uninstall/install??
 Looks like there is insufficient quoting of directory paths in that
 part of the JTSDK scripts, this causes paths with spaces to be
 misinterpreted as multiple tokens where they should be treated as one
 token. I would think that the required changes to the script are
 fairly trivial so I would hold off reinstalling or creating a new
 account on your machine for now.

 Attempting to change the home directory path is probably tricky and I
 would not recommend doing that as you will probably be plagued with
 downstream problems :(

 73 Jay

 Jay Hainline KA9CFD
 Colchester, IL EN40om
 73
 Bill
 G4WJS.
 -Original Message-
 From: Michael Black
 Sent: Tuesday, June 23, 2015 18:22
 To: 'WSJT software development'
 Subject: Re: [wsjt-devel] Building Hamlib3 question

 What you start JTSDK-MSYS do a pwd and see what directory you are in.
 Sounds like you may need to either update or reinstall JTSDK.


 -Original Message-
 From: Jay Hainline [mailto:ka9...@mtcnow.net]
 Sent: Tuesday, June 23, 2015 10:40 AM
 To: wsjt-devel@lists.sourceforge.net
 Subject: [wsjt-devel] Building Hamlib3 question

 Following the readme instructions, it says I should re-build hamlib3
 often as it receives frequent updates. When I try to do
 build-hamlib3 from JTSDK-MSYS, I get a message that says:

 /scripts/msys-build-hamlib3.sh: line 124: cd: /home/Jay: No such
 file or directory

 Does this mean there is nothing to upgrade or is there a problem
 with my install, or has something been changed and the readme file
 has not been updated?

 I have had no problem in building WSJT-X from JTSDK-QT.

 73 Jay

 Jay Hainline KA9CFD
 Colchester, IL EN40om

 --
  Monitor 25 network devices

Re: [wsjt-devel] Building Hamlib3 question

[Jay Hainline]

I don’t know how to edit that or where. I am not a programmer!


Jay Hainline KA9CFD
Colchester, IL EN40om

-Original Message- 
From: Michael Black
Sent: Wednesday, June 24, 2015 17:20
To: 'WSJT software development'
Subject: Re: [wsjt-devel] Building Hamlib3 question

All the $HOME references should be $HOME in the shell scripts
I do believe that will fix the problem.

Jay..there are two $HOME references in msys-build-hamlib3.sh which you can
change to $HOME and test to see if it works for you.

73
Mike W9MDB

-Original Message-
From: KI7MT [mailto:ki...@yahoo.com]
Sent: Wednesday, June 24, 2015 12:07 PM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] Building Hamlib3 question

Hi Jay,

Is your Windows username Jay or Jay Hainline with a space ? If it's the
the latter, I'll have to research how to work around this, as path names
with a space in them are a bit of a pain when using *Nix based apps on
Windows.JTSDK-QT/PY are all Windows shell scripts, whereas, JTSDK-DOC / MSYS
are not.

73's
Greg, KI7MT

On 06/24/2015 09:11 AM, Jay Hainline wrote:
 Sorry Greg, it did not fix it. When I type build-hamlib3, I get this:


 /scripts/msys-build-hamlib3.sh: line 124: cd: /home/Jay: No such file
 or directory


 Jay Hainline KA9CFD
 Colchester, IL EN40om

 -Original Message-
 From: KI7MT
 Sent: Wednesday, June 24, 2015 14:53
 To: wsjt-devel@lists.sourceforge.net
 Subject: Re: [wsjt-devel] Building Hamlib3 question

 Hi Jay,

 The problem was an issue in one of the updates I had made. It has been
 corrected and you should be able to update JTSDK to correct it.

 To Update:

 Got Start  Programs  JTSDK  Tools  Maintenance

 At the prompt, type: update followed by upgrade

 Then re-launch JTSDK-MSYS to rebuild Hamlib3.

 If this doesn't resolve it for you, let me know and I'll have a closer
look.

 73's
 Greg, KI7MT


 On 06/24/2015 07:02 AM, Jay Hainline wrote:
 Thanks for the reply Bill. I will heed your advice and not worry
 about it for now. I am able to build the various WSJT programs without
any issues.

 73 Jay

 Jay Hainline KA9CFD
 Colchester, IL EN40om

 -Original Message-
 From: Bill Somerville
 Sent: Wednesday, June 24, 2015 12:57
 To: wsjt-devel@lists.sourceforge.net
 Subject: Re: [wsjt-devel] Building Hamlib3 question

 On 24/06/2015 13:50, Jay Hainline wrote:

 Hi Jay,
 pwd gives me this:

 /home/Jay Hainline

 I assume this means the software is looking for just Jay for the
 directory name rather than my full name which is what my Windows 7
 computer uses.
 Is
 there an easy way to change directory names without having to do a
 complete uninstall/install??
 Looks like there is insufficient quoting of directory paths in that
 part of the JTSDK scripts, this causes paths with spaces to be
 misinterpreted as multiple tokens where they should be treated as one
 token. I would think that the required changes to the script are
 fairly trivial so I would hold off reinstalling or creating a new
 account on your machine for now.

 Attempting to change the home directory path is probably tricky and I
 would not recommend doing that as you will probably be plagued with
 downstream problems :(

 73 Jay

 Jay Hainline KA9CFD
 Colchester, IL EN40om
 73
 Bill
 G4WJS.
 -Original Message-
 From: Michael Black
 Sent: Tuesday, June 23, 2015 18:22
 To: 'WSJT software development'
 Subject: Re: [wsjt-devel] Building Hamlib3 question

 What you start JTSDK-MSYS do a pwd and see what directory you are in.
 Sounds like you may need to either update or reinstall JTSDK.


 -Original Message-
 From: Jay Hainline [mailto:ka9...@mtcnow.net]
 Sent: Tuesday, June 23, 2015 10:40 AM
 To: wsjt-devel@lists.sourceforge.net
 Subject: [wsjt-devel] Building Hamlib3 question

 Following the readme instructions, it says I should re-build hamlib3
 often as it receives frequent updates. When I try to do
 build-hamlib3 from JTSDK-MSYS, I get a message that says:

 /scripts/msys-build-hamlib3.sh: line 124: cd: /home/Jay: No such
 file or directory

 Does this mean there is nothing to upgrade or is there a problem
 with my install, or has something been changed and the readme file
 has not been updated?

 I have had no problem in building WSJT-X from JTSDK-QT.

 73 Jay

 Jay Hainline KA9CFD
 Colchester, IL EN40om

 --
  Monitor 25 network devices or servers for free with
 OpManager!
 OpManager is web-based network management software that monitors
 network devices and physical  virtual servers, alerts via email  sms
 for fault. Monitor 25 devices for free with no restriction. Download
 now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
 ___
 wsjt-devel mailing list
 wsjt-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wsjt-devel



 --
  Monitor 25 network

Re: [wsjt-devel] Summary of wsprnet.org server processing times

[Jay Hainline]

The real time waterfall is a big help when running a mode like WSPR-15 which 
is still being used by the lowfer experimenters testing transatlantic 
propagation. I welcome any development of consolidating the various programs 
into one.

73 Jay

Jay Hainline KA9CFD
Colchester, IL EN40om

-Original Message- 
From: KI7MT
Sent: Wednesday, April 22, 2015 18:26
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] Summary of wsprnet.org server processing times

Hi Joe,

FWIW, I think this is a good Idea. I addition to the Hamlib updates, I
would think the Qt Audio subsystem would also be of benefit.

I like Python, but keeping the tool-chains and frameworks similar would
surely be a plus and may even draw more developers to the project(s).

There seems to be allot of folks that like the RTW (Real Time Water
Fall) WSPR-X provides. I'm not sure about IQ support, but I see a fare
number of questions asked about that also.

73's
Greg, KI7MT

On 4/22/2015 7:17 AM, Joe Taylor wrote:
 Hi John,

 Many thanks for sharing your interesting results on processing time
 returned by the wsprnet.org server!

 Your recent work with WSPR-X has prodded me to think again about
 possible future developments of WSPR.  I'm presently leaning toward
 exploring the possibility of including WSPR as a selection on the WSJT-X
 Mode menu, so as to capitalize on the extensive rig-control
 capabilities that are now part of WSJT-X.  Obviously some things would
 need to be added to the program -- WSPR message generator, WSPR decoder,
 WSPRnet reporting, some additions to the user interface, etc.  But much
 of the program's structure would carry over directly for WSPR use, and
 it could be easier for us to maintain one program rather than two.
 (It's actually three programs now, or even four -- WSPR 2.12, WSPR 4.0,
 and WSPR-X, in addition to WSJT-X.)

 Comments on this possible course of action would be welcome, from anyone!

 -- 73, Joe, K1JT

 On 4/10/2015 3:25 PM, John C. Peterson wrote:

 As part of the work I have been doing on WSPR-X, I enabled some
 debugging statements. One of them saves the processing time returned by
 the wsprnet.org server when (my) spots are reported. Note that this
 is the time wsprnet.org reports that it used to just store the spot
 info in it's database, the network transit time is NOT included in the
 numbers below. I thought it would be helpful to share that info here.

 Anyhow, the wsprnet.org server is a bit of a victim of it's own
 success. Typical processing times are around 40-60 milliseconds, but
 on occasion can be as long as 25000 milliseconds. The changes I
 made to WSPR-X will timeout a connection after 90 seconds (although
 many of those spots still get into the database OK anyway).

 I have attached a PNG graphic that summarizes all the wsprnet.org
 processing times. Because the times span 3 orders of magnitude, the
 vertical axis is logarithmic scaled to see the detail. (If it does
 not make it through mailman, I will be posting the same info to
 wsprnet.org shortly which handles attachments OK).

 Here is a histogram of the data, which should format OK here;

 Summary of wsprnet.org server processing times

 Time Int (ms)  Raw Count Percentage
 -  --- --
 [0,   30)0   0.00
 [   30,   40)   31   0.46
 [   40,   50) 1238  18.38
 [   50,   60) 3045  45.20
 [   60,   70)  727  10.79
 [   70,   80)  222   3.30
 [   80,   90)  138   2.05
 [   90,  100)   65   0.96
 [  100,  120)   70   1.04
 [  120,  140)   61   0.91
 [  140,  160)   20   0.30
 [  160,  180)   28   0.42
 [  180,  200)   22   0.33
 [  200,  300)   89   1.32
 [  300,  400)   78   1.16
 [  400,  500)   59   0.88
 [  500,  600)   44   0.65
 [  600,  700)   35   0.52
 [  700,  800)   25   0.37
 [  800,  900)   14   0.21
 [  900, 1000)   16   0.24
 [ 1000, 2000)  172   2.55
 [ 2000, 3000)  116   1.72
 [ 3000, 4000)   87   1.29
 [ 4000, 5000)   85   1.26
 [ 5000, 6000)   84   1.25
 [ 6000, 7000)   67   0.99
 [ 7000, 8000)   34   0.50
 [ 8000, 9000)   14   0.21
 [ 9000,1)   10   0.15
 [1,15000)   16   0.24
 [15000,2)5   0.07
 [2,25000)7   0.10
 [25000,  inf)   12   0.18
  ---
 Total Spots   6736

 wsprnet.org responded with 'I cannot connect to the database' 41 times.

 --
 BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
 Develop your own process in accordance with the BPMN 2 standard
 Learn Process modeling best practices with Bonita BPM through

Re: [wsjt-devel] psk reporter

[Jay Hainline]

Doh! Nevermind, I just figured it out. Sorry for the bandwidth.

73 Jay

Jay Hainline KA9CFD
Colchester, IL EN40om

-Original Message- 
From: Jay Hainline
Sent: Monday, February 23, 2015 13:37
To: WSJT software development
Subject: Re: [wsjt-devel] psk reporter

While on the subject of psk reporter, is there a way for WSJT-x report to
the site your antenna info?


Jay Hainline KA9CFD
Colchester, IL EN40om

-Original Message- 
From: Bill Somerville
Sent: Monday, February 23, 2015 13:32
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] psk reporter


On 23/02/2015 12:51, richard stanley wrote:

Hi
Hi Richard,


Has the way wsjtx sends reports/version to the psk reporter website changed
?.
Yes it has.

Normall it say for example
WSJT-X r4978 ARMv7 1 DG0OPK   WSJT-X r4978-dirty 1 KK1D   WSJT-X r4982 2
W9MDB, M0CLZ   WSJT-X r4982 ARMv7 1 DG0OPK   WSJT-X r4986 ARMv7 1 DG0OPK

Now it seems to send much more information is
WSJT-X v1.4.0-rc3 r4984 by K1JT 1 NO5J   WSJT-X v1.5.0-devel by K1JT 1 KI7MT
WSJT-X v1.5.0-devel r4986 by K1JT 9
WSJT-X - 2e0nce v1.5.0-devel r4986 by K1JT 1 2E0NCE

As you can see my wife 2e0nce has her own line as I call using
wsjtx.exe --rig-name=2e0nce
As if she was another radio so she gets her own logbook.
I can see the statistics part of the psk reporter website getting  filled up
with this as they keep the data for 7 days and I am always testing new
releases and she likes jt65 as she cannot get mike shy.
Also i’m sure that other people use it for different radios.
I agree, the inclusion of the --rig-name=text 'text' part is unnecessary,
I will sort that out.

The intention was to make it clear which version is being used, the svn
changeset number is valuable to see who is using/testing various generations
but alone it is not helpful since it doesn't include  branch information.

I also intend to ask Philip N1DQ about a small change in the way that the
stats page sorts the data.


Just curious

Richard m0clz


73
Bill
G4WJS.






--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk





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



--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] decoding time slowing down in WSJT-x

[Jay Hainline]

I rebooted my computer and it seemed to help with the decoding speed. I will 
watch and see. Thanks.

73 Jay

Jay Hainline KA9CFD
Colchester, IL EN40om

-Original Message- 
From: Joe Taylor
Sent: Monday, February 23, 2015 17:18
To: WSJT software development
Subject: Re: [wsjt-devel] decoding time slowing down in WSJT-x

Hi Jay,

Decoding speed (measured by the time the blue background stays on) is
strongly dependent on the data being decoded.

If you find significant changes over time for decoding *identical* data
-- say, data in a recorded *.wav file -- I would take the report
seriously enough to investigate further.

Otherwise, not so much...

-- Joe, k1JT

On 2/23/2015 12:06 PM, Jay Hainline wrote:
 It does not appear to speed up when restarting the program. It has gotten
 slower since when I first installed it over time.

 Jay Hainline KA9CFD

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel



--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] decoding time slowing down in WSJT-x

[Jay Hainline]

I have noticed over time that the decoding speed seems to be slowing down 
with the decode button staying lit for longer periods. I am currently using 
the latest WSJT suite with WSJT-X v1.5.0-devel r4978. Computer is a Windows 
7 64 bit with an AMD quad processor. I wonder if anyone else has noticed the 
same? Would it be slowing down from checking the log file for new dxcc? The 
2 versions prior was very speedy in decoding.

73 Jay

Jay Hainline KA9CFD
Colchester, IL EN40om



--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] decoding time slowing down in WSJT-x

[Jay Hainline]

It does not appear to speed up when restarting the program. It has gotten 
slower since when I first installed it over time.

Jay Hainline KA9CFD
Colchester, IL EN40om

-Original Message- 
From: Bill Somerville
Sent: Monday, February 23, 2015 16:52
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] decoding time slowing down in WSJT-x

On 23/02/2015 16:36, Jay Hainline wrote:

Hi Jay,
 I have noticed over time that the decoding speed seems to be slowing down
 with the decode button staying lit for longer periods. I am currently 
 using
 the latest WSJT suite with WSJT-X v1.5.0-devel r4978. Computer is a 
 Windows
 7 64 bit with an AMD quad processor. I wonder if anyone else has noticed 
 the
 same? Would it be slowing down from checking the log file for new dxcc? 
 The
 2 versions prior was very speedy in decoding.
Is the slow down across one session i.e. does restarting the application
cause it to speed up again?

You can eliminate worked B4 and country name lookups as a cause of slow
downs simply by turning the feature off in the settings. I would be
fairly surprised if the lookups are the cause since they use logarithmic
complexity searches for the big ones rather than linear and should scale
well with logbook size.

 73 Jay

 Jay Hainline KA9CFD
 Colchester, IL EN40om
73
Bill
G4WJS.



 --
 Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
 from Actuate! Instantly Supercharge Your Business Reports and Dashboards
 with Interactivity, Sharing, Native Excel Exports, App Integration  more
 Get technology previously reserved for billion-dollar corporations, FREE
 http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk
 ___
 wsjt-devel mailing list
 wsjt-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wsjt-devel


--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel



--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] radio command issue using WSJT-x

[Jay Hainline]

Ah ok Bill. Then I think the focus is on Commander at this point and will 
look into that.

73 Jay

Jay Hainline KA9CFD
Colchester, IL EN40om

-Original Message- 
From: Bill Somerville
Sent: Tuesday, December 30, 2014 16:10
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] radio command issue using WSJT-x

On 30/12/2014 15:42, Jay Hainline wrote:

Hi Jay,
 OK. I am just using the rig control built into WSJT-x now. And it is not
 remembering which antenna port when switching bands from an HF band such 
 as
 10 meters to 6 meters and back. I think I need a CAT command to tell it to
 switch antenna ports when I go to 6 meters and the HF bands for both 
 VFO's.
 That may be the same for Commander also.
No, the correct way for the program to do this is to send a band change
command before setting the frequency when moving to a new band.
Commander is supposed to be doing that already. WSJT-X using Hamlib will
at some point in the future.



 Jay Hainline KA9CFD
 Colchester, IL EN40om
73
Bill
G4WJS.

 -Original Message-
 From: Bill Somerville
 Sent: Tuesday, December 30, 2014 15:36
 To: wsjt-devel@lists.sourceforge.net
 Subject: Re: [wsjt-devel] radio command issue using WSJT-x

 On 30/12/2014 15:29, Jay Hainline wrote:

 Hi Jay,
 I am going to turn Commander off and reconfigure the Rig control in 
 WSJT-x
 for the Yaesu and see if it works. That will isolate the problem.  On the
 band stacking question, I think the answer is no. I only have the 6 meter
 antenna connected to the antenna 2 port. So it should be selecting 
 antenna
 1
 when I am on the hf bands.
 OK, WSJT-X using Hamlib for a direct connection to the rig definitely
 doesn't send and band change commands so if that improves matters it
 will be useful to know.


 Jay Hainline KA9CFD
 Colchester, IL EN40om
 73
 Bill
 G4WJS.
 -Original Message-
 From: Bill Somerville
 Sent: Tuesday, December 30, 2014 15:17
 To: wsjt-devel@lists.sourceforge.net
 Subject: Re: [wsjt-devel] radio command issue using WSJT-x

 On 30/12/2014 15:08, Jay Hainline wrote:

 Hi Jay,
 Yes the 2nd VFO is on the correct band.
 OK, then possibly Commander is sending too many band change commands,
 sending a band change command when already on the band will cycle around
 the band stacking registers. Is it possible that you have different
 aerials selected for one or more of the band stacking registers on the
 target band?

 If you are familiar with the Yaesu CAT language it is possible to
 monitor the CAT conversation using the Msgs screen.

 Jay Hainline KA9CFD
 Colchester, IL EN40om
 73
 Bill
 G4WJS.
 -Original Message-
 From: Bill Somerville
 Sent: Tuesday, December 30, 2014 14:49
 To: wsjt-devel@lists.sourceforge.net
 Subject: Re: [wsjt-devel] radio command issue using WSJT-x

 On 30/12/2014 14:11, Jay Hainline wrote:

 Hi Jay,
 I am having an issue with my radio switching the 2nd VFO to Antenna 2
 position instead of keeping it on antenna 1 when using WSJT-X on the HF
 bands. I don’t know if this is a rig control problem in WSJT-x or in 
 the
 DXlabs Commander program. Here is my set up:

 Radio: Yaesu FT-2000
 WSJT software: WSJT-X v1.5.0-devel r4831
 Logging software: DXlabs with Commander ver. 11.1.5 for rig control.
 Also
 using JTAlertX 2.5.5

 Radio has HF antenna connected to Antenna 1, 6 meter antenna on Antenna
 2.

 When I am on HF, the radio shows both VFO's are on ANT 1. But if I fire
 up
 WSJT-X and try and transmit, the 2nd (transmit) VFO switches to ANT 2. 
 I
 am
 able to get it back on ANT 1 by turning off the 2nd VFO and hold the
 SPLIT
 button in to reactivate it. Then it will transmit on ANT 1.
 Yaesu complicate things a bit by having band change commands as well as
 frequency set commands in their CAT protocol. The band change commands
 restore the last used aerial, AGC, pre-amp and, attenuator settings for
 the target band. The frequency change commands do not do that, they just
 leave the settings as is.

 DX Lab Suite Commander recently changed to do the right band change
 command before setting a frequency, this means that once you have the
 right aerial and other settings for a band they should always be
 restored when you return to that band.

 If you do not use Commander as an intermediary this will not happen, for
 now, but this is considered a defect that will eventually be rectified.

 I suspect that Commander is not quite right yet and is not using the
 correct band change command on the split Tx VFO. Does the problem you
 are seeing still occur if the split Tx VFO is already on the right band?
 I hope that explains it. If this message needs to go to another list,
 please
 let me know.

 73 Jay

 Jay Hainline KA9CFD
 Colchester, IL EN40om
 73
 Bill
 G4WJS.

 --
 Dive into the World of Parallel Programming! The Go Parallel Website,
 sponsored by Intel and developed in partnership with Slashdot Media, is
 your
 hub for all things

Re: [wsjt-devel] WSJT Application Suite Installer ( Win32 )

[Jay Hainline]

I am still getting an error when running WSJT10 from the suite. The program 
will run for a couple of minutes then freeze up. I copied a print screen to 
my dropbox folder to show. I have no clue why it is doing it.

https://www.dropbox.com/s/p5c6cu7ymtkhkgl/wsjterror.jpg?dl=0


Jay Hainline KA9CFD
Colchester, IL EN40om

-Original Message- 
From: KI7MT
Sent: Friday, December 05, 2014 00:49
To: WSJT software development ; wsjtgroup ; ws...@yahoogroups.com ; 
hama...@yahoogroups.com.au
Subject: Re: [wsjt-devel] WSJT Application Suite Installer ( Win32 )

Hello All,

[UPDATE-2]

First, thanks for all the feedback, it's helped me catch  correct many
issues with the JTSDK v2 setup. Your testing is very much appreciated.

Most of the changes made today were to build scripts and a couple
Makefile changes. As a result, all 5 apps have been re-built  repackaged.

Folder: https://sourceforge.net/projects/jtsdk/files/win32/2.0.0/
Latest File: WSJT-Suite-1.0.6-Win32.exe

I would recommend un-installing any previous version of WSJT-Suite to
ensure the build system changes are working as expected. I'll send a
separate message about JTSDK v2 updates.


73's
Greg, KI7MT



--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT Application Suite Installer ( Win32 )

[Jay Hainline]

Thanks Greg. The stand alone version off of K1JT's web site works fine. So 
something is different. Glad somebody else gets the error besides me hi.

73 Jay

Jay Hainline KA9CFD
Colchester, IL EN40om

-Original Message- 
From: KI7MT
Sent: Friday, December 05, 2014 13:28
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] WSJT Application Suite Installer ( Win32 )

Hi Jay,

I didn't catch the fact the error was in FSK441 mode before. I was
testing JT65A trying to get it to fail, which it did not. However, I'm
getting the same exact error message if I leave the mode set to 441, it
only takes a minute or two.

I'll have to do digging on this one as I'm certainly not an FSK441
expert, but it may be down to the Pillow version being used, not sure.
JTSDK-PY is using 2.3 and JTSDK v2 is using 2.6. That part I can do some
testing on.

73's
Greg, KI7MT



--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT Application Suite Installer ( Win32 )

[Jay Hainline]

I am getting an error when running WSJT10 from the suite. Attach is a 
screenshot of the command line window. WSJT10 runs ok from K1JT's web site.

Jay Hainline KA9CFD
Colchester, IL EN40om

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel