[RTTY] One more thought on emergency comm

Joe Subich, W4TV lists at subich.com
Thu Dec 12 17:56:52 EST 2013


All things being equal - similar levels of convolutional coding,
similar symbol rates, etc. - as the number of carriers increases
and the bandwidth gets wider, for a constant PEP output, the peak
power available to each carrier drops and while the noise in each
decoder channel remains the same and the number of potential hits
due to selective fading and interference increases.  Because the
crest factor will naturally increase as the number of carriers
increases, one must increase ERP substantially to maintain the
same SNR for each carrier as bandwidth increases - again for
constant coding and symbol rate.

This is no great discovery - amateurs have known the principle for
80 years.  CW - assuming a 100 Hz bandwidth for the "human filter" -
will have a 10 to 12 dB advantage (perhaps more depending on "crest
factor" or clipping level) over SSB in a 2.4 KHz bandwidth for the
same peak power output.  Extend that to double sideband AM with
carrier in a 6 KHz bandwidth and CW has about 20 dB advantage.

 > Heck, even DominoEX wipes the floor with RTTY; DominoEX has many of
 > the properties of the modern modes to countermeasure both multipath
 > and Doppler spreading.

I have no argument that there are more efficient codes than traditional
RTTY.  I will maintain that all else being equal the narrow band
modes (lower symbol rates, fewer carriers) will get through when the
wide band (higher symbol rates, more carriers, more bits per symbol)
codes will not.  The question is which has greater effective through- 
put - "slow but steady" or "infrequent but fast" and how much
throughput is really required for *amateur* purposes.

More importantly to this discussion, is it appropriate to mix wide
and narrow bandwidth modes in the same spectrum or should the wide
band modes be grouped with other wideband modes (e.g., voice and
2400 Hz bandwidth image).

73,

    ... Joe, W4TV


On 12/12/2013 1:30 PM, Kok Chen wrote:
>
> On Dec 12, 2013, at 10:03 AM, Joe Subich, W4TV wrote:
>
>> They are are not likely to be sufficiently reliable - run the
>> numbers for SNR, fade margin, etc. for non AWGN circuits with
>> interference, selective fading and flutter and it will be clear
>> that for reliability, over any significant distance, wideband data
>> modes will require power levels in excess amateur limits and ERPs
>> far greater than anything likely to be generated with basic
>> transceivers and simple, field deployable antennas.
>
> Joe,
>
> I wouldn't generalize like this.  *We* have problems with running 2
> tone FSK at higher bit rates.
>
> But the modern modes have lots of technology that are built in to
> counter the ionosphere that steam RTTY can't even dream about.
>
> At the minimum, like Pactor-3, they would use Convolution codes, and
> either use long interleavers or Reed-Colomon type codes to get around
> slow QSB.
>
> The military quality stuff are designed to be robust under 12 ms
> worth of multipath, and 50 Hz of Doppler spreading.   Try sending
> steam RTTY through *that.*
>
> Notice that Pactor 3 uses 100 baud (10 ms data periods) and 120 Hz
> sub-carrier separations.  I would bet many Kopeks that they have both
> multipath and Doppler spreading in their minds.
>
> The ones that use higher symbol rates apply pre-emphasis based on how
> known "preamble" bits are distorted by multipath.  So, that is yet
> another tool that is available if you want to go to higher symbol
> rates.  They are all synchronous modes, of course.
>
> None of it is useful if you just want to send a 20 character message,
> of course.  The latency is high (but, that is true even with
> Amtor-FEC), and the overhead for such a short message is also very
> high.
>
> However, if you want to pass lots of data in one long burst, you can
> do *much* better than steam RTTY in a Rayleigh channel.
>
> Heck, even DominoEX wipes the floor with RTTY; DominoEX has many of
> the properties of the modern modes to countermeasure both multipath
> and Doppler spreading.
>
> 73 Chen, W7AY
>
>


More information about the RTTY mailing list