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 <wsjt-devel@lists.sourceforge.net>
Cc: Black Michael <mdblac...@yahoo.com>
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 <dsfis...@outlook.com>
wrote:
That ain’t happening at KH1/KH7X. Not on 20M anyway.
Dave / NX6D
_____
From: Black Michael via wsjt-devel <wsjt-devel@lists.sourceforge.net>
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
<char...@sucklingfamily.free-online.co.uk> 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 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
<https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsdm.link%2Fslashdot&data=02%7C01%7C%7C3b09c754bc7e45f8903708d5dea021cd%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636659701700098139&sdata=WKE2Y2w2KMQa1pFHGtM8yMllU%2F5hm2QN2W7jm4xXvRw%3D&reserved=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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fwsjt-devel&data=02%7C01%7C%7C3b09c754bc7e45f8903708d5dea021cd%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636659701700098139&sdata=9xzF%2F0MJpmqBfhDVC81H7lFwkiB7Xndq03cVQd8zjcA%3D&reserved=0>
_____
<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.avast.com%2Fsig-email%3Futm_medium%3Demail%26utm_source%3Dlink%26utm_campaign%3Dsig-email%26utm_content%3Demailclient&data=02%7C01%7C%7C3b09c754bc7e45f8903708d5dea021cd%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636659701700098139&sdata=dfOdwikqTyXj7RM2v8ghIQGMsYm3rxewvQHso3iZO7U%3D&reserved=0>
This email has been checked for viruses by Avast antivirus software.
www.avast.com
<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.avast.com%2Fsig-email%3Futm_medium%3Demail%26utm_source%3Dlink%26utm_campaign%3Dsig-email%26utm_content%3Demailclient&data=02%7C01%7C%7C3b09c754bc7e45f8903708d5dea021cd%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636659701700098139&sdata=dfOdwikqTyXj7RM2v8ghIQGMsYm3rxewvQHso3iZO7U%3D&reserved=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
