[RTTY] VP6DX

[Joe Subich, W4TV]

> 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.

This is, or should be, a non-issue.  The less than 1% error is 
less than the clock error of many UARTs and/or USB to serial 
converters  Hardware UARTs generally include PLL clock recovery 
circuits (that's the only way the early Orion with its >10% 
data rate errors would work with most serial ports) and good 
software decoders also implement clock recovery.  

> 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. 

You need to be sampling more than once per bit - particularly 
with 1.5 stop bits and quasi-synchronous decoding.  If you're 
oversampling, the < 1% clock error is even less of a factor. 

I would suspect other factors (overly wide filters, receiver 
IMD, receiver AGC desense, mistuning, improper shift, etc.) 
will cause far more issues than an insignificant variation 
in the UART clock rate. 

73, 

   ... Joe, W4TV 
  





> -----Original Message-----
> From: rtty-bounces at contesting.com 
> [mailto:rtty-bounces at contesting.com] On Behalf Of Kok Chen
> Sent: Wednesday, February 27, 2008 1:14 PM
> To: RTTY Reflector
> Subject: Re: [RTTY] VP6DX
> 
> 
> 
> 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 at contesting.com
> http://lists.contesting.com/mailman/listinfo/rtty