[CQ-Contest] Contesting and the FT8 Revolution

[Martin, LU5DX]

FTeedom of speech has always been a most valued quality of the email
ftflector.
Mr. Modeftrators, please keep ftit up.

Vy ft73,

Martín LU5DX

P.S. FT4 is pertectly suited for contesting.


El sáb., 3 jul. 2021 3:12 p. m., Jeff Clarke <ku8e at ku8e.com> escribió:

> Again for the umpteenth time... Why are people talking about this
> subject on a CONTESTING reflector? Neither FT8 or FT4 are contesting
> modes. I guess this is more proof that FT8 has totally taken over ham
> radio? I guess people are really bored and can't help themselves? Hello
> Mr Moderator can you please tell people to stop!
>
> Jeff
>
> On 7/2/2021 09:01 PM, David Gilbert 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
> > proposed a mode similar to FT4 except wider bandwidth (which dose NOT
> > necessarily degrade S/N as you claim) 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.  Just about everything you said
> > below is wrong simply because you're stuck in that mental trap.
> >
> > 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.  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.  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.  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.
> >
> > Dave   AB7E
> >
> >
> >
> > On 7/2/2021 10:39 AM, Bill Coleman wrote:
> >>
> >>> On Jun 21, 2021, at 2:59 PM, David Gilbert <ab7echo at 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 at 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 at contesting.com
> > http://lists.contesting.com/mailman/listinfo/cq-contest
> _______________________________________________
> CQ-Contest mailing list
> CQ-Contest at contesting.com
> http://lists.contesting.com/mailman/listinfo/cq-contest
>