Re: [wsjt-devel] Observation on Expedition Mode

[Tsutsumi Takehiko]

Joe,

Thank you for your response.

I will not count any synch words reduction for my calculation.

Regards,

take

de JA5AEA

Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10


From: Tsutsumi Takehiko 
Sent: Friday, July 6, 2018 10:55:59 AM
To: WSJT software development
Subject: RE: [wsjt-devel] Observation on Expedition Mode

Joe,

I am waiting your response to my previous message to recalculate additional 
gain for myself.

To make sure my intention, I described the inquiry as follow.

One FT8 frame has 7x7x3 =147 bits synch words and I understand current DX 
Pedition mode locates them in each FDM slot. Thus, we can shrink them from 147 
x 5 (= 735) to 147 bit in TDM frame at N=5 slots.

– Synchronization: 7×7 Costas arrays at start, middle, and end

I am waiting your response soon.

Regards,

take

de JA5AEA

Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10


From: Tsutsumi Takehiko 
Sent: Thursday, July 5, 2018 1:09:38 PM
To: WSJT software development
Subject: RE: [wsjt-devel] Observation on Expedition Mode


Joe,



It is good to hear from you to increase your calculation about my additional 
gain proposal  from +(1~8) dB to +(1.5~8) dB.



If you look into synch words, you may be able to get another additional gain.



Regards,



take



de JA5AEA



Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10






From: Joe Taylor 
Sent: Wednesday, July 4, 2018 11:27:08 PM
To: WSJT software development
Subject: Re: [wsjt-devel] Observation on Expedition Mode

Hi Take,

On 7/4/2018 9:20 AM, Tsutsumi Takehiko JA5AEA wrote:

> Concerning the “second +4dB term”, I remember Bill’s suggestion included
> hashing of callsign (I used the number of (28-15) x 5 = 65 bit
> reduction). I also reduced five 7x7 synch to one 7x7 synch, which I am
> not sure whether Bill included. I will not further describe the details
> to defend my ballpark number but I can say I disagree with your 0.6dB
> gain calculation, here.

Yes, if you convey less information you can achieve a lower threshold
SNR for decoding.

For this discussion I had assumed 11x28 = 308 bits for callsigns and 5x6
=30 bits for signal reports, 338 bits total.  Compared with the 5x75 =
375 bits for 5xFT8, this leads to a gain of ~0.5 dB.  Steve quoted 0.6
dB because he used 3-bit rather than 6-bit reports.

If we use 13-bit hashes for the callsigns being sent "RR73", the total
would be 6x28 + 5x13 + 5x6 = 263 bits.  Compared to 5xFT8, this yields
10log(375/263) = 1.5 dB.

Apparently you are suggesting something like 150-bit information
content, since 10log(375/150) = 4 dB.  This is not at all the same thing
as 5 FT8 messages.

> As I write to Steve, I do not have any intention to sell or stick to my
> +8dB number. If you feel uncomfortable, please deal it to + (1~8)dB
>   additional gain proposal .

No problem -- we are happy to discuss these things with you!

-- 73, Joe, K1JT


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

Re: [wsjt-devel] Observation on Expedition Mode

[Tsutsumi Takehiko]

Steve,

It seems the approach to increase M does not impact the down-link budget 
filling energy in unused clean spectrum from your response.

Well, I have to take your answer to my inquiry.

Thank you.

Regards,

take

de JA5AEA

PS: The reason I did not comment concerning QRA64 comparison was not the part 
of my inquiry. However, your story under 15% BER is worth to hear for me. Thank 
you.

Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10


From: Steven Franke via wsjt-devel 
Sent: Friday, July 6, 2018 9:52:04 PM
To: WSJT software development
Cc: Steven Franke
Subject: Re: [wsjt-devel] Observation on Expedition Mode

Hi Take,

Your textbook figure shows the difference in Eb/N0 required to achieve 10^-4 
BER on the AWGN channel, using single-symbol non-coherent detection.

Please consider the fact that if the SNR is large enough to provide 10^-4 BER, 
then any of the JT modes would virtually never fail to decode. We would be 
operating like a commercial communications system, at SNR well above the 50% 
decoding threshold that is used to characterize the relative sensitivity of the 
different JT modes.

Consider FT8 as an example - the error-correcting code that we use will decode 
about half of the frames having 26 bit errors (out of 174 total bits). This 
means that our 50% decoding threshold is obtained at a BER of approximately 
26/174=0.15. This is more than 3 orders of magnitude larger than the BER in 
your textbook Figure.

At the BER corresponding to the FT8 detection threshold, you will find that the 
advantage of 64FSK over 8FSK is relatively small, as I stated earlier.

As I also stated earlier, any near-threshold-SNR advantage of 64FSK can be 
completely erased if the 8FSK signal is detected on the basis of groups of 
symbols using a technique called “noncoherent sequence detection”.  The 
efficacy of sequence detection is not just something that I read about in a 
textbook.  This idea has been implemented in the improved WSPR decoder that was 
released in version 1.8, where the detection threshold has been improved by 
almost 3 dB for highly coherent MF and LF signals.

Finally, you have not commented on the comparison that I presented earlier 
where I scaled QRA64 to the same total transmission time as FT8, and I showed 
that their detection threshold were virtually the same. If 64FSK has a large 
advantage of 8FSK at the relevant SNRs, then how do you explain the parity 
between scaled QRA64 and FT8?

My assertions are not based on textbook figures. They are based on results 
obtained from realistic simulations, using detection and decoding algorithms 
implemented in computer programs written by Nico, Joe, and me. You have 
asserted that it should be possible to send nearly 5 times as many bits as FT8 
sends, in the same amount of time, while improving the decoding threshold by up 
to 1 dB over the current FT8 threshold. As Joe has already said, we invite you 
to prepare some code that demonstrates your assertion.

73, Steve k9an

On Jul 5, 2018, at 10:39 PM, Tsutsumi Takehiko 
mailto:ja5...@outlook.com>> wrote:

Hi Steve,

This is a result of my searching “modulation theory book” in my shelves.

See the attached copy and Figure 1.1 in Japanese.

It indicates the degradation of EB/N0 by the increase of M concerning M-FSK and 
this curve contradicts your “the energy-per-bit is the same, either way” in 
your previous memo.


Regards,<5CCC4EC6C6A94E25B2652B3E05EAC86F.jpg>

take

de JA5AEA

Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10


From: Tsutsumi Takehiko mailto:ja5...@outlook.com>>
Sent: Wednesday, July 4, 2018 10:20:16 PM
To: WSJT software development
Cc: Steven Franke
Subject: RE: [wsjt-devel] Observation on Expedition Mode

Steve,

Thank you for your comments.

Ok, I understand what is the disagreement between us.

First, I do not fully understand the point why you object my +4dB gain but I 
need to find modulation theory book in my book sheves (never opened for more 
than 20 years) and check about “ *bit* SNR, Eb/N0” related area before my final 
response. If I can not solve for myself, I can call my local experts without 
bothering you anymore.  But, I am thinking the longer symbol proposal does not 
heart any RF performance including the delay spread, fading performance, 
interference performance and a fraction of a dB gain with non-coherent 
detection given from you is another goody.

Concerning the “second +4dB term”, I remember Bill’s suggestion included 
hashing of callsign (I used the number of (28-15) x 5 = 65 bit reduction). I 
also reduced five 7x7 synch to one 7x7 synch, which I am not sure whether Bill 
included. I will not further describe the details to defend my ballpark number 
but I can say I disagree with your 0.6dB gain calculation, here.

Thank you very much spending your precious time to comment on my +8d

Re: [wsjt-devel] Observation on Expedition Mode

[Steven Franke via wsjt-devel]

Hi Take,

Your textbook figure shows the difference in Eb/N0 required to achieve 10^-4 
BER on the AWGN channel, using single-symbol non-coherent detection. 

Please consider the fact that if the SNR is large enough to provide 10^-4 BER, 
then any of the JT modes would virtually never fail to decode. We would be 
operating like a commercial communications system, at SNR well above the 50% 
decoding threshold that is used to characterize the relative sensitivity of the 
different JT modes. 

Consider FT8 as an example - the error-correcting code that we use will decode 
about half of the frames having 26 bit errors (out of 174 total bits). This 
means that our 50% decoding threshold is obtained at a BER of approximately 
26/174=0.15. This is more than 3 orders of magnitude larger than the BER in 
your textbook Figure. 

At the BER corresponding to the FT8 detection threshold, you will find that the 
advantage of 64FSK over 8FSK is relatively small, as I stated earlier.  

As I also stated earlier, any near-threshold-SNR advantage of 64FSK can be 
completely erased if the 8FSK signal is detected on the basis of groups of 
symbols using a technique called “noncoherent sequence detection”.  The 
efficacy of sequence detection is not just something that I read about in a 
textbook.  This idea has been implemented in the improved WSPR decoder that was 
released in version 1.8, where the detection threshold has been improved by 
almost 3 dB for highly coherent MF and LF signals.

Finally, you have not commented on the comparison that I presented earlier 
where I scaled QRA64 to the same total transmission time as FT8, and I showed 
that their detection threshold were virtually the same. If 64FSK has a large 
advantage of 8FSK at the relevant SNRs, then how do you explain the parity 
between scaled QRA64 and FT8?  

My assertions are not based on textbook figures. They are based on results 
obtained from realistic simulations, using detection and decoding algorithms 
implemented in computer programs written by Nico, Joe, and me. You have 
asserted that it should be possible to send nearly 5 times as many bits as FT8 
sends, in the same amount of time, while improving the decoding threshold by up 
to 1 dB over the current FT8 threshold. As Joe has already said, we invite you 
to prepare some code that demonstrates your assertion. 

73, Steve k9an

> On Jul 5, 2018, at 10:39 PM, Tsutsumi Takehiko  wrote:
> 
> Hi Steve,
>  
> This is a result of my searching “modulation theory book” in my shelves.
>  
> See the attached copy and Figure 1.1 in Japanese.
>  
> It indicates the degradation of EB/N0 by the increase of M concerning M-FSK 
> and this curve contradicts your “the energy-per-bit is the same, either way” 
> in your previous memo.
>  
>  
> Regards,<5CCC4EC6C6A94E25B2652B3E05EAC86F.jpg>
>  
> take
>  
> de JA5AEA
>  
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10
>  
> From: Tsutsumi Takehiko mailto:ja5...@outlook.com>>
> Sent: Wednesday, July 4, 2018 10:20:16 PM
> To: WSJT software development
> Cc: Steven Franke
> Subject: RE: [wsjt-devel] Observation on Expedition Mode
>  
> Steve,
>  
> Thank you for your comments.
>  
> Ok, I understand what is the disagreement between us.
>  
> First, I do not fully understand the point why you object my +4dB gain but I 
> need to find modulation theory book in my book sheves (never opened for more 
> than 20 years) and check about “ *bit* SNR, Eb/N0” related area before my 
> final response. If I can not solve for myself, I can call my local experts 
> without bothering you anymore.  But, I am thinking the longer symbol proposal 
> does not heart any RF performance including the delay spread, fading 
> performance, interference performance and a fraction of a dB gain with 
> non-coherent detection given from you is another goody.
>  
> Concerning the “second +4dB term”, I remember Bill’s suggestion included 
> hashing of callsign (I used the number of (28-15) x 5 = 65 bit reduction). I 
> also reduced five 7x7 synch to one 7x7 synch, which I am not sure whether 
> Bill included. I will not further describe the details to defend my ballpark 
> number but I can say I disagree with your 0.6dB gain calculation, here.
>  
> Thank you very much spending your precious time to comment on my +8dB 
> challenge.
>  
> Joe,
>  
> As I write to Steve, I do not have any intention to sell or stick to my +8dB 
> number. If you feel uncomfortable, please deal it to + (1~8)dB  additional 
> gain proposal .
>  
> take
>  
> de JA5AEA
>  
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10
>  
> From: Steven Franke via wsjt-devel  <mailto:wsjt-devel@lists.sourceforge.net>>
> Sent: Wednes

Re: [wsjt-devel] Observation on Expedition Mode

[Joe Taylor]

Hi Take,

On 7/5/2018 9:55 PM, Tsutsumi Takehiko JA5AEA wrote:

I am waiting your response to my previous message to recalculate 
additional gain for myself.


To make sure my intention, I described the inquiry as follow.

One FT8 frame has 7x7x3 =147 bits synch words and I understand current 
DX Pedition mode locates them in each FDM slot. Thus, we can shrink them 
from 147 x 5 (= 735) to 147 bit in TDM frame at N=5 slots.


/– Synchronization: 7×7 Costas arrays at start, middle, and end/

I am waiting your response soon.


Evidently you do not understand what is meant by a "7x7 Costas Array". 
This name refers to a sequence of 7 channel symbols at 7 different tone 
frequencies and possessing ideal auto-correlation properties in two 
dimensions.  The numbers 7x7=49 and 7x7x3=147 are wholly irrelevant.


The Costas arrays have nothing to do with "bits"; these symbols do not 
carry any message information.  Their only purpose in the FT8 protocol 
is to allow the receiving software to determine the frequency offset and 
starting point of a received signal waveform.


As described in the WSJT-X User Guide, an FT8 transmission consists of 
79 symbols: 58 3-bit symbols that convey message information, and 21 
symbols in three 7x7 Costas Arrays.  If time and frequency 
synchronization were provided in some other way, so that synchronizing 
symbols were unnecessary, the information-carrying symbols could be made 
longer in the ratio 79/58.  With no energy devoted to synchronization, 
sensitivity would be improved by only 10log(79/58) = 1.3 dB.


You advocate a five-fold reduction in the fraction of signal energy 
devoted to synchronization.  The consequence of such a change would be 
that sync losses would dominate all other causes of decoding failure.


Finally: you seem to suggest that we have not taken care to optimize the 
FT8 synchronization scheme, that we do not understand the dependence of 
threshold decoding sensitivity on various protocol design parameters, 
and that we have not done controlled, reliable simulation experiments to 
confirm our theoretical understanding.  None of these things is true.


Many further details, including results of sensitivity-measuring 
simulations, can be found in these papers:


http://physics.princeton.edu/pulsar/K1JT/JT65.pdf
http://physics.princeton.edu/pulsar/k1jt/FrankeTaylor_QEX_2016.pdf
http://physics.princeton.edu/pulsar/k1jt/MSK144_Protocol_QEX.pdf
http://physics.princeton.edu/pulsar/k1jt/Work_the_World_part2.pdf

I think that by now we have exhausted the potential benefits of this dialog.

With best wishes,

-- 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] Observation on Expedition Mode

[David Fisher]

Sure, I knew the callsign, but people make mistakes.



When I start the program in Hound mode, it reminds me (unnecessarily) to switch 
to “fake it” mode.  In my case the nag box is an annoyance since I run a Flex 
6600.  Why nag users about this?  Because people make mistakes, and the program 
is trying to help you avoid making a mistake.



Dave / NX6D






From: Joe Taylor 
Sent: Thursday, July 5, 2018 5:26:35 AM
To: k...@arrl.net; WSJT software development; Jim Brown
Subject: Re: [wsjt-devel] Observation on Expedition Mode

Hi Dave, Jim, and all,

On 7/4/2018 8:56 PM, Jim Brown wrote:
> On 7/4/2018 4:40 PM, David Fisher wrote:
>> Later when I uploaded to ClugLog, I was reminded that I logged the
>> wrong callsign.  Easily fixed in ClubLog, but for LOTW, all I could do
>> was log the contacts again as KH1/KH7X.
>
> I also simply click on their call when they're sending to someone else.
> I've never seen a CQ from them on FT8, but have worked them four times
> using FT8. I use JTAlert to log into DXKeeper, then edit the prefix in
> DXKeeper.

There should be no need to edit the prefix in DXKeeper.  When attempting
to work a DXpedition you know their callsign perfectly well, in advance.
  Item 5 under "Detailed Instructions for Hounds" in
https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fphysics.princeton.edu%2Fpulsar%2Fk1jt%2FFT8_DXpedition_Mode.pdf=02%7C01%7C%7Cd5c7079a7d6e46b9ba5208d5e2733276%7C84df9e7fe9f640afb435%7C1%7C0%7C636663906748274141=J8kHoXMREIbp6hzpu4LgO8DZfn433U%2B8wTXOBemdNeg%3D=0
reads as follows:

"5. Enter Fox’s callsign as DX Call. If Fox is using a compound
callsign, be sure to enter all of it. The grid locator is optional but
provides the advantage of displaying the short-path azimuth and distance
from your location."

The User guide even includes a picture showing "KH1/KH7Z" entered as DX
Call and "AJ10" as DX Grid.

I think the KH1 Fox operators did an excellent job and made good use of
the capabilities of FT8 DXpedition Mode.  ClubLog statistics show that
they made nearly as many FT8 QSOs as SSB QSOs, even though their setup
has three SSB stations and only two digi-stations.  And some of the
digi-time was spent on RTTY.  The Fox called CQ when he ran out of
callers, as expected.  Otherwise he responded to callers -- again, as
expected.
-- 73, Joe, K1JT

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! 
https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsdm.link%2Fslashdot=02%7C01%7C%7Cd5c7079a7d6e46b9ba5208d5e2733276%7C84df9e7fe9f640afb435%7C1%7C0%7C636663906748274141=4QFdyt%2BATnBZMSyqoN47nkSXkzj%2FlRWqYAvZ80mOZVA%3D=0
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fwsjt-devel=02%7C01%7C%7Cd5c7079a7d6e46b9ba5208d5e2733276%7C84df9e7fe9f640afb435%7C1%7C0%7C636663906748274141=yGIvj32kDuB%2FaRWzVb2ldRvRkW5xg%2BDRo%2BM3AmC90BI%3D=0
--
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] Observation on Expedition Mode

[Tsutsumi Takehiko]

Joe,

I am waiting your response to my previous message to recalculate additional 
gain for myself.

To make sure my intention, I described the inquiry as follow.

One FT8 frame has 7x7x3 =147 bits synch words and I understand current DX 
Pedition mode locates them in each FDM slot. Thus, we can shrink them from 147 
x 5 (= 735) to 147 bit in TDM frame at N=5 slots.

– Synchronization: 7×7 Costas arrays at start, middle, and end

I am waiting your response soon.

Regards,

take

de JA5AEA

Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10


From: Tsutsumi Takehiko 
Sent: Thursday, July 5, 2018 1:09:38 PM
To: WSJT software development
Subject: RE: [wsjt-devel] Observation on Expedition Mode


Joe,



It is good to hear from you to increase your calculation about my additional 
gain proposal  from +(1~8) dB to +(1.5~8) dB.



If you look into synch words, you may be able to get another additional gain.



Regards,



take



de JA5AEA



Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10






From: Joe Taylor 
Sent: Wednesday, July 4, 2018 11:27:08 PM
To: WSJT software development
Subject: Re: [wsjt-devel] Observation on Expedition Mode

Hi Take,

On 7/4/2018 9:20 AM, Tsutsumi Takehiko JA5AEA wrote:

> Concerning the “second +4dB term”, I remember Bill’s suggestion included
> hashing of callsign (I used the number of (28-15) x 5 = 65 bit
> reduction). I also reduced five 7x7 synch to one 7x7 synch, which I am
> not sure whether Bill included. I will not further describe the details
> to defend my ballpark number but I can say I disagree with your 0.6dB
> gain calculation, here.

Yes, if you convey less information you can achieve a lower threshold
SNR for decoding.

For this discussion I had assumed 11x28 = 308 bits for callsigns and 5x6
=30 bits for signal reports, 338 bits total.  Compared with the 5x75 =
375 bits for 5xFT8, this leads to a gain of ~0.5 dB.  Steve quoted 0.6
dB because he used 3-bit rather than 6-bit reports.

If we use 13-bit hashes for the callsigns being sent "RR73", the total
would be 6x28 + 5x13 + 5x6 = 263 bits.  Compared to 5xFT8, this yields
10log(375/263) = 1.5 dB.

Apparently you are suggesting something like 150-bit information
content, since 10log(375/150) = 4 dB.  This is not at all the same thing
as 5 FT8 messages.

> As I write to Steve, I do not have any intention to sell or stick to my
> +8dB number. If you feel uncomfortable, please deal it to + (1~8)dB
>   additional gain proposal .

No problem -- we are happy to discuss these things with you!

-- 73, Joe, K1JT


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

Re: [wsjt-devel] Observation on Expedition Mode

[Black Michael via wsjt-devel]

Simple patch to solve this problem...
@@ -4031,6 +4031,10 @@ void 
MainWindow::doubleClickOnCall2(Qt::KeyboardModifiers modifiers)

 void MainWindow::doubleClickOnCall(Qt::KeyboardModifiers modifiers)
 {
+  if (m_config.bHound()) {
+  MessageBox::information_message(this,"You must enter the DXpedition 
callsign in the DX Call box yourself to ensure correct logging!");
+  return;
+  }


 

On Thursday, July 5, 2018, 12:37:01 PM CDT, Mark Spencer 
 wrote:  
 
 That approach seemed to work for me.   
73

Mark spencerve7afznetsyn...@gmail.com


On Jul 5, 2018, at 9:59 AM, Black Michael via wsjt-devel 
 wrote:


So let's change the double-click on the Band Activity and tell them that rather 
than processing it."You must enter the DXpedition call yourself in the DX Call 
box".

de Mike W9MDB


 

On Thursday, July 5, 2018, 11:56:20 AM CDT, Joe Taylor  
wrote:  
 
 Jim --

On 7/5/2018 12:49 PM, Jim Brown wrote:
> On 7/5/2018 5:26 AM, Joe Taylor wrote:
>> There should be no need to edit the prefix in DXKeeper.  When 
>> attempting to work a DXpedition you know their callsign perfectly 
>> well, in advance.
> 
> Yes, but -- when you click on their call when they have called someone 
> else, you get KH7W, not KH1/KH7W, WSJT-X calls KH7W, and they respond. 
> Remember, I said I never saw them call CQ.

Of course I remember what you wrote.  The point is that you should not 
need to "click on their call", because you should already have entered 
the full call KH1/KH7Z in the DX Call box.

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

  --
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] Observation on Expedition Mode

[Joe Taylor]

Hi Charlie and all,

On 7/5/2018 1:51 PM, char...@sucklingfamily.free-online.co.uk wrote:

Joe

I think there has been confusion in the ranks from two different
instructions to hounds.

Baker's website says to click a decode,  and your instructions clearly
state to put the full expedition call into the DX box.

I followed your instructions.


Everyone did some learning, this first time out with DXpedition Mode.

In future, instructions published by DXpeditions should say "Do not call 
until you copy the Fox" rather than "Do not call until you copy a CQ 
from Fox".


DXpeditions using a compound call should say "Enter the DXpedition's 
full callsign as DX Call" rather than "click on a decode".


-- 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] Observation on Expedition Mode

[charlie]

Joe

I think there has been confusion in the ranks from two different
instructions to hounds.

Baker's website says to click a decode,  and your instructions clearly
state to put the full expedition call into the DX box.

I followed your instructions.

Charlie


--
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] Observation on Expedition Mode

[Mark Spencer]

That approach seemed to work for me.   

73

Mark Spencer
VE7AFZ
netsyn...@gmail.com



> On Jul 5, 2018, at 9:59 AM, Black Michael via wsjt-devel 
>  wrote:
> 
> So let's change the double-click on the Band Activity and tell them that 
> rather than processing it.
> "You must enter the DXpedition call yourself in the DX Call box".
> 
> de Mike W9MDB
> 
> 
> 
> 
> On Thursday, July 5, 2018, 11:56:20 AM CDT, Joe Taylor  
> wrote:
> 
> 
> Jim --
> 
> On 7/5/2018 12:49 PM, Jim Brown wrote:
> > On 7/5/2018 5:26 AM, Joe Taylor wrote:
> >> There should be no need to edit the prefix in DXKeeper.  When 
> >> attempting to work a DXpedition you know their callsign perfectly 
> >> well, in advance.
> > 
> > Yes, but -- when you click on their call when they have called someone 
> > else, you get KH7W, not KH1/KH7W, WSJT-X calls KH7W, and they respond. 
> > Remember, I said I never saw them call CQ.
> 
> Of course I remember what you wrote.  The point is that you should not 
> need to "click on their call", because you should already have entered 
> the full call KH1/KH7Z in the DX Call box.
> 
> -- 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
--
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] Observation on Expedition Mode

[Black Michael via wsjt-devel]

So let's change the double-click on the Band Activity and tell them that rather 
than processing it."You must enter the DXpedition call yourself in the DX Call 
box".

de Mike W9MDB


 

On Thursday, July 5, 2018, 11:56:20 AM CDT, Joe Taylor  
wrote:  
 
 Jim --

On 7/5/2018 12:49 PM, Jim Brown wrote:
> On 7/5/2018 5:26 AM, Joe Taylor wrote:
>> There should be no need to edit the prefix in DXKeeper.  When 
>> attempting to work a DXpedition you know their callsign perfectly 
>> well, in advance.
> 
> Yes, but -- when you click on their call when they have called someone 
> else, you get KH7W, not KH1/KH7W, WSJT-X calls KH7W, and they respond. 
> Remember, I said I never saw them call CQ.

Of course I remember what you wrote.  The point is that you should not 
need to "click on their call", because you should already have entered 
the full call KH1/KH7Z in the DX Call box.

    -- 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] Observation on Expedition Mode

[Joe Taylor]

Jim --

On 7/5/2018 12:49 PM, Jim Brown wrote:

On 7/5/2018 5:26 AM, Joe Taylor wrote:
There should be no need to edit the prefix in DXKeeper.  When 
attempting to work a DXpedition you know their callsign perfectly 
well, in advance.


Yes, but -- when you click on their call when they have called someone 
else, you get KH7W, not KH1/KH7W, WSJT-X calls KH7W, and they respond. 
Remember, I said I never saw them call CQ.


Of course I remember what you wrote.  The point is that you should not 
need to "click on their call", because you should already have entered 
the full call KH1/KH7Z in the DX Call box.


-- 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] Observation on Expedition Mode

[Jim Brown]

On 7/5/2018 5:26 AM, Joe Taylor wrote:
There should be no need to edit the prefix in DXKeeper.  When attempting 
to work a DXpedition you know their callsign perfectly well, in advance.


Yes, but -- when you click on their call when they have called someone 
else, you get KH7W, not KH1/KH7W, WSJT-X calls KH7W, and they respond. 
Remember, I said I never saw them call CQ.


73,


--
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] Observation on Expedition Mode

[Joe Taylor]

Hi Dave, Jim, and all,

On 7/4/2018 8:56 PM, Jim Brown wrote:

On 7/4/2018 4:40 PM, David Fisher wrote:
Later when I uploaded to ClugLog, I was reminded that I logged the 
wrong callsign.  Easily fixed in ClubLog, but for LOTW, all I could do 
was log the contacts again as KH1/KH7X.


