3khz??? The whole spot is only 3khz. Try 3hz. Aug AG5AT
Sent from my iPad > On Aug 29, 2021, at 3:00 PM, Koen Bijl via wsjt-devel > <wsjt-devel@lists.sourceforge.net> wrote: > > > 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
_______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
