Re: [wsjt-devel] WSJT-X New Feature request - de Joe wa6axe

[Joe WA6AXE]

Bill,


Mni Tnx  - much appreciate the info and your response.


73 Joe



From: Bill Somerville 
Sent: Tuesday, August 8, 2017 6:01 PM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] WSJT-X New Feature request - de Joe wa6axe

On 08/08/2017 23:18, Joe WA6AXE wrote:

Hello WSJT-X Developers,


I respectfully have a new feature request for WSJT-X.


Currently,  the WSJT-X program help files say:


The log file wsjtx_log.adi is updated whenever you log a QSO from WSJT-X. (Keep 
in mind that if you erase this file you will lose all “worked before” 
information.)

What I would like to see is ANOTHER (temporary) adi file that has the same info 
as the  wsjtx_log.adi file - BUT, this
new file CAN BE DELETED - without affecting anything else within WSJT-X program 
functions.

Background:  I have made a BRIDGE that auto-logs WSJT-X QSOs into the DXbase2007
Logging Program.  I am currently using the info from the wsjtx_log.adi file - 
but,
I do delete the wsjtx_log.adi file after reading it.. BUMMER for the guys who
want to use the “worked before” information.

I do not know if you all reply to these emails??  Thank you in advance!

73 Joe Glockner, WA6AXE, Sherman, TX

HI Joe,

if you have access to the DXbase2007 log file then it should be trivial to 
ignore duplicates and then you don't have to delete the WSJT-X log file which 
is a user file and not really yours to delete.

OTOH, the recommended way to get real time logging information from WSJT-X is 
via the UDP messages it sends, that way you get them as they happen which is 
what I would expect a "bridge" application to do.

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] WSJT-X New Feature request - de Joe wa6axe

[Bill Somerville]

On 08/08/2017 23:18, Joe WA6AXE wrote:


Hello WSJT-X Developers,


I respectfully have a new feature request for WSJT-X.


Currently,  the WSJT-X program help files say:


The log file |wsjtx_log.adi| is updated whenever you log a QSO from 
/WSJT-X/. (Keep in mind that if you erase this file you will lose all 
“worked before” information.)


What I would like to see is ANOTHER (temporary) adi file that has the 
same info as the  wsjtx_log.adi file - BUT, this
new file CAN BE DELETED - without affecting anything else within 
WSJT-X program functions.


Background:  I have made a BRIDGE that auto-logs WSJT-X QSOs into the 
DXbase2007
Logging Program.  I am currently using the info from the 
|wsjtx_log.adi| file - but,
I do delete the |wsjtx_log.adi| file after reading it.. BUMMER for the 
guys who

want to use the “worked before” information.

I do not know if you all reply to these emails??  Thank you in advance!

73 Joe Glockner, WA6AXE, Sherman, TX


HI Joe,

if you have access to the DXbase2007 log file then it should be trivial 
to ignore duplicates and then you don't have to delete the WSJT-X log 
file which is a user file and not really yours to delete.


OTOH, the recommended way to get real time logging information from 
WSJT-X is via the UDP messages it sends, that way you get them as they 
happen which is what I would expect a "bridge" application to do.


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

[Black Michael via wsjt-devel]

Thinking about this a bit more...if we put the capability into a resource file 
then users won't have the ability to customize or play with it without 
compiling wsjt-x.  That would limit the customization considerably.



  From: Bill Somerville 
 To: wsjt-devel@lists.sourceforge.net 
 Sent: Tuesday, August 8, 2017 5:11 PM
 Subject: Re: [wsjt-devel] Skins
  
 On 08/08/2017 22:58, Black Michael via wsjt-devel wrote:
  
 Was wondering how we want to integrate the skins capability/download to 
WSJT-X. 
  Do we want to include the skins under the samples download?  Or make a 
completely separate download area for it with it's own dialog? 
  I think we could add a SKINS under the samples and then subdirectories under 
that too, right?  Then just change the menu to Download Samples/Skins ?? 
  de Mike W9MDB 
 Hi Mike, sorry, I haven't had a chance to review the original patch yet, kinda 
busy with other matters right now. I assume it is just a QSS file to be loaded 
at startup, if it's not it should be, then it/they can be included in the 
resource filesystem. 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


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

[Bill Somerville]