I also simply click on their call when they're sending to someone else. 
I've never seen a CQ from them on FT8, but have worked them four times 
using FT8. I use JTAlert to log into DXKeeper, then edit the prefix in 
DXKeeper.


There should be no need to edit the prefix in DXKeeper.  When attempting 
to work a DXpedition you know their callsign perfectly well, in advance. 
 Item 5 under "Detailed Instructions for Hounds" in

http://physics.princeton.edu/pulsar/k1jt/FT8_DXpedition_Mode.pdf
reads as follows:

"5. Enter Fox’s callsign as DX Call. If Fox is using a compound 
callsign, be sure to enter all of it. The grid locator is optional but 
provides the advantage of displaying the short-path azimuth and distance 
from your location."


The User guide even includes a picture showing "KH1/KH7Z" entered as DX 
Call and "AJ10" as DX Grid.


I think the KH1 Fox operators did an excellent job and made good use of 
the capabilities of FT8 DXpedition Mode.  ClubLog statistics show that 
they made nearly as many FT8 QSOs as SSB QSOs, even though their setup 
has three SSB stations and only two digi-stations.  And some of the 
digi-time was spent on RTTY.  The Fox called CQ when he ran out of 
callers, as expected.  Otherwise he responded to callers -- again, as 
expected.

-- 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] Observation on Expedition Mode

[Tsutsumi Takehiko]

Joe,



It is good to hear from you to increase your calculation about my additional 
gain proposal  from +(1~8) dB to +(1.5~8) dB.



If you look into synch words, you may be able to get another additional gain.



Regards,



take



de JA5AEA



Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10






From: Joe Taylor 
Sent: Wednesday, July 4, 2018 11:27:08 PM
To: WSJT software development
Subject: Re: [wsjt-devel] Observation on Expedition Mode

Hi Take,

On 7/4/2018 9:20 AM, Tsutsumi Takehiko JA5AEA wrote:

> Concerning the “second +4dB term”, I remember Bill’s suggestion included
> hashing of callsign (I used the number of (28-15) x 5 = 65 bit
> reduction). I also reduced five 7x7 synch to one 7x7 synch, which I am
> not sure whether Bill included. I will not further describe the details
> to defend my ballpark number but I can say I disagree with your 0.6dB
> gain calculation, here.

Yes, if you convey less information you can achieve a lower threshold
SNR for decoding.

For this discussion I had assumed 11x28 = 308 bits for callsigns and 5x6
=30 bits for signal reports, 338 bits total.  Compared with the 5x75 =
375 bits for 5xFT8, this leads to a gain of ~0.5 dB.  Steve quoted 0.6
dB because he used 3-bit rather than 6-bit reports.

If we use 13-bit hashes for the callsigns being sent "RR73", the total
would be 6x28 + 5x13 + 5x6 = 263 bits.  Compared to 5xFT8, this yields
10log(375/263) = 1.5 dB.

Apparently you are suggesting something like 150-bit information
content, since 10log(375/150) = 4 dB.  This is not at all the same thing
as 5 FT8 messages.

> As I write to Steve, I do not have any intention to sell or stick to my
> +8dB number. If you feel uncomfortable, please deal it to + (1~8)dB
>   additional gain proposal .

No problem -- we are happy to discuss these things with you!

-- 73, Joe, K1JT


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

Re: [wsjt-devel] Observation on Expedition Mode

[Jim Brown]

On 7/4/2018 6:53 PM, Bill Barrett wrote:

Hello Jim-

I worked them several times and uploaded the contacts Club Log and LOTW but.
On Club Log I see "W" not green "C". No QSL in LOTW.
Just getting started with C.L. am I doing something wrong?


Go to ClubLog, but before you even sign in, click on Expeditions in the 
top right corner, then select this one, and enter your call in the Find 
QSOs window. If you don't see yours listed, look above the Red menu line 
to the time of the Last QSO in database. It often takes a day or so 
before recent QSOs show up here. You should see a green check mark for 
each band/mode where you're in their log.


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] Observation on Expedition Mode

[Bill Barrett]

Hello Jim-

I worked them several times and uploaded the contacts Club Log and LOTW but.
On Club Log I see "W" not green "C". No QSL in LOTW.
Just getting started with C.L. am I doing something wrong?
Thanks;

73;

Bill W2PKY

On Wed, Jul 4, 2018 at 8:56 PM Jim Brown  wrote:

> On 7/4/2018 4:40 PM, David Fisher wrote:
> > Later when I uploaded to ClugLog, I was reminded that I logged the wrong
> > callsign.  Easily fixed in ClubLog, but for LOTW, all I could do was log
> > the contacts again as KH1/KH7X.
>
> I also simply click on their call when they're sending to someone else.
> I've never seen a CQ from them on FT8, but have worked them four times
> using FT8. I use JTAlert to log into DXKeeper, then edit the prefix in
> DXKeeper.
>
> 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
>
--
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] Observation on Expedition Mode

[Jim Brown]

On 7/4/2018 4:40 PM, David Fisher wrote:
Later when I uploaded to ClugLog, I was reminded that I logged the wrong 
callsign.  Easily fixed in ClubLog, but for LOTW, all I could do was log 
the contacts again as KH1/KH7X.


I also simply click on their call when they're sending to someone else. 
I've never seen a CQ from them on FT8, but have worked them four times 
using FT8. I use JTAlert to log into DXKeeper, then edit the prefix in 
DXKeeper.


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] Observation on Expedition Mode

[David Fisher]

I’ll throw my experience in for what it’s worth:

I worked KH1/KH7Z on 20 and 30 within a few minutes a few nights ago.  I had 
Hound mode set, antennas ready, etc.  No problems making the two contacts.

But   I got it started by double clicking one of his reply messages.  There 
were no CQs, and as we have established, they are very rare to nonexistent when 
the band is busy.  So, my DX station ID wound up being set to KH7Z, not 
KH1/KH7Z.  Yes, I know better, but I was focused on making the QSO, not on the 
details.  Since I didn’t have a CQ to work with, I didn’t know his grid.  I had 
to dig around to find it (it is not right out in the open on their website, 
alongside the FT8 instructions, it’s down in the FAQ).

After working him on 20M, the program asked to log the QSO, I said yes, filled 
in the power and logged it.  Then I did the same for 30M a few minutes later.  
After that, happy that I had made a contact and a spare, I uploaded my log to 
LOTW, as I do at the end of every session.

Later when I uploaded to ClugLog, I was reminded that I logged the wrong 
callsign.  Easily fixed in ClubLog, but for LOTW, all I could do was log the 
contacts again as KH1/KH7X.

All of this is, in the end, a minor hassle, but could be avoided if they would 
do as the designers of the system expected, send a CQ every now and then so 
there is something proper to double-click.  Requiring them to do so every now 
and then would reduce the number of errors of this sort.  Perhaps it’s not an 
issue of Fox/Hound mode so much as an issue of compound call signs.  Perhaps 
stations sending a compound callsign need to required to send the full callsign 
periodically to reduce confusion and errors.

Dave / NX6D




From: Black Michael via wsjt-devel 
Sent: Monday, July 2, 2018 10:44:52 AM
To: 'WSJT software development'
Cc: Black Michael
Subject: Re: [wsjt-devel] Observation on Expedition Mode

In the case you give as long as you have the prior decode of them you would 
just double-click it and that solves the problem as you have actually received 
them before.
I assume you would still have them in your Band Activity window.

de Mike W9MDB


On Monday, July 2, 2018, 8:24:55 AM CDT, Russ  wrote:



Hello all.  Maybe I am sticking my nose where it does not belong, because I 
have not used or studied this fox/hound business.  But when I see many stations 
advocating to forcefully block calling a station “blind”, I have to think that 
some care is needed.  I have a lot of experience with FT8 on six meters and 
there at least two conditions that could be considered calling blind, yet are 
justified (I think) and do result in good QSO’s.



1.   I was in a qso and observed a station I wanted to work on another 
frequency.  When I finish my qso I do not hear him anymore but I do know where 
he was.  So I start calling him (either on his frequency or elsewhere).  Very 
often he will come back to me and we have a good qso.  However the software 
does not recognize that I have heard him before.  This is evident because even 
though I may have seen his grid square, the software does not have it when I go 
to log the qso.  This then is calling blind as far as the software is 
concerned.  If the same situation can exist with a fox then preventing it would 
be bad.

2.   QSB.  In this case I start out calling a station that I was copying.  Then 
he fades out before completion (maybe even before I hear an answer).  I 
continue calling him “blind” and in a few minutes he fades back in again, 
calling me.  And many times I have called for 5 or 6 sequences and then 
stopped, only to have him pop up suddenly, giving me a report.



So these are two situations that should not be prevented as they result in good 
qso’s.  I agree that if I were to continue calling for 10 minutes without 
hearing anything more, then I would be causing unnecessary QRM.  Maybe the 
software could have an automatic stop if the fox is calling the same station, 
with the same message, repeatedly for a long time, and without decoding any 
messages from the hound.



If these situations cannot arise with the fox/hound situation then please 
forgive me for “sticking my nose in”.



73 all, Russ K2TXB



From: Black Michael via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net]
Sent: Sunday, July 01, 2018 11:39 PM
To: WSJT software development 
Cc: Black Michael 
Subject: Re: [wsjt-devel] Observation on Expedition Mode



I foolishly thought that the commit message meant what it said.  It should have 
added "when the "More CQs box is checked".



So the only way to solve all the lids calling blind is to block them until they 
receive the DX station at least once (CQ or any other message).  This will 
benefit both sides of the situation.  Less QRM from all the lids and severely 
reduced blind callers causing timeouts.



I'm going to submit a patch to do just this.  I've not heard a single argument 
that thi

Re: [wsjt-devel] Observation on Expedition Mode

[Joe Taylor]

Hi Take,

On 7/4/2018 9:20 AM, Tsutsumi Takehiko JA5AEA wrote:

Concerning the “second +4dB term”, I remember Bill’s suggestion included 
hashing of callsign (I used the number of (28-15) x 5 = 65 bit 
reduction). I also reduced five 7x7 synch to one 7x7 synch, which I am 
not sure whether Bill included. I will not further describe the details 
to defend my ballpark number but I can say I disagree with your 0.6dB 
gain calculation, here.


Yes, if you convey less information you can achieve a lower threshold 
SNR for decoding.


For this discussion I had assumed 11x28 = 308 bits for callsigns and 5x6 
=30 bits for signal reports, 338 bits total.  Compared with the 5x75 = 
375 bits for 5xFT8, this leads to a gain of ~0.5 dB.  Steve quoted 0.6 
dB because he used 3-bit rather than 6-bit reports.


If we use 13-bit hashes for the callsigns being sent "RR73", the total
would be 6x28 + 5x13 + 5x6 = 263 bits.  Compared to 5xFT8, this yields 
10log(375/263) = 1.5 dB.


Apparently you are suggesting something like 150-bit information 
content, since 10log(375/150) = 4 dB.  This is not at all the same thing 
as 5 FT8 messages.


As I write to Steve, I do not have any intention to sell or stick to my 
+8dB number. If you feel uncomfortable, please deal it to + (1~8)dB 
  additional gain proposal .


No problem -- we are happy to discuss these things with you!

-- 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] Observation on Expedition Mode

[Tsutsumi Takehiko]

Steve,

Thank you for your comments.

Ok, I understand what is the disagreement between us.

First, I do not fully understand the point why you object my +4dB gain but I 
need to find modulation theory book in my book sheves (never opened for more 
than 20 years) and check about “ *bit* SNR, Eb/N0” related area before my final 
response. If I can not solve for myself, I can call my local experts without 
bothering you anymore.  But, I am thinking the longer symbol proposal does not 
heart any RF performance including the delay spread, fading performance, 
interference performance and a fraction of a dB gain with non-coherent 
detection given from you is another goody.

Concerning the “second +4dB term”, I remember Bill’s suggestion included 
hashing of callsign (I used the number of (28-15) x 5 = 65 bit reduction). I 
also reduced five 7x7 synch to one 7x7 synch, which I am not sure whether Bill 
included. I will not further describe the details to defend my ballpark number 
but I can say I disagree with your 0.6dB gain calculation, here.

Thank you very much spending your precious time to comment on my +8dB challenge.

Joe,

As I write to Steve, I do not have any intention to sell or stick to my +8dB 
number. If you feel uncomfortable, please deal it to + (1~8)dB  additional gain 
proposal .

take

de JA5AEA

Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10


From: Steven Franke via wsjt-devel 
Sent: Wednesday, July 4, 2018 6:32:00 PM
To: WSJT software development
Cc: Steven Franke
Subject: Re: [wsjt-devel] Observation on Expedition Mode

Hi Take-san,

I meant QRAXX as “Q-ary Repeat-Accumulate Codes for Weak Signal Communications” 
in  Nico’s literature but I do not have any intent to modify wsjt-X “QRA64” 
mode to this discussion.

Understood. But why not scale the well-known results from Nico’s excellent 
QRA64 mode to see what should be possible?


By the increase of symbol length to 64mS (FT64) and 74.7mS (FT128) from 32mS 
(from 160mS FT8 symbol length speed up by factor 5), the gain is 10LOG(64/32) = 
+3dB and 10LOG(74.7/32) = +4dB.

You have shown that the *symbol* SNR (Es/N0) will be doubled if we use 64FSK 
instead of 8FSK, but what matters is the *bit* SNR, Eb/N0.

A single 64FSK symbol conveys 6 bits of information, whereas the 8FSK symbol 
conveys only 3 bits. You neglected to factor this into your calculations. While 
the 64ms 64FSK symbol contains twice the energy of the 32ms 8FSK symbol, the 
energy-per-bit is the same, either way.

There *is* a slight modulation-detection-efficiency advantage to using 64FSK 
instead of 8FSK if the symbol detection is done noncoherently on a 
symbol-by-symbol basis, but the gain is fraction of a dB.  Furthermore, any 
such advantage vanishes if the 8FSK demodulator is configured to detect 
sequences of, say, 2 or 3 symbols rather than individual symbols.

In any case, the 64FSK vs 8FSK advantage was already included in the scaled 
QRA64 example that I described earlier.  I stand by my conclusions.

I also fully agree with Joe’s objection to your "second" +4dB term. Each FT8 
message conveys 75 bits. If we send five of them serially, then we are sending 
375 bits.  If we were to combine the essential information into a single 
packet, it would need to convey a total of 11 callsigns (the Fox call, 5 calls 
to be printed with RR73, and 5 calls to be printed with signal reports_ plus 5 
signal reports. This is a total of 11*28 + 5*3 where I have conservatively used 
only 3 bits for each signal report. Thus, the available savings is 
10*log10(375/323) = 0.6 dB.

73, Steve k9an


--
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] Observation on Expedition Mode

[Steven Franke via wsjt-devel]

Hi Take-san,

> I meant QRAXX as “Q-ary Repeat-Accumulate Codes for Weak Signal 
> Communications” in  Nico’s literature but I do not have any intent to modify 
> wsjt-X “QRA64” mode to this discussion.

Understood. But why not scale the well-known results from Nico’s excellent 
QRA64 mode to see what should be possible?

>  
> By the increase of symbol length to 64mS (FT64) and 74.7mS (FT128) from 32mS 
> (from 160mS FT8 symbol length speed up by factor 5), the gain is 10LOG(64/32) 
> = +3dB and 10LOG(74.7/32) = +4dB. 

You have shown that the *symbol* SNR (Es/N0) will be doubled if we use 64FSK 
instead of 8FSK, but what matters is the *bit* SNR, Eb/N0. 

A single 64FSK symbol conveys 6 bits of information, whereas the 8FSK symbol 
conveys only 3 bits. You neglected to factor this into your calculations. While 
the 64ms 64FSK symbol contains twice the energy of the 32ms 8FSK symbol, the 
energy-per-bit is the same, either way. 

There *is* a slight modulation-detection-efficiency advantage to using 64FSK 
instead of 8FSK if the symbol detection is done noncoherently on a 
symbol-by-symbol basis, but the gain is fraction of a dB.  Furthermore, any 
such advantage vanishes if the 8FSK demodulator is configured to detect 
sequences of, say, 2 or 3 symbols rather than individual symbols.

In any case, the 64FSK vs 8FSK advantage was already included in the scaled 
QRA64 example that I described earlier.  I stand by my conclusions. 

I also fully agree with Joe’s objection to your "second" +4dB term. Each FT8 
message conveys 75 bits. If we send five of them serially, then we are sending 
375 bits.  If we were to combine the essential information into a single 
packet, it would need to convey a total of 11 callsigns (the Fox call, 5 calls 
to be printed with RR73, and 5 calls to be printed with signal reports_ plus 5 
signal reports. This is a total of 11*28 + 5*3 where I have conservatively used 
only 3 bits for each signal report. Thus, the available savings is 
10*log10(375/323) = 0.6 dB. 

73, Steve k9an


--
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] Observation on Expedition Mode

[Tsutsumi Takehiko]

Hi Steve,

I am glad I have received  a memo from Urbana-Champaign.

I am sorry I confused you by the misuse of the terminology about FTXX and 
QRAXX. I meant QRAXX as “Q-ary Repeat-Accumulate Codes for Weak Signal 
Communications” in  Nico’s literature but I do not have any intent to modify 
wsjt-X “QRA64” mode to this discussion. If  your are comfortable by the change 
to FT64 and FT128, then I will use them from now on.

By the increase of symbol length to 64mS (FT64) and 74.7mS (FT128) from 32mS 
(from 160mS FT8 symbol length speed up by factor 5), the gain is 10LOG(64/32) = 
+3dB and 10LOG(74.7/32) = +4dB.  The necessary occupied bandwidth of FT64 is 
1,000Hz and FT128 is 1,714Hz and both are within 3kHz TX limitation.

As we have already included 7dB loss from the speed up by factor 5 in number 
“-14 “, the following figure becomes total +1dB gain even at Nslots=5.

“the figure becomes -14 + 7 + 4  +  4 =  +1 “

I hope the above explanation is satisfactory for you.

Regards,

take

de JA5AEA

Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10



From: Steven Franke via wsjt-devel 
Sent: Wednesday, July 4, 2018 9:48:02 AM
To: WSJT software development
Cc: Steven Franke
Subject: Re: [wsjt-devel] Observation on Expedition Mode

Hi Take-san,


Additional gain comes from:


1.   Adopt QRA64 or QRA128 utilizing 3kHz wide fox TX bandwidth : +4dB gain

I don’t think that there is 4 dB to gain here.

Nico showed that the 50% decoding threshold of QRA64 on the AWGN channel is 
about -26.5 dB under ideal circumstances. With sync losses, the number is about 
-26 dB. The duration of a QRA64 message is 48.4s.

The 50% decoding threshold of standard FT8 on the AWGN channel (including sync 
losses) is about -20.5 dB and the duration of an FT8 signal is 12.6 seconds.

Note that the QRA64 signal contains a 72-bit message payload, whereas FT8 
conveys a 75-bit payload. Let’s ignore the fact that FT8 conveys more bits for 
the moment.

If we shorten the QRA64 signal by a factor of 48.4/12.6=3.84 so that it has the 
same 12.6s duration as an FT8 signal, it’s decoding threshold would be 
increased by 10*log10(3.84)=5.8 dB, resulting in a decoding threshold of -26.0 
+ 5.8 = -20.2 dB, about 0.3 dB worse than FT8. The bandwidth of the sped-up 
QRA64 signal would be 3.84*111 Hz = 426 Hz, or a factor of 8.5 times the 
bandwidth of FT8.

The nearly equal sensitivity of FT8 and QRA64 (scaled to the same duration as 
FT8) would be maintained if both signals were sped up by a factor of 5, say. In 
that case, the decoding threshold of both signals would increase by 7 dB. The 
bandwidth of the sped-up FT8 signal would be 250 Hz, and the bandwidth of the 
QRA64 counterpart would be 5*426=2.1 kHz.

2.   65% packed message length base on Bill’s suggestion : +4dB gain

Of course, I agree that some gain would be available from careful source 
encoding, rather than just sending 5 standard messages serially.

73 Steve, k9an


--
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] Observation on Expedition Mode

[Joe Taylor]

Hi Take,

On 7/3/2018 8:03 PM, Tsutsumi Takehiko JA5AEA wrote:

Joe, Just “listened and watched the show“???

I saw a critical message last night on a Japanese SNS that KH1/KH7Z FT8 
OP should pay their respect to K1JT repeated calls and must promptly 
return RR73.


Never fear, I have worked KH1/KH7Z on 20 and 30m already.  I hope still 
to catch them on 40m.  :-)


This is just my back-of-the envelope calculation, but the link-budget 
improvement can be 15dB, not 7dB at Nslots=5


Additional gain comes from:

 1. Adopt QRA64 or QRA128 utilizing 3kHz wide fox TX bandwidth : +4dB gain
 2. 65% packed message length base on Bill’s suggestion : +4dB gain

Then, the figure becomes -14 + 7 + 4  +  4 =  +1.


Of course I encourage you to design and implement a protocol that will 
achieve this sensitivity improvement!


However: I do not accept either of the +4 dB numbers you have given. 
Steve has already pointed out part of the problem.  You give no details 
of where you think you can gain another +4 dB from changes in "packed 
message length".  I do not think that's achievable, either, while still 
conveying everything (1 Fox callsign, 5 Hound calls with RR73, another 5 
Hounds with a report) in a single message.


-- 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] Observation on Expedition Mode

[Tsutsumi Takehiko]

Joe, Just “listened and watched the show“???



I saw a critical message last night on a Japanese SNS that KH1/KH7Z FT8 OP 
should pay their respect to K1JT repeated calls and must promptly return RR73.



This is just my back-of-the envelope calculation, but the link-budget 
improvement can be 15dB, not 7dB at Nslots=5



Additional gain comes from:



  1.  Adopt QRA64 or QRA128 utilizing 3kHz wide fox TX bandwidth : +4dB gain
  2.  65% packed message length base on Bill’s suggestion : +4dB gain



Then, the figure becomes -14 + 7 + 4  +  4 =  +1.



Regards,



take



de JA5AEA



Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10




From: Joe Taylor 
Sent: Tuesday, July 3, 2018 10:24:56 PM
To: WSJT software development; Tsutsumi Takehiko
Subject: Re: [wsjt-devel] Observation on Expedition Mode

Hi Grant, Take, and all,

I think the Fox operators are learning to manage their pileups
reasonably well.  I listened and watched the show on 40m this morning
for ~2.5 hours, with good signals from Fox.  The Op was doing a good
job: he was using 2 slots, thereby keeping the queue moderately short.
He must have been running ~100/hr.

Most Hounds are learning the proper operating techniques, too.  On 40m
today there were very few calling below 1000 Hz or on the wrong sequence.

I am looking forward to "de-briefing" the Fox operators after they
return home!

As long as we use the present scheme of frequency-multiplexing multiple
slots, there's not much we can do about power levels.  Fox is already
transmitting the strongest undistorted signal he can generate, in each
slot.  It's up to the operators on both sides to watch the signal
reports, recognize and take advantage of the dependence of signal
strength on Nslots, and decide accordingly when to call.

There exists a potentially attractive design alternative.  Rather than
transmitting up to 5 signals spread over the range 300-600 Hz, we could
generate one signal with information payload large enough for (say) 5
QSOs.  Of course this would require more bandwidth -- indeed, roughly
the same 300 Hz total bandwidth as Fox uses presently.  But the
generated waveform would be constant-envelope and therefore could use
the full (Average=PEP) capability of the transmitter.  This would yield
a link-budget improvement of 7 dB at NSlots=5.

-- 73, Joe, K1JT

On 7/2/2018 11:09 PM, Tsutsumi Takehiko wrote:
> Grant,
>
> I am thinking that it is reasonable interpretation to consider CQ
> message, i.e. “CQ, CQ EU, CQ NA, CQ AS…..” is our “paging message” or
> “congestion control message” to allow certain group to send their access
> message such as “KH1/KH7Z JA5AEA PM95” at access channel i.e. above
> 1,000Hz~4,000Hz. However, the power should be limited to the minimum
> power to be able to communicate at individual message exchange as I
> said. However, CQ period should not be fixed and it should be only
> transmitted when “QSO queue” is becoming empty. (I think  this type of
> information is described in FT8 DXpedition Mode User Guide)
>
> Well, for JA wise, KH1/KH7Z is the first exposure to DX Pedition Mode
> without any trial opportunity, so, it is a fan to see the windows in
> WSJT-X and imagine what we should do next.
>
> Yes, It may be the time to wait the chairperson’s summarization and for
> a while, we should  chase KH1/KH7Z last day operation. I am expecting
> they will expand their service at high and low bands.
>
> Regards,
>
> take
>
> de JA5AEA
>
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
> Windows 10
>
> 
> *From:* Grant Willis 
> *Sent:* Tuesday, July 3, 2018 7:05:09 AM
> *To:* 'WSJT software development'
> *Subject:* Re: [wsjt-devel] Observation on Expedition Mode
>
> Everyone,
>
> The thread hi-jacking has been interesting but time to bring it back to
> my original question perhaps please?
>
> Take,
>
> Yes – the problem with varying power is I might hear him CQ when he
> transmits with only one channel but when -14dB of power reduction
> results from 5 responses I could loose him )and did do so several
> times). The CW and the power of the channels I am listening to of him
> calling everyone else needs to remain constant as an individual channel
> otherwise this wildly varying link budget just breaks contacts.
>
> A worthy modification would be to resolve the varying individual channel
> power dilemma I feel. I would be interested in Joe and Steve’s thoughts
> on this?
>
> Regards,
>
> Grant VK5GR
>
> P.S. The CQ calling is nice – and KH1/KH7Z could make better use of it
> and free text to control their pile more – but blocking people calling
> as proposed by others here until certain preconditio

Re: [wsjt-devel] Observation on Expedition Mode

[Jim Brown]

On 7/3/2018 6:24 AM, Joe Taylor wrote:
I think the Fox operators are learning to manage their pileups 
reasonably well.  I listened and watched the show on 40m this morning 
for ~2.5 hours, with good signals from Fox.  The Op was doing a good 
job: he was using 2 slots, thereby keeping the queue moderately short. 
He must have been running ~100/hr.


I worked them last night on 160M when they were using "standard" FT8. 
The rate was MUCH lower than with Fox/Hound mode, and, for the most 
part, he was only working thee "bigger" stations.


Those stations who are either ignorant about, or resistant to, Fox/Hound 
mode are shooting themselves in the foot. As I see it, the principal 
advantages of Fox/Hound mode are 1) that it keeps Fox and the stations 
he's working separate from other callers; and 2) the ability to work 
multiple stations on each cycle.


Certainly the alternative designs you're thinking about to reduce the 
additional power requirements per TX slot are worthwhile if you can pull 
it off!


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] Observation on Expedition Mode

[Steven Franke via wsjt-devel]

Mike,

