[wsjt-devel] Possible V 2.0 rc3 issue ?

2018-10-28 Thread Mark Spencer 
Changing focus between WSJT-X 2.0 RC 3 and other windows apps can cause 
dropouts in Tx Audio at times.

PC is running Windows 7.   Am sending audio to the transmitter via the PC sound 
card.


I noticed this while calling CQ with MSK144 in North American Contest Mode.

If there is any interest I could do some more testing (ie with a radio with a 
built in "sound card" interface, and / or other versions of WSJT-x.)  I don't 
recall ever having this issue in the past, but have never explicitly looked for 
it either.

73
Mark Spencer
VE7AFZ
netsyn...@gmail.com




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

Re: [wsjt-devel] wsjt-x 2 wspr SNR

2018-10-28 Thread Rob Robinett 
Hi Steve,

I was not aware of the additional command line flags until your email and a
chat from Jim.  It does increase CPU utilization enough that a Pi can no
longer perform two wsprd decodes on each of the 11 bands, so I have divided
the bands across 2 Pis.
In addition, I have modified my script to completely isolate the decodes
into separate directories.  I am running with C 1 rather than 5000.  It
seems to cost little in cpu cycles, but I will take your directions on the
optimal values.

Running with those changes  for the last two hours, I can see that KPH2 has
logged 577 spots in the last hour, while KPH has logged only 494 spots.
 These results are so good that I am inclined to switch the calls so that
KPH doesn't fall even further behind you and others in the top spotters
list ;=)

Thanks for all of your excellent work on WSJT-x and WSPR.  This technology
has revived my interest in ham radio after 40 years of dormancy.

73,

Rob
AI6VN


On Sat, Oct 27, 2018 at 9:28 PM, Steven Franke via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> Hi Rob -
>
> Are you using the same command-line arguments that WSJT-X uses when it
> calls the decoder? The “Deep” decode setting in WSJT-X v2.0.0-rc3 uses “-C
> 5000 -o 4”.
>
> Also, it is essential that the decoder in v2.0.0  have access to a
> well-populated hashtable.txt. Briefly, the enhanced sensitivity is obtained
> by invoking a new (to wsprd) decoding algorithm if the Fano algorithm
> fails. The new algorithm always returns a codeword, but only a fraction of
> these are “good”.  Many of the returned codewords are incorrect and would
> produce false decodes. Ideally, one would use a CRC to reject the incorrect
> codewords (as in FT8), but the WSPR message doesn’t include a CRC. Instead,
> we only accept codewords that unpack to callsigns that we’ve seen before,
> i.e. callsigns that are in the hashtable. If there’s no hashtable, then we
> will never accept any of the codewords from the new algorithm. This means
> that the v2.0.0 decoder becomes more sensitive than 1.9.1 to a particular
> callsign only after that callsign has been decoded at least once by the
> Fano algorithm.
>
> Finally, decodes produced by the new decoding algorithm will have a “1” as
> the last number on the line that is printed in ALL_WSPR.TXT.  Fano
> algorithm decodes will show a “0”.
>
> I’ve been very pleased with the results here. There have been many nights
> when all of my MF decodes of VK4YB were produced by the new algorithm.
>
> I hope that this information is helpful,
>
> 73 Steve k9an
>
> On Oct 27, 2018, at 10:27 PM, Rob Robinett  wrote:
>
> Hi Steve,
>
> Jim's question was stimulated by tests I have been running at KPH to
> compare the decode performance of the wsprd in 1.9.1 against the wsprd in
> 2.0rc3
>
> My test setup is located at KPH where I have one KiwiSDR fed by a 3-30
> Mhz  TCI-530 and a second KiwiSDR fed from a Marconi T.  I don't use the
> excellent wspr decode extension included in the Kiwi, but instead run a
> bash script on a Raspberry Pi 3B which records a 2 minute  wav file for
> each band from 2200M through 10 M.  Each 2 minutes wave file is then fed
> first to wsprd 2.0 and logged as KPH2 and then the sme wav file is fed to
> wsprd 1.9.1 and logged as KPH.  After 24 hours I can find no difference
> between the KPH spots and KPH2 spots.
>
> The wsprd binaries were obtained by downloading and installing packages
> from the WSJT-x site and the binaries definitely are different sizes:
>
> pi@KPH-Pi2:/tmp/kiwi-captures $ lrt /usr/bin/wsprd*
> -rwxr-xr-x 1 root root 46376 May 30 17:32 /usr/bin/wsprd
> -rwxr-xr-x 1 pi   pi   79972 Oct 16 21:32 /usr/bin/wsprd.v2
> pi@KPH-Pi2:/tmp/kiwi-captures $
>
> I can see from 'top' that my script is first executing wsprd.v2 and then
> wsprd, so I am confident in my test methodology.
> Perhaps I am misusing wsprd.  Before processing each wav file I truncate
> the ALL_WSPR.TXT file but leave the other files used by wsprd alone.  Could
> the two wsprd versions depend up the history in ALL_WSPR.TXT or be sharing
> information in wspr_wisdom.dat or the other support files which influence
> the results?
>
> Thanks,
>
> Rob
> AI6VN
>
>
>
>
>
> On Fri, Oct 26, 2018 at 3:37 PM, Steven Franke via wsjt-devel <
> wsjt-devel@lists.sourceforge.net> wrote:
>
>> > On Oct 26, 2018, at 2:21 PM, Jim Lill  wrote:
>> >
>> > What is the method to verify my system is indeed enjoying the 1 dB SNR
>> improvement that 2.0 gives?
>> >
>> > Thanks
>> >
>> > Jim
>> >
>> > WA2ZKD
>>
>> Hi Jim,
>>
>> You might try turning on “Save All” and running for, say, 24 hours or
>> even a couple of days. Then you can decode the saved batch of wav files
>> using older versions of WSJT-X and with new versions, and compare the
>> yield.
>>
>> Suppose that you want to compare the WSPR decoder in WSJT-X v 1.9.1 to
>> WSJT-X v 2.0.0-rc3.
>>
>> 1. Run with Save All to save a large batch of wav files.
>>
>> 2. Delete ALL_WSPR.TXT. Start WSJT-X v 1.9.1  and us

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