On 08/08/2017 23:27, Black Michael via wsjt-devel wrote:
But how would it work with the resource file and the user choosing 
different skins?


Hi Mike,

same as the waterfall palettes do now, except that a user stylesheet 
could also be picked instead, read from the config directory or even 
using the -style or -stylesheet option on the command line (that is 
there for all Qt applications already).


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

[Black Michael via wsjt-devel]

Never mind, I see the QSS labeling possibilties.
But how would it work with the resource file and the user choosing different 
skins?
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] Skins

[Black Michael via wsjt-devel]

I think with stylesheets don't they apply one style to all the same Qt type?  
i.e. all QLabels, all QPushButton, etc?
That limits the customization of individual buttons for example doesn't it? de 
Mike W9MDB
  From: Bill Somerville 
 To: wsjt-devel@lists.sourceforge.net 
 Sent: Tuesday, August 8, 2017 5:11 PM
 Subject: Re: [wsjt-devel] Skins
   
 On 08/08/2017 22:58, Black Michael via wsjt-devel wrote:
  
 Was wondering how we want to integrate the skins capability/download to 
WSJT-X. 
  Do we want to include the skins under the samples download?  Or make a 
completely separate download area for it with it's own dialog? 
  I think we could add a SKINS under the samples and then subdirectories under 
that too, right?  Then just change the menu to Download Samples/Skins ?? 
  de Mike W9MDB 
 Hi Mike, sorry, I haven't had a chance to review the original patch yet, kinda 
busy with other matters right now. I assume it is just a QSS file to be loaded 
at startup, if it's not it should be, then it/they can be included in the 
resource filesystem. 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] Skins

[Black Michael via wsjt-devel]

Actually not a QSS file right now.  I'm loading individual widget stylesheets 
based on their name.
Perhaps I should explore the QSS route instead?
de Mike W9MDB
  From: Bill Somerville 
 To: wsjt-devel@lists.sourceforge.net 
 Sent: Tuesday, August 8, 2017 5:11 PM
 Subject: Re: [wsjt-devel] Skins
   
 On 08/08/2017 22:58, Black Michael via wsjt-devel wrote:
  
 Was wondering how we want to integrate the skins capability/download to 
WSJT-X. 
  Do we want to include the skins under the samples download?  Or make a 
completely separate download area for it with it's own dialog? 
  I think we could add a SKINS under the samples and then subdirectories under 
that too, right?  Then just change the menu to Download Samples/Skins ?? 
  de Mike W9MDB 
 Hi Mike, sorry, I haven't had a chance to review the original patch yet, kinda 
busy with other matters right now. I assume it is just a QSS file to be loaded 
at startup, if it's not it should be, then it/they can be included in the 
resource filesystem. 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

[wsjt-devel] WSJT-X New Feature request - de Joe wa6axe

[Joe WA6AXE]

Hello WSJT-X Developers,


I respectfully have a new feature request for WSJT-X.


Currently,  the WSJT-X program help files say:


The log file wsjtx_log.adi is updated whenever you log a QSO from WSJT-X. (Keep 
in mind that if you erase this file you will lose all “worked before” 
information.)

What I would like to see is ANOTHER (temporary) adi file that has the same info 
as the  wsjtx_log.adi file - BUT, this
new file CAN BE DELETED - without affecting anything else within WSJT-X program 
functions.

Background:  I have made a BRIDGE that auto-logs WSJT-X QSOs into the DXbase2007
Logging Program.  I am currently using the info from the wsjtx_log.adi file - 
but,
I do delete the wsjtx_log.adi file after reading it.. BUMMER for the guys who
want to use the “worked before” information.

I do not know if you all reply to these emails??  Thank you in advance!

73 Joe Glockner, WA6AXE, Sherman, TX




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

[Bill Somerville]

On 08/08/2017 22:58, Black Michael via wsjt-devel wrote:
Was wondering how we want to integrate the skins capability/download 
to WSJT-X.


Do we want to include the skins under the samples download?  Or make a 
completely separate download area for it with it's own dialog?


I think we could add a SKINS under the samples and then subdirectories 
under that too, right?  Then just change the menu to Download 
Samples/Skins ??


de Mike W9MDB


Hi Mike,

sorry, I haven't had a chance to review the original patch yet, kinda 
busy with other matters right now. I assume it is just a QSS file to be 
loaded at startup, if it's not it should be, then it/they can be 
included in the resource filesystem.


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

