[CQ-Contest] Contesting and the FT8 Revolution

Jeff Clarke ku8e at ku8e.com
Sat Jul 3 12:36:42 EDT 2021


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


More information about the CQ-Contest mailing list