Gordon,It's Phil's proposal, not mine.I merely pointed out that network
throughput (a.k.a. the number of simultaneous users) would be affected
negatively if only 50 channels (Phil's original proposal) were available, a
problem that could be ameliorated by channel overlapping and two-pass decoding.
We are both concerned about network capacity. I don't know the upper bound of
simultaneous FT8 users in a given bandwidth. The original problem Phil was
trying to solve, of course, was the repeated-collision problem in FT8.Ed N4II.
-------- Original message --------From: Gordon Weast via wsjt-devel
<wsjt-devel@lists.sourceforge.net> Date: 8/29/21 2:34 PM (GMT-06:00) To:
jan0--- via wsjt-devel <wsjt-devel@lists.sourceforge.net> Cc: Gordon Weast
<gordonwe...@charter.net> Subject: Re: [wsjt-devel] Idea for "frequency
hopping" FT8 to reduce
collisions 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 wa9wtkjan0--- 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
listwsjt-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/wsjt-devel
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