[wsjt-devel] Skins

[Black Michael via wsjt-devel]

Was wondering how we want to integrate the skins capability/download to WSJT-X.
Do we want to include the skins under the samples download?  Or make a 
completely separate download area for it with it's own dialog?
I think we could add a SKINS under the samples and then subdirectories under 
that too, right?  Then just change the menu to Download Samples/Skins ??
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] WSJT on DXpedition

[Jim Brown]

On 8/8/2017 10:09 AM, Ned wrote:
You might be missing the real attraction for this use of FT8 on 
DXpeditions. It's about rate and operator ease. JT65 is not fast and 
requires a lot of manual operations to make QSOs. The KH1 DXpedition 
in April 2018 is also considering to try FT8 in order to find an 
alternative to RTTY for HF Digital operation. We should probably 
discuss this sort of operating practice after the rc2 release. 


Yes.  Also, from the perspective of a station LISTENING to a DXpedition 
working RTTY, it has always seemed to me that rates for RTTY are much 
slower than for either CW or SSB, and that a rate of 60/hour isn't all 
that bad!  You've been on some trips, Ned -- your thoughts?


73, Jim K9YC



--
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] Settings refresh

[Black Michael via wsjt-devel]

FYI..He upgrade to 10.12.8 and the Refresh works now.So apparently the problem 
was with 10.9.5 and the Qt kit it had.
de Mike W9MDB

  From: Bill Somerville 
 To: wsjt-devel@lists.sourceforge.net 
 Sent: Sunday, July 30, 2017 5:32 PM
 Subject: Re: [wsjt-devel] Settings refresh
   
 On 30/07/2017 14:05, Black Michael via wsjt-devel wrote:
  
Any reason we can't re-enumerate serial ports and audio devices when Settings 
is triggered rather than restarting WSJT-X?
 Hi Mike, the only one I can think of is what to do if the currently set one is 
no longer available and subsequently the settings window is cancelled. On 
Windows for example audio devices are accessed only by an enumerator number 
rather than a device name so matching up a device name to its internal handle 
may be impossible is the device has been renamed. I am not 100% certain without 
checking the Qt code whether either is actually able to detect changes but I 
guess that is likely to be ok. 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

[wsjt-devel] Weird Niggle with 8008

[Ricky Scott W7PSK]

was answering a gent with the standar -08 report
he answered with R-09
I then sent R-08 ???

Did it with a 2nd contact right after that.

Same thing.
--
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

[Gary - K7EK via wsjt-devel]

That is good for VHF/UHF contesting but is not satisfactory in its present form 
for HF contesting unless the exchanges can be  customized by the operator.

Best regards,

Gary, K7EK  (EM77at)

⁣Sent from BlueMail ​

On Aug 8, 2017, 13:29, at 13:29, Ria Jairam  wrote:
>This seems correct since this would be the format for most VHF
>contests.
>
>de N2RJ, Ria
>
>On Tue, Aug 8, 2017 at 1:13 PM, Black Michael via wsjt-devel
> wrote:
>> There is a Contest mode for MSK144 and FT8.
>>
>> But...I just tried it on local loopback and it doesn't appear autoseq
>works
>> at all for either of these Contest mode ops when both WSJT-X
>instances have
>> Contest mode enabled.
>> Just checking Contest for the CQ side doesn't appear to offer any
>shortening
>> of the interchange.
>> I'm running 1.7.1-devel r8013
>>
>> It's supposed to just send grids and not signal reports so should be
>just 4
>> transmissions..at least I think that's what it's supposed to be,
>isn't it?
>>
>> Should it be like this?  With both sides running Contest mode?
>>
>> CQ W9MDB EM49
>> W9MDB K1JT FN20
>> K1JT W9MDB 73
>> W9MDB K1JT 73
>>
>>
>> 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
>>
>
>--
>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

[Ria Jairam]

This seems correct since this would be the format for most VHF contests.

de N2RJ, Ria

On Tue, Aug 8, 2017 at 1:13 PM, Black Michael via wsjt-devel
 wrote:
