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

[Lynn W. Taylor, WB6UUT]

I was trying to remember JS8CALL -- thanks for the reminder.

The best thing about this hobby is that there are so many options and so 
many different things you can do.

David, in my off-list message, I was thinking of JS8CALL.

73 -- Lynn

On 7/12/20 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