Re: [wsjt-devel] Issues with WSJT-X and Flex Radio 3000

[Bill Somerville]

On 28/03/2018 19:42, Joe Taylor wrote:

On 3/28/2018 11:17 AM, K0TNT wrote:

Setup:

Program version: WSJT-X v1.90-rc3

Rig: Flex 3000 with Gateway dual core processor computer running 
Windows 10 Home 64 bit. 8 GB ram, 2.2 GHz, plenty of disk space.


Issue 1: Can't be the WSJT program to work with the Flex and PowerSDR 
2.80 (or the original 2.72) with any WSJT rig selection other than 
Kenwood TS-480 or TS-50S. The Flex SDR-1000 (only thing that appears 
in the selection window).


I'm not sure why you are describing this as an issue.  Does something 
not work as you expected when you use settings for a Kenwood radio?  I 
think TS-2000 is the preferred setting (but I'm not sure).


Hi Carl and Joe,

yes the TS-2000 is the correct Kenwood Hamlib model to use with 
Smart/Power SDR, it has special code to try and cope with the not quite 
perfect Kenwood CAT emulation.


There has been recent work on the Hamlib FlexRadio driver but I am not 
sure how good the support is for PowerSDR and it may only be functional 
with the Signature 6xxx series.


Both of these Hamlib drivers like all the others rely on users of the 
rigs in question to at least help with testing if not contributing 
patches themselves.


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] dummy rig patch

[Bill Somerville]

On 28/03/2018 20:11, Black Michael via wsjt-devel wrote:
Disable the greying out of "Monitor returns to last used frequency" 
for the "None" rig entry.


https://www.dropbox.com/s/ivkbi3dm7cb7yeu/lastmon.patch?dl=1

I can see why this was put in...but it prevents some logical 
operations when not using CAT control.


de Mike W9MDB


Hi Mike,

the reason it is disabled and forced to true for the dummy rig is so 
that restarting the application will return to the last used frequency, 
without that WSJT-X will always go to the rig's frequency which is 145.0 
MHz for the dummy rig. Simply re-enabling the option will be a backward 
step, some smarter logic will have to be designed if you want to allow 
band changes while "Monitor" is disabled.


OTOH I didn't think there was a problem. The OP should be able to do the 
following:


1 Disable "Monitor",

2 Switch bands on the rig,

3 Select the new frequency (or band if it is the standard frequency for 
the band).


That's it. Selecting a band in WSJT-X enables "Monitor", or a t least it 
used to. If it doesn't then something has been broken, and running a 
quick test proves that it is indeed broken. So rather than force all 
non-CAT users to set the frequency on start up, how about looking for 
which change stopped band changes from automatically enabling "Monitor"?


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] dummy rig patch

[Black Michael via wsjt-devel]

Disable the greying out of "Monitor returns to last used frequency" for the 
"None" rig entry.
 https://www.dropbox.com/s/ivkbi3dm7cb7yeu/lastmon.patch?dl=1
I can see why this was put in...but it prevents some logical operations when 
not using CAT control.
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] DXpedition Mode on 40 Meters?

[Hasan al-Basri]

Agreed on all counts, Gary.
73, N0AN

Hasan

On Wed, Mar 28, 2018 at 1:21 PM, Gary McDuffie  wrote:

>
>
> > On Mar 28, 2018, at 5:48 AM, Hasan al-Basri 
> wrote:
> >
> > Running DXp by the developers for testing and evaluation is justifiable.
> Releasing DXp "into the wild" with no restraints or protections from abuse
> is irresponsible.
>
> After seeing the results of “turning it loose”, I’m convinced that the
> test versions like rc3 should have a fuse that will make the software (or
> at least the DXp mode) inop after a certain date.  This would force an
> upgrade to the current thinking for its use.  I doubt this is doable with
> public software, but it would help to limit some of the abuses seen on the
> bands by non-legit DXpeditions.
>
> As an aside, I suspect that many people who are pi$$ed off about what DXp
> mode does to the spectrum will not know enough to be able to separate DXp
> from the basic mode itself, FT8.  This would perpetuate the hate that some
> seem to be generating toward 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

Re: [wsjt-devel] Issues with WSJT-X and Flex Radio 3000

[Joe Taylor]

Hi Carl,