Surely, those who really want to work the DX will take time to learn how to do 
it. The others will be frustrated and will eventually quit. Along the way, the 
clueless will also cause some QRM. That’s how it works in CW, SSB, and RTTY 
pileups, and I don’t expect FT8 to be any different. As always, the Deserving 
will work the DX.

Steve k9an

> On Jul 3, 2018, at 9:43 AM, Black Michael via wsjt-devel 
>  wrote:
> 
> Surely you jest...nobody reading directionslarge % calling in the 
> blindand they are going to learn how to control themselves based on sig 
> reports and slots?  Not only do the majority not understand how slots affects 
> anything but they won't care either.
> 
> de Mike W9MDB
> 
> 
> On Tuesday, July 3, 2018, 9:38:17 AM CDT, Joe Taylor  
> wrote:
> 
> 
> Grant --
> 
> I understand your story -- and of course the way the link budget depends 
> on the number of slots in use.
> 
> I do not think that making Fox weaker (i.e., always 20 W per signal) is 
> likely to increase QSO rate.  Better that Fox and Hound operators should 
> take note of signal reports each way, learn to recognize and take 
> advantage of the dependence of Fox's signal strength on Nslots, and 
> decide accordingly when to call.
> 
> -- Joe, K1JT
> 
> On 7/3/2018 10:11 AM, Grant Willis wrote:
> > Joe,
> > 
> > Thanks for the reply. Yes it seemed to be going pretty well today on 40m
> > (although the pileup was immense). Looked like definitely 100+ QSO/hr was
> > being achieved which is faster than they were managing on RTTY on 40m the
> > night before.
> > 
> > Your idea of changing the fox signal to a different multiplex but single FSK
> > signal would definitely be one way and the 7dB would help - but I was more
> > thinking is there something we can do so that the per channel power is
> > reduced to be equivalent to the worst case power reduction with 5 channels
> > (or whatever the channel limit was that the operator set) when less carriers
> > are transmitting.
> > 
> > IE. If when transmitting 5 slots I can only send 20W/carrier - then when I
> > am running 4 slots - still only run 20W/carrier but accept that your total
> > combined output power will drop - doesn't matter however as the link budget
> > is set by the individual channel power not the TX total power capacity. Even
> > if you only run one sub-carrier hold it at 20W. I am looking at it from the
> > maintain constant sub-channel power rather than the use all the available
> > power regardless of the number of channels perspective (which is what causes
> > the sub-channel power to vary up to 14dB between 1 and 5 channels active).
> > 
> > Practically, I was seeing good decodes at 3 channels on 20m the other day
> > which for a 500W amp would have been around 50W/carrier - if they had
> > limited the number of channels to 3 and no one channel was ever allowed to
> > send more than 50W as the channel count varied people would have been
> > working against a constant link budget and I feel would have had a better
> > chance of not breaking the QSOs. As it was, whenever the 4th channel
> > appeared I struggled to decode them and if the 5th channel appeared I never
> > decoded them that day. If there were three channels active and they answered
> > me by bringing up the 4th (which I think they did on a couple of occasions)
> > I lost them and could never complete the QSO. It was from that perspective
> > that I made my observations.
> > 
> > FWIW and further comment?
> > 
> > Regards,
> > Grant VK5GR
> > 
> > 
> > -Original Message-
> > From: Joe Taylor [mailto:j...@princeton.edu <mailto:j...@princeton.edu>]
> > Sent: Tuesday, 3 July 2018 10:55 PM
> > To: WSJT software development; Tsutsumi Takehiko
> > Subject: Re: [wsjt-devel] Observation on Expedition Mode
> > 
> > Hi Grant, Take, and all,
> > 
> > I think the Fox operators are learning to manage their pileups
> > reasonably well.  I listened and watched the show on 40m this morning
> > for ~2.5 hours, with good signals from Fox.  The Op was doing a good
> > job: he was using 2 slots, thereby keeping the queue moderately short.
> > He must have been running ~100/hr.
> > 
> > Most Hounds are learning the proper operating techniques, too.  On 40m
> > today there were very few calling below 1000 Hz or on the wrong sequence.
> > 
> > I am looking forward to "de-briefing" the Fox operators after they
> > return home!
> > 
> > As long as we use the present scheme of frequency-multiplexing multiple
> > slots, the

Re: [wsjt-devel] Observation on Expedition Mode

[Joe Taylor]

Mike --

On 7/3/2018 10:43 AM, Black Michael via wsjt-devel wrote:
Surely you jest...nobody reading directionslarge % calling in the 
blindand they are going to learn how to control themselves based on 
sig reports and slots?  Not only do the majority not understand how 
slots affects anything but they won't care either.


No, I'm not joking.  You're being much too skeptical.

Hounds who are not yet successful will learn from those who succeed. 
Already the trend has been steeply upward.


Today on 40m I saw very few Hounds calling blind, and the QSO rate was 
excellent.


As a rule, Hams using WSJT-X to chase DX are neither ignorant nor stupid.

-- 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] Observation on Expedition Mode

[Black Michael via wsjt-devel]

Surely you jest...nobody reading directionslarge % calling in the 
blindand they are going to learn how to control themselves based on sig 
reports and slots?  Not only do the majority not understand how slots affects 
anything but they won't care either.

de Mike W9MDB
 

On Tuesday, July 3, 2018, 9:38:17 AM CDT, Joe Taylor  
wrote:  
 
 Grant --

I understand your story -- and of course the way the link budget depends 
on the number of slots in use.

I do not think that making Fox weaker (i.e., always 20 W per signal) is 
likely to increase QSO rate.  Better that Fox and Hound operators should 
take note of signal reports each way, learn to recognize and take 
advantage of the dependence of Fox's signal strength on Nslots, and 
decide accordingly when to call.

    -- Joe, K1JT

On 7/3/2018 10:11 AM, Grant Willis wrote:
> Joe,
> 
> Thanks for the reply. Yes it seemed to be going pretty well today on 40m
> (although the pileup was immense). Looked like definitely 100+ QSO/hr was
> being achieved which is faster than they were managing on RTTY on 40m the
> night before.
> 
> Your idea of changing the fox signal to a different multiplex but single FSK
> signal would definitely be one way and the 7dB would help - but I was more
> thinking is there something we can do so that the per channel power is
> reduced to be equivalent to the worst case power reduction with 5 channels
> (or whatever the channel limit was that the operator set) when less carriers
> are transmitting.
> 
> IE. If when transmitting 5 slots I can only send 20W/carrier - then when I
> am running 4 slots - still only run 20W/carrier but accept that your total
> combined output power will drop - doesn't matter however as the link budget
> is set by the individual channel power not the TX total power capacity. Even
> if you only run one sub-carrier hold it at 20W. I am looking at it from the
> maintain constant sub-channel power rather than the use all the available
> power regardless of the number of channels perspective (which is what causes
> the sub-channel power to vary up to 14dB between 1 and 5 channels active).
> 
> Practically, I was seeing good decodes at 3 channels on 20m the other day
> which for a 500W amp would have been around 50W/carrier - if they had
> limited the number of channels to 3 and no one channel was ever allowed to
> send more than 50W as the channel count varied people would have been
> working against a constant link budget and I feel would have had a better
> chance of not breaking the QSOs. As it was, whenever the 4th channel
> appeared I struggled to decode them and if the 5th channel appeared I never
> decoded them that day. If there were three channels active and they answered
> me by bringing up the 4th (which I think they did on a couple of occasions)
> I lost them and could never complete the QSO. It was from that perspective
> that I made my observations.
> 
> FWIW and further comment?
> 
> Regards,
> Grant VK5GR
> 
> 
> -Original Message-
> From: Joe Taylor [mailto:j...@princeton.edu]
> Sent: Tuesday, 3 July 2018 10:55 PM
> To: WSJT software development; Tsutsumi Takehiko
> Subject: Re: [wsjt-devel] Observation on Expedition Mode
> 
> Hi Grant, Take, and all,
> 
> I think the Fox operators are learning to manage their pileups
> reasonably well.  I listened and watched the show on 40m this morning
> for ~2.5 hours, with good signals from Fox.  The Op was doing a good
> job: he was using 2 slots, thereby keeping the queue moderately short.
> He must have been running ~100/hr.
> 
> Most Hounds are learning the proper operating techniques, too.  On 40m
> today there were very few calling below 1000 Hz or on the wrong sequence.
> 
> I am looking forward to "de-briefing" the Fox operators after they
> return home!
> 
> As long as we use the present scheme of frequency-multiplexing multiple
> slots, there's not much we can do about power levels.  Fox is already
> transmitting the strongest undistorted signal he can generate, in each
> slot.  It's up to the operators on both sides to watch the signal
> reports, recognize and take advantage of the dependence of signal
> strength on Nslots, and decide accordingly when to call.
> 
> There exists a potentially attractive design alternative.  Rather than
> transmitting up to 5 signals spread over the range 300-600 Hz, we could
> generate one signal with information payload large enough for (say) 5
> QSOs.  Of course this would require more bandwidth -- indeed, roughly
> the same 300 Hz total bandwidth as Fox uses presently.  But the
> generated waveform would be constant-envelope and therefore could use
> the full (Average=PEP) capability of the transmitter.  This would yield
> a link-budget improvement of 

Re: [wsjt-devel] Observation on Expedition Mode

[Joe Taylor]

Grant --

I understand your story -- and of course the way the link budget depends 
on the number of slots in use.


I do not think that making Fox weaker (i.e., always 20 W per signal) is 
likely to increase QSO rate.  Better that Fox and Hound operators should 
take note of signal reports each way, learn to recognize and take 
advantage of the dependence of Fox's signal strength on Nslots, and 
decide accordingly when to call.


-- Joe, K1JT

On 7/3/2018 10:11 AM, Grant Willis wrote:

Joe,

Thanks for the reply. Yes it seemed to be going pretty well today on 40m
(although the pileup was immense). Looked like definitely 100+ QSO/hr was
being achieved which is faster than they were managing on RTTY on 40m the
night before.

Your idea of changing the fox signal to a different multiplex but single FSK
signal would definitely be one way and the 7dB would help - but I was more
thinking is there something we can do so that the per channel power is
reduced to be equivalent to the worst case power reduction with 5 channels
(or whatever the channel limit was that the operator set) when less carriers
are transmitting.

IE. If when transmitting 5 slots I can only send 20W/carrier - then when I
am running 4 slots - still only run 20W/carrier but accept that your total
combined output power will drop - doesn't matter however as the link budget
is set by the individual channel power not the TX total power capacity. Even
if you only run one sub-carrier hold it at 20W. I am looking at it from the
maintain constant sub-channel power rather than the use all the available
power regardless of the number of channels perspective (which is what causes
the sub-channel power to vary up to 14dB between 1 and 5 channels active).

Practically, I was seeing good decodes at 3 channels on 20m the other day
which for a 500W amp would have been around 50W/carrier - if they had
limited the number of channels to 3 and no one channel was ever allowed to
send more than 50W as the channel count varied people would have been
working against a constant link budget and I feel would have had a better
chance of not breaking the QSOs. As it was, whenever the 4th channel
appeared I struggled to decode them and if the 5th channel appeared I never
decoded them that day. If there were three channels active and they answered
me by bringing up the 4th (which I think they did on a couple of occasions)
I lost them and could never complete the QSO. It was from that perspective
that I made my observations.

FWIW and further comment?

Regards,
Grant VK5GR


-Original Message-
From: Joe Taylor [mailto:j...@princeton.edu]
Sent: Tuesday, 3 July 2018 10:55 PM
To: WSJT software development; Tsutsumi Takehiko
Subject: Re: [wsjt-devel] Observation on Expedition Mode

Hi Grant, Take, and all,

I think the Fox operators are learning to manage their pileups
reasonably well.  I listened and watched the show on 40m this morning
for ~2.5 hours, with good signals from Fox.  The Op was doing a good
job: he was using 2 slots, thereby keeping the queue moderately short.
He must have been running ~100/hr.

Most Hounds are learning the proper operating techniques, too.  On 40m
today there were very few calling below 1000 Hz or on the wrong sequence.

I am looking forward to "de-briefing" the Fox operators after they
return home!

As long as we use the present scheme of frequency-multiplexing multiple
slots, there's not much we can do about power levels.  Fox is already
transmitting the strongest undistorted signal he can generate, in each
slot.  It's up to the operators on both sides to watch the signal
reports, recognize and take advantage of the dependence of signal
strength on Nslots, and decide accordingly when to call.

There exists a potentially attractive design alternative.  Rather than
transmitting up to 5 signals spread over the range 300-600 Hz, we could
generate one signal with information payload large enough for (say) 5
QSOs.  Of course this would require more bandwidth -- indeed, roughly
the same 300 Hz total bandwidth as Fox uses presently.  But the
generated waveform would be constant-envelope and therefore could use
the full (Average=PEP) capability of the transmitter.  This would yield
a link-budget improvement of 7 dB at NSlots=5.

-- 73, Joe, K1JT

On 7/2/2018 11:09 PM, Tsutsumi Takehiko wrote:

Grant,

I am thinking that it is reasonable interpretation to consider CQ
message, i.e. "CQ, CQ EU, CQ NA, CQ AS..." is our "paging message" or
"congestion control message" to allow certain group to send their access
message such as "KH1/KH7Z JA5AEA PM95" at access channel i.e. above
1,000Hz~4,000Hz. However, the power should be limited to the minimum
power to be able to communicate at individual message exchange as I
said. However, CQ period should not be fixed and it should be only
transmitted when "QSO queue" is becoming empty. (I think  this type of
information is described in 

Re: [wsjt-devel] Observation on Expedition Mode

[Fred Carvalho]

Hi John and all
John I have also monitored 40mts this morning for a long period and I have
seen your qso.  This time I  watched what was expected. It was the first
time I could qso, calling above 3000Hz. It seemed that in other activities
that I have participated (30m and 20m) the Fox was not monitoring the full
4KHz channel. I had to go down on the channel to QSO.
 I was able to see Fox changing the number of slots from 1 up to 4. Once it
was one signal, I had a good decode. When he increased the number of slots
I lost the Fox, until propagation peeked up again. Pretty in line  to what
is expected.

DXpetion mode is a great achievement for DXpeditions. Fred PY2XB



2018-07-03 10:24 GMT-03:00 Joe Taylor :

> Hi Grant, Take, and all,
>
> I think the Fox operators are learning to manage their pileups reasonably
> well.  I listened and watched the show on 40m this morning for ~2.5 hours,
> with good signals from Fox.  The Op was doing a good job: he was using 2
> slots, thereby keeping the queue moderately short. He must have been
> running ~100/hr.
>
> Most Hounds are learning the proper operating techniques, too.  On 40m
> today there were very few calling below 1000 Hz or on the wrong sequence.
>
> I am looking forward to "de-briefing" the Fox operators after they return
> home!
>
> As long as we use the present scheme of frequency-multiplexing multiple
> slots, there's not much we can do about power levels.  Fox is already
> transmitting the strongest undistorted signal he can generate, in each
> slot.  It's up to the operators on both sides to watch the signal reports,
> recognize and take advantage of the dependence of signal strength on
> Nslots, and decide accordingly when to call.
>
> There exists a potentially attractive design alternative.  Rather than
> transmitting up to 5 signals spread over the range 300-600 Hz, we could
> generate one signal with information payload large enough for (say) 5
> QSOs.  Of course this would require more bandwidth -- indeed, roughly the
> same 300 Hz total bandwidth as Fox uses presently.  But the generated
> waveform would be constant-envelope and therefore could use the full
> (Average=PEP) capability of the transmitter.  This would yield a
> link-budget improvement of 7 dB at NSlots=5.
>
> -- 73, Joe, K1JT
>
> On 7/2/2018 11:09 PM, Tsutsumi Takehiko wrote:
>
>> Grant,
>>
>> I am thinking that it is reasonable interpretation to consider CQ
>> message, i.e. “CQ, CQ EU, CQ NA, CQ AS…..” is our “paging message” or
>> “congestion control message” to allow certain group to send their access
>> message such as “KH1/KH7Z JA5AEA PM95” at access channel i.e. above
>> 1,000Hz~4,000Hz. However, the power should be limited to the minimum power
>> to be able to communicate at individual message exchange as I said.
>> However, CQ period should not be fixed and it should be only transmitted
>> when “QSO queue” is becoming empty. (I think  this type of information is
>> described in FT8 DXpedition Mode User Guide)
>>
>> Well, for JA wise, KH1/KH7Z is the first exposure to DX Pedition Mode
>> without any trial opportunity, so, it is a fan to see the windows in WSJT-X
>> and imagine what we should do next.
>>
>> Yes, It may be the time to wait the chairperson’s summarization and for a
>> while, we should  chase KH1/KH7Z last day operation. I am expecting they
>> will expand their service at high and low bands.
>>
>> Regards,
>>
>> take
>>
>> de JA5AEA
>>
>> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
>> Windows 10
>>
>> 
>> *From:* Grant Willis 
>> *Sent:* Tuesday, July 3, 2018 7:05:09 AM
>> *To:* 'WSJT software development'
>> *Subject:* Re: [wsjt-devel] Observation on Expedition Mode
>>
>> Everyone,
>>
>> The thread hi-jacking has been interesting but time to bring it back to
>> my original question perhaps please?
>>
>> Take,
>>
>> Yes – the problem with varying power is I might hear him CQ when he
>> transmits with only one channel but when -14dB of power reduction results
>> from 5 responses I could loose him )and did do so several times). The CW
>> and the power of the channels I am listening to of him calling everyone
>> else needs to remain constant as an individual channel otherwise this
>> wildly varying link budget just breaks contacts.
>>
>> A worthy modification would be to resolve the varying individual channel
>> power dilemma I feel. I would be interested in Joe and Steve’s thoughts on
>> this?
>>
>> Regards,
>>
>&g

Re: [wsjt-devel] Observation on Expedition Mode

[Joe Taylor]

On 7/3/2018 9:47 AM, Black Michael via wsjt-devel wrote:
That sounds like a jolly good ideabut why only 7dB improvement?  
Wouldn't you recover all the loss from 5 slots=-14dB?


No.

With one signal handling 5 QSOs the information payload must be 
increased from 72 to nearly 360 bits.  The price of having to decode 350 
bits rather than 72 bits is the "other" 7 dB = 10log(360/72).


And how about increasing to 600Hz width and 10 slots?  Another 2X would 
probably be worth it and still stay below 1000 offset.


Nslots is a design parameter; we can set its maximum wherever we choose.

Sensitivity per slot must degrade at least as fast as 1/Nslots, or in dB 
-10log(Nslots).


If we stay with 8-FSK and a r=1/2 code, bandwidth must go up at least in 
proportion to NSlots.



Just think of how many QSOs they could have done at full power and 10 slots.


Let's not get carried away...


For the few times I saw them only saw 2 slots running.


Most of the time on 30, 20, and 17m they have been using NSlots=3 to 5. 
Three slots seems a good choice in many circumstances, and (as we 
established during the pre-expedition tests) can yield rates 200/hr or 
better.

-- 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] Observation on Expedition Mode

[Grant Willis]

Joe,

Thanks for the reply. Yes it seemed to be going pretty well today on 40m
(although the pileup was immense). Looked like definitely 100+ QSO/hr was
being achieved which is faster than they were managing on RTTY on 40m the
night before.

Your idea of changing the fox signal to a different multiplex but single FSK
signal would definitely be one way and the 7dB would help - but I was more
thinking is there something we can do so that the per channel power is
reduced to be equivalent to the worst case power reduction with 5 channels
(or whatever the channel limit was that the operator set) when less carriers
are transmitting.

IE. If when transmitting 5 slots I can only send 20W/carrier - then when I
am running 4 slots - still only run 20W/carrier but accept that your total
combined output power will drop - doesn’t matter however as the link budget
is set by the individual channel power not the TX total power capacity. Even
if you only run one sub-carrier hold it at 20W. I am looking at it from the
maintain constant sub-channel power rather than the use all the available
power regardless of the number of channels perspective (which is what causes
the sub-channel power to vary up to 14dB between 1 and 5 channels active).

Practically, I was seeing good decodes at 3 channels on 20m the other day
which for a 500W amp would have been around 50W/carrier - if they had
limited the number of channels to 3 and no one channel was ever allowed to
send more than 50W as the channel count varied people would have been
working against a constant link budget and I feel would have had a better
chance of not breaking the QSOs. As it was, whenever the 4th channel
appeared I struggled to decode them and if the 5th channel appeared I never
decoded them that day. If there were three channels active and they answered
me by bringing up the 4th (which I think they did on a couple of occasions)
I lost them and could never complete the QSO. It was from that perspective
that I made my observations.

FWIW and further comment?

Regards,
Grant VK5GR


-Original Message-
From: Joe Taylor [mailto:j...@princeton.edu] 
Sent: Tuesday, 3 July 2018 10:55 PM
To: WSJT software development; Tsutsumi Takehiko
Subject: Re: [wsjt-devel] Observation on Expedition Mode

Hi Grant, Take, and all,

I think the Fox operators are learning to manage their pileups 
reasonably well.  I listened and watched the show on 40m this morning 
for ~2.5 hours, with good signals from Fox.  The Op was doing a good 
job: he was using 2 slots, thereby keeping the queue moderately short. 
He must have been running ~100/hr.

Most Hounds are learning the proper operating techniques, too.  On 40m 
today there were very few calling below 1000 Hz or on the wrong sequence.

I am looking forward to "de-briefing" the Fox operators after they 
return home!

As long as we use the present scheme of frequency-multiplexing multiple 
slots, there's not much we can do about power levels.  Fox is already 
transmitting the strongest undistorted signal he can generate, in each 
slot.  It's up to the operators on both sides to watch the signal 
reports, recognize and take advantage of the dependence of signal 
strength on Nslots, and decide accordingly when to call.

There exists a potentially attractive design alternative.  Rather than 
transmitting up to 5 signals spread over the range 300-600 Hz, we could 
generate one signal with information payload large enough for (say) 5 
QSOs.  Of course this would require more bandwidth -- indeed, roughly 
the same 300 Hz total bandwidth as Fox uses presently.  But the 
generated waveform would be constant-envelope and therefore could use 
the full (Average=PEP) capability of the transmitter.  This would yield 
a link-budget improvement of 7 dB at NSlots=5.

-- 73, Joe, K1JT

On 7/2/2018 11:09 PM, Tsutsumi Takehiko wrote:
> Grant,
> 
> I am thinking that it is reasonable interpretation to consider CQ 
> message, i.e. “CQ, CQ EU, CQ NA, CQ AS…..” is our “paging message” or 
> “congestion control message” to allow certain group to send their access 
> message such as “KH1/KH7Z JA5AEA PM95” at access channel i.e. above 
> 1,000Hz~4,000Hz. However, the power should be limited to the minimum 
> power to be able to communicate at individual message exchange as I 
> said. However, CQ period should not be fixed and it should be only 
> transmitted when “QSO queue” is becoming empty. (I think  this type of 
> information is described in FT8 DXpedition Mode User Guide)
> 
> Well, for JA wise, KH1/KH7Z is the first exposure to DX Pedition Mode 
> without any trial opportunity, so, it is a fan to see the windows in 
> WSJT-X and imagine what we should do next.
> 
> Yes, It may be the time to wait the chairperson’s summarization and for 
> a while, we should  chase KH1/KH7Z last day operation. I am expecting 
> they will expand their service at high and low bands

Re: [wsjt-devel] Observation on Expedition Mode

[Black Michael via wsjt-devel]

That sounds like a jolly good ideabut why only 7dB improvement?  Wouldn't 
you recover all the loss from 5 slots=-14dB?
And how about increasing to 600Hz width and 10 slots?  Another 2X would 
probably be worth it and still stay below 1000 offset.
Just think of how many QSOs they could have done at full power and 10 slots.
For the few times I saw them only saw 2 slots running.
de Mike W9MDB




 

On Tuesday, July 3, 2018, 8:27:13 AM CDT, Joe Taylor  
wrote:  
 
 Hi Grant, Take, and all,

I think the Fox operators are learning to manage their pileups 
reasonably well.  I listened and watched the show on 40m this morning 
for ~2.5 hours, with good signals from Fox.  The Op was doing a good 
job: he was using 2 slots, thereby keeping the queue moderately short. 
He must have been running ~100/hr.

Most Hounds are learning the proper operating techniques, too.  On 40m 
today there were very few calling below 1000 Hz or on the wrong sequence.

I am looking forward to "de-briefing" the Fox operators after they 
return home!

As long as we use the present scheme of frequency-multiplexing multiple 
slots, there's not much we can do about power levels.  Fox is already 
transmitting the strongest undistorted signal he can generate, in each 
slot.  It's up to the operators on both sides to watch the signal 
reports, recognize and take advantage of the dependence of signal 
strength on Nslots, and decide accordingly when to call.

There exists a potentially attractive design alternative.  Rather than 
transmitting up to 5 signals spread over the range 300-600 Hz, we could 
generate one signal with information payload large enough for (say) 5 
QSOs.  Of course this would require more bandwidth -- indeed, roughly 
the same 300 Hz total bandwidth as Fox uses presently.  But the 
generated waveform would be constant-envelope and therefore could use 
the full (Average=PEP) capability of the transmitter.  This would yield 
a link-budget improvement of 7 dB at NSlots=5.

    -- 73, Joe, K1JT

On 7/2/2018 11:09 PM, Tsutsumi Takehiko wrote:
> Grant,
> 
> I am thinking that it is reasonable interpretation to consider CQ 
> message, i.e. “CQ, CQ EU, CQ NA, CQ AS…..” is our “paging message” or 
> “congestion control message” to allow certain group to send their access 
> message such as “KH1/KH7Z JA5AEA PM95” at access channel i.e. above 
> 1,000Hz~4,000Hz. However, the power should be limited to the minimum 
> power to be able to communicate at individual message exchange as I 
> said. However, CQ period should not be fixed and it should be only 
> transmitted when “QSO queue” is becoming empty. (I think  this type of 
> information is described in FT8 DXpedition Mode User Guide)
> 
> Well, for JA wise, KH1/KH7Z is the first exposure to DX Pedition Mode 
> without any trial opportunity, so, it is a fan to see the windows in 
> WSJT-X and imagine what we should do next.
> 
> Yes, It may be the time to wait the chairperson’s summarization and for 
> a while, we should  chase KH1/KH7Z last day operation. I am expecting 
> they will expand their service at high and low bands.
> 
> Regards,
> 
> take
> 
> de JA5AEA
> 
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for 
> Windows 10
> 
> 
> *From:* Grant Willis 
> *Sent:* Tuesday, July 3, 2018 7:05:09 AM
> *To:* 'WSJT software development'
> *Subject:* Re: [wsjt-devel] Observation on Expedition Mode
> 
> Everyone,
> 
> The thread hi-jacking has been interesting but time to bring it back to 
> my original question perhaps please?
> 
> Take,
> 
> Yes – the problem with varying power is I might hear him CQ when he 
> transmits with only one channel but when -14dB of power reduction 
> results from 5 responses I could loose him )and did do so several 
> times). The CW and the power of the channels I am listening to of him 
> calling everyone else needs to remain constant as an individual channel 
> otherwise this wildly varying link budget just breaks contacts.
> 
> A worthy modification would be to resolve the varying individual channel 
> power dilemma I feel. I would be interested in Joe and Steve’s thoughts 
> on this?
> 
> Regards,
> 
> Grant VK5GR
> 
> P.S. The CQ calling is nice – and KH1/KH7Z could make better use of it 
> and free text to control their pile more – but blocking people calling 
> as proposed by others here until certain preconditions are met – based 
> on my observations of the traffic patterns I don’t see it helping the 
> situation at all.
> 
> *From:*Tsutsumi Takehiko [mailto:ja5...@outlook.com]
> *Sent:* Monday, 2 July 2018 3:09 PM
> *To:* WSJT software development
> *Subject:* Re: [wsjt-devel] Observation on Expedition Mode
> 
> Grant,
> 