> There is a Contest mode for MSK144 and FT8.
>
> But...I just tried it on local loopback and it doesn't appear autoseq works
> at all for either of these Contest mode ops when both WSJT-X instances have
> Contest mode enabled.
> Just checking Contest for the CQ side doesn't appear to offer any shortening
> of the interchange.
> I'm running 1.7.1-devel r8013
>
> It's supposed to just send grids and not signal reports so should be just 4
> transmissions..at least I think that's what it's supposed to be, isn't it?
>
> Should it be like this?  With both sides running Contest mode?
>
> CQ W9MDB EM49
> W9MDB K1JT FN20
> K1JT W9MDB 73
> W9MDB K1JT 73
>
>
> 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
>

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

[Black Michael via wsjt-devel]

There is a Contest mode for MSK144 and FT8.
But...I just tried it on local loopback and it doesn't appear autoseq works at 
all for either of these Contest mode ops when both WSJT-X instances have 
Contest mode enabled.Just checking Contest for the CQ side doesn't appear to 
offer any shortening of the interchange.I'm running 1.7.1-devel r8013
It's supposed to just send grids and not signal reports so should be just 4 
transmissions..at least I think that's what it's supposed to be, isn't it?
Should it be like this?  With both sides running Contest mode?
CQ W9MDB EM49W9MDB K1JT FN20K1JT W9MDB 73W9MDB K1JT 73

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] WSJT on DXpedition

[Ned]

Bill,

You might be missing the real attraction for this use of FT8 on 
DXpeditions. It's about rate and operator ease. JT65 is not fast and 
requires a lot of manual operations to make QSOs. The KH1 DXpedition in 
April 2018 is also considering to try FT8 in order to find an 
alternative to RTTY for HF Digital operation. We should probably discuss 
this sort of operating practice after the rc2 release.


73,

Ned/AA7A


On 8/8/2017 4:44 PM, Bill Somerville wrote:

On 08/08/2017 17:19, John Zantek wrote:

Rate is the number #1 concern as well as a few other issues.  A WSJT
exchange from an expedition perspective is a fast exchange which hams 
are

typically familiar with, such as CW and or RTTY modes.


Hi John,

just a quick initial reply, I will think more about this requirement 
and reply more fully later.


My first comment is that perhaps rate expectations should be moderate 
and the real benefit of weak signal modes like JT65/JT9/FT8 is their 
potential to exploit band conditions unable to support CW/RTTY/Phone 
QSOs. Given that then dedicating a position to weak signal modes when 
QSOs may be logged far faster with CW/RTTY/Phone will not be popular. 
OTOH if a position is idle due to no open band to run then that should 
be the cue to open up on the weak signal modes on the least marginal 
available band.


It may be worth considering operating on a non-conventional frequency 
(assuming one can be found) to try and avoid hoards of stations 
calling on frequency, although stations calling on frequency can be 
easily ignored (unlike on CW/RTTY/Phone) so maybe it's not a huge issue.


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

[George J Molnar]

Agree 100% with Ria.

FT8 in Contest Mode would be ideal for DXPeditions. Running split - of course! 
Nice thing is that a custom "CQ UP VQ9TC” meets the mode specification.


George J Molnar
Nevada, USA
KF2T  @GJMolnar





> On Aug 8, 2017, at 9:53 AM, Ria Jairam  wrote:
> 
> I think that the real appeal of FT8, apart from the weak signal
> capability is that it is a capable replacement for RTTY.
> 
> RTTY is a pain in the neck to use and provides increasingly
> diminishing returns. You can use less power on FT8 and get out better
> plus auto SEQ and prem. JT65 had the problem of 6 minutes per QSO
> which will only make angry ops worldwide if used on a DXpedition for
> anything except EME. Meanwhile 30 seconds for a QSO isn't too bad for
> FT8.
> 
> I'd probably suggest that major DXpeditions would be better off using
> a separate window instead of the regular window. This would help keep
> the QRM down.
> 
> Watching this with keen interest.
> 
> 73
> Ria, N2RJ
> 
> On Tue, Aug 8, 2017 at 12:44 PM, Bill Somerville  
> wrote:
>> On 08/08/2017 17:19, John Zantek wrote:
>>> 
>>> Rate is the number #1 concern as well as a few other issues.  A WSJT
>>> exchange from an expedition perspective is a fast exchange which hams are
>>> typically familiar with, such as CW and or RTTY modes.
>> 
>> 
>> Hi John,
>> 
>> just a quick initial reply, I will think more about this requirement and
>> reply more fully later.
>> 
>> My first comment is that perhaps rate expectations should be moderate and
>> the real benefit of weak signal modes like JT65/JT9/FT8 is their potential
>> to exploit band conditions unable to support CW/RTTY/Phone QSOs. Given that
>> then dedicating a position to weak signal modes when QSOs may be logged far
>> faster with CW/RTTY/Phone will not be popular. OTOH if a position is idle
>> due to no open band to run then that should be the cue to open up on the
>> weak signal modes on the least marginal available band.
>> 
>> It may be worth considering operating on a non-conventional frequency
>> (assuming one can be found) to try and avoid hoards of stations calling on
>> frequency, although stations calling on frequency can be easily ignored
>> (unlike on CW/RTTY/Phone) so maybe it's not a huge issue.
>> 
>> 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

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