2018-10-28 Thread Marco Calistri via wsjt-devel 
Il 28/10/18 10:45, Black Michael via wsjt-devel ha scritto:
> The directions are missing the phrase "if your rig is capable of it". 
> Kind of assumes everybody understands this stuff.
Probably I'm not "so smart as_"everybody_ is to _understand this stuff"_.

I'm sorry to bore the ML with obvious stuff, I'm here as a new FT8 user
and as such I would need to have a confirmation by more expert people,
not just regarding the WSJT-X software itself, but hopefully by someone
else using WSJT-X along with same radio as the one I use.
Hams often find amazing solutions which sometimes go beyond the standard
features we get by factory radio, maybe through some custom modifications...
> Bandwidth settings are on of the big variables on rigs and have
> generally gotten wider as the years have gone on.
>
> So...if your FT-100 cannot widen bandwidth you are stuck with what you
> have.  But, either Fake It or Rig Split settings will allow you to
> work whatever you can see as long as your bandwidth covers 1500-2000Hz.
>
> de Mike W9MDB
Ok Mike, for me your answer is anyway valid and useful to understand
that I cannot set the audio frequencies out of the radio bandwidth
limits of my transceiver.

Thanks!

-- 
73 de Marco, PY1ZRJ
___
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

2018-10-28 Thread Marco Calistri via wsjt-devel 


Il 28/10/18 12:29, Bill Somerville ha scritto:
> On 28/10/2018 13:45, Black Michael via wsjt-devel wrote:
>> The directions are missing the phrase "if your rig is capable of
>> it".  Kind of assumes everybody understands this stuff.
>>
>> Bandwidth settings are on of the big variables on rigs and have
>> generally gotten wider as the years have gone on.
>>
>> So...if your FT-100 cannot widen bandwidth you are stuck with what
>> you have.  But, either Fake It or Rig Split settings will allow you
>> to work whatever you can see as long as your bandwidth covers
>> 1500-2000Hz.
>>
>> de Mike W9MDB
>>
> Hi Mike,
>
> the FT8 DXpedition mode instructions are written assuming the user has
> working CAT control for their rig, it is not impossible to use
> DXpedition mod without CAT control but there are limitations when
> doing so. One such limitation is that you must work within the Tx
> passband of your rig.
>
> 73
> Bill
> G4WJS.
>
>
Bill, *GWJS*,