Re: [wsjt-devel] Observation on Expedition Mode

[Joe Taylor]

Hi Grant, Take, and all,

I think the Fox operators are learning to manage their pileups 
reasonably well.  I listened and watched the show on 40m this morning 
for ~2.5 hours, with good signals from Fox.  The Op was doing a good 
job: he was using 2 slots, thereby keeping the queue moderately short. 
He must have been running ~100/hr.


Most Hounds are learning the proper operating techniques, too.  On 40m 
today there were very few calling below 1000 Hz or on the wrong sequence.


I am looking forward to "de-briefing" the Fox operators after they 
return home!


As long as we use the present scheme of frequency-multiplexing multiple 
slots, there's not much we can do about power levels.  Fox is already 
transmitting the strongest undistorted signal he can generate, in each 
slot.  It's up to the operators on both sides to watch the signal 
reports, recognize and take advantage of the dependence of signal 
strength on Nslots, and decide accordingly when to call.


There exists a potentially attractive design alternative.  Rather than 
transmitting up to 5 signals spread over the range 300-600 Hz, we could 
generate one signal with information payload large enough for (say) 5 
QSOs.  Of course this would require more bandwidth -- indeed, roughly 
the same 300 Hz total bandwidth as Fox uses presently.  But the 
generated waveform would be constant-envelope and therefore could use 
the full (Average=PEP) capability of the transmitter.  This would yield 
a link-budget improvement of 7 dB at NSlots=5.


-- 73, Joe, K1JT

On 7/2/2018 11:09 PM, Tsutsumi Takehiko wrote:

Grant,

I am thinking that it is reasonable interpretation to consider CQ 
message, i.e. “CQ, CQ EU, CQ NA, CQ AS…..” is our “paging message” or 
“congestion control message” to allow certain group to send their access 
message such as “KH1/KH7Z JA5AEA PM95” at access channel i.e. above 
1,000Hz~4,000Hz. However, the power should be limited to the minimum 
power to be able to communicate at individual message exchange as I 
said. However, CQ period should not be fixed and it should be only 
transmitted when “QSO queue” is becoming empty. (I think  this type of 
information is described in FT8 DXpedition Mode User Guide)


Well, for JA wise, KH1/KH7Z is the first exposure to DX Pedition Mode 
without any trial opportunity, so, it is a fan to see the windows in 
WSJT-X and imagine what we should do next.


Yes, It may be the time to wait the chairperson’s summarization and for 
a while, we should  chase KH1/KH7Z last day operation. I am expecting 
they will expand their service at high and low bands.


Regards,

take

de JA5AEA

Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for 
Windows 10



*From:* Grant Willis 
*Sent:* Tuesday, July 3, 2018 7:05:09 AM
*To:* 'WSJT software development'
*Subject:* Re: [wsjt-devel] Observation on Expedition Mode

Everyone,

The thread hi-jacking has been interesting but time to bring it back to 
my original question perhaps please?


Take,

Yes – the problem with varying power is I might hear him CQ when he 
transmits with only one channel but when -14dB of power reduction 
results from 5 responses I could loose him )and did do so several 
times). The CW and the power of the channels I am listening to of him 
calling everyone else needs to remain constant as an individual channel 
otherwise this wildly varying link budget just breaks contacts.


A worthy modification would be to resolve the varying individual channel 
power dilemma I feel. I would be interested in Joe and Steve’s thoughts 
on this?


Regards,

Grant VK5GR

P.S. The CQ calling is nice – and KH1/KH7Z could make better use of it 
and free text to control their pile more – but blocking people calling 
as proposed by others here until certain preconditions are met – based 
on my observations of the traffic patterns I don’t see it helping the 
situation at all.


*From:*Tsutsumi Takehiko [mailto:ja5...@outlook.com]
*Sent:* Monday, 2 July 2018 3:09 PM
*To:* WSJT software development
*Subject:* Re: [wsjt-devel] Observation on Expedition Mode

Grant,

Allow me to write my comment on your topic as I have same topic interest 
writing “FOX adaptive power control” in this thread.


Concerning your proposal, i.e.“to have the setting of number of channels 
vs the number of active channels maintain a constant PER CHANNEL TX power”


My comment is

 1. When fox sets 5 slot mode and it activates 5 slots, the average
power per channel is -20*LOG(5) dB=-14dB. This means about 20W per
channel if fox uses 500W linear.

 2. When active channel is actually 1 slot, What does fox obtain the
benefit to maintain link with a particular hound keeping 20W instead
it can transmit 500W?  Please keep in mind fox uses his channel to
send his message to particular fox such as “VK5GR KH7Z -05”, “VK5GR
RR73”. It is not the messages to me JA5AEA.

Re: [wsjt-devel] Observation on Expedition Mode

[Tsutsumi Takehiko]

Grant,

I am thinking that it is reasonable interpretation to consider CQ message, i.e. 
“CQ, CQ EU, CQ NA, CQ AS…..” is our “paging message” or “congestion control 
message” to allow certain group to send their access message such as “KH1/KH7Z 
JA5AEA PM95” at access channel i.e. above 1,000Hz~4,000Hz. However, the power 
should be limited to the minimum power to be able to communicate at individual 
message exchange as I said. However, CQ period should not be fixed and it 
should be only transmitted when “QSO queue” is becoming empty. (I think  this 
type of information is described in FT8 DXpedition Mode User Guide)

Well, for JA wise, KH1/KH7Z is the first exposure to DX Pedition Mode without 
any trial opportunity, so, it is a fan to see the windows in WSJT-X and imagine 
what we should do next.

Yes, It may be the time to wait the chairperson’s summarization and for a 
while, we should  chase KH1/KH7Z last day operation. I am expecting they will 
expand their service at high and low bands.

Regards,

take

de JA5AEA

Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10


From: Grant Willis 
Sent: Tuesday, July 3, 2018 7:05:09 AM
To: 'WSJT software development'
Subject: Re: [wsjt-devel] Observation on Expedition Mode

Everyone,

The thread hi-jacking has been interesting but time to bring it back to my 
original question perhaps please?

Take,

Yes – the problem with varying power is I might hear him CQ when he transmits 
with only one channel but when -14dB of power reduction results from 5 
responses I could loose him )and did do so several times). The CW and the power 
of the channels I am listening to of him calling everyone else needs to remain 
constant as an individual channel otherwise this wildly varying link budget 
just breaks contacts.

A worthy modification would be to resolve the varying individual channel power 
dilemma I feel. I would be interested in Joe and Steve’s thoughts on this?

Regards,
Grant VK5GR

P.S. The CQ calling is nice – and KH1/KH7Z could make better use of it and free 
text to control their pile more – but blocking people calling as proposed by 
others here until certain preconditions are met – based on my observations of 
the traffic patterns I don’t see it helping the situation at all.

From: Tsutsumi Takehiko [mailto:ja5...@outlook.com]
Sent: Monday, 2 July 2018 3:09 PM
To: WSJT software development
Subject: Re: [wsjt-devel] Observation on Expedition Mode

Grant,

Allow me to write my comment on your topic as I have same topic interest 
writing “FOX adaptive power control” in this thread.

Concerning your proposal, i.e.“to have the setting of number of channels vs the 
number of active channels maintain a constant PER CHANNEL TX power”

My comment is


  1.  When fox sets 5 slot mode and it activates 5 slots, the average power per 
channel is -20*LOG(5) dB=-14dB. This means about 20W per channel if fox uses 
500W linear.


  1.  When active channel is actually 1 slot, What does fox obtain the benefit 
to maintain link with a particular hound keeping 20W instead it can transmit 
500W?  Please keep in mind fox uses his channel to send his message to 
particular fox such as “VK5GR KH7Z -05”, “VK5GR RR73”. It is not the messages 
to me JA5AEA.



  1.  Instead,  I agree to keep CQ message to be fixed, i.e. 20W as this is a 
broad cast message. If fox sends 500W, it is disastrous. (KH1/KHZ may be 
confusing us and creating lengthy arguments by this high power CQ feature??)

Regards,

take

de JA5AEA

Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10



From: Grant Willis 
Sent: Saturday, June 30, 2018 9:47:02 PM
To: 'WSJT software development'
Subject: [wsjt-devel] Observation on Expedition Mode

Joe,

An observation if I may about expedition mode. I see with KH1/KH7Z that the 
number of Fox TX channels varies – I presume as they place more stations in the 
queue. As expected, the power per channel drops the more channels running so 
that the amplifiers can keep up. However, this has an unintended consequence 
perhaps of potentially breaking QSOs. A few times now I have started calling 
KH1/KH7Z on 20m when I am receiving them around -09 (but with pretty low 
S-meter  signal strength). Usually this is with 1-2 channels running on their 
downlink. If they go to 3 channels I can still receive but it falls to say -15. 
If they bring up channel 4 and 5 I loose them. There just isn’t the link budget 
left to receive them when the power is split between more than 3 channels in 
this example.

Now the issue is, if they answer me by adding the 4th channel – I wont hear 
them under those conditions. If I am part way through a QSO I can loose the 
RR73 for the same reason if they answer someone else on the 4th channel– simply 
because the link runs out of steam.

Now if I couldn’t hear them in the first place I wouldn’t have tried calling. 
In this 

Re: [wsjt-devel] Observation on Expedition Mode

[Grant Willis]

Everyone,

 

The thread hi-jacking has been interesting but time to bring it back to my
original question perhaps please?

 

Take,

 

Yes - the problem with varying power is I might hear him CQ when he
transmits with only one channel but when -14dB of power reduction results
from 5 responses I could loose him )and did do so several times). The CW and
the power of the channels I am listening to of him calling everyone else
needs to remain constant as an individual channel otherwise this wildly
varying link budget just breaks contacts.

 

A worthy modification would be to resolve the varying individual channel
power dilemma I feel. I would be interested in Joe and Steve's thoughts on
this?

 

Regards,

Grant VK5GR

 

P.S. The CQ calling is nice - and KH1/KH7Z could make better use of it and
free text to control their pile more - but blocking people calling as
proposed by others here until certain preconditions are met - based on my
observations of the traffic patterns I don't see it helping the situation at
all. 

 

From: Tsutsumi Takehiko [mailto:ja5...@outlook.com] 
Sent: Monday, 2 July 2018 3:09 PM
To: WSJT software development
Subject: Re: [wsjt-devel] Observation on Expedition Mode

 

Grant,

 

Allow me to write my comment on your topic as I have same topic interest
writing "FOX adaptive power control" in this thread.

 

Concerning your proposal, i.e."to have the setting of number of channels vs
the number of active channels maintain a constant PER CHANNEL TX power"

 

My comment is 

 

1.  When fox sets 5 slot mode and it activates 5 slots, the average
power per channel is -20*LOG(5) dB=-14dB. This means about 20W per channel
if fox uses 500W linear.

 

2.  When active channel is actually 1 slot, What does fox obtain the
benefit to maintain link with a particular hound keeping 20W instead it can
transmit 500W?  Please keep in mind fox uses his channel to send his message
to particular fox such as "VK5GR KH7Z -05", "VK5GR RR73". It is not the
messages to me JA5AEA.

 

3.  Instead,  I agree to keep CQ message to be fixed, i.e. 20W as this
is a broad cast message. If fox sends 500W, it is disastrous. (KH1/KHZ may
be confusing us and creating lengthy arguments by this high power CQ
feature??)

 

Regards,

 

take

 

de JA5AEA

 

Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986>  for Windows
10

 

 

  _  

From: Grant Willis 
Sent: Saturday, June 30, 2018 9:47:02 PM
To: 'WSJT software development'
Subject: [wsjt-devel] Observation on Expedition Mode 

 

Joe,

 

An observation if I may about expedition mode. I see with KH1/KH7Z that the
number of Fox TX channels varies - I presume as they place more stations in
the queue. As expected, the power per channel drops the more channels
running so that the amplifiers can keep up. However, this has an unintended
consequence perhaps of potentially breaking QSOs. A few times now I have
started calling KH1/KH7Z on 20m when I am receiving them around -09 (but
with pretty low S-meter  signal strength). Usually this is with 1-2 channels
running on their downlink. If they go to 3 channels I can still receive but
it falls to say -15. If they bring up channel 4 and 5 I loose them. There
just isn't the link budget left to receive them when the power is split
between more than 3 channels in this example.

 

Now the issue is, if they answer me by adding the 4th channel - I wont hear
them under those conditions. If I am part way through a QSO I can loose the
RR73 for the same reason if they answer someone else on the 4th channel-
simply because the link runs out of steam.

 

Now if I couldn't hear them in the first place I wouldn't have tried
calling. In this case however, they can disappear under load effectively and
I loose them mid QSO.

 

For future consideration perhaps is to have the setting of number of
channels vs the number of active channels maintain a constant PER CHANNEL TX
power rather than the variable situation we have now. Ie I enable my fox
station to run say 4 channels, but only reply on 1 channel, then the output
power should be the equivalent of the power that would be in that channel if
all 4 were in fact on air but aren't. At least that way I have a constant
link budget I am working with on my comms channel with the fox station
rather than one that can have them drastically cut power mid QSO without
reference to the conditions on the path I am working them via.

 

If what I am describing is not how it is supposed to work already then there
is another factor at work somewhere in the chain to be explored. I would be
happy to discuss this further and use the KH1/KH7Z expedition to observe and
learn more about how the multi-channel nature of the mode works.

 

Regards,

Grant VK5GR

 

--
Check out the vibrant tech community on one of the world's most
enga

Re: [wsjt-devel] Observation on Expedition Mode

[Daniel Ekman]

In hound mode, would it be a good idea to use another watchdog timer to
trigger on received messages from the DX call, perhaps started with a 5 min
period (after first call) and reset to a longer timeout (15min?) on decoded
messages from the DX ? Additional reset by a longer idle period (say
30-60min ?). Of course on receiving a reply to your call you'll be able to
respond, so this should not mess too much with the usual weak signal way of
communication.
This way, you would be able to call initially but further calling needs
decoded messages. Sure it would be reset by a program restart, but perhaps
deter the casual blind caller.
These special functions would be specific to hound mode, also perhaps not
used on VHF and up, if fox/hound ever get popular there.

In fox mode, I can see that blocking seemingly non responding calls can
catch a bunch of serious operators if a QRM station decides to send on top
of the DX and mess with the pileup. Something like this likely needs some
selectable timeout.

Very nice to see this mode activated with dedicated stations on
expeditions, it clearly demonstrates the big potential of this great mode.
73's and happy DX'ing
Daniel SA2KNG
--
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] Observation on Expedition Mode

[Mark Spencer]

I've been watching them (KH1/KH7Z) work various stations on 14 Mhz for the
last 30 Minutes or so.  I have yet to see a single CQ from them.

73
Mark S
VE7AFZ

On Mon, Jul 2, 2018 at 7:38 AM, Bill Turner via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> I have seen kh7z answering stations on 20m last night at -7 to -20
> strength.  Only saw one CQ at 11pm local in NC.
>
> Sent from Yahoo Mail on Android
> 
>
> On Mon, Jul 2, 2018 at 9:24 AM, Russ
>  wrote:
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>
>
> 
> --
> 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] Observation on Expedition Mode

[Black Michael via wsjt-devel]

In the case you give as long as you have the prior decode of them you would 
just double-click it and that solves the problem as you have actually received 
them before.
I assume you would still have them in your Band Activity window.

de Mike W9MDB
 

On Monday, July 2, 2018, 8:24:55 AM CDT, Russ  wrote:  
 
 
Hello all.  Maybe I am sticking my nose where it does not belong, because I 
have not used or studied this fox/hound business.  But when I see many stations 
advocating to forcefully block calling a station “blind”, I have to think that 
some care is needed.  I have a lot of experience with FT8 on six meters and 
there at least two conditions that could be considered calling blind, yet are 
justified (I think) and do result in good QSO’s.

  

1.   I was in a qso and observed a station I wanted to work on another 
frequency.  When I finish my qso I do not hear him anymore but I do know where 
he was.  So I start calling him (either on his frequency or elsewhere).  Very 
often he will come back to me and we have a good qso.  However the software 
does not recognize that I have heard him before.  This is evident because even 
though I may have seen his grid square, the software does not have it when I go 
to log the qso.  This then is calling blind as far as the software is 
concerned.  If the same situation can exist with a fox then preventing it would 
be bad.

2.   QSB.  In this case I start out calling a station that I was copying.  Then 
he fades out before completion (maybe even before I hear an answer).  I 
continue calling him “blind” and in a few minutes he fades back in again, 
calling me.  And many times I have called for 5 or 6 sequences and then 
stopped, only to have him pop up suddenly, giving me a report.

  

So these are two situations that should not be prevented as they result in good 
qso’s.  I agree that if I were to continue calling for 10 minutes without 
hearing anything more, then I would be causing unnecessary QRM.  Maybe the 
software could have an automatic stop if the fox is calling the same station, 
with the same message, repeatedly for a long time, and without decoding any 
messages from the hound.

  

If these situations cannot arise with the fox/hound situation then please 
forgive me for “sticking my nose in”.

  

73 all, Russ K2TXB

  

From: Black Michael via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net] 
Sent: Sunday, July 01, 2018 11:39 PM
To: WSJT software development 
Cc: Black Michael 
Subject: Re: [wsjt-devel] Observation on Expedition Mode

  

I foolishly thought that the commit message meant what it said.  It should have 
added "when the "More CQs box is checked".

  

So the only way to solve all the lids calling blind is to block them until they 
receive the DX station at least once (CQ or any other message).  This will 
benefit both sides of the situation.  Less QRM from all the lids and severely 
reduced blind callers causing timeouts.

  

I'm going to submit a patch to do just this.  I've not heard a single argument 
that this is a bad idea.  The only thing even possibly useful is if the 
DXpedition used these types of callers to see if the band was open which I 
doubt.

  

de Mike W9MDB

  

  

  

  

On Sunday, July 1, 2018, 7:52:05 PM CDT, David Fisher  
wrote: 

  

  

That ain’t happening at KH1/KH7X.  Not on 20M anyway.

 

Dave / NX6D

 

 

From: Black Michael via wsjt-devel 
Sent: Saturday, June 30, 2018 8:39:05 AM
To: 'WSJT software development'
Cc: Black Michael
Subject: Re: [wsjt-devel] Observation on Expedition Mode 

 

  

WSJT-X has already been changed where Fox transmits CQ every 5 transmissions 
now.

If you don't see it then you shouldn't be calling.

  

>From the git log:

  

In DXpedition mode, enforce a Fox CQ at least every 5 transmissions.

  

  

  

On Saturday, June 30, 2018, 10:10:09 AM CDT, Charles Suckling 
 wrote: 

  

  

Hi Mike

 

The problem with needing to see a CQ is that the dxpedition may rarely transmit 
a CQ (some folks were reporting this yesterday).  Then, stations were working 
them by just calling.  Majority were on the correct period, most were above 
1000Hz.  From what I could see here about 90% of hounds were calling correctly. 
 Whether they could hear the dxpedition is another matter.

 

Earlier this afternoon there was a run of CQ from them (or someone pretending 
to be them) about 10dB stronger than they are here most of the time (-18 to 
-20).  During this spell there seemed to be no QSOs.

 

Charlie

From: Black Michael via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net] 
Sent: 30 June 2018 15:15
To: ' WSJT software development '
Cc: Black Michael
Subject: Re: [wsjt-devel] Observation on Expedition Mode

 

I have some observations too.

 

#1 Tons of ops calling KH7Z when they can't see them.  I assume this only 
causes problems as it's quite possible KH7Z with their honker antennas and can 
see them but not the other way round.  So KH7Z will put

Re: [wsjt-devel] Observation on Expedition Mode

[Bill Turner via wsjt-devel]

I have seen kh7z answering stations on 20m last night at -7 to -20 strength.  
Only saw one CQ at 11pm local in NC.

Sent from Yahoo Mail on Android 
 
  On Mon, Jul 2, 2018 at 9:24 AM, Russ wrote:   
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot  
--
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] Observation on Expedition Mode

[Russ]

Hello all.  Maybe I am sticking my nose where it does not belong, because I 
have not used or studied this fox/hound business.  But when I see many stations 
advocating to forcefully block calling a station “blind”, I have to think that 
some care is needed.  I have a lot of experience with FT8 on six meters and 
there at least two conditions that could be considered calling blind, yet are 
justified (I think) and do result in good QSO’s.
 
1.   I was in a qso and observed a station I wanted to work on another 
frequency.  When I finish my qso I do not hear him anymore but I do know where 
he was.  So I start calling him (either on his frequency or elsewhere).  Very 
often he will come back to me and we have a good qso.  However the software 
does not recognize that I have heard him before.  This is evident because even 
though I may have seen his grid square, the software does not have it when I go 
to log the qso.  This then is calling blind as far as the software is 
concerned.  If the same situation can exist with a fox then preventing it would 
be bad.
2.   QSB.  In this case I start out calling a station that I was copying.  Then 
he fades out before completion (maybe even before I hear an answer).  I 
continue calling him “blind” and in a few minutes he fades back in again, 
calling me.  And many times I have called for 5 or 6 sequences and then 
stopped, only to have him pop up suddenly, giving me a report.
 
So these are two situations that should not be prevented as they result in good 
qso’s.  I agree that if I were to continue calling for 10 minutes without 
hearing anything more, then I would be causing unnecessary QRM.  Maybe the 
software could have an automatic stop if the fox is calling the same station, 
with the same message, repeatedly for a long time, and without decoding any 
messages from the hound.
 
If these situations cannot arise with the fox/hound situation then please 
forgive me for “sticking my nose in”.
 
73 all, Russ K2TXB
 
From: Black Michael via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net] 
Sent: Sunday, July 01, 2018 11:39 PM
To: WSJT software development 
Cc: Black Michael 
Subject: Re: [wsjt-devel] Observation on Expedition Mode
 
I foolishly thought that the commit message meant what it said.  It should have 
added "when the "More CQs box is checked".
 
So the only way to solve all the lids calling blind is to block them until they 
receive the DX station at least once (CQ or any other message).  This will 
benefit both sides of the situation.  Less QRM from all the lids and severely 
reduced blind callers causing timeouts.
 
I'm going to submit a patch to do just this.  I've not heard a single argument 
that this is a bad idea.  The only thing even possibly useful is if the 
DXpedition used these types of callers to see if the band was open which I 
doubt.
 
de Mike W9MDB
 
 
 
 
On Sunday, July 1, 2018, 7:52:05 PM CDT, David Fisher  
wrote: 
 
 
That ain’t happening at KH1/KH7X.  Not on 20M anyway.
 
Dave / NX6D
 
 
  _  

From: Black Michael via wsjt-devel 
Sent: Saturday, June 30, 2018 8:39:05 AM
To: 'WSJT software development'
Cc: Black Michael
Subject: Re: [wsjt-devel] Observation on Expedition Mode 
 
 
WSJT-X has already been changed where Fox transmits CQ every 5 transmissions 
now.
If you don't see it then you shouldn't be calling.
 
>From the git log:
 
In DXpedition mode, enforce a Fox CQ at least every 5 transmissions.
 
 
 
On Saturday, June 30, 2018, 10:10:09 AM CDT, Charles Suckling 
 wrote: 
 
 
Hi Mike
 
The problem with needing to see a CQ is that the dxpedition may rarely transmit 
a CQ (some folks were reporting this yesterday).  Then, stations were working 
them by just calling.  Majority were on the correct period, most were above 
1000Hz.  From what I could see here about 90% of hounds were calling correctly. 
 Whether they could hear the dxpedition is another matter.
 
Earlier this afternoon there was a run of CQ from them (or someone pretending 
to be them) about 10dB stronger than they are here most of the time (-18 to 
-20).  During this spell there seemed to be no QSOs.
 
Charlie
  _  

From: Black Michael via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net] 
Sent: 30 June 2018 15:15
To: ' WSJT software development '
Cc: Black Michael
Subject: Re: [wsjt-devel] Observation on Expedition Mode
 
I have some observations too.
 
