RTTY
[Top] [All Lists]

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

To: rtty@contesting.com
Subject: Re: [RTTY] PSK31 is faster (Was FD RTTY Question)
From: aflowers@frontiernet.net
Date: Sat, 30 Jun 2012 04:37:42 +0000 (UTC)
List-post: <rtty@contesting.com">mailto:rtty@contesting.com>

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%
_______________________________________________
RTTY mailing list
RTTY@contesting.com
http://lists.contesting.com/mailman/listinfo/rtty

<Prev in Thread] Current Thread [Next in Thread>