Be so kind please to confirm me if a YAESU FT-100 *with* CAT control ,
is capable to strictly follow WSJT-X audio settings as per FT DXpedition
mode instructions or not, otherwise I will stay with my doubts.

In other words, by using CAT control, could we get some "extra TX/Rx
bandwidth" in respect to the one we get without the CAT?

Many thanks and best regards!

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

Re: [wsjt-devel] failure WSJT-X 2.0.0 rc3

2018-10-28 Thread Saku 

Hi !

-
Now as Mike has reported a bug below I will release this mail that I was 
writing a while ago. I did not sent it as I could not reproduce bug for 
sure. Difference to Mike's observation was that I did not initiate qsos 
from wsjtx main window but from companion program. Below is my original 
draft mail




First of all big thanks for developers. This task is not a small one. 
Too big to be "just hobby programming".


Devel list has so many messages that is is impossible to dig out is the 
"found bug" already listed.
We should have some kind of "Wall" where someone (not us all) should 
collect all bugs.


Bug name | what it does/does not do | is there a workaround  | confirm 
to be known by developers


That way we could avoid multiple reporting of same bug because reporting 
it  has variable subjects in devel mails.


I do not know if this bug has been already reported:

When I have called someone but not got qso my std messages are set for 
that callsign. If I then choose another CQ caller to try qso with and 
double click that line on companion program (cqrlog/CQ-monitor) to start 
qso by UDP request sent by the program to wsjtx TX starts but standard 
messages are NOT populated with that new call. The previous call is 
still there.
Old versions, 1.9.2 and below, never did this. I did not have had time 
enough to play with 2.0.0.rc1 and rc2 to see that happen with them.


WSJT-X 2.0.0 rc3, Fedora 28/LXDE, cqrlog 2.3.0-107

--
Saku
OH1KH


Mike kirjoitti 28.10.2018 klo 12.04:
When I was using it with the tx fq locked, when I double clicked on a 
new station, the information below did not update and transmitted the 
previous station information instead of the station I had just double 
clicked.


Haven't succeed making any contacts, but station is not power house 
and antennas so-so. Combined with 0 sunspots I am not surprised.


73,

Mike
AK7ML






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

Re: [wsjt-devel] wsjt-x 2 wspr SNR

2018-10-28 Thread Steven Franke via wsjt-devel 
Jim,
The number in question is the total Fano path metric for the returned codeword. 
When the last number is 1, that means that the Fano algorithm failed. In such 
cases, the path metric is just set to its maximum possible value, 810.  
Steve k9an