#1 Tons of ops calling KH7Z when they can't see them.  I assume this only 
causes problems as it's quite possible KH7Z with their honker antennas and can 
see them but not the other way round.  So KH7Z will put them in the queue and 
try to process them taking up the limited slots they are using right now (2 
from what I've seen).  IMHO the solution to this is pretty simplewhen you 
turn on Hound or switch bands you should be PREVENTED FROM TRANSMITTING UNTIL 
YOU GET CQ FRO THE DX STATION.So, you would be required to double-click on 
a CQ to allow transmitting.  I not

Re: [wsjt-devel] Observation on Expedition Mode

[Black Michael via wsjt-devel]

One question maybe some could answer is if they saw a Fox CQ and the Hound 
responses but never saw the Fox secondary messages.  You'd likely see several 
repeats from the hounds that don't see the reduced power signal.

de Mike W9MDB

 

On Monday, July 2, 2018, 12:43:01 AM CDT, Tsutsumi Takehiko 
 wrote:  
 
 
Grant,

  
 
Allow me to write my comment on your topic as I have same topic interest 
writing “FOX adaptive power control” in this thread.

  
 
Concerning your proposal, i.e.“to have the setting of number of channels vs the 
number of active channels maintain a constant PER CHANNEL TX power”

  
 
My comment is 

  

   - When fox sets 5 slot mode and it activates 5 slots, the average power per 
channel is -20*LOG(5) dB=-14dB. This means about 20W per channel if fox uses 
500W linear.

  

   - When active channel is actually 1 slot, What does fox obtain the benefit 
to maintain link with a particular hound keeping 20W instead it can transmit 
500W?  Please keep in mind fox uses his channel to send his message to 
particular fox such as “VK5GR KH7Z -05”, “VK5GR RR73”. It is not the messages 
to me JA5AEA.

  

   - Instead,  I agree to keep CQ message to be fixed, i.e. 20W as this is a 
broad cast message. If fox sends 500W, it is disastrous. (KH1/KHZ may be 
confusing us and creating lengthy arguments by this high power CQ feature??)

  
 
Regards,

  
 
take

  
 
de JA5AEA

  
 
Sent from Mail for Windows 10

  
 
  
 From: Grant Willis 
Sent: Saturday, June 30, 2018 9:47:02 PM
To: 'WSJT software development'
Subject: [wsjt-devel] Observation on Expedition Mode 
Joe,
 
  
 
An observation if I may about expedition mode. I see with KH1/KH7Z that the 
number of Fox TX channels varies – I presume as they place more stations in the 
queue. As expected, the power per channel drops the more channels running so 
that the amplifiers can keep up. However, this has an unintended consequence 
perhaps of potentially breaking QSOs. A few times now I have started calling 
KH1/KH7Z on 20m when I am receiving them around -09 (but with pretty low 
S-meter  signal strength). Usually this is with 1-2 channels running on their 
downlink. If they go to 3 channels I can still receive but it falls to say -15. 
If they bring up channel 4 and 5 I loose them. There just isn’t the link budget 
left to receive them when the power is split between more than 3 channels in 
this example.
 
  
 
Now the issue is, if they answer me by adding the 4th channel – I wont hear 
them under those conditions. If I am part way through a QSO I can loose the 
RR73 for the same reason if they answer someone else on the 4th channel– simply 
because the link runs out of steam.
 
  
 
Now if I couldn’t hear them in the first place I wouldn’t have tried calling. 
In this case however, they can disappear under load effectively and I loose 
them mid QSO.
 
  
 
For future consideration perhaps is to have the setting of number of channels 
vs the number of active channels maintain a constant PER CHANNEL TX power 
rather than the variable situation we have now. Ie I enable my fox station to 
run say 4 channels, but only reply on 1 channel, then the output power should 
be the equivalent of the power that would be in that channel if all 4 were in 
fact on air but aren’t. At least that way I have a constant link budget I am 
working with on my comms channel with the fox station rather than one that can 
have them drastically cut power mid QSO without reference to the conditions on 
the path I am working them via.
 
  
 
If what I am describing is not how it is supposed to work already then there is 
another factor at work somewhere in the chain to be explored. I would be happy 
to discuss this further and use the KH1/KH7Z expedition to observe and learn 
more about how the multi-channel nature of the mode works.
 
  
 
Regards,
 
Grant VK5GR
 
  
 --
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] Observation on Expedition Mode

[Tsutsumi Takehiko]

Grant,

Allow me to write my comment on your topic as I have same topic interest 
writing “FOX adaptive power control” in this thread.

Concerning your proposal, i.e.“to have the setting of number of channels vs the 
number of active channels maintain a constant PER CHANNEL TX power”

My comment is


  1.  When fox sets 5 slot mode and it activates 5 slots, the average power per 
channel is -20*LOG(5) dB=-14dB. This means about 20W per channel if fox uses 
500W linear.


  1.  When active channel is actually 1 slot, What does fox obtain the benefit 
to maintain link with a particular hound keeping 20W instead it can transmit 
500W?  Please keep in mind fox uses his channel to send his message to 
particular fox such as “VK5GR KH7Z -05”, “VK5GR RR73”. It is not the messages 
to me JA5AEA.



  1.  Instead,  I agree to keep CQ message to be fixed, i.e. 20W as this is a 
broad cast message. If fox sends 500W, it is disastrous. (KH1/KHZ may be 
confusing us and creating lengthy arguments by this high power CQ feature??)

Regards,

take

de JA5AEA

Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10



From: Grant Willis 
Sent: Saturday, June 30, 2018 9:47:02 PM
To: 'WSJT software development'
Subject: [wsjt-devel] Observation on Expedition Mode

Joe,

An observation if I may about expedition mode. I see with KH1/KH7Z that the 
number of Fox TX channels varies – I presume as they place more stations in the 
queue. As expected, the power per channel drops the more channels running so 
that the amplifiers can keep up. However, this has an unintended consequence 
perhaps of potentially breaking QSOs. A few times now I have started calling 
KH1/KH7Z on 20m when I am receiving them around -09 (but with pretty low 
S-meter  signal strength). Usually this is with 1-2 channels running on their 
downlink. If they go to 3 channels I can still receive but it falls to say -15. 
If they bring up channel 4 and 5 I loose them. There just isn’t the link budget 
left to receive them when the power is split between more than 3 channels in 
this example.

Now the issue is, if they answer me by adding the 4th channel – I wont hear 
them under those conditions. If I am part way through a QSO I can loose the 
RR73 for the same reason if they answer someone else on the 4th channel– simply 
because the link runs out of steam.

Now if I couldn’t hear them in the first place I wouldn’t have tried calling. 
In this case however, they can disappear under load effectively and I loose 
them mid QSO.

For future consideration perhaps is to have the setting of number of channels 
vs the number of active channels maintain a constant PER CHANNEL TX power 
rather than the variable situation we have now. Ie I enable my fox station to 
run say 4 channels, but only reply on 1 channel, then the output power should 
be the equivalent of the power that would be in that channel if all 4 were in 
fact on air but aren’t. At least that way I have a constant link budget I am 
working with on my comms channel with the fox station rather than one that can 
have them drastically cut power mid QSO without reference to the conditions on 
the path I am working them via.

If what I am describing is not how it is supposed to work already then there is 
another factor at work somewhere in the chain to be explored. I would be happy 
to discuss this further and use the KH1/KH7Z expedition to observe and learn 
more about how the multi-channel nature of the mode works.

Regards,
Grant VK5GR

--
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] Observation on Expedition Mode

[Black Michael via wsjt-devel]

I foolishly thought that the commit message meant what it said.  It should have 
added "when the "More CQs box is checked".
So the only way to solve all the lids calling blind is to block them until they 
receive the DX station at least once (CQ or any other message).  This will 
benefit both sides of the situation.  Less QRM from all the lids and severely 
reduced blind callers causing timeouts.

I'm going to submit a patch to do just this.  I've not heard a single argument 
that this is a bad idea.  The only thing even possibly useful is if the 
DXpedition used these types of callers to see if the band was open which I 
doubt.

de Mike W9MDB


 

On Sunday, July 1, 2018, 7:52:05 PM CDT, David Fisher 
 wrote:  
 
 
That ain’t happening at KH1/KH7X.  Not on 20M anyway.

  
 
Dave / NX6D

  
 
  
 From: Black Michael via wsjt-devel 
Sent: Saturday, June 30, 2018 8:39:05 AM
To: 'WSJT software development'
Cc: Black Michael
Subject: Re: [wsjt-devel] Observation on Expedition Mode 
WSJT-X has already been changed where Fox transmits CQ every 5 transmissions 
now.If you don't see it then you shouldn't be calling.

>From the git log:

In DXpedition mode, enforce a Fox CQ at least every 5 transmissions.



On Saturday, June 30, 2018, 10:10:09 AM CDT, Charles Suckling 
 wrote:


Hi Mike

 

The problem with needing to see a CQ is that the dxpedition may rarely transmit 
a CQ (some folks were reporting this yesterday).  Then, stations were working 
them by just calling.  Majority were on the correct period, most were above 
1000Hz.  From what I could see here about 90% of hounds were calling correctly. 
 Whether they could hear the dxpedition is another matter.

 

Earlier this afternoon there was a run of CQ from them (or someone pretending 
to be them) about 10dB stronger than they are here most of the time (-18 to 
-20).  During this spell there seemed to be no QSOs.

 

Charlie

From: Black Michael via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net] 
Sent: 30 June 2018 15:15
To: ' WSJT software development '
Cc: Black Michael
Subject: Re: [wsjt-devel] Observation on Expedition Mode

 

I have some observations too.

 

#1 Tons of ops calling KH7Z when they can't see them.  I assume this only 
causes problems as it's quite possible KH7Z with their honker antennas and can 
see them but not the other way round.  So KH7Z will put them in the queue and 
try to process them taking up the limited slots they are using right now (2 
from what I've seen).  IMHO the solution to this is pretty simplewhen you 
turn on Hound or switch bands you should be PREVENTED FROM TRANSMITTING UNTIL 
YOU GET CQ FRO THE DX STATION.    So, you would be required to double-click on 
a CQ to allow transmitting.  I noticed the the Baker team gave a lukewarm 
endorsement of FT8 on their news update quite likely due to this problem.

 

#2 We need to turn on spotting for the DX station so that PSKReporter and 
Hamspots can work and also so JTAlert can produce alerts when the DX station is 
received.  Don't need to spot the hounds of course.  Trying to figure out what 
band is good for local ops would be much improved with automatic spotting for 
us and for the DX team who could then see where their signal is going as more 
teams use internet on site via satellite links.

 

de Mike W9MDB

 

 

 

 

 

On Saturday, June 30, 2018, 8:13:39 AM CDT, Grant Willis  
wrote:

 

 

Joe,

 

An observation if I may about expedition mode. I see with KH1/KH7Z that the 
number of Fox TX channels varies – I presume as they place more stations in the 
queue. As expected, the power per channel drops the more channels running so 
that the amplifiers can keep up. However, this has an unintended consequence 
perhaps of potentially breaking QSOs. A few times now I have started calling 
KH1/KH7Z on 20m when I am receiving them around -09 (but with pretty low 
S-meter  signal strength). Usually this is with 1-2 channels running on their 
downlink. If they go to 3 channels I can still receive but it falls to say -15. 
If they bring up channel 4 and 5 I loose them. There just isn’t the link budget 
left to receive them when the power is split between more than 3 channels in 
this example.

 

Now the issue is, if they answer me by adding the 4th channel – I wont hear 
them under those conditions. If I am part way through a QSO I can loose the 
RR73 for the same reason if they answer someone else on the 4th channel– simply 
because the link runs out of steam.

 

Now if I couldn’t hear them in the first place I wouldn’t have tried calling. 
In this case however, they can disappear under load effectively and I loose 
them mid QSO.

 

For future consideration perhaps is to have the setting of number of channels 
vs the number of active channels maintain a constant PER CHANNEL TX power 
rather than the variable situation we have now. Ie I enable my fox station to 
run say 4 channels, but only reply on 1 channel, then the o

Re: [wsjt-devel] Observation on Expedition Mode

[David Fisher]

One would think that it would be reasonable to at least skim the very ample 
instructions that have been put out. But no, it is not about to happen.

Nope, and there is little you can do to change it.  As a person who spends a 
fraction of his time writing documentation, I can tell you from personal 
experience, you can write documents till you’re blue in the face, and they 
won’t read them.  They’ll dive in feet first, make a mess, then jump online and 
complain at you for creating something they can’t figure out how to use.  
Assuming users will read and following instructions is foolish.  If you want 
more order in the FT8/DXpedition world, it will have to be enforced.

Dave / NX6D



From: Gary Kohtala - K7EK via wsjt-devel 
Sent: Saturday, June 30, 2018 11:25:32 AM
To: 'WSJT software development'; John Zantek; Black Michael
Cc: Gary Kohtala - K7EK
Subject: Re: [wsjt-devel] Observation on Expedition Mode

The Baker Island DXpedition has brought out the very worst:  Stations calling 
blind for hours when KH7Z is not even on FT8, incessant calling below 1000 hz, 
calling the wrong call sign (KH7V), calling in the wrong time slot, etc. One 
would think that it would be reasonable to at least skim the very ample 
instructions that have been put out. But no, it is not about to happen. I came 
close to completing for an ATNO on 30m but sadly, I never got his RR73 and did 
not go into their log. So, I continue to fight the
uninformed and apparently clueless hoards that have descended upon the bands. 
And of course throw in bad propagation, low power,
and a less than ideal antenna system and the odds of making the Q are even 
lower. Oh well. There is still time. I'd love to get
KH1 for that ATNO on any mode, any band.

Best regards,

Gary, K7EK

Radcliff, KY (EM77at)

--
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] Observation on Expedition Mode

[David Fisher]

That ain’t happening at KH1/KH7X.  Not on 20M anyway.

Dave / NX6D



From: Black Michael via wsjt-devel 
Sent: Saturday, June 30, 2018 8:39:05 AM
To: 'WSJT software development'
Cc: Black Michael
Subject: Re: [wsjt-devel] Observation on Expedition Mode


WSJT-X has already been changed where Fox transmits CQ every 5 transmissions 
now.
If you don't see it then you shouldn't be calling.

>From the git log:

In DXpedition mode, enforce a Fox CQ at least every 5 transmissions.



On Saturday, June 30, 2018, 10:10:09 AM CDT, Charles Suckling 
 wrote:



Hi Mike



The problem with needing to see a CQ is that the dxpedition may rarely transmit 
a CQ (some folks were reporting this yesterday).  Then, stations were working 
them by just calling.  Majority were on the correct period, most were above 
1000Hz.  From what I could see here about 90% of hounds were calling correctly. 
 Whether they could hear the dxpedition is another matter.



Earlier this afternoon there was a run of CQ from them (or someone pretending 
to be them) about 10dB stronger than they are here most of the time (-18 to 
-20).  During this spell there seemed to be no QSOs.



Charlie



From: Black Michael via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net]
Sent: 30 June 2018 15:15
To: ' WSJT software development '
Cc: Black Michael
Subject: Re: [wsjt-devel] Observation on Expedition Mode



I have some observations too.



#1 Tons of ops calling KH7Z when they can't see them.  I assume this only 
causes problems as it's quite possible KH7Z with their honker antennas and can 
see them but not the other way round.  So KH7Z will put them in the queue and 
try to process them taking up the limited slots they are using right now (2 
from what I've seen).  IMHO the solution to this is pretty simplewhen you 
turn on Hound or switch bands you should be PREVENTED FROM TRANSMITTING UNTIL 
YOU GET CQ FRO THE DX STATION.So, you would be required to double-click on 
a CQ to allow transmitting.  I noticed the the Baker team gave a lukewarm 
endorsement of FT8 on their news update quite likely due to this problem.



#2 We need to turn on spotting for the DX station so that PSKReporter and 
Hamspots can work and also so JTAlert can produce alerts when the DX station is 
received.  Don't need to spot the hounds of course.  Trying to figure out what 
band is good for local ops would be much improved with automatic spotting for 
us and for the DX team who could then see where their signal is going as more 
teams use internet on site via satellite links.



de Mike W9MDB











On Saturday, June 30, 2018, 8:13:39 AM CDT, Grant Willis  
wrote:





Joe,



An observation if I may about expedition mode. I see with KH1/KH7Z that the 
number of Fox TX channels varies – I presume as they place more stations in the 
queue. As expected, the power per channel drops the more channels running so 
that the amplifiers can keep up. However, this has an unintended consequence 
perhaps of potentially breaking QSOs. A few times now I have started calling 
KH1/KH7Z on 20m when I am receiving them around -09 (but with pretty low 
S-meter  signal strength). Usually this is with 1-2 channels running on their 
downlink. If they go to 3 channels I can still receive but it falls to say -15. 
If they bring up channel 4 and 5 I loose them. There just isn’t the link budget 
left to receive them when the power is split between more than 3 channels in 
this example.



Now the issue is, if they answer me by adding the 4th channel – I wont hear 
them under those conditions. If I am part way through a QSO I can loose the 
RR73 for the same reason if they answer someone else on the 4th channel– simply 
because the link runs out of steam.



Now if I couldn’t hear them in the first place I wouldn’t have tried calling. 
In this case however, they can disappear under load effectively and I loose 
them mid QSO.



For future consideration perhaps is to have the setting of number of channels 
vs the number of active channels maintain a constant PER CHANNEL TX power 
rather than the variable situation we have now. Ie I enable my fox station to 
run say 4 channels, but only reply on 1 channel, then the output power should 
be the equivalent of the power that would be in that channel if all 4 were in 
fact on air but aren’t. At least that way I have a constant link budget I am 
working with on my comms channel with the fox station rather than one that can 
have them drastically cut power mid QSO without reference to the conditions on 
the path I am working them via.



If what I am describing is not how it is supposed to work already then there is 
another factor at work somewhere in the chain to be explored. I would be happy 
to discuss this further and use the KH1/KH7Z expedition to observe and learn 
more about how the multi-channel nature of the mode works.



Regards,

Grant VK

Re: [wsjt-devel] Observation on Expedition Mode

[David Fisher]

I would amend this to say that the Hound needs to hear a signal from the Fox 
first.  KH1/KH7Z is seldom calling CQ when things get busy.  Lots of people are 
going to tailgate his transmissions to get into the chase.

Dave / NX6D


From: Black Michael via wsjt-devel 
Sent: Saturday, June 30, 2018 7:14:54 AM
To: 'WSJT software development'
Cc: Black Michael
Subject: Re: [wsjt-devel] Observation on Expedition Mode

I have some observations too.

#1 Tons of ops calling KH7Z when they can't see them.  I assume this only 
causes problems as it's quite possible KH7Z with their honker antennas and can 
see them but not the other way round.  So KH7Z will put them in the queue and 
try to process them taking up the limited slots they are using right now (2 
from what I've seen).  IMHO the solution to this is pretty simplewhen you 
turn on Hound or switch bands you should be PREVENTED FROM TRANSMITTING UNTIL 
YOU GET CQ FRO THE DX STATION.So, you would be required to double-click on 
a CQ to allow transmitting.  I noticed the the Baker team gave a lukewarm 
endorsement of FT8 on their news update quite likely due to this problem.

#2 We need to turn on spotting for the DX station so that PSKReporter and 
Hamspots can work and also so JTAlert can produce alerts when the DX station is 
received.  Don't need to spot the hounds of course.  Trying to figure out what 
band is good for local ops would be much improved with automatic spotting for 
us and for the DX team who could then see where their signal is going as more 
teams use internet on site via satellite links.

de Mike W9MDB





On Saturday, June 30, 2018, 8:13:39 AM CDT, Grant Willis  
wrote:



Joe,



An observation if I may about expedition mode. I see with KH1/KH7Z that the 
number of Fox TX channels varies – I presume as they place more stations in the 
queue. As expected, the power per channel drops the more channels running so 
that the amplifiers can keep up. However, this has an unintended consequence 
perhaps of potentially breaking QSOs. A few times now I have started calling 
KH1/KH7Z on 20m when I am receiving them around -09 (but with pretty low 
S-meter  signal strength). Usually this is with 1-2 channels running on their 
downlink. If they go to 3 channels I can still receive but it falls to say -15. 
If they bring up channel 4 and 5 I loose them. There just isn’t the link budget 
left to receive them when the power is split between more than 3 channels in 
this example.



Now the issue is, if they answer me by adding the 4th channel – I wont hear 
them under those conditions. If I am part way through a QSO I can loose the 
RR73 for the same reason if they answer someone else on the 4th channel– simply 
because the link runs out of steam.



Now if I couldn’t hear them in the first place I wouldn’t have tried calling. 
In this case however, they can disappear under load effectively and I loose 
them mid QSO.



For future consideration perhaps is to have the setting of number of channels 
vs the number of active channels maintain a constant PER CHANNEL TX power 
rather than the variable situation we have now. Ie I enable my fox station to 
run say 4 channels, but only reply on 1 channel, then the output power should 
be the equivalent of the power that would be in that channel if all 4 were in 
fact on air but aren’t. At least that way I have a constant link budget I am 
working with on my comms channel with the fox station rather than one that can 
have them drastically cut power mid QSO without reference to the conditions on 
the path I am working them via.



If what I am describing is not how it is supposed to work already then there is 
another factor at work somewhere in the chain to be explored. I would be happy 
to discuss this further and use the KH1/KH7Z expedition to observe and learn 
more about how the multi-channel nature of the mode works.



Regards,

Grant VK5GR



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! 
http://sdm.link/slashdot<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsdm.link%2Fslashdot=02%7C01%7C%7C650bf19e6da14b8ccf2b08d5de942dcc%7C84df9e7fe9f640afb435%7C1%7C0%7C636659650363994635=UC6zW2ChKaIkdu21K7E0I9LyvZ%2By%2Bv2lJu2dHKQXFnA%3D=0>___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net<mailto:wsjt-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/wsjt-devel<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fwsjt-devel=02%7C01%7C%7C650bf19e6da14b8ccf2b08d5de942dcc%7C84df9e7fe9f640afb435%7C1%7C0%7C636659650363994635=wES0mOJodfn0V4w0yOFPH3A7mfs32Y3mOS2tCrlM%2FFA%3D=0>
--
Che

Re: [wsjt-devel] Observation on Expedition Mode

[Black Michael via wsjt-devel]

What branch has this been checked into?
The master branch doesn't appear to have any such change.
de Mike W9MDB


 

On Sunday, July 1, 2018, 9:37:53 AM CDT, Joe Taylor  
wrote:  
 
 Hi Jarmo,

On 7/1/2018 10:14 AM, jarmo wrote:
> My observations, what more guys making contacts, that smoother
> it goes. And also "hounds" are learning. We have to remember, that
> this is really first dxpeditio with FT8.
> 
> But, suggest that next versions, no change to click other than
> DX.

This change has already been made in source code, and it will certainly 
be in the next release.

> Secondly, disable DX-mode using in regular ft8 freqs. Noticed more
> growing use, not only S01WS.

WSJT-X v1.9.1 already does not allow using DXpedition Mode in the 
conventional FT8 band segments.  If you see stations doing this, you can 
be sure they are not using WSJT-X v1.9.1.

    -- 73, Joe, K1JT

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

Re: [wsjt-devel] Observation on Expedition Mode

[Joe Taylor]

Hi Jarmo,

On 7/1/2018 10:14 AM, jarmo wrote:

My observations, what more guys making contacts, that smoother
it goes. And also "hounds" are learning. We have to remember, that
this is really first dxpeditio with FT8.

But, suggest that next versions, no change to click other than
DX.


This change has already been made in source code, and it will certainly 
be in the next release.



Secondly, disable DX-mode using in regular ft8 freqs. Noticed more
growing use, not only S01WS.


WSJT-X v1.9.1 already does not allow using DXpedition Mode in the 
conventional FT8 band segments.  If you see stations doing this, you can 
be sure they are not using WSJT-X v1.9.1.


-- 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] Observation on Expedition Mode

[jarmo]

My observations, what more guys making contacts, that smoother
it goes. And also "hounds" are learning. We have to remember, that
this is really first dxpeditio with FT8.

But, suggest that next versions, no change to click other than
DX.
Secondly, disable DX-mode using in regular ft8 freqs. Noticed more
growing use, not only S01WS.

Really good job, KUDOS

Jarmo

--
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] Observation on Expedition Mode

[Joe Taylor]

Hi all,

Some here may not already know that not all the early FT8 QSOs made it 
into the first upload from KH1/KH7Z to ClubLog.  They have now caught up 
a bit further.


Some statistics of currently uploaded QSOs:

ModeQSOs  DXCCs

CQ 13,571   105
SSB 8,986   102
FT8 7,71995
RTTY  18827

Total  30,464   124

The KH1 setup includes 3 CW stations, 3 SSB stations, and 2 digital 
stations.  Even so, and despite the fact that some time at one of the 
digi-sstations has been devoted to RTTY, FT8 is producing nearly as many 
QSOs as SSB.


Openings between AJ10 and the US Northeast have been spotty and weak... 
but I'm happy to have them in my log now on both 20 and 30m.  :-)


-- 73, Joe, K1JT

On 6/30/2018 2:56 PM, Joe Taylor wrote:

On 6/30/2018 10:14 AM, Black Michael via wsjt-devel wrote:

... I noticed the the Baker team gave a lukewarm endorsement of FT8 on 
their news update ...


I do not consider their endorsement of FT8 to be lukewarm, at all.

Currently they have uploaded 12,319 QSOs to ClubLog:

CQ   4,735
SSB  4,507
FT8  3,077
---
     12,319

One of their intentions was to run CW amd SSB when band conditions are 
good, when QSO rates can be highest.  FT8 works well even in poorer 
conditions.  I believe they are happy with their decision to use FT8 and 
its DXpedition Mode.


They would be even happier if more people used the correct software and 
followed the Hound operating instructions, preferably with a dollop of 
common sense.


 -- 73, Joe, K1JT

-- 


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


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

Re: [wsjt-devel] Observation on Expedition Mode

[Hasan al-Basri]

1239 UTC 01July18 , 14.090 USB Fox/Hound FT8

Up to 4 streams running -3 dB with a Tribander at 52'. Also seeing them
with 110' CF dipole at -8 db, and with -8 dB on my 6 meter LFA!

In other words, very good signals on 20m

I worked them in less than 2 minutes, probably first call.

Latest 5 streams at -6 dB on Tribander, working well, 3 RR 73 to stations
and 2 reports to other stations, all simultaneous.

Congrats Joe and Team, impressive!

73, N0AN
Hasan


On Sat, Jun 30, 2018 at 8:47 PM Tsutsumi Takehiko 
wrote:

> Joe and all Dx Pedition Mode developers,
>
>
>
> I am with Joe about the share of modes which he raised in the statistics.
>
>
>
> Congratulations and I hope FT8 will soon beat the rest of the modes. FT8
> gives me a new joy about Dx pedition hunting while listening my favorite
> music and writing e-mails to my friends.
>
>
>
> However, we need to be careful about the expected story is right or not
> i.e.  “to run CW and SSB when band conditions are good, when QSO rates can
> be highest.  FT8 works well even in poorer conditions”.
>
>
>
> It is well said that EU is the most difficult continent to QSO with Baker
> Island before the operation. “Continent by Mode” statistic indicates EU
> total average is 8.7% and very small percentage as expected. However, the
> breakdown of mode is 5.3%(SSB), 13%(CW), 7.3%(FT8). FT8 is a half of CW and
> on a par with SSB. I feel EU may be frustrated with FT8 as well as SSB and
> stay at CW mode.
>
>
>
> It is a (scientific) fact that less than 2 days operation statistics would
> not tell the solid answer and thus,  I am carefully watching them.
>
>
>
> Regards,
>
>
>
> take
>
>
>
> de JA5AEA
>
>
>
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
> Windows 10
>
>
> ------
> *From:* Joe Taylor 
> *Sent:* Sunday, July 1, 2018 3:56:39 AM
> *To:* WSJT software development
> *Subject:* Re: [wsjt-devel] Observation on Expedition Mode
>
> On 6/30/2018 10:14 AM, Black Michael via wsjt-devel wrote:
>
> > ... I noticed the the Baker team gave a lukewarm endorsement
> > of FT8 on their news update ...
>
> I do not consider their endorsement of FT8 to be lukewarm, at all.
>
> Currently they have uploaded 12,319 QSOs to ClubLog:
>
> CQ   4,735
> SSB  4,507
> FT8  3,077
> ---
>  12,319
>
> One of their intentions was to run CW amd SSB when band conditions are
> good, when QSO rates can be highest.  FT8 works well even in poorer
> conditions.  I believe they are happy with their decision to use FT8 and
> its DXpedition Mode.
>
> They would be even happier if more people used the correct software and
> followed the Hound operating instructions, preferably with a dollop of
> common sense.
>
> -- 73, Joe, K1JT
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
--
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] Observation on Expedition Mode

