On Apr 15, 2005, at 7:18 AM, f6irf@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
_______________________________________________
RTTY mailing list
RTTY@contesting.com
http://lists.contesting.com/mailman/listinfo/rtty
|