If a channelized scheme is introduced to avoid recurrent channel collisions, care should be taken not to reduce the network throughput. As anyone who has visited 14.074 lately can attest, for much of the day there is more channel demand than channel availability -- and other bands are frequently similar.
Two-pass decoding, available in many if not all FT8 software suites, enables multiple signals to be decoded across a single transmission bandwidth. With two-pass decoding, the number of available frequency slots can be increased by overlapping them, so that, for example, more than 60 slots can be available in a 3-kHz bandwidth. This would increase the network throughput, to a degree dependent upon frequency offset, signal amplitude differences, waveform fidelity, transmit and receive phase noise, channel impairments (e.g., Doppler spreading), demodulator cochannel rejection, and a host of other parameters I am sure I am forgetting. One thought experiment is to consider a functioning channelized system with, say, 56, 50-Hz channels in a 200 to 3000 Hz bandwidth, and then overlay a second channelized system, with 55, 50-Hz channels, in a 225 to 2975 Hz bandwidth. With two-pass decoding the combined, overlaid system will have higher network throughput than either system alone, although less than twice the individual system throughput due to collisions. Network simulations would be required to quantify the performance, the performance difference to the system of the present day, and an optimum offset value (in Hz); the definition of "optimum," in terms of the desired system performance (collision rate, network throughput, statistical distribution of collisions, etc.) would also have to be decided. Note the use of overlapping (direct-sequence spread spectrum) channels in the IEEE 802.11b standard (Wi-Fi), albeit for a different, if similar, purpose. Ed N4II. -----Original Message----- From: William Smith via wsjt-devel <wsjt-devel@lists.sourceforge.net> Sent: Saturday, August 28, 2021 6:56 AM To: WSJT software development <wsjt-devel@lists.sourceforge.net> Cc: William Smith <w_sm...@compusmiths.com> Subject: Re: [wsjt-devel] Idea for "frequency hopping" FT8 to reduce collisions Interesting idea, a couple of thoughts come to mind (not that you haven't already considered them): When you are only listening, you have a good idea of who else is transmitting when/where, but as soon as you start transmitting, you lose visibilty into your timeslot. I use a combination of visual inspection and a Python program that grinds through the last couple of minutes of ALL.TXT to pick an empty transmit frequency, and while it works, it's a bit of a kludge. There's no good answer to "How wide is someone else's rx bandwidth?". While some have fancy SDR rigs with 5KHz or more, others have voice rigs (or don't know how to set their filters), so attempting a QSO at 200Hz or 4KHz is only going to work for some random subset of operators. 73, Willie N1JBJ > On Aug 27, 2021, at 3:48 PM, Phil Karn via wsjt-devel <wsjt-devel@lists.sourceforge.net> wrote: > > 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
