[RTTY] PSK31 is faster (Was FD RTTY Question)

[aflowers at frontiernet.net]

Interesting discussion, though I don't exactly know why this veered off into what modes are "better" contesting and how to hack MMTTY for 7 bit ASCII.  This thread was about PSK31 being less fun than RTTY in FD because it was too slow.  I don't particularly care if someone includes a SITOR-B in their contest like the RTTY Roundup or strictly 45 baud Baudot (apparently 45.45 baud allowed--I may risk the DQ and crank it up to 46.0 baud this year).  As far as I'm concerned it is up to the contest sponsor define and then the operators to decide how to maximize score (or fun).  This was initially about the perceived lethargy of PSK31.

Anyway, thanks to those who were willing to check math--the back of the envelope is not a spreadsheet :-) Chen pointed out that PSK31 actually uses what is effectively two stop bits for character synchronization (ouch, but it does make writing a demodulator much easier).  The updated tables are at the bottom of this message.  I also changed the messages to have a leading and trailing space, since this is maximally efficient in both modes and is an accepted practice in the RTTY world.  RTTY is still calculated using USOS.  That's probably as "apples-to-apples" as we can get.

The important part for our discussion is that the FD exchange tends to break even with 45 baud RTTY--its a little faster than RTTY if you are in NE and a little slower if you are in WCF or your callsign has lots of Z's and X's, but certainly not significantly slower on the whole.  As has been mentioned in the thread, the ARRL FD exchange is expensive in RTTY due to all of the LTRS/FIGS shifts from which no contortions of USOS can save you.  If operators would send lowercase and keep out the unnecessary punctuations and emoticons, PSK31--especially in FD--shouldn't be slow because of the nature of the encoding and lower bit rate.

So where's the beef?  Paul, N8HM, mentioned the preamble and squelch tail that seemed to waste time.  I listened to about 10 minutes of 20m that I recorded Saturday evening.  Having never used PSK for short exchanges, it was never something I paid attention to.  With half the transmission eaten up by the squelch opener and squelch tail with no print, I can sympathize.  The demodulator probably needs a short sequence of 0's in PSK31 to get sync, but apparently the software out there sends the sync sequence for about a second, which has to be way more than necessary for character synchronization--I would think you would need only a few for the demodulator to get the timing.  This is really no different than the mark tone before the first character on RTTY--a mark-space transition to know where noise ends and signal starts and will probably help the demodulator find that first start bit.  The squelch tail on PSK31 is apparently intended to be a way turn the reciever off so that it doesn't print noise when there is no signal.  This is pointless in a contest, and other than unattended reception of the ARRL QSTs, I wonder what purpose this really serves.

It seems to me that the real annoyances stem from ancillary "features" that get in the way. If someone cares enough, perhaps he or she would petition the software developers to make more contest friendly features for PSK31.  I know several watch this list.  It seems to me that if a sponsor is going to have a PSK31 contest, why not actually make it more fun by having a software configuration that makes it so.  Maybe we'll have something for the next FD?  What better place to to set a good example and do some on-air education?  

Just inferring from comments on this reflector, here's perhaps a starting point:

A) Short synchronization sequence
B) No squelch tail.  Maybe force a space at the end the transmission.
C) Force sending in lowercase by default
D) Option to print received text in all caps

I imagine some of these would be pretty easy to do, but I learned long ago never to estimate another developer's effort level or desire to do some work :-)

Thoughts?

Andy K0SM/2

---------------------------------

Here are the corrected tables:

                       Bits(P)        Bits(R) PSK(s)        RTTY(s)        Difference
_cq_k0sm_k0sm_cq_       123     157.5   3.94    3.47    -13.58%
_cq_aa5au_aa5au_cq_     147     172.5   4.70    3.80    -23.94%
_aa5au_andy_ny_ny_      111     150     3.55    3.30     -7.63%
_aa5au_4a_ne_           82      127.5   2.62    2.81      6.46%
_aa5au_599_678_         125     142.5   4.00    3.14        -27.58%
                                        

Here are a selections of callsigns (not including surrounding spaces).  John gets a heavy penalty by the varicode, but not as bad as on CW.
n6ee        25        45        0.80        0.99        19.20%
aa5au        37        52.5        1.18        1.16        -2.50%
k0sm        35        45        1.12        0.99        -13.12%
4x6z        43        60        1.38        1.32        -4.23%
wa5zup        51        60        1.63        0.99        -64.83%