This ignores the delay at the end of transmissions, which is quite
annoying, plus the problem of PSK31 operators adding superfluous
information. PSK31 operators, even in PSK31 contests, rarely use as
few characters as are used in RTTY contests. For example, PSK31
operators seem to always need to indicate which station they are
calling instead of just throwing out their callsign.
Yes, lower case would help. Now someone needs to write software that
displays PSK31 in lower case as upper case!
Your technical analysis that PSK31 is faster is correct, but it
ignores real-world use. PSK31 operators need to shorten their
exchanges and learn that the big knob on the front of the radio exists
for a reason.
On Wed, Jun 27, 2012 at 9:02 AM, <firstname.lastname@example.org> wrote:
> Apologies for the provocative title, but the lamenting of PSK31's perceived
> slowness during the FD festivities prompted me to crunch some actual numbers.
> The question I thought to investigate was "how much slower PSK31 is vs. RTTY
> in various contest-like exchanges?" I'm giving my results for discussion.
> For the record, I have never participated in in a PSK31 contest, so this is
> all back-of-the-envelope math and not based on any kind of actual contest
> experience. I have other thoughts regarding PSK31 in contesting, but this
> message is strictly about information transmission speed.
> I took several messages that are typical of RTTY contests. For all messages
> I assumed a CR/LF at the beginning of the message. RTTY is sent with USOS
> on, 1.5 stop bits at 45.45b. PSK31 is sent in lowercase (more on this below)
> at 31.25b. (Given the recent thread on character encoding in email you may
> want to cut and paste the table below into a fixed width editor to get
> columns to line up right.)
> Message, Bits PSK31, Bits RTTY, Time PSK31, Time RTTY, PSK31 advantage
> <CR><LF>cq k0sm k0sm cq <EOT> 98 172.5 3.14
> 3.80 17.37%
> <CR><LF>cq aa5au aa5au cq <EOT> 98 187.5 3.14
> 4.13 23.98%
> <CR><LF>aa5au andy ny ny <EOT> 104 172.5 3.33
> 3.80 12.31%
> <CR><LF>aa5au 4a wny <EOT> 72 150 2.30
> 3.30 30.19%
> <CR><LF>aa5au 599 678 <EOT> 122 180 3.90
> 3.96 1.42%
> It turns out its really quite hard to engineer a message where 31.25b PSK31
> is slower than 45.45b RTTY! Even numeric exchanges, which are quite long in
> varicode end up being at parity or better. Replacing the CR/LF with a
> single leading space makes PSK31 even faster.
> Because of the variable-length encoding in PSK31 your own callsign could
> potentially take longer to send. This is a function of how many "unusual
> letters" you have in your callsign. Here are some examples, although it
> should be pointed out that "wa5zup" breaks nearly even with RTTY if you
> include leading and trailing spaces (which you would in a message), which are
> only one bit in varicode:
> n6ee 17 45 0.54 0.99 45.06%
> aa5au 27 52.5 0.86 1.16 25.20%
> k0sm 27 45 0.86 0.99 12.74%
> 4x6z 35 60 1.12 1.32 15.16%
> wa5zup 41 60 1.31 0.99 -32.51%
> This begs the question as to why PSK31 is slow. How many people are using
> their RTTY macros in all caps for PSK31? PSK31 averages about 10 bits for
> capital letters, and exactly 6 bits for lowercase. One way to change this
> behavior would be to have contesting software always send lowercase, and if
> one wanted, always print uppercase on the screen for legibility. I can't
> imagine a contest where case would matter, and you get instant speed
> improvement and better copy without having to change your beloved macros.
> Like USOS for RTTY, forcing lowercase transmission would a kind of hack to
> make things go a little faster and improve copy, and people who don't know
> any better still reap the advantage of lower-case transmission by default.
> This seems to this armchair observer to be a much better solution to
> increasing the baudrate (and thus losing SNR) by switching to PSK63 or
> whatever I to overcome poor utilization of the character table.
> I hope this is helpful!
> Andy K0SM/2
> RTTY mailing list
RTTY mailing list