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
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
<mailto:vk...@bigpond.com> <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

 


 
<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_cam
paign=sig-email&utm_content=emailclient> 

Virus-free.
<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_cam
paign=sig-email&utm_content=emailclient> www.avg.com 








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



---
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://sdm.link/slashdot
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Reply via email to