> On Oct 28, 2018, at 11:31 AM, Jim Lill  wrote:
> 
> Steve,
> 
> What does the number before the 0 or 1 in ALL_WSPR.TXT represent? I see it as 
> 810 when there's a 1 (new algo) decode
> 
> 
> 
> -Jim wa2zkd
> 
> 
> On 10/28/2018 12:28 AM, Steven Franke via wsjt-devel wrote:
>> Hi Rob - 
>> 
>> Are you using the same command-line arguments that WSJT-X uses when it calls 
>> the decoder? The “Deep” decode setting in WSJT-X v2.0.0-rc3 uses “-C 5000 -o 
>> 4”. 
>> 
>> Also, it is essential that the decoder in v2.0.0  have access to a 
>> well-populated hashtable.txt. Briefly, the enhanced sensitivity is obtained 
>> by invoking a new (to wsprd) decoding algorithm if the Fano algorithm fails. 
>> The new algorithm always returns a codeword, but only a fraction of these 
>> are “good”.  Many of the returned codewords are incorrect and would produce 
>> false decodes. Ideally, one would use a CRC to reject the incorrect 
>> codewords (as in FT8), but the WSPR message doesn’t include a CRC. Instead, 
>> we only accept codewords that unpack to callsigns that we’ve seen before, 
>> i.e. callsigns that are in the hashtable. If there’s no hashtable, then we 
>> will never accept any of the codewords from the new algorithm. This means 
>> that the v2.0.0 decoder becomes more sensitive than 1.9.1 to a particular 
>> callsign only after that callsign has been decoded at least once by the Fano 
>> algorithm.
>> 
>> Finally, decodes produced by the new decoding algorithm will have a “1” as 
>> the last number on the line that is printed in ALL_WSPR.TXT.  Fano algorithm 
>> decodes will show a “0”.
>> 
>> I’ve been very pleased with the results here. There have been many nights 
>> when all of my MF decodes of VK4YB were produced by the new algorithm.
>> 
>> I hope that this information is helpful,
>> 
>> 73 Steve k9an
>> 
>>> On Oct 27, 2018, at 10:27 PM, Rob Robinett >> > wrote:
>>> 
>>> Hi Steve,
>>> 
>>> Jim's question was stimulated by tests I have been running at KPH to 
>>> compare the decode performance of the wsprd in 1.9.1 against the wsprd in 
>>> 2.0rc3
>>> 
>>> My test setup is located at KPH where I have one KiwiSDR fed by a 3-30 Mhz  
>>> TCI-530 and a second KiwiSDR fed from a Marconi T.  I don't use the 
>>> excellent wspr decode extension included in the Kiwi, but instead run a 
>>> bash script on a Raspberry Pi 3B which records a 2 minute  wav file for 
>>> each band from 2200M through 10 M.  Each 2 minutes wave file is then fed 
>>> first to wsprd 2.0 and logged as KPH2 and then the sme wav file is fed to 
>>> wsprd 1.9.1 and logged as KPH.  After 24 hours I can find no difference 
>>> between the KPH spots and KPH2 spots.
>>> 
>>> The wsprd binaries were obtained by downloading and installing packages 
>>> from the WSJT-x site and the binaries definitely are different sizes:
>>> 
>>> pi@KPH-Pi2:/tmp/kiwi-captures $ lrt /usr/bin/wsprd*
>>> -rwxr-xr-x 1 root root 46376 May 30 17:32 /usr/bin/wsprd
>>> -rwxr-xr-x 1 pi   pi   79972 Oct 16 21:32 /usr/bin/wsprd.v2
>>> pi@KPH-Pi2:/tmp/kiwi-captures $
>>> 
>>> I can see from 'top' that my script is first executing wsprd.v2 and then 
>>> wsprd, so I am confident in my test methodology.
>>> Perhaps I am misusing wsprd.  Before processing each wav file I truncate 
>>> the ALL_WSPR.TXT file but leave the other files used by wsprd alone.  Could 
>>> the two wsprd versions depend up the history in ALL_WSPR.TXT or be sharing 
>>> information in wspr_wisdom.dat or the other support files which influence 
>>> the results?
>>> 
>>> Thanks,
>>> 
>>> Rob
>>> AI6VN
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On Fri, Oct 26, 2018 at 3:37 PM, Steven Franke via wsjt-devel 
>>> >> > wrote:
>>> > On Oct 26, 2018, at 2:21 PM, Jim Lill >> > > wrote:
>>> > 
>>> > What is the method to verify my system is indeed enjoying the 1 dB SNR 
>>> > improvement that 2.0 gives?
>>> > 
>>> > Thanks
>>> > 
>>> > Jim
>>> > 
>>> > WA2ZKD
>>> 
>>> Hi Jim,
>>> 
>>> You might try turning on “Save All” and running for, say, 24 hours or even 
>>> a couple of days. Then you can decode the saved batch of wav files using 
>>> older versions of WSJT-X and with new versions, and compare the yield. 
>>> 
>>> Suppose that you want to compare the WSPR decoder in WSJT-X v 1.9.1 to 
>>> WSJT-X v 2.0.0-rc3.
>>> 
>>> 1. Run with Save All to save a large batch of wav files.
>>> 
>>> 2. Delete ALL_WSPR.TXT. Start WSJT-X v 1.9.1  and use "File/Open" to select 
>>> the first (earliest) wav file in the batch that you saved. This will cause 
>>> WSJT-X to process that file. Next, select "File/Decode remaining files in 
>>> directory" to process the rest of the files. When you have finished 
>>> pro

Re: [wsjt-devel] wsjt-x 2 wspr SNR

2018-10-28 Thread Jim Lill 

Steve,

What does the number before the 0 or 1 in ALL_WSPR.TXT represent? I see 
it as 810 when there's a 1 (new algo) decode



-Jim wa2zkd


On 10/28/2018 12:28 AM, Steven Franke via wsjt-devel wrote:

Hi Rob -

