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