On Feb 27, 2008, at 9:25 AM, Charles Morrison wrote:
> This is very interesting, why is this? I thought the speed was set
> by the
> software?
The baud rate of the FSK port in the microHAM keyers (microKeyer,
digiKeyer, microKeyer II) is set using an integer whose value is 2700/
rate. Integer values that give baud rates that are closest to 45.45
are therefore 59 and 60.
If you use 59, you get 45.8 baud and if you use 60, you get 45.0 baud.
I stumbled onto this when I was writing an interface to it
(http://homepage.mac.com/chen/w7ay/Router/Contents/routerinstall.html
) for cocoaModem to use.
The error is very small, since the two integers are 1/60 from one
another. I.e, the baud rate is only 1/100 off.
Baudot consists of 1 start bit, 5 data bits and 1.5 stop bits (stop
could be anywhere between 1.4 and 2 for teletypes, but most software
appear to use 1.5). For validated decoding, you therefore want the
mid bit samples to be good for about 7.5 bits. I.e., you want the
last sample to stay within the bit timing no more than 1/2 a bit from
the mid bit position.
A 1/100 per bit error will accumulate to 1/14 bit error at the end of
each Baudot character. So, instead of sampling at the middle of the
last bit, you will be sampling at the middle plus or minus 1/14 of a
bit. With a clean signal, this pretty much never happens.
When a signal is noisy, however, the start bit sync recovery itself
will not be perfect. Your error margin will further be reduced by
this 1/14 number.
In addition, if the software is using an optimal detector such as a
Matched Filter (both RITTY and cocoaModem use Matched Filters), then
the 1/14 of a bit offset will cause the samples not to be taken at
where the match filter peaks temporally. This will cause a loss in SNR.
Some software can also treat RTTY (with diddles) as a synchronous
rather than an asynchronous (start-stop) stream. This helps during
QSB when you can lose the start bit. The pseudo synchronous decoding
will just hum along; even if characters are printed incorrectly during
the troughs of QSB, you do not lose character sync -- you do not want
to lose character sync since it often takes few characters to catch
up. If the baud rate is off, then some of the advantage of the
synchonous nature is lost --- this is mitigated if the software
attempts to estimate the baud rate in real time rather than use 22
millison bit times as gospel.
Anyhow, the error by using 45 baud instead of 45.45 is quite small and
is not a problem until copy is really marginal to start with. I
wouldn't lose sleep over it. In the future, I will probably estimate
a baud rate correction in cocoaModem to automatically handle errors in
received baud rates.
The difference between 45.45 baud and 50 baud is much greater -- off a
little over 9% per bit. In the span of 7.5 bits, the bit sampling is
off a whopping 67.5 percent, causing the mid-bit (50% position) to
fall into the wrong bit. This explains why lots of people could not
copy P5/4L4FN when he switched to 50 baud (bad for them but good for
the rest of us who have a thinner pileup to fight).
73
Chen, W7AY
_______________________________________________
RTTY mailing list
RTTY@contesting.com
http://lists.contesting.com/mailman/listinfo/rtty
|