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