On 3/28/2018 11:17 AM, K0TNT wrote:

Setup:

Program version: WSJT-X v1.90-rc3

Rig: Flex 3000 with Gateway dual core processor computer running Windows 
10 Home 64 bit. 8 GB ram, 2.2 GHz, plenty of disk space.


Issue 1: Can't be the WSJT program to work with the Flex and PowerSDR 
2.80 (or the original 2.72) with any WSJT rig selection other than 
Kenwood TS-480 or TS-50S. The Flex SDR-1000 (only thing that appears in 
the selection window).


I'm not sure why you are describing this as an issue.  Does something 
not work as you expected when you use settings for a Kenwood radio?  I 
think TS-2000 is the preferred setting (but I'm not sure).


Issue 2: Since my computer is an 8 year old dual core, I have observed 
that if the CPU % usage goes above 35%, WSJT-X will almost always fail 
to automatically begin the decode process after 13-14 seconds into the 
cycle has begun. If I have the PoweSDR window open to full screen and 
any of the panadapter options selected, the program won't decode. But if 
I minimize the PowerSDR screen and set the panadapter screen selectioin 
to off, decode occurs nearly 90% of the time. (Not seeing the 
panadapter's various idisplay options isn't significant since the WSJT 
screen displays whatever I need to see.)


You're asking your 8-year-old computer to do heavy numerical lifting 
simultaneously in two programs, each with real-time requirements.  It 
sounds like you need more computer horsepower, especially if you want to 
use wide bandwidths, full-screen displays, etc.


You might want to correspond with other Flex 3000 users.

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

Re: [wsjt-devel] DXpedition Mode on 40 Meters?

[Gary McDuffie]

> On Mar 28, 2018, at 5:48 AM, Hasan al-Basri  wrote:
> 
> Running DXp by the developers for testing and evaluation is justifiable. 
> Releasing DXp "into the wild" with no restraints or protections from abuse is 
> irresponsible. 

After seeing the results of “turning it loose”, I’m convinced that the test 
versions like rc3 should have a fuse that will make the software (or at least 
the DXp mode) inop after a certain date.  This would force an upgrade to the 
current thinking for its use.  I doubt this is doable with public software, but 
it would help to limit some of the abuses seen on the bands by non-legit 
DXpeditions.

As an aside, I suspect that many people who are pi$$ed off about what DXp mode 
does to the spectrum will not know enough to be able to separate DXp from the 
basic mode itself, FT8.  This would perpetuate the hate that some seem to be 
generating toward 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

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

[Hasan al-Basri]

Excellent, Look forward to it, Joe.
73, N0AN

Hasan

On Wed, Mar 28, 2018 at 12:35 PM, Joe Taylor  wrote:

> 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 follows:
>>
>> DateUTC   Frequency Fox callsign  Operator
>> ---
>> April 7  1400   14.105 MHzW1/KH7Z   N1DG
>> April 7  1500   14.105W7/KH7Z  

Re: [wsjt-devel] Cannot make lasting change to band while not in "Monitor" mode

[Gary McDuffie]

> On Mar 28, 2018, at 11:16 AM, Black Michael via wsjt-devel 
>  wrote:
> 
> Turn off "Monitor returns to last used frequency" in Settings/General.

I have a similar problem to his, Mike, but that setting is completely greyed 
out on my non CAT version.  I’m running two radios, one full CAT and one 
strictly manual for monitoring a second band.  The second one will not allow 
turning that function off.  I am always afraid I’ll be too slow in getting the 
band changed before a report is sent to pskreporter while changing bands.

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

Re: [wsjt-devel] Alternative FT8 DXpedition mode freqs.

[Gary McDuffie]

> On Mar 28, 2018, at 7:57 AM, George Molnar  wrote:
> 
> Granted, this accounts for just one Dxpedition at a time.

And given the explanation of what the mode is supposed to be used for, this 
would be correct.  As I read it, it isn’t for just any DXpedition to use.  Only 
the big ones like FT8ZM or similar.  “Normal” Expeditions should use the normal 
procedures.

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

Re: [wsjt-devel] Audio input from RTP stream?

[Joe Taylor]

Hi Alex,

These sound like good ideas to me.  A mechanism for sending I/Q data 
into WSJT-X has been on our back-burner "To Do" list for some time.  But 
as you can probably guess, I'm only superficially familiar with the 
protocols you're considering.  Bill will probably have a more useful 
response for you.

-- Joe, K1JT

On 3/28/2018 10:34 AM, Alex, VE3NEA wrote:

Hello developers,

I am looking into supporting the RTP+RTCP protocol in CW Skimmer, and I 
want to do this in a way compatible with other software, including 
WSJTX. RTP seems to be the best way of exchanging the I/Q data between 
the programs, but it needs to be complemented with another protocol for 
reading and setting the radio's parameters. I was thinking about using 
NDJSON over TCP for that (https://github.com/ndjson/ndjson-spec), the 
solution that worked well in my GRITTY project 
(http://dxatlas.com/Gritty/). However, Hubert, HB9JND has drawn my 
attention to the new TCI protocol (https://github.com/maksimus1210/TCI) 
that seems to have all required radio control commands, but sends I/Q 
data via TCP. Do you think it would make sense to combine RTP+RTCP (for 
data) with TCI (for commands)? Would you be interested in supporting 
this combination in WSJTX? Are there any good alternatives to this 
solution?


73 Alex VE3NEA


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

[Joe Taylor]

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

Date    UTC   Frequency Fox callsign  Operator
---
April 7  1400   14.105 MHz    W1/KH7Z   N1DG
April 7  1500   14.105    W7/KH7Z   AA7A

If last-minute instructions are necessary they will be announced on the 
"Ping Jockey Relief" chat page:

http://www.pingjockey.net/cgi-bin/pingtalkB
### 



Installation packages for Windows, Linux, Macintosh, and Raspian Jessie 
have been posted on the 

Re: [wsjt-devel] Cannot make lasting change to band while not in "Monitor" mode

[Black Michael via wsjt-devel]

DuhSo is there a reason dummy mode always returns true?
bool Configuration::monitor_last_used () const {return m_->rig_is_dummy_ || 
m_->monitor_last_used_;}

Mike

 

On Wednesday, March 28, 2018, 12:23:16 PM CDT, Joe Taylor 
 wrote:  
 
 Mike --

On 3/28/2018 1:16 PM, Black Michael via wsjt-devel wrote:
> Turn off "Monitor returns to last used frequency" in Settings/General.

Please think before hitting "Send".  He said he's not using CAT control, 
so that option is grayed out.

    -- 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] Cannot make lasting change to band while not in "Monitor" mode

[Karl Heinz Kremer]

Joe is correct, that setting is grayed out.

I just checked, and the Raspberry Pi version behaves the same way

Karl Heinz - K5KHK

On Wed, Mar 28, 2018 at 1:19 PM, Joe Taylor  wrote:

> Mike --
>
> On 3/28/2018 1:16 PM, Black Michael via wsjt-devel wrote:
>
>> Turn off "Monitor returns to last used frequency" in Settings/General.
>>
>
> Please think before hitting "Send".  He said he's not using CAT control,
> so that option is grayed out.
>
> -- 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] Cannot make lasting change to band while not in "Monitor" mode

[Joe Taylor]

Mike --

On 3/28/2018 1:16 PM, Black Michael via wsjt-devel wrote:

Turn off "Monitor returns to last used frequency" in Settings/General.


Please think before hitting "Send".  He said he's not using CAT control, 
so that option is grayed out.


-- 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] Cannot make lasting change to band while not in "Monitor" mode

[Black Michael via wsjt-devel]

Turn off "Monitor returns to last used frequency" in Settings/General.
de Mike W9MDB



 

On Wednesday, March 28, 2018, 10:59:03 AM CDT, Karl Heinz Kremer 
 wrote:  
 
 I am using FT8 with WSJT-X without CAT control (only PTT is controlled via a 
serial interface). In order to change the band (and not to report faulty 
results to PSKReporter), I have to do the following:
1. Disable transmit and monitor2. Change the band on my transmitter (and tune 
the antenna) the 
3. Enable monitor mode and right away4. Change the band in WSJT-X
It would be much safer to change the band in WSJT-X between steps 1 and 2 
because when I then perform #3, WSJT-X would already be configured for the 
correct band. 
When I perform the steps in the sequence #1, #4, #2, #3, the band selection 
performed in step #4 will be reverted to whatever was selected before I 
disabled monitor mode. 
This is with version 1.9.0rc3 on a Mac, but has worked the same way with all 
previous versions I've used. 
Thanks and 73, 
Karl Heinz - 
K5KHK--
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] FT8 for 2018 Field Day