Are you using the same command-line arguments that WSJT-X uses when it 
calls the decoder? The “Deep” decode setting in WSJT-X v2.0.0-rc3 uses 
“-C 5000 -o 4”.


Also, it is essential that the decoder in v2.0.0  have access to a 
well-populated hashtable.txt. Briefly, the enhanced sensitivity is 
obtained by invoking a new (to wsprd) decoding algorithm if the Fano 
algorithm fails. The new algorithm always returns a codeword, but only 
a fraction of these are “good”.  Many of the returned codewords are 
incorrect and would produce false decodes. Ideally, one would use a 
CRC to reject the incorrect codewords (as in FT8), but the WSPR 
message doesn’t include a CRC. Instead, we only accept codewords that 
unpack to callsigns that we’ve seen before, i.e. callsigns that are in 
the hashtable. If there’s no hashtable, then we will never accept any 
of the codewords from the new algorithm. This means that the v2.0.0 
decoder becomes more sensitive than 1.9.1 to a particular callsign 
only after that callsign has been decoded at least once by the Fano 
algorithm.


Finally, decodes produced by the new decoding algorithm will have a 
“1” as the last number on the line that is printed in ALL_WSPR.TXT. 
 Fano algorithm decodes will show a “0”.


I’ve been very pleased with the results here. There have been many 
nights when all of my MF decodes of VK4YB were produced by the new 
algorithm.


I hope that this information is helpful,

73 Steve k9an

On Oct 27, 2018, at 10:27 PM, Rob Robinett > wrote:


Hi Steve,

Jim's question was stimulated by tests I have been running at KPH to 
compare the decode performance of the wsprd in 1.9.1 against the 
wsprd in 2.0rc3


My test setup is located at KPH where I have one KiwiSDR fed by a 
3-30 Mhz  TCI-530 and a second KiwiSDR fed from a Marconi T.  I don't 
use the excellent wspr decode extension included in the Kiwi, but 
instead run a bash script on a Raspberry Pi 3B which records a 2 
minute  wav file for each band from 2200M through 10 M. Each 2 
minutes wave file is then fed first to wsprd 2.0 and logged as KPH2 
and then the sme wav file is fed to wsprd 1.9.1 and logged as KPH.  
After 24 hours I can find no difference between the KPH spots and 
KPH2 spots.


The wsprd binaries were obtained by downloading and installing 
packages from the WSJT-x site and the binaries definitely are 
different sizes:


pi@KPH-Pi2:/tmp/kiwi-captures $ lrt /usr/bin/wsprd*
-rwxr-xr-x 1 root root 46376 May 30 17:32 /usr/bin/wsprd
-rwxr-xr-x 1 pi   pi   79972 Oct 16 21:32 /usr/bin/wsprd.v2
pi@KPH-Pi2:/tmp/kiwi-captures $

I can see from 'top' that my script is first executing wsprd.v2 and 
then wsprd, so I am confident in my test methodology.
Perhaps I am misusing wsprd.  Before processing each wav file I 
truncate the ALL_WSPR.TXT file but leave the other files used by 
wsprd alone.  Could the two wsprd versions depend up the history in 
ALL_WSPR.TXT or be sharing information in wspr_wisdom.dat or the 
other support files which influence the results?


Thanks,

Rob
AI6VN





On Fri, Oct 26, 2018 at 3:37 PM, Steven Franke via wsjt-devel 
> wrote:


> On Oct 26, 2018, at 2:21 PM, Jim Lill mailto:j...@jimlill.com>> wrote:
>
> What is the method to verify my system is indeed enjoying the 1
dB SNR improvement that 2.0 gives?
>
> Thanks
>
> Jim
>
> WA2ZKD

Hi Jim,

You might try turning on “Save All” and running for, say, 24
hours or even a couple of days. Then you can decode the saved
batch of wav files using older versions of WSJT-X and with new
versions, and compare the yield.

Suppose that you want to compare the WSPR decoder in WSJT-X v
1.9.1 to WSJT-X v 2.0.0-rc3.

1. Run with Save All to save a large batch of wav files.