[Ria Jairam]

That should be "auto seq and pre-made exchanges"

73
Ria, N2RJ

On Tue, Aug 8, 2017 at 12:53 PM, Ria Jairam  wrote:
> I think that the real appeal of FT8, apart from the weak signal
> capability is that it is a capable replacement for RTTY.
>
> RTTY is a pain in the neck to use and provides increasingly
> diminishing returns. You can use less power on FT8 and get out better
> plus auto SEQ and prem. JT65 had the problem of 6 minutes per QSO
> which will only make angry ops worldwide if used on a DXpedition for
> anything except EME. Meanwhile 30 seconds for a QSO isn't too bad for
> FT8.
>
> I'd probably suggest that major DXpeditions would be better off using
> a separate window instead of the regular window. This would help keep
> the QRM down.
>
> Watching this with keen interest.
>
> 73
> Ria, N2RJ
>
> On Tue, Aug 8, 2017 at 12:44 PM, Bill Somerville  
> wrote:
>> On 08/08/2017 17:19, John Zantek wrote:
>>>
>>> Rate is the number #1 concern as well as a few other issues.  A WSJT
>>> exchange from an expedition perspective is a fast exchange which hams are
>>> typically familiar with, such as CW and or RTTY modes.
>>
>>
>> Hi John,
>>
>> just a quick initial reply, I will think more about this requirement and
>> reply more fully later.
>>
>> My first comment is that perhaps rate expectations should be moderate and
>> the real benefit of weak signal modes like JT65/JT9/FT8 is their potential
>> to exploit band conditions unable to support CW/RTTY/Phone QSOs. Given that
>> then dedicating a position to weak signal modes when QSOs may be logged far
>> faster with CW/RTTY/Phone will not be popular. OTOH if a position is idle
>> due to no open band to run then that should be the cue to open up on the
>> weak signal modes on the least marginal available band.
>>
>> It may be worth considering operating on a non-conventional frequency
>> (assuming one can be found) to try and avoid hoards of stations calling on
>> frequency, although stations calling on frequency can be easily ignored
>> (unlike on CW/RTTY/Phone) so maybe it's not a huge issue.
>>
>> 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 on DXpedition

[Ria Jairam]

I think that the real appeal of FT8, apart from the weak signal
capability is that it is a capable replacement for RTTY.

RTTY is a pain in the neck to use and provides increasingly
diminishing returns. You can use less power on FT8 and get out better
plus auto SEQ and prem. JT65 had the problem of 6 minutes per QSO
which will only make angry ops worldwide if used on a DXpedition for
anything except EME. Meanwhile 30 seconds for a QSO isn't too bad for
FT8.

I'd probably suggest that major DXpeditions would be better off using
a separate window instead of the regular window. This would help keep
the QRM down.

Watching this with keen interest.

73
Ria, N2RJ

