Joe, Thanks for the reply. Yes it seemed to be going pretty well today on 40m (although the pileup was immense). Looked like definitely 100+ QSO/hr was being achieved which is faster than they were managing on RTTY on 40m the night before.
Your idea of changing the fox signal to a different multiplex but single FSK signal would definitely be one way and the 7dB would help - but I was more thinking is there something we can do so that the per channel power is reduced to be equivalent to the worst case power reduction with 5 channels (or whatever the channel limit was that the operator set) when less carriers are transmitting. IE. If when transmitting 5 slots I can only send 20W/carrier - then when I am running 4 slots - still only run 20W/carrier but accept that your total combined output power will drop - doesnt matter however as the link budget is set by the individual channel power not the TX total power capacity. Even if you only run one sub-carrier hold it at 20W. I am looking at it from the maintain constant sub-channel power rather than the use all the available power regardless of the number of channels perspective (which is what causes the sub-channel power to vary up to 14dB between 1 and 5 channels active). Practically, I was seeing good decodes at 3 channels on 20m the other day which for a 500W amp would have been around 50W/carrier - if they had limited the number of channels to 3 and no one channel was ever allowed to send more than 50W as the channel count varied people would have been working against a constant link budget and I feel would have had a better chance of not breaking the QSOs. As it was, whenever the 4th channel appeared I struggled to decode them and if the 5th channel appeared I never decoded them that day. If there were three channels active and they answered me by bringing up the 4th (which I think they did on a couple of occasions) I lost them and could never complete the QSO. It was from that perspective that I made my observations. FWIW and further comment? Regards, Grant VK5GR -----Original Message----- From: Joe Taylor [mailto:j...@princeton.edu] Sent: Tuesday, 3 July 2018 10:55 PM To: WSJT software development; Tsutsumi Takehiko Subject: Re: [wsjt-devel] Observation on Expedition Mode 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 chairpersons 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 Steves 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 dont 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 isnt 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 couldnt hear them in the first place I wouldnt 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 arent. > 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 ------------------------------------------------------------------------------ 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