[RTTY] VP6DX

[Kok Chen]

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