On Tue, Aug 8, 2017 at 12:44 PM, Bill Somerville  wrote:
> On 08/08/2017 17:19, John Zantek wrote:
>>
>> Rate is the number #1 concern as well as a few other issues.  A WSJT
>> exchange from an expedition perspective is a fast exchange which hams are
>> typically familiar with, such as CW and or RTTY modes.
>
>
> Hi John,
>
> just a quick initial reply, I will think more about this requirement and
> reply more fully later.
>
> My first comment is that perhaps rate expectations should be moderate and
> the real benefit of weak signal modes like JT65/JT9/FT8 is their potential
> to exploit band conditions unable to support CW/RTTY/Phone QSOs. Given that
> then dedicating a position to weak signal modes when QSOs may be logged far
> faster with CW/RTTY/Phone will not be popular. OTOH if a position is idle
> due to no open band to run then that should be the cue to open up on the
> weak signal modes on the least marginal available band.
>
> It may be worth considering operating on a non-conventional frequency
> (assuming one can be found) to try and avoid hoards of stations calling on
> frequency, although stations calling on frequency can be easily ignored
> (unlike on CW/RTTY/Phone) so maybe it's not a huge issue.
>
> 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 on DXpedition

[Bill Somerville]

On 08/08/2017 17:19, John Zantek wrote:

Rate is the number #1 concern as well as a few other issues.  A WSJT
exchange from an expedition perspective is a fast exchange which hams are
typically familiar with, such as CW and or RTTY modes.


Hi John,

just a quick initial reply, I will think more about this requirement and 
reply more fully later.


My first comment is that perhaps rate expectations should be moderate 
and the real benefit of weak signal modes like JT65/JT9/FT8 is their 
potential to exploit band conditions unable to support CW/RTTY/Phone 
QSOs. Given that then dedicating a position to weak signal modes when 
QSOs may be logged far faster with CW/RTTY/Phone will not be popular. 
OTOH if a position is idle due to no open band to run then that should 
be the cue to open up on the weak signal modes on the least marginal 
available band.


It may be worth considering operating on a non-conventional frequency 
(assuming one can be found) to try and avoid hoards of stations calling 
on frequency, although stations calling on frequency can be easily 
ignored (unlike on CW/RTTY/Phone) so maybe it's not a huge issue.


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

[wsjt-devel] WSJT on DXpedition

[John Zantek]

[Prelim: I'm posting this on the Developers reflector instead of the wider
WSJT group since I find this group has a better SNR.  If you feel it needs
the wider distribution of the latter net, please let me know - John/KE7B]

This past weekend, I attended the Pacific NW DX Convention, where the buzz
of JT/FT was tangible.  Mind you, while these folks are very accomplished
hams, as a more "experienced" WSJT operator, I often felt I was visiting
Jurassic Park.  When I mentioned I had worked 240/confirmed 236 on
JT65/JT9/FT8, I was given some creds (most had never tried these modes and
believed our community was tiny and incapable of serious DX work).  The
biggest news for me was the talk about the upcoming DXpedition to Mellish
Reef (VK9MA) and the stated intention to try JT65 and/or FT8 on one of the 5
positions.  Of course, RATE is always the #1 issue with DXpeditioners and
Contesters.  I believe this may be the first great opportunity for WSJT to
succeed for a major DXpedition.   I spent some time talking with the team
leader and others about expectations.  Not surprisingly, we cannot expect
the team to run QSOs conventionally.

Below is the summary of their thoughts.  Again, we can't insist that they
run their Q-exchanges conventionally as WSJT is designed, but they are open
to some moderated feedback.  I promised I would provide their input to the
Developers and get them a summarized response.  

SUMMARY BEGINS (Notes from team to me)

Rate is the number #1 concern as well as a few other issues.  A WSJT
exchange from an expedition perspective is a fast exchange which hams are
typically familiar with, such as CW and or RTTY modes.

Current expedition exchange(s) using CW and/or RTTY normally look like the
following:
VK9MA:  CQ CQ VK9MA {optional UP | DN }
KE7B  replying to VK9MA replies: KE7B 
VK9MA sends:  KE7B 599 
KE7B replies: 599 TU 

at this point the QSO is concluded if VK9MA replies with: 
TU QRZ VK9MA UP 
OR 
continues a bit longer if VK9MA retries/replies with: 
KE7B 599 
if VK9MA didn't receive KE7B initial reply 
at which point KE7B replies with: 
599 TU
and VK9MA sends: TU QRZ VK9MA UP 

JT65/JT9 or FT8 throws us a different curve ball in that:
1.  An FT8 exchange is automated with built in retries. therefore the
exchange is  either successful or not. Therefore we (VK9MA) don't have to
worry about retries, as the exchange will either be successful or not.
2.   JT65/JT9 exchanges can be orchestrated because users have time to
change the exchange.
3.   The users of WSJT application are trained to click on the CQ calling
station. Therefore only the really advanced users know/understand the
concept of calling UP/or DOWN in frequency.  Therefore we can expect almost
all  stations respond to the VK9MA CQ by  clicking on the VK9MA CQ in the
application and effectively responding by TX on the VK9MA  calling
frequency.
4.   WSJT application normally has KE7B initially respond to the exchange
with Grid Square which the DX station doesn't care about. 