[Tsutsumi Takehiko]

Joe and all Dx Pedition Mode developers,



I am with Joe about the share of modes which he raised in the statistics.



Congratulations and I hope FT8 will soon beat the rest of the modes. FT8 gives 
me a new joy about Dx pedition hunting while listening my favorite music and 
writing e-mails to my friends.



However, we need to be careful about the expected story is right or not  i.e.  
“to run CW and SSB when band conditions are good, when QSO rates can be 
highest.  FT8 works well even in poorer conditions”.



It is well said that EU is the most difficult continent to QSO with Baker 
Island before the operation. “Continent by Mode” statistic indicates EU total 
average is 8.7% and very small percentage as expected. However, the breakdown 
of mode is 5.3%(SSB), 13%(CW), 7.3%(FT8). FT8 is a half of CW and on a par with 
SSB. I feel EU may be frustrated with FT8 as well as SSB and stay at CW mode.



It is a (scientific) fact that less than 2 days operation statistics would not 
tell the solid answer and thus,  I am carefully watching them.



Regards,



take



de JA5AEA



Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10




From: Joe Taylor 
Sent: Sunday, July 1, 2018 3:56:39 AM
To: WSJT software development
Subject: Re: [wsjt-devel] Observation on Expedition Mode

On 6/30/2018 10:14 AM, Black Michael via wsjt-devel wrote:

> ... I noticed the the Baker team gave a lukewarm endorsement
> of FT8 on their news update ...

I do not consider their endorsement of FT8 to be lukewarm, at all.

Currently they have uploaded 12,319 QSOs to ClubLog:

CQ   4,735
SSB  4,507
FT8  3,077
---
 12,319

One of their intentions was to run CW amd SSB when band conditions are
good, when QSO rates can be highest.  FT8 works well even in poorer
conditions.  I believe they are happy with their decision to use FT8 and
its DXpedition Mode.

They would be even happier if more people used the correct software and
followed the Hound operating instructions, preferably with a dollop of
common sense.

-- 73, Joe, K1JT

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

Re: [wsjt-devel] Observation on Expedition Mode

[John L. Broughton]

A friend of mine from my amateur radio club, Yavapai Amateur Radio Club, 
Prescott, AZ, is one of the ops on the Baker Island DXpedition. He has 
lots of experience working the CQ World Wide CW Contest with the Voodoo 
Contest Group in African and Middle Eastern countries. I'm really 
looking forward to talking to him when he gets back to get feedback on 
how things were on their end.


John, WB9VGJ

John L. Broughton
www.wb9vgj.us
wb9...@arrl.net
2silverhon...@gmail.com

On 6/30/2018 12:50 PM, Black Michael via wsjt-devel wrote:
I would like to approach this idea with some set of principles that 
everybody can agree on...so here goes...


#1 Maximize QSO rate
#2 Minimize blind callers

Just those two principles are enough to say we should do whatever we 
can to reduce blind callers which will also help to maximize QSO rate 
as they are inversely relates (i.e. fewer blind means > qso rate).


Now...to take the logic to the extreme...if all callers were blind 
then the QSO rate would be zero...quite obviously an undesirable 
situation.  As the % of blind callers reduces the QSO rate 
increases...and the QSO rate is maximized when nobody is blind (notice 
we're not considering band conditions here as that is not something we 
can anything about).


So...given the two extremes which should we strive to support?

"good enough" is for horseshoes and hand grenades as the saying goes.  
So why would we NOT try to minimize blind callers when it's an easy 
software change to do so?  This would have no changes on the fox 
side...only the hounds


de Mike W9MDB






On Saturday, June 30, 2018, 11:13:07 AM CDT, Bill Somerville 
 wrote:



Hi Mike,

we are not hear to determine how operators at a DXpedition site choose 
to operate, we are not aware of conditions on the ground. If they feel 
that they are getting optimum rates without calling CQ then that is 
their choice. Remember that calling CQ from a rare entity can result 
in a passband 100% full of pile up, they may have tried it and decided 
it doesn't help the QSO rate.


73
Bill
G4WJS.

On 30/06/2018 17:05, Black Michael via wsjt-devel wrote:
But what about them receiving all these calls in the blind?  Isn't 
that going to interfere when they try to respond to people who can't 
hear them?


Mike




On Saturday, June 30, 2018, 11:04:11 AM CDT, Bill Somerville 
  wrote:



On 30/06/2018 16:57, Black Michael via wsjt-devel wrote:
OK...so it appears the CQ every 5 trasnmissions is NOT enforced 
unless Fox clicks the "More CQs" box.
We'd be a lot better off if this was always forced and Hounds were 
restricted to only answer CQ's.
This explains why we don't see the CQ's and calling blind is 
normally necessary (as long as you can see KH7Z that is).


if(m_tFoxTxSinceCQ>=m_foxCQtimeandui->cbMoreCQs->isChecked()){

de Mike W9MDB



Hi Mike,

it should be reasonable to assume that if the Baker Is. operators are 
not enforcing regular CQ calls then they have plenty of callers to 
keep the to-be-worked queue populated with more stations than Tx 
slots and a QSO rate that is high.




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

 
	Virus-free. www.avg.com 
 



<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>


--
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] Observation on Expedition Mode

[James Shaver]

I’ve literally only heard them with FT8 (still haven’t gotten them in the log 
because I could only hear them for about an hour on 20 and an hour on 30 at -20 
and below) – I’ve heard the pileup for CW and SSB but can’t hear Baker at all.  
If that trend continues, my ONLY chance of getting them in the log will be FT8. 
 To me, that’s pretty darn cool as I otherwise would not have a shot.  

 

Jim S. 

N2ADV

 

From: Glen Brown [mailto:210g...@gmail.com] 
Sent: Saturday, June 30, 2018 6:49 PM
To: WSJT software development
Subject: Re: [wsjt-devel] Observation on Expedition Mode

 

In my opinion FT8 has been working great in its first outing.  And it's proven 
robust enough to keep working when some operators are not set up correctly.  
Just RTFM and you'll do well.  

And don't be threatened by a new way of operating.  As Joe points out, work 
them CW and SSB when you can, FT8 when you can't.  This is a great opportunity 
for low power and antenna-limited stations to get a new one.  

Kudos to the FT8 development team.

73, Glen W6GJB

 

On Sat, Jun 30, 2018 at 11:56 AM, Joe Taylor  wrote:

On 6/30/2018 10:14 AM, Black Michael via wsjt-devel wrote:

... I noticed the the Baker team gave a lukewarm endorsement of FT8 on their 
news update ...


I do not consider their endorsement of FT8 to be lukewarm, at all.

Currently they have uploaded 12,319 QSOs to ClubLog:

CQ   4,735
SSB  4,507
FT8  3,077
---
12,319

One of their intentions was to run CW amd SSB when band conditions are good, 
when QSO rates can be highest.  FT8 works well even in poorer conditions.  I 
believe they are happy with their decision to use FT8 and its DXpedition Mode.

They would be even happier if more people used the correct software and 
followed the Hound operating instructions, preferably with a dollop of common 
sense.

-- 73, Joe, K1JT



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

 

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

Re: [wsjt-devel] Observation on Expedition Mode

[Glen Brown]

In my opinion FT8 has been working great in its first outing.  And it's
proven robust enough to keep working when some operators are not set up
correctly.  Just RTFM and you'll do well.
And don't be threatened by a new way of operating.  As Joe points out, work
them CW and SSB when you can, FT8 when you can't.  This is a great
opportunity for low power and antenna-limited stations to get a new one.
Kudos to the FT8 development team.
73, Glen W6GJB

On Sat, Jun 30, 2018 at 11:56 AM, Joe Taylor  wrote:

> On 6/30/2018 10:14 AM, Black Michael via wsjt-devel wrote:
>
> ... I noticed the the Baker team gave a lukewarm endorsement of FT8 on
>> their news update ...
>>
>
> I do not consider their endorsement of FT8 to be lukewarm, at all.
>
> Currently they have uploaded 12,319 QSOs to ClubLog:
>
> CQ   4,735
> SSB  4,507
> FT8  3,077
> ---
> 12,319
>
> One of their intentions was to run CW amd SSB when band conditions are
> good, when QSO rates can be highest.  FT8 works well even in poorer
> conditions.  I believe they are happy with their decision to use FT8 and
> its DXpedition Mode.
>
> They would be even happier if more people used the correct software and
> followed the Hound operating instructions, preferably with a dollop of
> common sense.
>
> -- 73, Joe, K1JT
>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Observation on Expedition Mode

[Saku]

I also agree with Mike. Blind calling should be prevented somehow by software. 

People do not read manuals, unfortunately.

JT and FT modes have clearly shown "diode" conditions of bands. Blind 
transmitter does not receive Dx, but Dx may copy him well and waste his time 
trying to make qso.
Of course this works also other way around, you may hear Dx but he does not 
hear you. How ever this does not take Dx's time for trying to make qso that 
does not succeed, what should be the goal to maximize Dx's qso rate. 

So preventing this requires software to decide when to fire transmitter.
Do not rely on operator he is blinded because he needs qso and does anything, 
against manuals, to get it.

It does not have to be Cq to be heard first before releasing transmitter. It 
just needs to be any transmission from the call that is entered to Dx call edit 
box by hound operator.

-- 
Saku
OH1KH   --
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] Observation on Expedition Mode

[Black Michael via wsjt-devel]

I would like to approach this idea with some set of principles that everybody 
can agree on...so here goes...
#1 Maximize QSO rate#2 Minimize blind callers
Just those two principles are enough to say we should do whatever we can to 
reduce blind callers which will also help to maximize QSO rate as they are 
inversely relates (i.e. fewer blind means > qso rate).

Now...to take the logic to the extreme...if all callers were blind then the QSO 
rate would be zero...quite obviously an undesirable situation.  As the % of 
blind callers reduces the QSO rate increases...and the QSO rate is maximized 
when nobody is blind (notice we're not considering band conditions here as that 
is not something we can anything about).
So...given the two extremes which should we strive to support?
"good enough" is for horseshoes and hand grenades as the saying goes.  So why 
would we NOT try to minimize blind callers when it's an easy software change to 
do so?  This would have no changes on the fox side...only the hounds
de Mike W9MDB




 

On Saturday, June 30, 2018, 11:13:07 AM CDT, Bill Somerville 
 wrote:  
 
  Hi Mike,
 
 we are not hear to determine how operators at a DXpedition site choose to 
operate, we are not aware of conditions on the ground. If they feel that they 
are getting optimum rates without calling CQ then that is their choice. 
Remember that calling CQ from a rare entity can result in a passband 100% full 
of pile up, they may  have tried it and decided it doesn't help the QSO rate.
 
 73
 Bill
 G4WJS.
 
 On 30/06/2018 17:05, Black Michael via wsjt-devel wrote:
  
   But what about them receiving all these calls in the blind?  Isn't that 
going to interfere when they try to respond to people who can't hear them? 
  Mike
  
   

  
  On Saturday, June 30, 2018, 11:04:11 AM CDT, Bill Somerville 
 wrote:  
  
 On 30/06/2018 16:57, Black Michael via wsjt-devel wrote:
  
  OK...so it appears the CQ every 5 trasnmissions is NOT enforced unless Fox 
clicks the "More CQs" box. We'd be a lot better off if this was always forced 
and Hounds were restricted to only answer CQ's. This explains why we don't see 
the CQ's and calling blind is normally necessary (as long as you can see KH7Z 
that is).
  
   if(m_tFoxTxSinceCQ >= m_foxCQtime and ui->cbMoreCQs->isChecked()) {
  
  de Mike W9MDB
  
   

 
Hi Mike,
 
it should be reasonable to assume that if the Baker Is. operators are not 
enforcing regular CQ calls then they have plenty of callers to keep the 
to-be-worked queue populated with more stations than Tx slots and a QSO rate 
that is high.
  
 

 
 --
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] Observation on Expedition Mode

[Charles Suckling]

Hi Mike

 

I think this is worth considering. 

 

Or maybe a warning message like 'Do you *really* want to call when you have
not yet decoded the fox?' 

 

Charlie

 

  _  

From: Black Michael via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net]

Sent: 30 June 2018 20:21
To: wsjt-devel@lists.sourceforge.net
Cc: Black Michael
Subject: Re: [wsjt-devel] Observation on Expedition Mode

 

I'll modify the idea to recognize ANY call from the DXpedition (i.e. the
call in the DX Call box).

Surely you'd have to agree that you should see them once before
calling...either CQ or answering somebody else.  And the software should
enforce it.

 

de Mike W9MDB

 

 

 

 

On Saturday, June 30, 2018, 1:26:42 PM CDT, John L. Broughton
<2silverhon...@gmail.com> wrote: 

 

 

I can't say I agree with Mike that one should have to answer a CQ to work
the DXpedition station.

I worked KH7Z on 17M this past Thursday. However, in the time I was on the
frequency, I did not decode any CQ. KH7Z was working stations the entire
time I was on frequency. I simply kept an eye on his signal strength which
was varying from about -22 to -15. I set my transmit frequency at 3343 and
started calling. It didn't take very long, just several minutes, before he
called me and we completed the QSO. My report to him was -22 and his to me
was -06 (I'm running a hy-gain DX-88 vertical with my IC-7300; hardly a DX
big gun.) If I would have had to answer a CQ in order to work him, I could
not have gotten the QSO due to the short time I had to try to make  it and
with him just working station after station, not needing to call CQ.

I was watching the stations he was calling to make sure they weren't, say,
all in Europe, as I did not know if he had called CQ for any particular
region. As most all the stations he was working were in the US, I had no
hesitation about calling him.

As far as finding where KH7Z is operating, I've just been using the HB9DRV-9
DX Cluster spots option in m HRD logbook program (I don't run the main HRD
program.) or just selecting various bands in the right hand window of it to
see if and where he is operating then, if on SSB or FT8, I go to the
frequency to see if he is strong enough to work.

John, WB9VGJ

John L. Broughton
www.wb9vgj.us
wb9...@arrl.net
2silverhon...@gmail.com

On 6/30/2018 7:14 AM, Black Michael via wsjt-devel wrote:

I have some observations too.

 

#1 Tons of ops calling KH7Z when they can't see them.  I assume this only
causes problems as it's quite possible KH7Z with their honker antennas and
can see them but not the other way round.  So KH7Z will put them in the
queue and try to process them taking up the limited slots they are using
right now (2 from what I've seen).  IMHO the solution to this is pretty
simplewhen you turn on Hound or switch bands you should be PREVENTED
FROM TRANSMITTING UNTIL YOU GET CQ FRO THE DX STATION.So, you would be
required to double-click on a CQ to allow transmitting.  I noticed the the
Baker team gave a lukewarm endorsement of FT8 on their news update quite
likely due to this problem.

 

#2 We need to turn on spotting for the DX station so that PSKReporter and
Hamspots can work and also so JTAlert can produce alerts when the DX station
is received.  Don't need to spot the hounds of course.  Trying to figure out
what band is good for local ops would be much improved with automatic
spotting for us and for the DX team who could then see where their signal is
going as more teams use internet on site via satellite links.

 

de Mike W9MDB

 

 

 

 

 

On Saturday, June 30, 2018, 8:13:39 AM CDT, Grant Willis
<mailto:vk...@bigpond.com>  wrote: 

 

 

Joe,

 

An observation if I may about expedition mode. I see with KH1/KH7Z that the
number of Fox TX channels varies - I presume as they place more stations in
the queue. As expected, the power per channel drops the more channels
running so that the amplifiers can keep up. However, this has an unintended
consequence perhaps of potentially breaking QSOs. A few times now I have
started calling KH1/KH7Z on 20m when I am receiving them around -09 (but
with pretty low S-meter  signal strength). Usually this is with 1-2 channels
running on their downlink. If they go to 3 channels I can still receive but
it falls to say -15. If they bring up channel 4 and 5 I loose them. There
just isn't the link budget left to receive them when the power is split
between more than 3 channels in this example.

 

Now the issue is, if they answer me by adding the 4th channel - I wont hear
them under those conditions. If I am part way through a QSO I can loose the
RR73 for the same reason if they answer someone else on the 4th channel-
simply because the link runs out of steam.

 

Now if I couldn't hear them in the first place I wouldn't have tried
calling. In this case however, they can disappear under load effectively and
I loose them mid QSO.

 

For future consideration perhaps is to have the setting of number of

Re: [wsjt-devel] Observation on Expedition Mode

[Black Michael via wsjt-devel]

I'll modify the idea to recognize ANY call from the DXpedition (i.e. the call 
in the DX Call box).Surely you'd have to agree that you should see them once 
before calling...either CQ or answering somebody else.  And the software should 
enforce it.

de Mike W9MDB


 

On Saturday, June 30, 2018, 1:26:42 PM CDT, John L. Broughton 
<2silverhon...@gmail.com> wrote:  
 
  I can't say I agree with Mike that one should have to answer a CQ to work the 
DXpedition station.
 
 I worked KH7Z on 17M this past Thursday. However, in the time I was on the 
frequency, I did not decode any CQ. KH7Z was working stations the entire time I 
was on frequency. I simply kept an eye on his signal strength which was varying 
from about -22 to -15. I set my transmit frequency at 3343 and started calling. 
It didn't take very long, just several minutes, before he called me and we 
completed the QSO. My report to him was -22 and his to me was -06 (I'm running 
a hy-gain DX-88 vertical with my IC-7300; hardly a DX big gun.) If I would have 
had to answer a CQ in order to work him, I could not have gotten the QSO due to 
the short time I had to try to make  it and with him just working station after 
station, not needing to call CQ.
 
 I was watching the stations he was calling to make sure they weren't, say, all 
in Europe, as I did not know if he had called CQ for any particular region. As 
most all the stations he was working were in the US, I had no hesitation about 
calling him.
 
 As far as finding where KH7Z is operating, I've just been using the HB9DRV-9 
DX Cluster spots option in m HRD logbook program (I don't run the main HRD 
program.) or just selecting various bands in the right hand window of it to see 
if and where he is operating then, if on SSB or FT8, I go to the frequency to 
see if he is strong enough  to work.
 
 John, WB9VGJ
 John L. Broughton
www.wb9vgj.us
wb9...@arrl.net
2silverhon...@gmail.com On 6/30/2018 7:14 AM, Black Michael via wsjt-devel 
wrote:
  
I have some observations too. 
  #1 Tons of ops calling KH7Z when they can't see them.  I assume this only 
causes problems as it's quite possible KH7Z with their honker antennas and can 
see them but not the other way round.  So KH7Z will put them in the queue and 
try to process them taking up the limited slots they are using right now (2 
from what I've seen).  IMHO the solution to this is pretty simplewhen you 
turn on Hound or switch bands you should be PREVENTED FROM TRANSMITTING UNTIL 
YOU GET CQ FRO THE DX STATION.    So, you would be required to double-click on 
a CQ to allow transmitting.  I noticed the the Baker team gave a lukewarm 
endorsement of FT8 on their news update quite likely due to this problem.
  
  #2 We need to turn on spotting for the DX station so that PSKReporter and 
Hamspots can work and also so JTAlert can produce alerts when the DX station is 
received.  Don't need to spot the hounds of course.  Trying to figure out what 
band is good for local ops would be much improved with automatic spotting for 
us and for the DX team who could then see where their signal is going as more 
teams use internet on site via satellite links. 
  de Mike W9MDB
  
  
   

  
  On Saturday, June 30, 2018, 8:13:39 AM CDT, Grant Willis 
 wrote:  
  
  
Joe,
 
  
 
An observation if I may about expedition mode. I see with KH1/KH7Z that the 
number of Fox TX channels varies – I presume as they place more stations in the 
queue. As expected, the power per channel drops the more channels running so 
that the  amplifiers can keep up. However, this has an unintended consequence 
perhaps of potentially breaking QSOs. A few times now I have started calling 
KH1/KH7Z on 20m when I am receiving them around -09 (but with pretty low 
S-meter  signal strength). Usually this is with 1-2 channels running on their 
downlink. If they go to 3 channels I can still receive but it falls to say -15. 
If they bring up channel 4 and 5 I loose them. There just isn’t the link budget 
left to  receive them when the power is split between more than 3 channels in 
this example.
 
  
 
Now the issue is, if they answer me by adding the 4th channel – I wont hear 
them under those conditions. If I am part way through a QSO I can loose the 
RR73 for the same reason if they answer someone else on the 4th channel– simply 
because the link runs out of steam.
 
  
 
Now if I couldn’t hear them in the first place I wouldn’t have tried calling. 
In this case however, they can disappear under load effectively and I loose 
them mid QSO.
 
  
 
For future consideration perhaps is to have the setting of number of channels 
vs the number of active channels maintain a constant PER CHANNEL TX power 
rather than the variable situation we have now. Ie I enable my fox station to 
run say 4  channels, but only reply on 1 channel, then the output power should 
be the equivalent of the power that would be in that channel if all 4 were in 
fact on air but aren’t. At least that 

Re: [wsjt-devel] Observation on Expedition Mode

[James Shaver]

There are several people who have outright said they refuse to use 1.9.1 (or 
WSJTX in general) and/or that they refuse to use DXPedition Mode because they 
“don’t agree with being forced to use it.”  I’m willing to bet some of the 
people causing QRM fall into that category, as well, for some odd reason.  

 

Jim S.

N2ADV

 

From: Gary Kohtala - K7EK via wsjt-devel 
[mailto:wsjt-devel@lists.sourceforge.net] 
Sent: Saturday, June 30, 2018 2:26 PM
To: 'WSJT software development'; John Zantek; Black Michael
Cc: Gary Kohtala - K7EK
Subject: Re: [wsjt-devel] Observation on Expedition Mode

 

The Baker Island DXpedition has brought out the very worst:  Stations calling 
blind for hours when KH7Z is not even on FT8, incessant calling below 1000 hz, 
calling the wrong call sign (KH7V), calling in the wrong time slot, etc. One 
would think that it would be reasonable to at least skim the very ample 
instructions that have been put out. But no, it is not about to happen. I came 
close to completing for an ATNO on 30m but sadly, I never got his RR73 and did 
not go into their log. So, I continue to fight the 

uninformed and apparently clueless hoards that have descended upon the bands. 
And of course throw in bad propagation, low power, 

and a less than ideal antenna system and the odds of making the Q are even 
lower. Oh well. There is still time. I'd love to get

KH1 for that ATNO on any mode, any band.  

 

Best regards,

 

Gary, K7EK

 

Radcliff, KY (EM77at)

 

--
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] Observation on Expedition Mode

[John Zantek]

Wholly concur with #2, but not necessarily #1, Mike.  Yes, lots of folks are 
calling in the blind.  That’s not limited to FT8, guys.  

 

But…

 

Depending on who’s running the digital tent (Don/Ned/?), rates of CQ vary from 
every 10 minutes to generate some traffic down to NONE, because there are 
stations calling.  I have a pretty ideal QTH to work Baker on any band, and I’m 
observing too much of the latter pattern.  I know there are lots of new folks 
sitting at their keyboards, waiting for the CQ, not seeing one, then walking 
away.  That’s not good, as it just reduces the rate for Baker, and frustrates 
the new ham who’s a potential DXer and digital apostle.

 

The QSB on 17M has been horrendous, with Baker’s sig, regardless of mode, 
varying wildly here.  On 17M, they were working the usual wall of JA but I 
never did see a CQ, so I entered it manually and generated the Std Msgs to work 
them successfully.  

 

From: Black Michael via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net] 
Sent: Saturday, June 30, 2018 7:15 AM
To: 'WSJT software development' 
Cc: Black Michael 
Subject: Re: [wsjt-devel] Observation on Expedition Mode

 

I have some observations too.

 

#1 Tons of ops calling KH7Z when they can't see them.  I assume this only 
causes problems as it's quite possible KH7Z with their honker antennas and can 
see them but not the other way round.  So KH7Z will put them in the queue and 
try to process them taking up the limited slots they are using right now (2 
from what I've seen).  IMHO the solution to this is pretty simplewhen you 
turn on Hound or switch bands you should be PREVENTED FROM TRANSMITTING UNTIL 
YOU GET CQ FRO THE DX STATION.So, you would be required to double-click on 
a CQ to allow transmitting.  I noticed the the Baker team gave a lukewarm 
endorsement of FT8 on their news update quite likely due to this problem.

 

#2 We need to turn on spotting for the DX station so that PSKReporter and 
Hamspots can work and also so JTAlert can produce alerts when the DX station is 
received.  Don't need to spot the hounds of course.  Trying to figure out what 
band is good for local ops would be much improved with automatic spotting for 
us and for the DX team who could then see where their signal is going as more 
teams use internet on site via satellite links.

 

de Mike W9MDB

 

 

 

 

 

On Saturday, June 30, 2018, 8:13:39 AM CDT, Grant Willis mailto:vk...@bigpond.com> > wrote: 

 

 

Joe,

 

An observation if I may about expedition mode. I see with KH1/KH7Z that the 
number of Fox TX channels varies – I presume as they place more stations in the 
queue. As expected, the power per channel drops the more channels running so 
that the amplifiers can keep up. However, this has an unintended consequence 
perhaps of potentially breaking QSOs. A few times now I have started calling 
KH1/KH7Z on 20m when I am receiving them around -09 (but with pretty low 
S-meter  signal strength). Usually this is with 1-2 channels running on their 
downlink. If they go to 3 channels I can still receive but it falls to say -15. 
If they bring up channel 4 and 5 I loose them. There just isn’t the link budget 
left to receive them when the power is split between more than 3 channels in 
this example.

 

Now the issue is, if they answer me by adding the 4th channel – I wont hear 
them under those conditions. If I am part way through a QSO I can loose the 
RR73 for the same reason if they answer someone else on the 4th channel– simply 
because the link runs out of steam.

 

Now if I couldn’t hear them in the first place I wouldn’t have tried calling. 
In this case however, they can disappear under load effectively and I loose 
them mid QSO.

 

For future consideration perhaps is to have the setting of number of channels 
vs the number of active channels maintain a constant PER CHANNEL TX power 
rather than the variable situation we have now. Ie I enable my fox station to 
run say 4 channels, but only reply on 1 channel, then the output power should 
be the equivalent of the power that would be in that channel if all 4 were in 
fact on air but aren’t. At least that way I have a constant link budget I am 
working with on my comms channel with the fox station rather than one that can 
have them drastically cut power mid QSO without reference to the conditions on 
the path I am working them via.

 

If what I am describing is not how it is supposed to work already then there is 
another factor at work somewhere in the chain to be explored. I would be happy 
to discuss this further and use the KH1/KH7Z expedition to observe and learn 
more about how the multi-channel nature of the mode works.

 

Regards,

Grant VK5GR

 

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

Re: [wsjt-devel] Observation on Expedition Mode

[Joe Taylor]

On 6/30/2018 10:14 AM, Black Michael via wsjt-devel wrote:

... I noticed the the Baker team gave a lukewarm endorsement 
of FT8 on their news update ...


I do not consider their endorsement of FT8 to be lukewarm, at all.

Currently they have uploaded 12,319 QSOs to ClubLog:

CQ   4,735
SSB  4,507
FT8  3,077
---
12,319

One of their intentions was to run CW amd SSB when band conditions are 
good, when QSO rates can be highest.  FT8 works well even in poorer 
conditions.  I believe they are happy with their decision to use FT8 and 
its DXpedition Mode.


They would be even happier if more people used the correct software and 
followed the Hound operating instructions, preferably with a dollop of 
common sense.


-- 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] Observation on Expedition Mode