[W4TMO via wsjt-devel]

At one point, there were 3 extra bits available in the FT8 message payload.  If 
one is still available, perhaps it could be used like this:
Add a "CONTEST" menu itemWhen clicked, an input screen something akin to this 
comes up:
    RUN Message                        S Exchange
__                    
                        ACCEPT         CANCEL
A RUN message for the NC QSO party might be NC QP W4ABC WAK
For the S Exhange, enter your county, state or DX as appropriate.  Someone in 
New York would enter NY for instance.
Click on ACCEPT and 1) a CONTEST button on the  main GUI turns GREEN alerting 
user they're in CONTEST mode and 2) the program sets one of the FT8 message 
bits.
Sequence of events when RUNning:
RUN                                       S
NC QP W4ABC WAK                                    W4ABC  W2XYZ -10 NYW4ABC -12 
73
-W2XYZ
 knows the callsign (W4ABC) and exchange (WAK) from the RUN message.  W4ABC 
then knows the station (W2XYZ), signal level (-10) and exchange (NY) from 
W2XYZ's transmissionW2XYZ then receives an acknowlegement and signal level (12) 
from W4ABC
Enough info to meet most QSO party rules for a successful QSO.
Screen layout for user input and user instructions need to be fleshed out of 
course.  No DXpedition mode!
Maybe a checkbox in S mode to only display RUN stations also in CONTEST mode? 
 Make it easier on contest participants.