Therefore if I would like JT65/JT9/FT8 to follow the normal CW/RTTY
expedition exchange 
1.   An Ideal exchange should follow as close to the following as possible.
VK9MA initially sends: "CQ VK9MA XX87" , note without the UP/DWN
KE7B replies anywhere in the 1-4KHz window: "VK9MA KE7B -01"
VK9MA responds: "KE7B VK9MA R-01" 
At this point the exchange is complete.  If KE7B didn't get the
VK9MA response, then he can then call again with KE7B -01...and VK9MA can
repeat "KE7B R-01". This can be integrated/automated into the WSJT FT8
application. 
VK9MA sends: "TU QRZ VK9MA"
Using this approach will be super efficient and make FT8  the GO TO
digital mode
2.   Using JT65 or JT9 the exchange should be the same, other than the users
will have to manually select the exchange using the "Next" buttons which
might be a challenge to most users. 

END SUMMARY

OK, folks.  This is the Mellish Reef team's intent for 90 days hence.  It's
now your opportunity to tell them what they can reasonably expect, what they
should and should not try, or perhaps consider for future WSJT HF
enhancement.  How Mellish goes may be groundbreaking, since propagation will
be poor, and it is a golden opportunity for WSJT to shine on a
DXer/Contester stage as well as for the newly licensed.  I welcome your
feedback.  I'll assemble and relay your voices to the VK9MA team.

73 John KE7B




--
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] Changing recipients on the fly? - 8011

[Mark Turner via wsjt-devel]

Hi Bob,

could you also look at the scenario where Tx5 is being used to send qrz, 
e.g. "QRZ EI3KD". A reply to this isn't handled well by auto-sequencing. 
In fact, when doing this, it didn't even seem to be possible to 
double-click on a caller to fill the fields, without halting tx first?


Regards, Mark

WSJT-X v1.8.0-rc2 r8011


On 08/08/2017 12:01, Bill Somerville wrote:

On 08/08/2017 11:52, R Edward wrote:
I had a problem a couple of times last night when I was calling a 
station, but then another station called me (and my original target 
had not responded). Double-clicking the new caller's call didn't 
switch messages - the program kept calling the original target. I had 
to halt TX, then double-click the new caller's callsign to set up the 
appropriate messages. Is there a way this can be automated in a 
single double-click?


Hi Bob,

auto-sequencing has introduced a whole new set of problems to be 
solved in how WSJT-X responds to user actions. I am working through 
many different operating scenarios trying to iron out the defects and 
will make sure that this one is covered.


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] Changing recipients on the fly? - 8011

[Bill Somerville]

On 08/08/2017 11:52, R Edward wrote:

I had a problem a couple of times last night when I was calling a station, but 
then another station called me (and my original target had not responded). 
Double-clicking the new caller's call didn't switch messages - the program kept 
calling the original target. I had to halt TX, then double-click the new 
caller's callsign to set up the appropriate messages. Is there a way this can 
be automated in a single double-click?


Hi Bob,

auto-sequencing has introduced a whole new set of problems to be solved 
in how WSJT-X responds to user actions. I am working through many 
different operating scenarios trying to iron out the defects and will 
make sure that this one is covered.


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

[wsjt-devel] Changing recipients on the fly? - 8011

[R Edward]

I had a problem a couple of times last night when I was calling a station, but 
then another station called me (and my original target had not responded). 
Double-clicking the new caller's call didn't switch messages - the program kept 
calling the original target. I had to halt TX, then double-click the new 
caller's callsign to set up the appropriate messages. Is there a way this can 
be automated in a single double-click?

73,

Bob Edward KH6BE
Honolulu, HI
--
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] Mac OSX sample crash

[John Nelson]

Mike,

Samples download works perfectly on Mac OSX 10.11.6 with 1.8.0-rc1 with Qt 
5.8.0.   Problem with his Mac configuration rather than WSJT-X?

— John G4KLA
--
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