[John L. Broughton]

As noticed in my previous post, my experience was the fox was not 
calling CQ every five minutes, but simply working station after station. 
Seeing as how I could copy all his transmissions, I called him, and got 
the QSO. I don't feel guilty about how I worked him. I figure as long as 
I can copy him steadily and he is working stations calling, there is no 
reason I should not call, as long as he is not working a specific area 
that doesn't include the US.


That being said, I can't fault your idea that the fox should call CQ 
every five minutes, but before I would force that to be mandatory, I'd 
get input from the DXpedition to see if they think it was/should be 
necessary. The one problem it could solve is stations calling blind who 
can't hear the fox, but it would be nice to know if that is a real 
problem. Judged by many years of SSB DXing, I have no doubts there are 
stations who don't follow general guidelines, rules and regulations when 
it comes to working DX, though.


John, WB9VGJ

John L. Broughton
www.wb9vgj.us
wb9...@arrl.net
2silverhon...@gmail.com

On 6/30/2018 8:57 AM, Black Michael via wsjt-devel wrote:
OK...so it appears the CQ every 5 trasnmissions is NOT enforced unless 
Fox clicks the "More CQs" box.
We'd be a lot better off if this was always forced and Hounds were 
restricted to only answer CQ's.
This explains why we don't see the CQ's and calling blind is normally 
necessary (as long as you can see KH7Z that is).


if(m_tFoxTxSinceCQ>=m_foxCQtimeandui->cbMoreCQs->isChecked()){

de Mike W9MDB




On Saturday, June 30, 2018, 10:41:44 AM CDT, John Zantek 
 wrote:



Wholly concur with #2, but not necessarily #1, Mike.  Yes, lots of 
folks are calling in the blind.  That’s not limited to FT8, guys.


But…

Depending on who’s running the digital tent (Don/Ned/?), rates of CQ 
vary from every 10 minutes to generate some traffic down to NONE, 
because there are stations calling.  I have a pretty ideal QTH to work 
Baker on any band, and I’m observing too much of the latter pattern.  
I know there are lots of new folks sitting at their keyboards, waiting 
for the CQ, not seeing one, then walking away. That’s not good, as it 
just reduces the rate for Baker, and frustrates the new ham who’s a 
potential DXer and digital apostle.


The QSB on 17M has been horrendous, with Baker’s sig, regardless of 
mode, varying wildly here.  On 17M, they were working the usual wall 
of JA but I never did see a CQ, so I entered it manually and generated 
the Std Msgs to work them successfully.


*From:*Black Michael via wsjt-devel 
[mailto:wsjt-devel@lists.sourceforge.net]

*Sent:* Saturday, June 30, 2018 7:15 AM
*To:* 'WSJT software development' 
*Cc:* Black Michael 
*Subject:* Re: [wsjt-devel] Observation on Expedition Mode

I have some observations too.

#1 Tons of ops calling KH7Z when they can't see them.  I assume this 
only causes problems as it's quite possible KH7Z with their honker 
antennas and can see them but not the other way round.  So KH7Z will 
put them in the queue and try to process them taking up the limited 
slots they are using right now (2 from what I've seen). IMHO the 
solution to this is pretty simplewhen you turn on Hound or switch 
bands you should be PREVENTED FROM TRANSMITTING UNTIL YOU GET CQ FRO 
THE DX STATION.    So, you would be required to double-click on a CQ 
to allow transmitting.  I noticed the the Baker team gave a lukewarm 
endorsement of FT8 on their news update quite likely due to this problem.


#2 We need to turn on spotting for the DX station so that PSKReporter 
and Hamspots can work and also so JTAlert can produce alerts when the 
DX station is received.  Don't need to spot the hounds of course.  
Trying to figure out what band is good for local ops would be much 
improved with automatic spotting for us and for the DX team who could 
then see where their signal is going as more teams use internet on 
site via satellite links.


de Mike W9MDB

On Saturday, June 30, 2018, 8:13:39 AM CDT, Grant Willis 
mailto:vk...@bigpond.com>> wrote:


Joe,

An observation if I may about expedition mode. I see with KH1/KH7Z 
that the number of Fox TX channels varies – I presume as they place 
more stations in the queue. As expected, the power per channel drops 
the more channels running so that the amplifiers can keep up. However, 
this has an unintended consequence perhaps of potentially breaking 
QSOs. A few times now I have started calling KH1/KH7Z on 20m when I am 
receiving them around -09 (but with pretty low S-meter  signal 
strength). Usually this is with 1-2 channels running on their 
downlink. If they go to 3 channels I can still receive but it falls to 
say -15. If they bring up channel 4 and 5 I loose them. There just 
isn’t the link budget left to receive them when the power is split 
between more than 3 channels in this example.


Now the issue is, if they answer me by adding the 4^th channel – I 
wont hear them under those con

Re: [wsjt-devel] Observation on Expedition Mode

[Gary Kohtala - K7EK via wsjt-devel]

 The Baker Island DXpedition has brought out the very worst:  Stations calling 
blind for hours when KH7Z is not even on FT8, incessant calling below 1000 hz, 
calling the wrong call sign (KH7V), calling in the wrong time slot, etc. One 
would think that it would be reasonable to at least skim the very ample 
instructions that have been put out. But no, it is not about to happen. I came 
close to completing for an ATNO on 30m but sadly, I never got his RR73 and did 
not go into their log. So, I continue to fight the uninformed and apparently 
clueless hoards that have descended upon the bands. And of course throw in bad 
propagation, low power, and a less than ideal antenna system and the odds of 
making the Q are even lower. Oh well. There is still time. I'd love to getKH1 
for that ATNO on any mode, any band.  
Best regards,
Gary, K7EK
Radcliff, KY (EM77at)
--
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] Observation on Expedition Mode

[John L. Broughton]

I can't say I agree with Mike that one should have to answer a CQ to 
work the DXpedition station.


I worked KH7Z on 17M this past Thursday. However, in the time I was on 
the frequency, I did not decode any CQ. KH7Z was working stations the 
entire time I was on frequency. I simply kept an eye on his signal 
strength which was varying from about -22 to -15. I set my transmit 
frequency at 3343 and started calling. It didn't take very long, just 
several minutes, before he called me and we completed the QSO. My report 
to him was -22 and his to me was -06 (I'm running a hy-gain DX-88 
vertical with my IC-7300; hardly a DX big gun.) If I would have had to 
answer a CQ in order to work him, I could not have gotten the QSO due to 
the short time I had to try to make  it and with him just working 
station after station, not needing to call CQ.


I was watching the stations he was calling to make sure they weren't, 
say, all in Europe, as I did not know if he had called CQ for any 
particular region. As most all the stations he was working were in the 
US, I had no hesitation about calling him.


As far as finding where KH7Z is operating, I've just been using the 
HB9DRV-9 DX Cluster spots option in m HRD logbook program (I don't run 
the main HRD program.) or just selecting various bands in the right hand 
window of it to see if and where he is operating then, if on SSB or FT8, 
I go to the frequency to see if he is strong enough to work.


John, WB9VGJ

John L. Broughton
www.wb9vgj.us
wb9...@arrl.net
2silverhon...@gmail.com

On 6/30/2018 7:14 AM, Black Michael via wsjt-devel wrote:

I have some observations too.

#1 Tons of ops calling KH7Z when they can't see them. I assume this 
only causes problems as it's quite possible KH7Z with their honker 
antennas and can see them but not the other way round.  So KH7Z will 
put them in the queue and try to process them taking up the limited 
slots they are using right now (2 from what I've seen).  IMHO the 
solution to this is pretty simplewhen you turn on Hound or switch 
bands you should be PREVENTED FROM TRANSMITTING UNTIL YOU GET CQ FRO 
THE DX STATION.    So, you would be required to double-click on a CQ 
to allow transmitting.  I noticed the the Baker team gave a lukewarm 
endorsement of FT8 on their news update quite likely due to this problem.


#2 We need to turn on spotting for the DX station so that PSKReporter 
and Hamspots can work and also so JTAlert can produce alerts when the 
DX station is received.  Don't need to spot the hounds of course.  
Trying to figure out what band is good for local ops would be much 
improved with automatic spotting for us and for the DX team who could 
then see where their signal is going as more teams use internet on 
site via satellite links.


de Mike W9MDB





On Saturday, June 30, 2018, 8:13:39 AM CDT, Grant Willis 
 wrote:



Joe,

An observation if I may about expedition mode. I see with KH1/KH7Z 
that the number of Fox TX channels varies – I presume as they place 
more stations in the queue. As expected, the power per channel drops 
the more channels running so that the amplifiers can keep up. However, 
this has an unintended consequence perhaps of potentially breaking 
QSOs. A few times now I have started calling KH1/KH7Z on 20m when I am 
receiving them around -09 (but with pretty low S-meter  signal 
strength). Usually this is with 1-2 channels running on their 
downlink. If they go to 3 channels I can still receive but it falls to 
say -15. If they bring up channel 4 and 5 I loose them. There just 
isn’t the link budget left to receive them when the power is split 
between more than 3 channels in this example.


Now the issue is, if they answer me by adding the 4^th channel – I 
wont hear them under those conditions. If I am part way through a QSO 
I can loose the RR73 for the same reason if they answer someone else 
on the 4^th channel– simply because the link runs out of steam.


Now if I couldn’t hear them in the first place I wouldn’t have tried 
calling. In this case however, they can disappear under load 
effectively and I loose them mid QSO.


For future consideration perhaps is to have the setting of number of 
channels vs the number of active channels maintain a constant PER 
CHANNEL TX power rather than the variable situation we have now. Ie I 
enable my fox station to run say 4 channels, but only reply on 1 
channel, then the output power should be the equivalent of the power 
that would be in that channel if all 4 were in fact on air but aren’t. 
At least that way I have a constant link budget I am working with on 
my comms channel with the fox station rather than one that can have 
them drastically cut power mid QSO without reference to the conditions 
on the path I am working them via.


If what I am describing is not how it is supposed to work already then 
there is another factor at work somewhere in the chain to be explored. 
I would be happy to discuss this further and use the KH1/KH7Z 

Re: [wsjt-devel] Observation on Expedition Mode

[Jim Brown]

On 6/30/2018 9:16 AM, Black Michael via wsjt-devel wrote:

I just tested this and Fox tried 3 times to respond to a blind call.


Define a "blind call."  I would define it as calling someone you can't 
copy.


As others have observed, an expedition op with a screenful of callers is 
unlikely to call CQ.


DXpedition mode is ingeniously designed so that additional callers DON'T 
interfere with a QSO in progress unless they call in the controlled 
region below 1 kHz. As such, it is FAR superior to the usual pileups.


I have made many 6M QSOs with stations in grids I needed by calling them 
either after they sent RRR or RR73, or after decoding 3-4 of their 
transmissions trying to work a caller for whom propagation no longer 
exists. And I never respond on the frequency of the station I'm calling, 
so I'm unlikely to QRM the station he's trying to work.


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] Observation on Expedition Mode

[Jim Brown]

On 6/30/2018 7:14 AM, Black Michael via wsjt-devel wrote:
Tons of ops calling KH7Z when they can't see them.  I assume this only 
causes problems as it's quite possible KH7Z with their honker antennas 
and can see them but not the other way round.


It's not "big honker antennas" -- the expedition is limited to verticals 
by Fish and Wildlife. It's more likely their lack of noise (the only 
that can be on the island is THEIRS) -- and the relatively high noise 
levels of the stations trying to work them.



  So KH7Z will put them in
the queue and try to process them taking up the limited slots they are 
using right now (2 from what I've seen).  IMHO the solution to this is 
pretty simplewhen you turn on Hound or switch bands you should be 
PREVENTED FROM TRANSMITTING UNTIL YOU GET CQ FRO THE DX STATION.    So, 
you would be required to double-click on a CQ to allow transmitting.


I've worked them on three bands, the first time monitoring for at least 
an hour and not seeing their CQ. I came to the conclusion that they were 
not calling CQ, so I double clicked on one of their transmissions and 
started calling them. After three calls, I had a QSO in the log. I did 
the same for the two other QSOs.


I've been concentrating on studying and teaching hams how to find and 
kill receive noise. My most recent efforts are here. One is text, the 
other is the slide show for talks I've done at ham events.


http://k9yc.com/KillingReceiveNoise.pdf
http://k9yc.com/KillingRXNoiseVisalia.pdf

If you find yourself giving much weaker (more negative) signal reports 
than you receive, it's likely that noise is a problem for you, and that 
finding and killing it will do more for your on-air success than 
anything else you try.


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] Observation on Expedition Mode

[Charles Suckling]

Neil

 

Thanks - that's very helpful.  

 

I didn't waste much time calling!

 

The other clue was that it was at a time when the propagation predictions
were blank. 

 

Charlie

 

  _  

From: Neil Zampella [mailto:ne...@techie.com] 
Sent: 30 June 2018 17:21
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] Observation on Expedition Mode

 

Charlie,

the consensus of many on the FB pages is that this station was a pirate.

Neil, KN3ILZ

 

On 6/30/2018 11:09 AM, Charles Suckling wrote:

Hi Mike

 

The problem with needing to see a CQ is that the dxpedition may rarely
transmit a CQ (some folks were reporting this yesterday).  Then, stations
were working them by just calling.  Majority were on the correct period,
most were above 1000Hz.  From what I could see here about 90% of hounds were
calling correctly.  Whether they could hear the dxpedition is another
matter.

 

Earlier this afternoon there was a run of CQ from them (or someone
pretending to be them) about 10dB stronger than they are here most of the
time (-18 to -20).  During this spell there seemed to be no QSOs.

 

Charlie


  _  


From: Black Michael via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net]

Sent: 30 June 2018 15:15
To: 'WSJT software development'
Cc: Black Michael
Subject: Re: [wsjt-devel] Observation on Expedition Mode

 

I have some observations too.

 

#1 Tons of ops calling KH7Z when they can't see them.  I assume this only
causes problems as it's quite possible KH7Z with their honker antennas and
can see them but not the other way round.  So KH7Z will put them in the
queue and try to process them taking up the limited slots they are using
right now (2 from what I've seen).  IMHO the solution to this is pretty
simplewhen you turn on Hound or switch bands you should be PREVENTED
FROM TRANSMITTING UNTIL YOU GET CQ FRO THE DX STATION.So, you would be
required to double-click on a CQ to allow transmitting.  I noticed the the
Baker team gave a lukewarm endorsement of FT8 on their news update quite
likely due to this problem.

 

#2 We need to turn on spotting for the DX station so that PSKReporter and
Hamspots can work and also so JTAlert can produce alerts when the DX station
is received.  Don't need to spot the hounds of course.  Trying to figure out
what band is good for local ops would be much improved with automatic
spotting for us and for the DX team who could then see where their signal is
going as more teams use internet on site via satellite links.

 

de Mike W9MDB

 

 

 

 

 

On Saturday, June 30, 2018, 8:13:39 AM CDT, Grant Willis
<mailto:vk...@bigpond.com>  wrote: 

 

 

Joe,

 

An observation if I may about expedition mode. I see with KH1/KH7Z that the
number of Fox TX channels varies - I presume as they place more stations in
the queue. As expected, the power per channel drops the more channels
running so that the amplifiers can keep up. However, this has an unintended
consequence perhaps of potentially breaking QSOs. A few times now I have
started calling KH1/KH7Z on 20m when I am receiving them around -09 (but
with pretty low S-meter  signal strength). Usually this is with 1-2 channels
running on their downlink. If they go to 3 channels I can still receive but
it falls to say -15. If they bring up channel 4 and 5 I loose them. There
just isn't the link budget left to receive them when the power is split
between more than 3 channels in this example.

 

Now the issue is, if they answer me by adding the 4th channel - I wont hear
them under those conditions. If I am part way through a QSO I can loose the
RR73 for the same reason if they answer someone else on the 4th channel-
simply because the link runs out of steam.

 

Now if I couldn't hear them in the first place I wouldn't have tried
calling. In this case however, they can disappear under load effectively and
I loose them mid QSO.

 

For future consideration perhaps is to have the setting of number of
channels vs the number of active channels maintain a constant PER CHANNEL TX
power rather than the variable situation we have now. Ie I enable my fox
station to run say 4 channels, but only reply on 1 channel, then the output
power should be the equivalent of the power that would be in that channel if
all 4 were in fact on air but aren't. At least that way I have a constant
link budget I am working with on my comms channel with the fox station
rather than one that can have them drastically cut power mid QSO without
reference to the conditions on the path I am working them via.

 

If what I am describing is not how it is supposed to work already then there
is another factor at work somewhere in the chain to be explored. I would be
happy to discuss this further and use the KH1/KH7Z expedition to observe and
learn more about how the multi-channel nature of the mode works.

 

Regards,

Grant VK5GR

 


--
Check out the vibrant tech com

Re: [wsjt-devel] Observation on Expedition Mode

[Joe Taylor]

For the record, here's the "Most important advice for Hounds" that I 
posted to wsjtgroup yesterday:


1. Read the FT8 DXpedition Mode User Guide.  Read it all!

http://physics.princeton.edu/pulsar/k1jt/FT8_DXpedition_Mode.pdf

2. You must select Hound mode.

3. The *Tx even/1st* box (grayed out) must NOT be checked.  (It's
supposed to be impossible for this to happen, but several have claimed
that it can.  If you find the box is checked: exit Hound mode, clear the
box, then re-enter Hound mode.) [Also see below.]

4. Enter the full call, KH1/KH7Z, in the *DX Call* box.  Although it's
not necessary, you may also enter "AJ10" in the *DX Grid* box.  [Then 
you'll see the short-path azimuth and know where to point your beam.]


5. Do not call the Fox if you are not copying him.  However, it is NOT
necessary to wait until you copy his CQ.  They are not calling CQ very
often.  [Also see below.]

6. Pick a clear Tx frequency above 1000 Hz, and go ahead and call.

Good luck to all for working KH1/KH7Z on as many bands as possible!

Notes added today:

1. Several of us have recognized that "Tx even/1st" can become checked 
in Hound mode if you double-click on a decode in the odd/2nd sequence. 
Of course, there's no good reason for a Hound to do this; but we all 
make mistakes.  The program should not permit this to happen, and we'll 
fix this defect.  Meanwhile, don't do it!


2. There are VERY GOOD reasons why you should not call the Fox "blind". 
If you are not copying Fox's transmissions, DO NOT call him.  Doing so 
only creates QRM.


However...

3. If you are copying Fox's transmissions, there is NO good reason to 
refrain from calling until you copy his CQ.  Fox expects Hounds to be 
calling all the time, on open propagation paths.  Most QSOs are made 
this way.


And fiinally...

4. If you copy Fox's CQ but copy few if any other transmissions from 
Fox, your chances of a QSO are probably not very good.  CQs from Fox are 
generally sent in single-slot mode, so they are 6 to 14 dB stronger than 
most of his other transmissions.


-- 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] Observation on Expedition Mode

[Black Michael via wsjt-devel]

I thought the goal of DXpedition mode was to optimize the QSO rate.The 
DXPedition has no idea if the station calling can actually hear them so why 
should WSJT-X allow it?
Allowing such blind calls is the antithesis  to optimizing rates.

They haven't tried it because everybody is calling them blind so they don't 
need to.  But I'll bet $$ that a lot of QSOs are timing out.  Maybe we can get 
some feedback from the team on that.

I will also state that blocking such blind calling would ELIMINATE what I saw 
on all bands of people calling when there was no propagation to there.
Wouldn't you agree that having a pileup of people that can actually hear the DX 
site is much better for QSO rate than people that can't hear them?  In the 
extreme...the DX site may not make any QSOs with blind callers where my 
proposed solution would eliminate that problem.

I realize that we need to be conservative about what we enforce, operators are 
responsible (NOT!), and such but we need to make life better for everybody and 
enforcing CQ requirements would do that for both sides of the QSO.  So instead 
of the dozens of people calling in the blind for hours on end you have people 
that can actually see the place.
Mike
 

On Saturday, June 30, 2018, 11:13:07 AM CDT, Bill Somerville 
 wrote:  
 
  Hi Mike,
 
 we are not hear to determine how operators at a DXpedition site choose to 
operate, we are not aware of conditions on the ground. If they feel that they 
are getting optimum rates without calling CQ then that is their choice. 
Remember that calling CQ from a rare entity can result in a passband 100% full 
of pile up, they may  have tried it and decided it doesn't help the QSO rate.
 
 73
 Bill
 G4WJS.
 
 On 30/06/2018 17:05, Black Michael via wsjt-devel wrote:
  
   But what about them receiving all these calls in the blind?  Isn't that 
going to interfere when they try to respond to people who can't hear them? 
  Mike
  
   

  
  On Saturday, June 30, 2018, 11:04:11 AM CDT, Bill Somerville 
 wrote:  
  
 On 30/06/2018 16:57, Black Michael via wsjt-devel wrote:
  
  OK...so it appears the CQ every 5 trasnmissions is NOT enforced unless Fox 
clicks the "More CQs" box. We'd be a lot better off if this was always forced 
and Hounds were restricted to only answer CQ's. This explains why we don't see 
the CQ's and calling blind is normally necessary (as long as you can see KH7Z 
that is).
  
   if(m_tFoxTxSinceCQ >= m_foxCQtime and ui->cbMoreCQs->isChecked()) {
  
  de Mike W9MDB
  
   

 
Hi Mike,
 
it should be reasonable to assume that if the Baker Is. operators are not 
enforcing regular CQ calls then they have plenty of callers to keep the 
to-be-worked queue populated with more stations than Tx slots and a QSO rate 
that is high.
  
 

 
 --
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] Observation on Expedition Mode

[Neil Zampella]

Charlie,

the consensus of many on the FB pages is that this station was a pirate.

Neil, KN3ILZ


On 6/30/2018 11:09 AM, Charles Suckling wrote:


Hi Mike

The problem with needing to see a CQ is that the dxpedition may rarely 
transmit a CQ (some folks were reporting this yesterday).  Then, 
stations were working them by just calling. Majority were on the 
correct period, most were above 1000Hz.  From what I could see here 
about 90% of hounds were calling correctly.  Whether they could hear 
the dxpedition is another matter.


Earlier this afternoon there was a run of CQ from them (or someone 
pretending to be them) about 10dB stronger than they are here most of 
the time (-18 to -20).  During this spell there seemed to be no QSOs.


Charlie



*From:*Black Michael via wsjt-devel 
[mailto:wsjt-devel@lists.sourceforge.net]

*Sent:* 30 June 2018 15:15
*To:* 'WSJT software development'
*Cc:* Black Michael
*Subject:* Re: [wsjt-devel] Observation on Expedition Mode

I have some observations too.

#1 Tons of ops calling KH7Z when they can't see them.  I assume this 
only causes problems as it's quite possible KH7Z with their honker 
antennas and can see them but not the other way round.  So KH7Z will 
put them in the queue and try to process them taking up the limited 
slots they are using right now (2 from what I've seen).  IMHO the 
solution to this is pretty simplewhen you turn on Hound or switch 
bands you should be PREVENTED FROM TRANSMITTING UNTIL YOU GET CQ FRO 
THE DX STATION.    So, you would be required to double-click on a CQ 
to allow transmitting.  I noticed the the Baker team gave a lukewarm 
endorsement of FT8 on their news update quite likely due to this problem.


#2 We need to turn on spotting for the DX station so that PSKReporter 
and Hamspots can work and also so JTAlert can produce alerts when the 
DX station is received.  Don't need to spot the hounds of course.  
Trying to figure out what band is good for local ops would be much 
improved with automatic spotting for us and for the DX team who could 
then see where their signal is going as more teams use internet on 
site via satellite links.


de Mike W9MDB

On Saturday, June 30, 2018, 8:13:39 AM CDT, Grant Willis 
 wrote:


Joe,

An observation if I may about expedition mode. I see with KH1/KH7Z 
that the number of Fox TX channels varies – I presume as they place 
more stations in the queue. As expected, the power per channel drops 
the more channels running so that the amplifiers can keep up. However, 
this has an unintended consequence perhaps of potentially breaking 
QSOs. A few times now I have started calling KH1/KH7Z on 20m when I am 
receiving them around -09 (but with pretty low S-meter  signal 
strength). Usually this is with 1-2 channels running on their 
downlink. If they go to 3 channels I can still receive but it falls to 
say -15. If they bring up channel 4 and 5 I loose them. There just 
isn’t the link budget left to receive them when the power is split 
between more than 3 channels in this example.


Now the issue is, if they answer me by adding the 4^th channel – I 
wont hear them under those conditions. If I am part way through a QSO 
I can loose the RR73 for the same reason if they answer someone else 
on the 4^th channel– simply because the link runs out of steam.


Now if I couldn’t hear them in the first place I wouldn’t have tried 
calling. In this case however, they can disappear under load 
effectively and I loose them mid QSO.


For future consideration perhaps is to have the setting of number of 
channels vs the number of active channels maintain a constant PER 
CHANNEL TX power rather than the variable situation we have now. Ie I 
enable my fox station to run say 4 channels, but only reply on 1 
channel, then the output power should be the equivalent of the power 
that would be in that channel if all 4 were in fact on air but aren’t. 
At least that way I have a constant link budget I am working with on 
my comms channel with the fox station rather than one that can have 
them drastically cut power mid QSO without reference to the conditions 
on the path I am working them via.


If what I am describing is not how it is supposed to work already then 
there is another factor at work somewhere in the chain to be explored. 
I would be happy to discuss this further and use the KH1/KH7Z 
expedition to observe and learn more about how the multi-channel 
nature of the mode works.


Regards,

Grant VK5GR

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

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

Re: [wsjt-devel] Observation on Expedition Mode

[Black Michael via wsjt-devel]

I just tested this and Fox tried 3 times to respond to a blind call.
I can guarantee that the majority of calls were blind and thus causing all 
sorts of time wasting at the DXPedition.
We really need to block blind calling so enforce the CQ-every-5 and prevent 
transmitting until you see CQ from the DX station.  Require the DX station to 
be put in the Advanced tab too and disable the DXCall box from being used too.
I know this sounds like a lot of hand holding but there are far too many 
abusing the FT8 protocol this way and not realizing the problem they are 
causing.  It shouldn't be up to the DXpedition to figure out who to 
block...they're busy enough

de Mike W9MDB




 

On Saturday, June 30, 2018, 11:08:17 AM CDT, Black Michael via wsjt-devel 
 wrote:  
 
 But what about them receiving all these calls in the blind?  Isn't that going 
to interfere when they try to respond to people who can't hear them?
Mike


 

On Saturday, June 30, 2018, 11:04:11 AM CDT, Bill Somerville 
 wrote:  
 
  On 30/06/2018 16:57, Black Michael via wsjt-devel wrote:
  
  OK...so it appears the CQ every 5 trasnmissions is NOT enforced unless Fox 
clicks the "More CQs" box. We'd be a lot better off if this was always forced 
and Hounds were restricted to only answer CQ's. This explains why we don't see 
the CQ's and calling blind is normally necessary (as long as you can see KH7Z 
that is).
  
   if(m_tFoxTxSinceCQ >= m_foxCQtime and ui->cbMoreCQs->isChecked()) {
  
  de Mike W9MDB
  
   

 
Hi Mike,
 
it should be reasonable to assume that if the Baker Is. operators are not 
enforcing regular CQ calls then they have plenty of callers to keep the 
to-be-worked queue populated with more stations than Tx slots and a QSO rate 
that is high.
 

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] Observation on Expedition Mode