Just some ideas, maybe the designers will find something useful :)
73Jim
W4TMOUSAF Retired 

On Tuesday, March 27, 2018, 8:01:33 PM EDT, Rich - K1HTV 
 wrote:  
 
  
FT8 for 2018 Field Day

Regarding the use of FT8 on Field Day, you can do what I did during the recent 
VA QSO Party, that is, use the Tx5 (73) message to send contest data. The VQP 
exchange sent was number, county & State, "nnn CUL VA 73", where 'nnn' was my 
QSO number and 'CUL' was the abbreviation for Culpeper county. The 'VA' for 
Virginia was not a contest exchange  requirement. The Tx5 message met the 13 
character maximum and ended with '73', which trigger the '73' message of the 
station being worked. I created a Tx5 macro message "000 CUL VA 73". When a QSO 
started, I simply pulled down that macro message and manually changed the 000 
to the next number in the sequence. 




Unfortunately almost no FT8 stations worked in the VA QSO Party knew how to 
send the required data. As a result I focused mainly on working DX on FT8, 
where the only a number (dB report) was required. 285 of the 287 VA QSO Party 
QSOs were with DX stations.




If a future WSJT-X release could have a check box for ""Lock Tx5 message", that 
would allow the easier use of FT8 in various contests, such as Field Day and 
State QSO parties. Once the 'Lock' box was checked, the user would type in the 
fixed contest exchange text into the Tx5 message box. It would remain there 
until the contest was over and not be overwritten when a new station was being 
worked.


Sponsors would have to explain, in their rules, how to use FT8 in their 
contest. The Field day exchange wouldn't  present any problem. However, those 
State QSO parties that presently requiring sequential QSO number exchanges 
could switch to using the dB report as the numbers exchanged.




73,
Rich - K1HTV


= = =

Jordan Sherer, KN4CRD wrote: 
 
At that very least you can use a free text message for the exchange, Don: 
"KN4CRD 1B GA"

You just won't be able to use auto sequencing when operating FT8 during field 
day.

Best,
Jordan
KN4CRD

On Mar 27, 2018, 7:40 AM -0400, Don Goldston , wrote:
Any chance that an FT8 mode that performs the required exchange of information 
for the 2018 Field Day could be 
created?

I know y'all are wrapped up in DXP mode, but thought it was worth asking.

Thanks,
 --
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] Cannot make lasting change to band while not in "Monitor" mode

[Karl Heinz Kremer]

I am using FT8 with WSJT-X without CAT control (only PTT is controlled via
a serial interface). In order to change the band (and not to report faulty
results to PSKReporter), I have to do the following:

