[RTTY] re VE3NEA rtty-modems tests - is MMTTY obsolete?

[Kok Chen]

On Apr 15, 2005, at 7:18 AM, f6irf at free.fr wrote:
> take this opportunity to thanks
> Alex for providing RttyCompare, a really useful tool.

I am definitely indebted to Alex VE3NEA for sharing the RttyCompare 
project.  I liked it so much that I ended up creating a special tool in 
my modem for which to adjust parameters (ATC, matched filter, 
equalization, etc) using a signal that has been passed through the HF 
channel simulator.

Albeit, the channel simulator is only a model of the real world, but it 
is at least a repeatable one, and in my case, one which I can compare 
against a clean signal -- something an off-the-air recording does not 
provide.

The tool I'd created allows a stereo channel to be fed into the modem, 
the left channel is a pristine RTTY signal and the right channel being 
the signal (e.g., at -10 dB Eb/No) that had been passed through the HF 
channel simulator.  These two signals are then run into two 
simultaneously running identical demodulators, so that any framing 
errors and cycle slippage from framing errors can be recorded and 
studied, in addition to looking for the individual bit errors.

I had been interested in the issue of false positives and false 
negatives when identifying "start bits" to determine how aggressive one 
should be in deciding whether a new frame has started.  For example, if 
false positives are more destructive, then one should bias towards 
being less aggressive at picking a bit to be a start bit.

The use of diddles can dramatically improve print.  Alex had earlier 
discussed with me in email that most on-the-air signals can pretty much 
be considered as a synchronous stream, but of course this is only true 
if a diddle is sent.

The interpretation of an RTTY signal as a synchronous stream instead of 
being a per-character start-stop driven asynchronous stream allow for 
pretty dramatic improvement of word error rate (or CER, in Alex's 
plots) for a given bit error rate since the misidentification of a 
single start bit can cause *multiple* word errors (from cycle 
slippage).  By being able to use the framing information from multiple 
characters (only possible with a synchronous case) reduces the framing 
error very rapidly as you use a wider "window."

David Mills, W3HCF in his excellent series of papers (the main chapter 
is at 
http://www.eecis.udel.edu/~mills/database/reports/dsp93/dsp93b.pdf, the 
rest are dsp93a.pdf, dsp93c.pdf, etc --  if memory serves, a version of 
this appeared in QEX a few years ago) had considered both the async and 
sync analysis of an RTTY stream, and how bad the cycle slippage problem 
is (in the appendix dsp93d.pdf).

Mills uses the more standard textbook Eb/No representation of SNR while 
Alex uses SNR in a 3kHz bandwidth, so you need to make an adjustment of 
about 18.2 dB (i.e., Eb per 22 milliseconds) when comparing their 
plots.

The use of fractional stop bits (i.e., 1.5 stop bits instead of 1 or 2 
stop bits) further helps in identifying a proper character frame.  I 
have found that even signals from "1.4 stop bit" mechanical teletypes 
work very well.

K6STI's RITTY had a "digital flywheel" that is probably a variant of 
considering the RTTY stream to be a synchronous character stream.  But 
not knowing the details of RITTY, I can only guess at what Brian was 
doing.

73
Chen, W7AY