2. Delete ALL_WSPR.TXT. Start WSJT-X v 1.9.1  and use "File/Open"
to select the first (earliest) wav file in the batch that you
saved. This will cause WSJT-X to process that file. Next, select
"File/Decode remaining files in directory" to process the rest of
the files. When you have finished processing all of the files,
ALL_WSPR.TXT will contain all of the decodes. Rename ALL_WSPR.TXT
to something different, such as ALL_WSPR_1.9.1.TXT, so that it
will not be overwritten or appended to by subsequent runs.

5. Make sure that you have moved ALL_WSPR.TXT to a new filename.
Start WSJT-X v 2.0.0-rc3. Process all files. Rename your
ALL_WSPR.TXT, e.g. to ALL_WSPR_2.0.0.TXT.

6. Use your favorite tools to compare the decodes in
ALL_WSPR_1.9.1.TXT and ALL_WSPR_2.0.0.TXT.

Here are some results that I obtained back in September:

Bands monitored: 160/80/40/30/20/17/15/10 (thes

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

2018-10-28 Thread Bill Somerville 

On 28/10/2018 13:45, Black Michael via wsjt-devel wrote:
The directions are missing the phrase "if your rig is capable of it".  
Kind of assumes everybody understands this stuff.


Bandwidth settings are on of the big variables on rigs and have 
generally gotten wider as the years have gone on.


So...if your FT-100 cannot widen bandwidth you are stuck with what you 
have.  But, either Fake It or Rig Split settings will allow you to 
work whatever you can see as long as your bandwidth covers 1500-2000Hz.


de Mike W9MDB


Hi Mike,

the FT8 DXpedition mode instructions are written assuming the user has 
working CAT control for their rig, it is not impossible to use 
DXpedition mod without CAT control but there are limitations when doing 
so. One such limitation is that you must work within the Tx passband of 
your rig.


73
Bill
G4WJS.

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

Re: [wsjt-devel] failure WSJT-X 2.0.0 rc3

2018-10-28 Thread Black Michael via wsjt-devel 
That would (should) have no bearing.Mike


 

On Sunday, October 28, 2018, 8:42:19 AM CDT, Mike  
wrote:  
 
  More on previous reply, I will using hold tx frequency if that could have any 
bearing.
 
 Mike
 
 On 10/28/2018 6:03 AM, Black Michael via wsjt-devel wrote:
  
 
  You must be double-clicking the wrong message. If this was a bug we'd have 
all sorts of complaints. 
  Can you give an example of what you are clicking on, what you expect, and 
what you get? 
  de Mike W9MDB
  
   

  
  On Sunday, October 28, 2018, 5:08:59 AM CDT, Mike  
wrote:  
  
   When I was using it with the tx fq locked, when I double clicked on a 
  new station, the information below did not update and transmitted the 
  previous station information instead of the station I had just double 
  clicked.
  
  Haven't succeed making any contacts, but station is not power house and 
  antennas so-so. Combined with 0 sunspots I am not surprised.
  
  73,
  
  Mike
  AK7ML
  
  
  ___
  wsjt-devel mailing list
  wsjt-devel@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wsjt-devel
 
  
 
  
 ___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
 
 ___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
  ___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

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

2018-10-28 Thread Black Michael via wsjt-devel 
The directions are missing the phrase "if your rig is capable of it".  Kind of 
assumes everybody understands this stuff.

Bandwidth settings are on of the big variables on rigs and have generally 
gotten wider as the years have gone on.

So...if your FT-100 cannot widen bandwidth you are stuck with what you have.  
But, either Fake It or Rig Split settings will allow you to work whatever you 
can see as long as your bandwidth covers 1500-2000Hz.
de Mike W9MDB
 

On Sunday, October 28, 2018, 8:35:25 AM CDT, Marco Calistri via wsjt-devel 
 wrote:  
 
  
 
 Il 27/10/18 21:58, Bill Somerville ha scritto:
  
On 28/10/2018 01:30, Morris Wideman via wsjt-devel wrote: 
 
My MP does not put out full power but if you have a way to increase the TX 
audio level such as mic gain then this is not that big a problem. 
 
 
 Morris, 
 
 this is a very bad idea. Increasing the audio drive to compensate for the SSB 
IF filter attenuating the Tx signal will almost certainly overload the 
modulator input. This is particularly poor practice if you do this to 
compensate for a low frequency audio tone as the resulting audio harmonics will 
pass through the SSB IF filter unattenuated leaving you with a filthy Tx 
signal. 
 
 The correct way to deal with Tx audio frequencies outside of the Tx SSB IF 
filter passband is to either restrict your operation to Tx audio offsets to 
above 1500 Hz (to keep any audio harmonics outside of the passband) and to 
below ~2400 Hz, alternatively if you have CAT control you should enable 
"Settings->Radio->Split Operating" and let WSJT-X do the right thing 
automatically; then there are no restrictions on the Tx audio offset you may 
use. 
 
 Incidentally, this is one of the reasons that using the rig's ALC indication 
to estimate the correct audio drive is missing the point and may result in poor 
Tx signals. 
 
 73 
 Bill 
 G4WJS. 
 
 
 
 ___ 
 wsjt-devel mailing list 
 wsjt-devel@lists.sourceforge.net 
 https://lists.sourceforge.net/lists/listinfo/wsjt-devel 
 
 Hi Bill,
 
 I have some doubts here regarding the WSJT-X TX audio settings, because my 
radio is a very modest and not so modern YAESU FT-100 and I verified that it 
can't handle frequencies above about 2900 Hz or below about a couple of hundred 
Hertz, probably due its SSB filters passband. When I try to set frequencies out 
of the standard my RF power went strongly reduced.
 
 Despite this limitation, from the FT8_DXpedition_Mode instructions we can read 
that we could set Tx audio carrier up to 4.000Hz:
 
 Select Tab 1 on the main window for transmitted messages, and set Tx  Hz to
 a Tx frequency between 1000 and 4000 Hz. You can also select a Tx frequency by
 using Shift+Click on the waterfall display. You may find frequencies above 3000
 Hz are desitable because they have less QRM. Select the “Tx1” message under
 Next.
 
 
 
 Hence I would like to know: is the above Tx audio setting always possible?
 
 How do we can set this higher frequency on older transceivers like mine, which 
has not "too much adjustments" to play with?
 
 Thanks for your kind attention!
 
 Best regards,
 
 -- 
 73 de Marco, PY1ZRJ  ___
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] failure WSJT-X 2.0.0 rc3

