Hi John and all
John I have also monitored 40mts this morning for a long period and I have
seen your qso. This time I watched what was expected. It was the first
time I could qso, calling above 3000Hz. It seemed that in other activities
that I have participated (30m and 20m) the Fox was not monitoring the full
4KHz channel. I had to go down on the channel to QSO.
I was able to see Fox changing the number of slots from 1 up to 4. Once it
was one signal, I had a good decode. When he increased the number of slots
I lost the Fox, until propagation peeked up again. Pretty in line to what
is expected.
DXpetion mode is a great achievement for DXpeditions. Fred PY2XB
2018-07-03 10:24 GMT-03:00 Joe Taylor <j...@princeton.edu>:
> 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
>
--
Fred - PY2XB
Other calls: PY2FXH, PY2FXH/W2, PY2XB/0, F/PY2XB, ZX2XB, PT7BXB,
PY2XB/PY0F, PQ0F, VP5/PY2XB, PW2IO (SA-071), ZX8W (SA-060), PY2XB/1
(SA-029), 8P9XB, PQ8XB (SA-045), ZX2S (SA-28), W4/PY2XB, 3D2XB, PY22XB,
PY0FX, W2/PY2XB, W9/PY2XB, VE3/PY2XB. Team member: PW2M (SA-071), PX8J
(SA-041), T30PY - T30SIX, PT0S, 9M0W
------------------------------------------------------------------------------
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