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