2018-10-28 Thread Mike 
More on previous reply, I will using hold tx frequency if that could 
have any bearing.


Mike

On 10/28/2018 6:03 AM, Black Michael via wsjt-devel wrote:

You must be double-clicking the wrong message.
If this was a bug we'd have all sorts of complaints.

Can you give an example of what you are clicking on, what you expect, 
and what you get?


de Mike W9MDB




On Sunday, October 28, 2018, 5:08:59 AM CDT, Mike 
 wrote:



When I was using it with the tx fq locked, when I double clicked on a
new station, the information below did not update and transmitted the
previous station information instead of the station I had just double
clicked.

Haven't succeed making any contacts, but station is not power house and
antennas so-so. Combined with 0 sunspots I am not surprised.

73,

Mike
AK7ML


___
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] failure WSJT-X 2.0.0 rc3

2018-10-28 Thread Mike 
It was a transient thing. I clicked on a station on the band activity 
list, which should change the messages down below, but they did not 
change. The messages stayed the same, even though I clicked on another 
station in the list. I went back to the current version and it did not 
show the error.


I went back now and tried again and it worked correctly.  I will keep an 
eye on it. It might be an RF in the shack problem disabling the mouse 
click, but that usually locks it up until I unplug the mouse and plug it 
back in.


Mike, AK7ML

On 10/28/2018 6:03 AM, Black Michael via wsjt-devel wrote:

You must be double-clicking the wrong message.
If this was a bug we'd have all sorts of complaints.

Can you give an example of what you are clicking on, what you expect, 
and what you get?


de Mike W9MDB




On Sunday, October 28, 2018, 5:08:59 AM CDT, Mike 
 wrote:



When I was using it with the tx fq locked, when I double clicked on a
new station, the information below did not update and transmitted the
previous station information instead of the station I had just double
clicked.

Haven't succeed making any contacts, but station is not power house and
antennas so-so. Combined with 0 sunspots I am not surprised.

73,

Mike
AK7ML


___
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] Flex Split Operation Setup with WSJT-X

2018-10-28 Thread Marco Calistri via wsjt-devel 


