Band planning is good idea. I've failed to understand why a given segment of the bands were agreed on for JT65, JT9, FT4, FT8 and so forth. Seems better to operate with any of those mode on any part of the RTTY and data segments of the bands. Maybe the idea to use a given frequency for each mode was because ops may not recognize what mode it is based on the sound and how it looks in the waterfall? I'm not condemning the decision on selecting a given frequency for a given JT mode. Cycle 25 is picking up, but it's getting really crowded on many of the FT8 frequencies. Personally; I'm looking forward to prop improving and jumping into a huge SSB pileup for one of the most wanted DXCC entities. Like Bouvet Island :)
73 Stan KM4HQE On 8/27/21 5:55 PM, Grant VK5GR via wsjt-devel wrote: > Phil, > > As part of a multi-region IARU Band planning sub-committee we are working on > getting agreement to expand the FT8 band to enable at least 2-3 FT8 "3kHz" > channels per band. > > Could your frequency hopping idea be expanded so that the transceiver > frequency control could be included enabling traffic to be spread over say > 3x3kHz, but still help people maintain their "band awareness" of who is on > the band I wonder? > > Regards, > Grant VK5GR > IARU R3 Bandplan subcommittee rep > > -----Original Message----- > From: H.Shrikumar KA6Q via wsjt-devel > [mailto:wsjt-devel@lists.sourceforge.net] > Sent: Saturday, 28 August 2021 5:54 AM > To: Phil Karn via wsjt-devel > Cc: H.Shrikumar KA6Q > Subject: Re: [wsjt-devel] Idea for "frequency hopping" FT8 to reduce > collisions > > > I've had such ideas also, so adding to this: > > Do the hashing only when starting a CQ, not in the midst of a QSO. > Make the hash return not a single value but actually a series > eg. add a try number into the hash input making it a PRNG. > Before grabbing a Tx offset, you know from the past cycles if it was free. > at least, to you it appeared free (modulo hidden station problem) > if it was not free earlier, then check the next hash. > Thus it goes from plain aloha to slotted aloha to some CSMA/CA. > so channel capacity goes up. > > Small change, and should be interoperable with existing software. > so it does not force a mandated upgrade upon everyone. > The newer version with this idea will be able to perform better > (not worse :-) so it encourages upgrade/adoption. > > -- 73 de ka6q Shri > > ---Original Message--- >> From: Phil Karn via wsjt-devel <wsjt-devel@lists.sourceforge.net> >> Date: Fri, 27 Aug 2021 12:48:27 -0700 >> To: WSJT software development <wsjt-devel@lists.sourceforge.net> >> Cc: Phil Karn <k...@ka9q.net> >> Subject: [wsjt-devel] Idea for "frequency hopping" FT8 to reduce > collisions >> X-Headers-End: 1mJiC4-003uGY-9u >> Reply-To: WSJT software development <wsjt-devel@lists.sourceforge.net> >> >> While composing another message I had an idea that might help reduce >> FT-8 congestion. >> >> Every FT-8 receiver listens to an entire "band" (approximately 1 SSB >> bandwidth) and it will hear and decode every station transmitting >> anywhere in it. This makes each station's exact transmit frequency >> unimportant. So for some time I've felt that FT-8 transmissions should >> be randomized in frequency to avoid repeated collisions, as most WSPR >> stations already do. But the transmit frequency need not be truly >> random; if it is based on a hash function, then other stations can know >> the frequency on which you will (or would) transmit during any given >> 15-second slot. >> >> So here's my idea. Divide the FT-8 "band" into slots, each wide enough >> to take one signal. Set your transmit frequency "slot" based on a hash >> of the transmitting station's callsign, perturbed by the time of day in >> 15 second increments. This sets up the frequency hopping. It is backward >> compatible with current operation. >> >> Everyone monitors everyone else's protocol exchanges so they are aware >> of the active callsigns and their current QSO exchange states. If your >> hash happens to match that of a station expected to transmit, either >> inhibit transmission or choose from a small set of secondary "overflow" >> slots unprotected against a collision. >> >> I just had this idea so it is far from fully formed. Nor can it be >> perfect because, if nothing else, you are unable to monitor >> transmissions while you yourself are transmitting. But I wanted to see >> if anyone else had any comments on it, or if it has been suggested before. >> >> 73, Phil >> >> >> >> >> >> _______________________________________________ >> wsjt-devel mailing list >> wsjt-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/wsjt-devel >> > > _______________________________________________ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel > > > > _______________________________________________ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel _______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