1. Disable transmit and monitor
2. Change the band on my transmitter (and tune the antenna) the
3. Enable monitor mode and right away
4. Change the band in WSJT-X

It would be much safer to change the band in WSJT-X between steps 1 and 2
because when I then perform #3, WSJT-X would already be configured for the
correct band.

When I perform the steps in the sequence #1, #4, #2, #3, the band selection
performed in step #4 will be reverted to whatever was selected before I
disabled monitor mode.

This is with version 1.9.0rc3 on a Mac, but has worked the same way with
all previous versions I've used.

Thanks and 73,

Karl Heinz - K5KHK
--
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] Issues with WSJT-X and Flex Radio 3000

[K0TNT]

Good morning to the group. I have enjoyed using WSJT in its several 
modes but have some issues that don't seem to be solvable at my end.


Setup:

Program version: WSJT-X v1.90-rc3

Rig: Flex 3000 with Gateway dual core processor computer running Windows 
10 Home 64 bit. 8 GB ram, 2.2 GHz, plenty of disk space.


Issue 1: Can't be the WSJT program to work with the Flex and PowerSDR 
2.80 (or the original 2.72) with any WSJT rig selection other than 
Kenwood TS-480 or TS-50S. The Flex SDR-1000 (only thing that appears in 
the selection window).


Issue 2: Since my computer is an 8 year old dual core, I have observed 
that if the CPU % usage goes above 35%, WSJT-X will almost always fail 
to automatically begin the decode process after 13-14 seconds into the 
cycle has begun. If I have the PoweSDR window open to full screen and 
any of the panadapter options selected, the program won't decode. But if 
I minimize the PowerSDR screen and set the panadapter screen selectioin 
to off, decode occurs nearly 90% of the time. (Not seeing the 
panadapter's various idisplay options isn't significant since the WSJT 
screen displays whatever I need to see.)


I have been impressed with the performance of WSJT, especially FT-8. My 
antenna is a W9INN five band shortened dipole mounted in my attic and I 
can still occasionally work DX even with the current horrendous 
propagation conditions. When all other modes are dead, FT-8 gets through.


Thanks for all your efforts to bring such a great new mode to the ham 
bands.


73, Carl KØTNT


--
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] using tune button while in FT8 Hound mode

[Joe Taylor]

Hi Jay,

Thanks for noticing and reporting this seeming oddity.  It's a bug, an 
unintended consequence of a change that prevents the transmission of 
all-blank messages.  It has been corrected in code revision r8587.


-- Joe, K1JT

On 3/28/2018 9:58 AM, Jay Hainline wrote:

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] Audio input from RTP stream?

[Alex, VE3NEA]

Hello developers,

I am looking into supporting the RTP+RTCP protocol in CW Skimmer, and I want to do this in a way compatible with other software, 
including WSJTX. RTP seems to be the best way of exchanging the I/Q data between the programs, but it needs to be complemented 
with another protocol for reading and setting the radio's parameters. I was thinking about using NDJSON over TCP for that 
(https://github.com/ndjson/ndjson-spec), the solution that worked well in my GRITTY project (http://dxatlas.com/Gritty/). 
However, Hubert, HB9JND has drawn my attention to the new TCI protocol (https://github.com/maksimus1210/TCI) that seems to have 
all required radio control commands, but sends I/Q data via TCP. Do you think it would make sense to combine RTP+RTCP (for data) 
with TCI (for commands)? Would you be interested in supporting this combination in WSJTX? Are there any good alternatives to 
this solution?


73 Alex VE3NEA

--
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] 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] Alternative FT8 DXpedition mode freqs.

[George Molnar]

Regarding comments suggesting that a band plan can be implemented and enforced 
in software, I don’t think that will work. It would rely on properly engaged 
and functional CAT control by the Fox. Given that several stations have already 
“jumped the gun” and are using the mode in its incomplete form, I don’t hold 
out a lot of hope there. 

K1HTV and N0AN have made well-reasoned and prudent suggestions. It is likely 
true that whatever the dev team bakes into the software will become the de 
facto standard. It is also likely that whatever they choose will torque 
somebody off. 

Perhaps a compromise (that, of course will not please everyone) could be:

Frequency (Hz) above current FT8 lower “channel edge” --
 - 2000 FT8 operation
