Popularity from ft8 is that all the hams are within 3 kHz and not separated by let’s say 20 kHz.
Op zo 29 aug. 2021 om 21:35 schreef Gordon Weast via wsjt-devel < wsjt-devel@lists.sourceforge.net> > Ed, > > When I look at decodes on 20m today, I've seen multiple times when > signals offset by as little as 1 Hz are decoded just fine. > Basically, the protocol works fine with lots of overlap. There is NO > need to channelize transmission frequencies. > > Restricting transmissions to the channels you're proposing would > severely restrict the number of simultaneous users. > > In any event, you can't avoid overlap since what looks like a clear > channel at your location will probably not look like a clear channel at > a different location. > > Gordon wa9wtk > > jan0--- via wsjt-devel wrote: > > 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 > > > > > > _______________________________________________ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel > -- Koen Bijl Goudvinkhaga 26 3993 bc Houten The Netherlands
_______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