Il 27/10/18 21:58, Bill Somerville ha scritto:
> On 28/10/2018 01:30, Morris Wideman via wsjt-devel wrote:
>> My MP does not put out full power but if you have a way to increase
>> the TX audio level such as mic gain then this is not that big a problem.
>
> Morris,
>
> this is a very bad idea. Increasing the audio drive to compensate for
> the SSB IF filter attenuating the Tx signal will almost certainly
> overload the modulator input. This is particularly poor practice if
> you do this to compensate for a low frequency audio tone as the
> resulting audio harmonics will pass through the SSB IF filter
> unattenuated leaving you with a filthy Tx signal.
>
> The correct way to deal with Tx audio frequencies outside of the Tx
> SSB IF filter passband is to either restrict your operation to Tx
> audio offsets to above 1500 Hz (to keep any audio harmonics outside of
> the passband) and to below ~2400 Hz, alternatively if you have CAT
> control you should enable "Settings->Radio->Split Operating" and let
> WSJT-X do the right thing automatically; then there are no
> restrictions on the Tx audio offset you may use.
>
> Incidentally, this is one of the reasons that using the rig's ALC
> indication to estimate the correct audio drive is missing the point
> and may result in poor Tx signals.
>
> 73
> Bill
> G4WJS.
>
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Hi Bill,

I have some doubts here regarding the WSJT-X TX audio settings, because
my radio is a very modest and not so modern YAESU FT-100 and I verified
that it can't handle frequencies above about 2900 Hz or below about a
couple of hundred Hertz, probably due its SSB filters passband. When I
try to set frequencies out of the standard my RF power went strongly
reduced.

Despite this limitation, from the *FT8_DXpedition_Mode* instructions we
can read that we could set Tx audio carrier up to 4.000Hz:

/Select Tab 1 on the main window for transmitted messages, and set Tx
 Hz to//
//a Tx frequency *between 1000 and 4000 Hz*. You can also select a Tx
frequency by//
//using Shift+Click on the waterfall display. You may find frequencies
above 3000//
//Hz are desitable because they have less QRM. Select the “Tx1” message
under//
//Next./



Hence I would like to know: is the above Tx audio setting always possible?

How do we can set this higher frequency on older transceivers like mine,
which has not "too much adjustments" to play with?

Thanks for your kind attention!

Best regards,

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

Re: [wsjt-devel] failure WSJT-X 2.0.0 rc3

2018-10-28 Thread Black Michael via wsjt-devel 
You must be double-clicking the wrong message.If this was a bug we'd have all 
sorts of complaints.
Can you give an example of what you are clicking on, what you expect, and what 
you get?
de Mike W9MDB


 

On Sunday, October 28, 2018, 5:08:59 AM CDT, Mike  
wrote:  
 
 When I was using it with the tx fq locked, when I double clicked on a 
new station, the information below did not update and transmitted the 
previous station information instead of the station I had just double 
clicked.

Haven't succeed making any contacts, but station is not power house and 
antennas so-so. Combined with 0 sunspots I am not surprised.

73,

Mike
AK7ML


___
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] FTdx3000

2018-10-28 Thread Tom Ramberg via wsjt-devel 
I'm using the FTdx5000 definition for JW6VDA and JW5E, JQ78tf.
Works great.

73 de Tom OH6VDA


> 26. okt. 2018 kl. 05:24 skrev Black Michael via wsjt-devel 
> :
> 
> Have you tried any others?  Maybe the FTdx5000?
> 
> Looks like the 3000 has the same command set.
> 
> If it does work we can add a definition for it.
> 
> de Mike W9MDB
> 
> 
> 
> 
> On Thursday, October 25, 2018, 9:45:30 PM CDT, S.WATANABE 
>  wrote:
> 
> 
> What radio can I choose for my Yaesu FTdx3000 to interface FT8?
> That one seems to be not appeared in the radio list.
> Is there any alternative choice?
> 
> Thanks and 73!
> Watt JA0DAI (also WR3W)
> 
> 
> 
> ___
> 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] failure WSJT-X 2.0.0 rc3

2018-10-28 Thread Mike 
When I was using it with the tx fq locked, when I double clicked on a 
new station, the information below did not update and transmitted the 
previous station information instead of the station I had just double 
clicked.


Haven't succeed making any contacts, but station is not power house and 
antennas so-so. Combined with 0 sunspots I am not surprised.


73,

Mike
AK7ML


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