[Elecraft] FT8 - was "On Second Thought, I'll Take The Stairs"

[David Gilbert]

Not quite.  I'm aware of JS8 and tried it more than a year ago, but it 
still has much of the rigidity of the WSJT-X user interface and isn't as 
basic as I think would be desirable.

Think of it this way ... CW works fine as both a contest mode, DXing 
mode, and conversational mode.  Underlaying CW with a well configured 
digital signal processing scheme like that which is under FT8, except 
with a different user interface than either WSJT-X or JS8,  could be 
equally versatile but with maybe 6-8 db better S/N ... possibly by an 
even greater margin if the decoding allowed errors instead of being all 
or nothing.

I'm not saying text-to-CW is the only way to reap the benefit of modern 
digital signal processing ... only using it as an example.

People only interested in a contact will probably always prefer 
WSJT-X/FT8 because it does that very well, but both contesting and rag 
chewing could really use a different (simpler) structure while still 
utilizing the superior weak signal peformance of modern digital signal 
processing.  I guarantee that it is possible to do so.

73,
Dave   AB7E


On 7/12/2020 6:18 PM, Lyn Norstad wrote:
> Enter JS8Call.
>
> All the technology of FT8, plus all of the conversationality of CW, RTTY and SSB rolled into one.
>
> If you haven't tried it, you really should.  It's developer, Jordan Sherer (KN4CRD) has done a terrific job with it and I am honored to have been a part of the beta team almost since day one.
>
> http://js8call.com/
>
> 73
> Lyn, W0LEN
>
>
> -----Original Message-----
> From: elecraft-bounces at mailman.qth.net [mailto:elecraft-bounces at mailman.qth.net] On Behalf Of David Gilbert
> Sent: Sunday, July 12, 2020 7:40 PM
> To: elecraft at mailman.qth.net
> Subject: [Elecraft] FT8 - was "On Second Thought, I'll Take The Stairs"
>
>
> Well, the fact is that the coding and processing behind modes like FT8
> doesn't have to be as rigid as is implemented in WSJT-X.  It only
> requires that information be sent and received in time frames, and those
> time frames are simply a function of three variables ... bandwidth,
> rate, and number of characters in the message frame.  It would be
> possible to change any of those, such as widening the bandwidth to
> increase the number of characters for the same time frame.
>
> It would also be possible to send text but have it converted to CW on
> the other end.  Or even to key CW that gets converted to text before
> transmission ... i.e., CW to CW except with significantly better S/N
> performance.  If the user was willing to live with a narrow bandwidth
> single conversation format, clock synchronization isn't even really
> needed.   And if we were willing to live with a single conversation
> format, there would be no point in cramming everyone into 2.4 KHz and we
> could spread out like we do for every other mode.
>
> I'm no expert, but I think that the coding could have enough error
> checking to allow busted message frames to be printed (or converted to
> CW) ... although of course with errors.  The extra error processing
> would reduce the character count, though, all other things being equal.
>
> The point is that the digital signal processing behind FT8 is extremely
> powerful and could be adapted to other user formats with a lot more
> flexibility than we have with FT8.  The hams who just dismiss FT8 out of
> hand really don't understand the broader weak signal applicability of it.
>
> 73,
> Dave   AB7E
>
>
>
> On 7/12/2020 4:53 PM, Lynn W. Taylor, WB6UUT wrote:
>> Yeah, great, reliable at or below the noise floor, but if all you're
>> doing is meeting the somewhat arbitrary minimum that defines a QSO,
>> what's the point?
>>
>> I mean seriously, can you even ask about the weather?  Just say "hi?"
>>
>> Meh.
>>
>> I'm fine with typing, but I want a real live person typing back, and
>> if we can type back and forth for an hour, that's great.
>>
>> 73 -- Lynn
>>
>> On 7/12/20 2:33 PM, Wayne Burdick wrote:
>>> The argument for digital modes like FT8 is that they're reliable at
>>> or below the noise floor, making it possible to work lots of DX even
>>> if solar conditions are very poor. Simplicity of protocol is a side
>>> effect of this design.
>> _________________