Comments below.
> On Jul 2, 2021, at 9:01 PM, David Gilbert <ab7echo@gmail.com> wrote:
>
>
> I've gone through this stuff in detail with someone who knows far more about
> digital signal processing than either of us, and everything I said is
> possible with the exception that I will acknowledge that synchronous
> operation has advantages. My postulation does NOT involve adhering to the
> FT8 or FT4 protocol as you seem to suggest below.
I never suggested you had to keep to the FT8 or FT4 protocols. What I said was
that the design trade-offs of FT8 and FT4 are what gave them their weak-signal
performance. Getting the same level of weak-signal performance out of a
non-synchronous protocol is very difficult.
> I proposed a mode similar to FT4 except wider bandwidth (which dose NOT
> necessarily degrade S/N as you claim)
You are incorrect here. Wider bandwidth means MORE NOISE. Given the signal
level is the same, that’s going to decrease the S/N.
> and a different set of other parameters ... plus conversion to CW instead of
> fixed text blocks simply to make it more adaptable to common contesting
> practice.
>
> I don't care what you say ... it can be done, but it's going to take somebody
> to work it up from scratch instead of trying to port FT8 or FT4 to a
> different user interface.
I **NEVER** said it couldn’t be done. What I was pointing our is that many of
the things you want tossed by the wayside are the very things that make FT8 and
FT4 perform as well as they do.
> Just about everything you said below is wrong simply because you're stuck in
> that mental trap.
HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA — That’s a good one!
> I will say again since nobody seems to get it ... FT8 and FT4 as implemented
> by WSJT-X are not some new invention that locks all other similar efforts
> into the same set of boundary conditions that K1JT chose.
I **NEVER** said that.
> K1JT made very clever use of modern signal processing to create FT8, FT4, and
> other similar modes but he chose a VERY restrictive set of boundary
> conditions in order to implement his own particular vision.
And many of those boundary conditions are what gave these protocols their
tremendous weak-signal performance.
> Those same modern signal processing techniques could be implemented with
> different boundary conditions to give ham radio (and in particular
> contesting) a much cleaner and more usable interface.
Certainly. But changing those boundary conditions is going to change the
performance of the protocol.
> Go read K1JT's descriptions of what he did and what techniques he used, and
> if you then do a bit of searching you will find lots of technical discussions
> of those same methods applied in different ways to other tasks. WSJT-X is
> unique, but the the science behind it is not.
>
> I know that I am flogging a dead horse here, but it frustrates the hell out
> of me to see the opportunity that is being squandered simply because the guy
> that came up with the first popular manifestation of modern signal processing
> had such a limited vision of what it should be.
I’ll agree there is certainly room to innovate, but I feel you lack an innate
understanding of what K1JT did, and how changing it will change the performance.
The first element is that K1JT limits his transmissions to a very few bits. FT8
and FT4 use 77 bits in each transmission. Each transmission is fundamentally a
77-bit number that conveys the station callsigns and any message associated
with them. A lot of the genius is carefully mapping every possible combination
of callsigns and messages onto that 77 bit space.
With a 77 bit message, he then adds a 14-bit CRC, resulting in a 91 bit message
with error checking (the CRC isn’t perfect, I’m sure anyone who has operated
either mode for any length of time has witnessed falser messages). That 91 bits
is then forward-error-corrected into a matrix of 174 bits.
These bits are then broken down into symbols which are transmitted (and this
differs for FT8 and FT4). The number of symbols is small, roughly 60 for FT8
and 90 for FT4.
The resulting symbol rates are really, really low — less than 5 symbols/second
for FT8. And that’s part of what makes for good performance. Low symbol rates
means less bandwidth for a well-designed encoding, and less bandwidth leads to
better weak-signal performance.
Now, if you want to take this and say you want to just send arbitrary text,
then the whole thing blows up. You got to send a lot more bits. If you keep the
symbol rates low and do similar encoding, then the resulting data rates are
going to be very slow — trivial to out-type. If you speed things up a bit and
go with faster symbols, you’ll end up with less weak-signal performance.
—
By all means, however, we can have a free-text protocol using modern DSP
techniques. It just won’t have the same performance of FT8 or FT4.
I’m just wondering where you start. PSK31 is actually pretty good. Maybe you
improve it by throwing out lower case and a lot of punctuation and rebuilding
the Huffman encoder for a more limited alphabet. That might give you enough
bits to allow for forward-error-correction without being terribly slow.
But then, I wonder, what are you going to do when a transmission block is
garbled?
There’s a lot to think about, and none of it is easy.
> Dave AB7E
>
>
>
> On 7/2/2021 10:39 AM, Bill Coleman wrote:
>>
>>> On Jun 21, 2021, at 2:59 PM, David Gilbert <ab7echo@gmail.com> wrote:
>>>
>>> Everything you just said there is the fault of WSJT-X as a user interface
>>> ... not FT8 or FT4 as a mode. They are NOT the same thing. WSJT-X is
>>> simply the narrow and restrictive vehicle by which we have been exposed to
>>> the exceptional weak signal capability of modern digital processing
>>> (forward error correcting, Costas array processing, etc). We'd all be
>>> having a LOT more fun with a more open ended interface ... possibly with
>>> these parameters:
>>>
>>> 1. wider individual signal bandwidth, such as maybe 200 Hz instead of 83
>>> Hz.
>> A wider bandwidth would potentially decrease the sensitivity of the mod
>>
>>> 2. fully tunable over the typical digital sub band (like RTTY does)
>> There’s absolutely nothing stopping you from running FT8 or FT4 anywhere in
>> the digital sub-bands. You may not have many QSOs there, but it is possible.
>>
>>> 3. Asynchronous in time ... i.e., not locked to a discrete and specific
>>> clock window
>> This requirement is fundamentally incompatible to the way that FT8 or FT4
>> work. The fixed transmission / reception windows are clearly a part of the
>> mode.
>>
>>> 4. shorter blocks of data with continuous feed of the blocks
>> Shorter blocks? The blocks today only convey 77 bits (BITS!) of information.
>> That’s right, it takes nominally 15 (or 7.5) seconds to transmit 77 bits
>> (BITS!) of information.
>>
>> And continuous blocks don’t work either.
>>
>>> 5. sent via text blocks on the transmit end ... exactly as DVRs and
>>> contest loggers do now
>> Remember the 77 bits (BITS!) mentioned earlier? Each transmitted block has a
>> certain structure, and typically contains the two callsigns (caller and
>> callee) and a little bit of additional text. There’s no much room for
>> sending any random text, because there’s only a few bits available to on
>> each sent block.
>>
>>> 6. displayed as text or converted to audible CW (or even digital voice) on
>>> the receive end
>> Bill Coleman, AA4LR, PP-ASEL Mail: aa4lr@arrl.net
>> Web: http://boringhamradiopart.blogspot.com
>> Quote: "Not within a thousand years will man ever fly!"
>> -- Wilbur Wright, 1901
>>
>
> _______________________________________________
> CQ-Contest mailing list
> CQ-Contest@contesting.com
> http://lists.contesting.com/mailman/listinfo/cq-contest
Bill Coleman, AA4LR, PP-ASEL Mail: aa4lr@arrl.net
Web: http://boringhamradiopart.blogspot.com
Quote: "Not within a thousand years will man ever fly!"
-- Wilbur Wright, 1901
_______________________________________________
CQ-Contest mailing list
CQ-Contest@contesting.com
http://lists.contesting.com/mailman/listinfo/cq-contest
|