2001 - 4000 JT65, JT9 primary, and FT8 shared
4001 - 6000 FT8 DXpedition mode or extreme weak signal efforts for JT9 or JT65.

Granted, this accounts for just one Dxpedition at a time. Given the nature of 
the project, I would doubt there will be an effective way of preventing 
determined users from bypassing any software lockouts, etc., preventing DXp 
mode use. Education will be necessary, and, as many of our colleagues suggest, 
a healthy dose of “Ham Spirit.” Perhaps the software can feature a pop-up box 
(like the beta versions do) upon entering DXp mode, that requires 
acknowledgment, beyond just hitting enter, that the operator is running a 
recognized DXPedition? Won’t stop anyone who really wants to use it, but might 
give pause to the unknowing.




George J Molnar
Washington, DC, USA
KF2T   -   @GJMolnar








--
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] Alternative FT8 DXpedition mode freqs.

[Hasan al-Basri]

 *The WSJT-X Development Group selected the FT8 frequencies now being used
by all. I believe that after serious consideration, they should define a
recommended DXpedition mode frequencies for each HF band.  I'd further
recommend that the 'Frequencies' table be populated with these recommended
DXpedition mode frequencies. Even better, whenever the 'Fox' box is
checked, display ONLY the recommended DXpedition mode frequencies' in the
band pull down menu.*

Very constructive, Rich. I would add that if a real DXp freq plan can be
"generated", it needs to be *enforced in the software* , not just be in an
easily manipulated frequency table.

If, after due consideration of the needs of all the digital modes, a plan
can be implemented, then the place to do it is *inside *the software. Hard
code the mode/freq. If left up to users, DXp will be done wherever anyone
chooses. The choice cannot be left up to DXpeditionsthat's what started
this conversation in the first place.

73, N0AN


Hasan

On Tue, Mar 27, 2018 at 10:16 PM, Rich - K1HTV  wrote:

>
> *With all of the discussion about the QRM to 40 Meter PSK users from
> 7Q7EI's use of the FT8 DXpedition mode, it is now time to take a serious
> look at alternative DXpedition frequencies. *
>
>
> *IARU Regions 1, 2 & 3 already have drawn up 'Bandplan Recommendations'.
> You can read about their 40 Meter recommendations at:*
> *https://en.wikipedia.org/wiki/40-meter_band#Band_plans
> *
>
>
> *Recommendations for the use of 'DATA' modes are:*
> *Region #1 - 7040-7060 plus 7060-7200*
> *Region #2 - 7040-7050 plus 7050-7300*
> *Region #3 - 7025-7040 (appears to be the most restrictive, although many
> R#3 Pacific stations use 7074 for FT8)*
>
>
> *Also mentioned are:*
> *Japan - 7025-7030 plus 7030-7300*
> *USA - 7025-7125*
> *Canada - 7035-7050 (but we know that VE's use 7070 and above for the
> various digital modes)*
>
>
> *As I listen in the evening to hundreds of FT8 stations on 7074 KHz, using
> the main and Beverage antennas, I hear very few, if any, signals just above
> 7080 KHz.  I know that during the dozen of so weekends when RTTY contests
> are scheduled, these frequencies (+/- tens of KHz) are full of RTTY
> stations. But during non-contest times, these frequencies are virtual
> empty. The same can be said about 20 Meters and frequencies just above
> 14.080 KHz and 15 Meters just above 21.080 KHz. **. *
>
>
> *My suggestion would be, if possible, to have WSJT-X software inhibit the
> use of the already defined standard FT8 HF operating frequencies whenever
> the 'Fox' box is checked. In addition, notify the 'Fox' via a message box
> to use alternate recommended DXpedition mode frequencies from the band pull
> down menu. *
>
>
> *The WSJT-X Development Group selected the FT8 frequencies now being used
> by all. I believe that after serious consideration, they should define a
> recommended DXpedition mode frequencies for each HF band.  I'd further
> recommend that the 'Frequencies' table be populated with these recommended
> DXpedition mode frequencies. Even better, whenever the 'Fox' box is
> checked, display ONLY the recommended DXpedition mode frequencies' in the
> band pull down menu.*
>
>
> *Comments and discussion?*
>
> *73,*
> *Rich - K1HTV*
>
> 
> --
> 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] DXpedition Mode on 40 Meters?

[Hasan al-Basri]

