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 simple....when 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 
<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-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

Reply via email to