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

[Lyn Norstad]

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.
> ______________________________________________________________
> Elecraft mailing list
> Home: http://mailman.qth.net/mailman/listinfo/elecraft
> Help: http://mailman.qth.net/mmfaq.htm
> Post: mailto:Elecraft at mailman.qth.net
>
> This list hosted by: http://www.qsl.net
> Please help support this email list: http://www.qsl.net/donate.html
> Message delivered to ab7echo at gmail.com 

______________________________________________________________
Elecraft mailing list
Home: http://mailman.qth.net/mailman/listinfo/elecraft
Help: http://mailman.qth.net/mmfaq.htm
Post: mailto:Elecraft at mailman.qth.net

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html
Message delivered to lyn at lnainc.com