Quoting from K9YC:

"It is a LONG established principle of ham radio, defined by FCC Rules and
corresponding laws in other countries, that no one person or group has
priority on any given frequency at any given time; indeed, these Rules
(laws) establish only permitted emission types for a range of frequencies."

No on has said that what DXp mode is doing is illegal, or violating rules.
Spare us us the straw man arguments. The crux of the matter has been the
devastating impact this particular mode of operation (DXp, not FT8
specifically) has on the existing digital mode operations. To use your own
"logic"..."*It has been a long established principle to have modes
segregated by users' agreement to preserve their viability*" This prevents
chaos, as well as incidental and deliberate interference that does no one
justice.

These *voluntary* agreements among people of good will (not the hysterical
I gotta have that new grid or country and screw anyone in my road, crowd),
have been around a long time.

Further quoting:

"This discussion is totally out of place on the developers' reflector.
Rather, it should be addressed to those hearty individuals who give of
their time and treasure to put stations on the air from usually very
difficult places and under difficult conditions, and for the benefit of
tens of thousands of hams around the world. Choice of operating frequencies
and times is THEIRS."


My Response: :

Not at all. The developers knew or should have known (legal standard for
*neglect*, by the way) the impact that DXp; would have had on any set of
frequencies *where they encouraged* DXp mode use.. Proof of this knowledge
is in the developers' explicit instructions to "*not run DXp mode in the
normal FT8 usage area*" . Why? For two reasons: 1) DXp trashes the spectrum
for whomever was already using it;  2). It was a cleaner test to be away
from the mutual interference of current FT8 usage.

In other words, "We don't want to mess up our nest, someone else's nest
will do nicely" This is what I meant when I referred to the approach
as "*hypocritical
and dismissive indifference" To say there are no nests is disingenuous at
best.*

*Running DXp by the developers for testing and evaluation is justifiable.
Releasing DXp "into the wild" with no restraints or protections from abuse
is irresponsible. *

*There are solutions, but they rest ONLY in the hands of the developers*.
Many DX'ers (do you listen to the conduct during DXpediitons?) have no
conscience whatever. They are incapable of self-restraint in the pursuit of
their self-imagined accomplishments. DXpeditions spend enough money and are
sufficiently popular to create in their minds and the minds of their
minions,  the firm belief that they are *entitled* to do whatever they like.

I happily stipulate that the software is amazing. I love using it. Yet,
there are *norms* that exist for the benefit of all of us.

In summary, norms and agreements may be even more important than FCC
rules. Rules
are a required element of success, but they are not sufficient for same.
Success ultimately requires  cooperation and consideration

Discussion of the impact of DXp mode on the developers' list is precisely
where it should take place. It was created and released by the developers.
The deleterious impact of that release is at least partially their
responsibility.

 73, N0AN

Hasan

On Tue, Mar 27, 2018 at 8:01 PM, Mike Besemer  wrote:

> Like or not, the inconsistency exists.  I'm not the one who set it up that
> way and neither of our opinions really matters anyway; the fact is that
> 7070 has been in use by PSK for over 15 years in Region 2 and there is no
> reason NOT to know that; it is widely published for anyone to see.  If you
> think I'm pulling that fact out of my posterior, feel free to Google it
> yourself.
>
> I'm not sure where you get the idea I have a limited world view; I clearly
> stated in several of my emails that things always go to hell in a
> handbasket when rare DX hits the bands.  As for not buying my comment about
> 7040 being mostly EU, that's the way the bandplan has it set up.  Again,
> Google is your friend.  If you're hearing PSK on 7040 during the day in
> your area, there are obviously stations in your area using it; leave it to
> the left coast to have it ass-backwards.  I'm not a no-code tech... I've
> been doing this for over 40 years and I don't appreciate you talking down
> to me.
>
> I get it... you don’t like PSK-31.  That's fine, but you need not throw
> stones at those of us who do.  If you like FT8 and the
> wham-bam-thank-you-ma'am type of contact, more power to you.  Those of us
> who care more about the human element of ham radio than our DXCC or grid
> count are fine with that.  All we ask is that you leave us the hell alone
> in our little 2 KHz segment of the band and for God's sake be a gentleman
> and listen before you transmit; anything less is nothing less than an
> indication of a piss-poor operator.