[RTTY] ST0R RTTY Statistics

[Joe Subich, W4TV]

The "skimmer like" techniques are there already .... see the video
from CE0Y/I2DMI - http://www.mdxc.org/ce0yi2dmi/ using microKEYER II
with N1MM Logger/MMVARI in "DXpedition mode" for Windows or the 9X0TL
videos you reference using Digikeyer II. cocoaModem and RUMped for
OS-X.  The point here is that both I2DIM and DL2RUM put a priority on
RTTY.

Using multi-channel decoding techniques would reduce the issues with
"length of transmission" (the brag tape effect) on RTTY such that it
should be as efficient as the multiple callers in a phone pile-up and
the need for the DX to constantly be saying "I want only the W7A 
station", "EU only", etc.

With multi-channel receive techniques, the DX station should be able
to maintain a queue two or three stations deep and "knock them off"
at rates of two to three a minute for extended periods of time just
like phone or CW.

It's a matter of devoting as many complete high quality stations
(transceivers, amplifiers, antennas, and operators) and "band slots"
to RTTY as the DXpeditions devote to phone or CW.  Unfortunately, most
operations tend to put RTTY on the band with poorest propagation, don't
start RTTY operations until the third or fourth day, terminate RTTY
operations early, and fail to use ops who specialize in RTTY (e.g.,
those as skilled at RTTY as an N5KO, etc. is on CW).  One of the
10-10-10 PJ operations was so poor on RTTY compared to phone/CW that
for most of the time their RTTY station was an FT-840 and a trapped
vertical while all of the other stations (multiple per mode) were K3,
FT-1000MP, IC-7600 with amplifiers and yagis, full size verticals,
etc.

73,

    ... Joe, W4TV


On 8/11/2011 12:09 PM, Kok Chen wrote:
>
> On Aug 11, 2011, at 8:02 AM, Joe Subich, W4TV wrote:
>
>> With nearly three times as many CW QSOs as RTTY (Digital) QSOs and
>> five phone QSOs for every two RTTY QSOs, there is still a long way
>> to go before major DXpeditions are giving RTTY more than "lip
>> service."
>
> I suspect this will improve as DXpeditions adopt better tuning
> techniques for RTTY.  IMHO.
>
> With CW, you can listen for signals and decode a signal that are a
> full kHz away (guys like N5KO use the filters in their own brains for
> CW; Trey's advice to me was to call away from a CW pile if I know
> that he is the op at the DX end).
>
> With voice, you make use of the "cocktail party effect" (the term is
> actually used in technical papers, see also here
> http://en.wikipedia.org/wiki/Cocktail_party_effect).
>
> You cannot do either in RTTY if you are tuning with a VFO knob.
>
> If the pile is heavy on the previous RTTY QSX, it could take a bit of
> waiting for a call to appear cleanly on the DX's screen, or for a
> really large signal to override everyones power combined (like the FM
> "capture effect," but with one station against the power of many
> stations combined, versus one station against one other station), or
> having to retune slowly using the VFO knob.  None of this is
> especially fast.
>
> If the DX uses an RTTY skimmer, or a waterfall with memory, they
> could find a station far away from the pile to work.  Just find the
> first station that is in the clear within a 20 kHz (or however wide
> the receiver can tune) passband to work next.
>
> You can imagine that for CW, you are instantaneously working with a 2
> dimensional field (time and frequency).  With a traditional way of
> tuning RTTY, it is one dimensional (time only).  But you gain back
> the advantage compared to CW when you use a skimmer or
> memory-buffered waterfall tuning (standard waterfalls won't give you
> that of course).
>
> All digital modes are machine decoded today anyway, so you might as
> well take advantage of that fact to pull out one signal from among
> many signals.  (Whether you prefer to call it RTTY or something else
> -- the technology today that people use for keyboard modes is far
> different from the "RTTY" that was used with mechanical teletypes;
> the only similarity to real steam powered RTTY is the use of two FSK
> carriers, a shift of 170 Hz and a baud rate of 45.45 Hz.  And if you
> don't write your own software to do the demodulation, that
> distinction between the different digital modulation modes is blurred
> even further.)
>
> Bear in mind that dynamic range is not so big a problem if you are
> the DX.  They can polish off all the large signals first before
> working their way to the weaker ones.  The limitation of being able
> to concurrently decode RTTY signals whose signal strengths are
> separated by "only" 10 or 15 S units is not a problem.  At some
> point, that weak signal that is barely above the noise floor is going
> to be within 10 S units of the loudest signal present at the time.
>
> Once a DXpedition adopts wideband, agile tuning for RTTY, we too
> would have to change our pileup busting behavior.  The key is to look
> for an empty hole, no matter how far away from the previous QSX it
> is.  That has already been shown to be true with 9X0TL.  In Tom's
> Quicktime video, you can also watch 9X0TL clear out the strongest
> signals first but eventually get to the weak ones.
>
> I don't myself really look forward to that progress (where the DX can
> pick you off quickly as long as you are above the FSK decoding
> threshold with respect to their noise floor).  Working DX becomes
> "shooting fish in the barrel" and the challenge goes away.  How hard
> anyway is it to find an empty bandpass to transmit.  He eventually
> finds you.
>
> BTW, the above scheme also applies to working a DX that is "begging"
> in an almost empty subband where you have no idea what his QSX is.
> Today, you have to wait for him to slowly tune across you while you
> are calling.  If you are weak, he will usually miss you completely if
> he is not a seasoned RTTY operator (this happens to me so often that
> I prefer to let the DX find a strong station first and then call next
> at that frequency; the strong station acts as a beacon for the
> inexperienced RTTY op to hone in on).  With a skimmer or waterfall at
> his end, he will notice you the instant you transmit.
>
> The skimmer allows inexperienced ops to be pretty much as effective
> as the experienced ops -- is that what we want eventually?  (Even a
> child can use a cell phone.)
>
> 73
 > Chen, W7AY
>