[Bill Somerville]

Hi Mike,

we are not hear to determine how operators at a DXpedition site choose 
to operate, we are not aware of conditions on the ground. If they feel 
that they are getting optimum rates without calling CQ then that is 
their choice. Remember that calling CQ from a rare entity can result in 
a passband 100% full of pile up, they may have tried it and decided it 
doesn't help the QSO rate.


73
Bill
G4WJS.

On 30/06/2018 17:05, Black Michael via wsjt-devel wrote:
But what about them receiving all these calls in the blind?  Isn't 
that going to interfere when they try to respond to people who can't 
hear them?


Mike




On Saturday, June 30, 2018, 11:04:11 AM CDT, Bill Somerville 
 wrote:



On 30/06/2018 16:57, Black Michael via wsjt-devel wrote:
OK...so it appears the CQ every 5 trasnmissions is NOT enforced 
unless Fox clicks the "More CQs" box.
We'd be a lot better off if this was always forced and Hounds were 
restricted to only answer CQ's.
This explains why we don't see the CQ's and calling blind is normally 
necessary (as long as you can see KH7Z that is).


if(m_tFoxTxSinceCQ>=m_foxCQtimeandui->cbMoreCQs->isChecked()){

de Mike W9MDB



Hi Mike,

it should be reasonable to assume that if the Baker Is. operators are 
not enforcing regular CQ calls then they have plenty of callers to 
keep the to-be-worked queue populated with more stations than Tx slots 
and a QSO rate that is high.




--
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] Observation on Expedition Mode

[Black Michael via wsjt-devel]

But what about them receiving all these calls in the blind?  Isn't that going 
to interfere when they try to respond to people who can't hear them?
Mike


 

On Saturday, June 30, 2018, 11:04:11 AM CDT, Bill Somerville 
 wrote:  
 
  On 30/06/2018 16:57, Black Michael via wsjt-devel wrote:
  
  OK...so it appears the CQ every 5 trasnmissions is NOT enforced unless Fox 
clicks the "More CQs" box. We'd be a lot better off if this was always forced 
and Hounds were restricted to only answer CQ's. This explains why we don't see 
the CQ's and calling blind is normally necessary (as long as you can see KH7Z 
that is).
  
   if(m_tFoxTxSinceCQ >= m_foxCQtime and ui->cbMoreCQs->isChecked()) {
  
  de Mike W9MDB
  
   

 
Hi Mike,
 
it should be reasonable to assume that if the Baker Is. operators are not 
enforcing regular CQ calls then they have plenty of callers to keep the 
to-be-worked queue populated with more stations than Tx slots and a QSO rate 
that is high.
 

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] Observation on Expedition Mode

[Bill Somerville]

On 30/06/2018 16:57, Black Michael via wsjt-devel wrote:
OK...so it appears the CQ every 5 trasnmissions is NOT enforced unless 
Fox clicks the "More CQs" box.
We'd be a lot better off if this was always forced and Hounds were 
restricted to only answer CQ's.
This explains why we don't see the CQ's and calling blind is normally 
necessary (as long as you can see KH7Z that is).


if(m_tFoxTxSinceCQ>=m_foxCQtimeandui->cbMoreCQs->isChecked()){

de Mike W9MDB



Hi Mike,

it should be reasonable to assume that if the Baker Is. operators are 
not enforcing regular CQ calls then they have plenty of callers to keep 
the to-be-worked queue populated with more stations than Tx slots and a 
QSO rate that is high.


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] Observation on Expedition Mode

[Black Michael via wsjt-devel]

OK...so it appears the CQ every 5 trasnmissions is NOT enforced unless Fox 
clicks the "More CQs" box.We'd be a lot better off if this was always forced 
and Hounds were restricted to only answer CQ's.This explains why we don't see 
the CQ's and calling blind is normally necessary (as long as you can see KH7Z 
that is).

 if(m_tFoxTxSinceCQ >= m_foxCQtime and ui->cbMoreCQs->isChecked()) {

de Mike W9MDB


 

On Saturday, June 30, 2018, 10:41:44 AM CDT, John Zantek  
wrote:  
 
 
Wholly concur with #2, but not necessarily #1, Mike.  Yes, lots of folks are 
calling in the blind.  That’s not limited to FT8, guys.  

  

But…

  

Depending on who’s running the digital tent (Don/Ned/?), rates of CQ vary from 
every 10 minutes to generate some traffic down to NONE, because there are 
stations calling.  I have a pretty ideal QTH to work Baker on any band, and I’m 
observing too much of the latter pattern.  I know there are lots of new folks 
sitting at their keyboards, waiting for the CQ, not seeing one, then walking 
away.  That’s not good, as it just reduces the rate for Baker, and frustrates 
the new ham who’s a potential DXer and digital apostle.

  

The QSB on 17M has been horrendous, with Baker’s sig, regardless of mode, 
varying wildly here.  On 17M, they were working the usual wall of JA but I 
never did see a CQ, so I entered it manually and generated the Std Msgs to work 
them successfully.  

  

From: Black Michael via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net] 
Sent: Saturday, June 30, 2018 7:15 AM
To: 'WSJT software development' 
Cc: Black Michael 
Subject: Re: [wsjt-devel] Observation on Expedition Mode

  

I have some observations too.

  

#1 Tons of ops calling KH7Z when they can't see them.  I assume this only 
causes problems as it's quite possible KH7Z with their honker antennas and can 
see them but not the other way round.  So KH7Z will put them in the queue and 
try to process them taking up the limited slots they are using right now (2 
from what I've seen).  IMHO the solution to this is pretty simplewhen you 
turn on Hound or switch bands you should be PREVENTED FROM TRANSMITTING UNTIL 
YOU GET CQ FRO THE DX STATION.    So, you would be required to double-click on 
a CQ to allow transmitting.  I noticed the the Baker team gave a lukewarm 
endorsement of FT8 on their news update quite likely due to this problem.

  

#2 We need to turn on spotting for the DX station so that PSKReporter and 
Hamspots can work and also so JTAlert can produce alerts when the DX station is 
received.  Don't need to spot the hounds of course.  Trying to figure out what 
band is good for local ops would be much improved with automatic spotting for 
us and for the DX team who could then see where their signal is going as more 
teams use internet on site via satellite links.

  

de Mike W9MDB

  

  

  

  

  

On Saturday, June 30, 2018, 8:13:39 AM CDT, Grant Willis  
wrote: 

  

  

Joe,

 

An observation if I may about expedition mode. I see with KH1/KH7Z that the 
number of Fox TX channels varies – I presume as they place more stations in the 
queue. As expected, the power per channel drops the more channels running so 
that the amplifiers can keep up. However, this has an unintended consequence 
perhaps of potentially breaking QSOs. A few times now I have started calling 
KH1/KH7Z on 20m when I am receiving them around -09 (but with pretty low 
S-meter  signal strength). Usually this is with 1-2 channels running on their 
downlink. If they go to 3 channels I can still receive but it falls to say -15. 
If they bring up channel 4 and 5 I loose them. There just isn’t the link budget 
left to receive them when the power is split between more than 3 channels in 
this example.

 

Now the issue is, if they answer me by adding the 4th channel – I wont hear 
them under those conditions. If I am part way through a QSO I can loose the 
RR73 for the same reason if they answer someone else on the 4th channel– simply 
because the link runs out of steam.

 

Now if I couldn’t hear them in the first place I wouldn’t have tried calling. 
In this case however, they can disappear under load effectively and I loose 
them mid QSO.

 

For future consideration perhaps is to have the setting of number of channels 
vs the number of active channels maintain a constant PER CHANNEL TX power 
rather than the variable situation we have now. Ie I enable my fox station to 
run say 4 channels, but only reply on 1 channel, then the output power should 
be the equivalent of the power that would be in that channel if all 4 were in 
fact on air but aren’t. At least that way I have a constant link budget I am 
working with on my comms channel with the fox station rather than one that can 
have them drastically cut power mid QSO without reference to the conditions on 
the path I am working them via.

 

If what I am describing is not how it is supposed to work already then there is 
another facto

Re: [wsjt-devel] Observation on Expedition Mode

[Black Michael via wsjt-devel]

Please give a logical explanation why you think transmitting in the blind is 
OK?DXpeditions generally run very good antennas on beaches in quiet places and 
can receive pretty well.
The is absolutely NO reason to call them until you hear CQ as long as WSJT-X 
forces a CQ every 5 transmissions.
If you call in the blind they may well receive you and try to respond when you 
can't hear them which means you take up a call slot that somebody who CAN hear 
them would better occupy.  When you call them it's an implied "I hear 
you..please respond".

de Mike W9MDB
 

On Saturday, June 30, 2018, 10:41:44 AM CDT, John Zantek  
wrote:  
 
 
Wholly concur with #2, but not necessarily #1, Mike.  Yes, lots of folks are 
calling in the blind.  That’s not limited to FT8, guys.  

  

But…

  

Depending on who’s running the digital tent (Don/Ned/?), rates of CQ vary from 
every 10 minutes to generate some traffic down to NONE, because there are 
stations calling.  I have a pretty ideal QTH to work Baker on any band, and I’m 
observing too much of the latter pattern.  I know there are lots of new folks 
sitting at their keyboards, waiting for the CQ, not seeing one, then walking 
away.  That’s not good, as it just reduces the rate for Baker, and frustrates 
the new ham who’s a potential DXer and digital apostle.

  

The QSB on 17M has been horrendous, with Baker’s sig, regardless of mode, 
varying wildly here.  On 17M, they were working the usual wall of JA but I 
never did see a CQ, so I entered it manually and generated the Std Msgs to work 
them successfully.  

  

From: Black Michael via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net] 
Sent: Saturday, June 30, 2018 7:15 AM
To: 'WSJT software development' 
Cc: Black Michael 
Subject: Re: [wsjt-devel] Observation on Expedition Mode

  

I have some observations too.

  

#1 Tons of ops calling KH7Z when they can't see them.  I assume this only 
causes problems as it's quite possible KH7Z with their honker antennas and can 
see them but not the other way round.  So KH7Z will put them in the queue and 
try to process them taking up the limited slots they are using right now (2 
from what I've seen).  IMHO the solution to this is pretty simplewhen you 
turn on Hound or switch bands you should be PREVENTED FROM TRANSMITTING UNTIL 
YOU GET CQ FRO THE DX STATION.    So, you would be required to double-click on 
a CQ to allow transmitting.  I noticed the the Baker team gave a lukewarm 
endorsement of FT8 on their news update quite likely due to this problem.

  

#2 We need to turn on spotting for the DX station so that PSKReporter and 
Hamspots can work and also so JTAlert can produce alerts when the DX station is 
received.  Don't need to spot the hounds of course.  Trying to figure out what 
band is good for local ops would be much improved with automatic spotting for 
us and for the DX team who could then see where their signal is going as more 
teams use internet on site via satellite links.

  

de Mike W9MDB

  

  

  

  

  

On Saturday, June 30, 2018, 8:13:39 AM CDT, Grant Willis  
wrote: 

  

  

Joe,

 

An observation if I may about expedition mode. I see with KH1/KH7Z that the 
number of Fox TX channels varies – I presume as they place more stations in the 
queue. As expected, the power per channel drops the more channels running so 
that the amplifiers can keep up. However, this has an unintended consequence 
perhaps of potentially breaking QSOs. A few times now I have started calling 
KH1/KH7Z on 20m when I am receiving them around -09 (but with pretty low 
S-meter  signal strength). Usually this is with 1-2 channels running on their 
downlink. If they go to 3 channels I can still receive but it falls to say -15. 
If they bring up channel 4 and 5 I loose them. There just isn’t the link budget 
left to receive them when the power is split between more than 3 channels in 
this example.

 

Now the issue is, if they answer me by adding the 4th channel – I wont hear 
them under those conditions. If I am part way through a QSO I can loose the 
RR73 for the same reason if they answer someone else on the 4th channel– simply 
because the link runs out of steam.

 

Now if I couldn’t hear them in the first place I wouldn’t have tried calling. 
In this case however, they can disappear under load effectively and I loose 
them mid QSO.

 

For future consideration perhaps is to have the setting of number of channels 
vs the number of active channels maintain a constant PER CHANNEL TX power 
rather than the variable situation we have now. Ie I enable my fox station to 
run say 4 channels, but only reply on 1 channel, then the output power should 
be the equivalent of the power that would be in that channel if all 4 were in 
fact on air but aren’t. At least that way I have a constant link budget I am 
working with on my comms channel with the fox station rather than one that can 
have them drastically cut power mid QSO without reference to the 

Re: [wsjt-devel] Observation on Expedition Mode

[Black Michael via wsjt-devel]

WSJT-X has already been changed where Fox transmits CQ every 5 transmissions 
now.If you don't see it then you shouldn't be calling.

>From the git log:

In DXpedition mode, enforce a Fox CQ at least every 5 transmissions.

 

On Saturday, June 30, 2018, 10:10:09 AM CDT, Charles Suckling 
 wrote:  
 
 
Hi Mike
 
  
 
The problem with needing to see a CQ isthat the dxpedition may rarely transmit 
a CQ (some folks were reporting thisyesterday).  Then, stations were working 
them by just calling. Majority were on the correct period, most were above 
1000Hz.  From what Icould see here about 90% of hounds were calling correctly.  
Whether theycould hear the dxpedition is another matter.
 
  
 
Earlier this afternoon there was a run ofCQ from them (or someone pretending to 
be them) about 10dB stronger than theyare here most of the time (-18 to -20).  
During this spell there seemed tobe no QSOs.
 
  
 
Charlie
 
From: Black Michael via wsjt-devel[mailto:wsjt-devel@lists.sourceforge.net] 
Sent: 30 June 2018 15:15
To: ' WSJT software development '
Cc: Black Michael
Subject: Re: [wsjt-devel]Observation on Expedition Mode
 
  
 
I have some observations too.
 
  
 
#1 Tons of ops calling KH7Z when they can't seethem.  I assume this only causes 
problems as it's quite possible KH7Z withtheir honker antennas and can see them 
but not the other way round.  SoKH7Z will put them in the queue and try to 
process them taking up the limitedslots they are using right now (2 from what 
I've seen).  IMHO the solutionto this is pretty simplewhen you turn on 
Hound or switch bands you shouldbe PREVENTED FROM TRANSMITTING UNTIL YOU GET CQ 
FRO THE DXSTATION.    So, you would be required to double-click on a CQ toallow 
transmitting.  I noticed the the Baker team gave a lukewarmendorsement of FT8 
on their news update quite likely due to this problem.
 
  
 
#2 We need to turn on spotting for the DX station sothat PSKReporter and 
Hamspots can work and also so JTAlert can produce alertswhen the DX station is 
received.  Don't need to spot the hounds ofcourse.  Trying to figure out what 
band is good for local ops would bemuch improved with automatic spotting for us 
and for the DX team who could thensee where their signal is going as more teams 
use internet on site viasatellite links.
 
  
 
de Mike W9MDB
 
  
 
  
 
  
 
  
 
  
 
On Saturday, June30, 2018, 8:13:39 AM CDT, Grant Willis  
wrote: 
 
  
 
  
 
Joe,
 
 
 
Anobservation if I may about expedition mode. I see with KH1/KH7Z that the 
numberof Fox TX channels varies – I presume as they place more stations in 
thequeue. As expected, the power per channel drops the more channels running 
sothat the amplifiers can keep up. However, this has an unintended 
consequenceperhaps of potentially breaking QSOs. A few times now I have started 
callingKH1/KH7Z on 20m when I am receiving them around -09 (but with pretty 
lowS-meter  signal strength). Usually this is with 1-2 channels running ontheir 
downlink. If they go to 3 channels I can still receive but it falls tosay -15. 
If they bring up channel 4 and 5 I loose them. There just isn’tthe link budget 
left to receive them when the power is split between more than3 channels in 
this example.
 
 
 
Nowthe issue is, if they answer me by adding the 4th channel – Iwont hear them 
under those conditions. If I am part way through a QSO I canloose the RR73 for 
the same reason if they answer someone else on the 4thchannel– simply because 
the link runs out of steam.
 
 
 
Nowif I couldn’t hear them in the first place I wouldn’t have triedcalling. In 
this case however, they can disappear under load effectively and Iloose them 
mid QSO.
 
 
 
Forfuture consideration perhaps is to have the setting of number of channels 
vsthe number of active channels maintain a constant PER CHANNEL TX power 
ratherthan the variable situation we have now. Ie I enable my fox station to 
run say4 channels, but only reply on 1 channel, then the output power should be 
theequivalent of the power that would be in that channel if all 4 were in fact 
onair but aren’t. At least that way I have a constant link budget I amworking 
with on my comms channel with the fox station rather than one that canhave them 
drastically cut power mid QSO without reference to the conditions onthe path I 
am working them via.
 
 
 
Ifwhat I am describing is not how it is supposed to work already then there 
isanother factor at work somewhere in the chain to be explored. I would be 
happyto discuss this further and use the KH1/KH7Z expedition to observe and 
learnmore about how the multi-channel nature of the mode works.
 
 
 
Regards,
 
GrantVK5GR
 
 
 
--
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
ht

Re: [wsjt-devel] Observation on Expedition Mode

[Charles Suckling]

Hi Mike

 

The problem with needing to see a CQ is that the dxpedition may rarely
transmit a CQ (some folks were reporting this yesterday).  Then, stations
were working them by just calling.  Majority were on the correct period,
most were above 1000Hz.  From what I could see here about 90% of hounds were
calling correctly.  Whether they could hear the dxpedition is another
matter.

 

Earlier this afternoon there was a run of CQ from them (or someone
pretending to be them) about 10dB stronger than they are here most of the
time (-18 to -20).  During this spell there seemed to be no QSOs.

 

Charlie

  _  

From: Black Michael via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net]

Sent: 30 June 2018 15:15
To: 'WSJT software development'
Cc: Black Michael
Subject: Re: [wsjt-devel] Observation on Expedition Mode

 

I have some observations too.

 

#1 Tons of ops calling KH7Z when they can't see them.  I assume this only
causes problems as it's quite possible KH7Z with their honker antennas and
can see them but not the other way round.  So KH7Z will put them in the
queue and try to process them taking up the limited slots they are using
right now (2 from what I've seen).  IMHO the solution to this is pretty
simplewhen you turn on Hound or switch bands you should be PREVENTED
FROM TRANSMITTING UNTIL YOU GET CQ FRO THE DX STATION.So, you would be
required to double-click on a CQ to allow transmitting.  I noticed the the
Baker team gave a lukewarm endorsement of FT8 on their news update quite
likely due to this problem.

 

#2 We need to turn on spotting for the DX station so that PSKReporter and
Hamspots can work and also so JTAlert can produce alerts when the DX station
is received.  Don't need to spot the hounds of course.  Trying to figure out
what band is good for local ops would be much improved with automatic
spotting for us and for the DX team who could then see where their signal is
going as more teams use internet on site via satellite links.

 

de Mike W9MDB

 

 

 

 

 

On Saturday, June 30, 2018, 8:13:39 AM CDT, Grant Willis 
wrote: 

 

 

Joe,

 

An observation if I may about expedition mode. I see with KH1/KH7Z that the
number of Fox TX channels varies - I presume as they place more stations in
the queue. As expected, the power per channel drops the more channels
running so that the amplifiers can keep up. However, this has an unintended
consequence perhaps of potentially breaking QSOs. A few times now I have
started calling KH1/KH7Z on 20m when I am receiving them around -09 (but
with pretty low S-meter  signal strength). Usually this is with 1-2 channels
running on their downlink. If they go to 3 channels I can still receive but
it falls to say -15. If they bring up channel 4 and 5 I loose them. There
just isn't the link budget left to receive them when the power is split
between more than 3 channels in this example.

 

Now the issue is, if they answer me by adding the 4th channel - I wont hear
them under those conditions. If I am part way through a QSO I can loose the
RR73 for the same reason if they answer someone else on the 4th channel-
simply because the link runs out of steam.

 

Now if I couldn't hear them in the first place I wouldn't have tried
calling. In this case however, they can disappear under load effectively and
I loose them mid QSO.

 

For future consideration perhaps is to have the setting of number of
channels vs the number of active channels maintain a constant PER CHANNEL TX
power rather than the variable situation we have now. Ie I enable my fox
station to run say 4 channels, but only reply on 1 channel, then the output
power should be the equivalent of the power that would be in that channel if
all 4 were in fact on air but aren't. At least that way I have a constant
link budget I am working with on my comms channel with the fox station
rather than one that can have them drastically cut power mid QSO without
reference to the conditions on the path I am working them via.

 

If what I am describing is not how it is supposed to work already then there
is another factor at work somewhere in the chain to be explored. I would be
happy to discuss this further and use the KH1/KH7Z expedition to observe and
learn more about how the multi-channel nature of the mode works.

 

Regards,

Grant VK5GR

 


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



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http

Re: [wsjt-devel] Observation on Expedition Mode

[Black Michael via wsjt-devel]

I have some observations too.
#1 Tons of ops calling KH7Z when they can't see them.  I assume this only 
causes problems as it's quite possible KH7Z with their honker antennas and can 
see them but not the other way round.  So KH7Z will put them in the queue and 
try to process them taking up the limited slots they are using right now (2 
from what I've seen).  IMHO the solution to this is pretty simplewhen you 
turn on Hound or switch bands you should be PREVENTED FROM TRANSMITTING UNTIL 
YOU GET CQ FRO THE DX STATION.    So, you would be required to double-click on 
a CQ to allow transmitting.  I noticed the the Baker team gave a lukewarm 
endorsement of FT8 on their news update quite likely due to this problem.

#2 We need to turn on spotting for the DX station so that PSKReporter and 
Hamspots can work and also so JTAlert can produce alerts when the DX station is 
received.  Don't need to spot the hounds of course.  Trying to figure out what 
band is good for local ops would be much improved with automatic spotting for 
us and for the DX team who could then see where their signal is going as more 
teams use internet on site via satellite links.
de Mike W9MDB



 

On Saturday, June 30, 2018, 8:13:39 AM CDT, Grant Willis 
 wrote:  
 
 
Joe,

  

An observation if I may about expedition mode. I see with KH1/KH7Z that the 
number of Fox TX channels varies – I presume as they place more stations in the 
queue. As expected, the power per channel drops the more channels running so 
that the amplifiers can keep up. However, this has an unintended consequence 
perhaps of potentially breaking QSOs. A few times now I have started calling 
KH1/KH7Z on 20m when I am receiving them around -09 (but with pretty low 
S-meter  signal strength). Usually this is with 1-2 channels running on their 
downlink. If they go to 3 channels I can still receive but it falls to say -15. 
If they bring up channel 4 and 5 I loose them. There just isn’t the link budget 
left to receive them when the power is split between more than 3 channels in 
this example.

  

Now the issue is, if they answer me by adding the 4th channel – I wont hear 
them under those conditions. If I am part way through a QSO I can loose the 
RR73 for the same reason if they answer someone else on the 4th channel– simply 
because the link runs out of steam.

  

Now if I couldn’t hear them in the first place I wouldn’t have tried calling. 
In this case however, they can disappear under load effectively and I loose 
them mid QSO.

  

For future consideration perhaps is to have the setting of number of channels 
vs the number of active channels maintain a constant PER CHANNEL TX power 
rather than the variable situation we have now. Ie I enable my fox station to 
run say 4 channels, but only reply on 1 channel, then the output power should 
be the equivalent of the power that would be in that channel if all 4 were in 
fact on air but aren’t. At least that way I have a constant link budget I am 
working with on my comms channel with the fox station rather than one that can 
have them drastically cut power mid QSO without reference to the conditions on 
the path I am working them via.

  

If what I am describing is not how it is supposed to work already then there is 
another factor at work somewhere in the chain to be explored. I would be happy 
to discuss this further and use the KH1/KH7Z expedition to observe and learn 
more about how the multi-channel nature of the mode works.

  

Regards,

Grant VK5GR

  
--
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] Observation on Expedition Mode

[Grant Willis]

Joe,

 

An observation if I may about expedition mode. I see with KH1/KH7Z that the
number of Fox TX channels varies - I presume as they place more stations in
the queue. As expected, the power per channel drops the more channels
running so that the amplifiers can keep up. However, this has an unintended
consequence perhaps of potentially breaking QSOs. A few times now I have
started calling KH1/KH7Z on 20m when I am receiving them around -09 (but
with pretty low S-meter  signal strength). Usually this is with 1-2 channels
running on their downlink. If they go to 3 channels I can still receive but
it falls to say -15. If they bring up channel 4 and 5 I loose them. There
just isn't the link budget left to receive them when the power is split
between more than 3 channels in this example.

 

Now the issue is, if they answer me by adding the 4th channel - I wont hear
them under those conditions. If I am part way through a QSO I can loose the
RR73 for the same reason if they answer someone else on the 4th channel-
simply because the link runs out of steam.

 

Now if I couldn't hear them in the first place I wouldn't have tried
calling. In this case however, they can disappear under load effectively and
I loose them mid QSO.

 

For future consideration perhaps is to have the setting of number of
channels vs the number of active channels maintain a constant PER CHANNEL TX
power rather than the variable situation we have now. Ie I enable my fox
station to run say 4 channels, but only reply on 1 channel, then the output
power should be the equivalent of the power that would be in that channel if
all 4 were in fact on air but aren't. At least that way I have a constant
link budget I am working with on my comms channel with the fox station
rather than one that can have them drastically cut power mid QSO without
reference to the conditions on the path I am working them via.

 

If what I am describing is not how it is supposed to work already then there
is another factor at work somewhere in the chain to be explored. I would be
happy to discuss this further and use the KH1/KH7Z expedition to observe and
learn more about how the multi-channel nature of the mode works.

 

Regards,

Grant VK5GR

 

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