[RTTY] RTTY

[Kok Chen]

On Mar 21, 2011, at 1:21 PM, Gary AL9A wrote:

> "Some programs rely on the the UART "buffer full" signal for proper PTT 
> timing and drop PTT (unkey) when the UART buffer is empty..."

Wow, some programs are really slow enough that they cannot keep up? (Remember, all you need to do is to keep up with the RTTY character rate, not the bit rate.)

I remember when I encountered the FSK interface of the microKeyer for the first time (on Mac OS X, you have to write everything yourself, so you end up knowing all the nitty gritty of the stuff you use :-) .  One of the obvious things is that the only way to interface to a MicroHAM keyer properly is to use its FIFO as a single character buffer and use a high priority thread to feed characters to it whenever the single character FIFO is empty.  As long as the thread wakes up and sends the next character within 150 ms there is no extra delay.  150 ms is an eternity as far as modern computers are concerned.  The microKeyer has a multi-character FIFO, but you cannot really use more than one character since there is no way to "flush" characters that are sent ahead to the FIFO. 

> I checked MMTTY and on the Decode tab the StopLength 
> item selected is "Rx=1bit, Tx=1.5bit".  I changed this to "1bit" and tried 
> the same test exchange - 8:68 seconds!  My exchange was set up with spaces 
> between the elements as "RST NR TIME NR TIME.  I changed that to have a "-" 
> in between the elements so that now it is RST-NR-TIME-NR-TIME.  The test 
> exchange time is now down to 8:05 seconds!  That's 2:39 seconds off the 
> orginal exhange time!

Uh oh, I might have turned Gary into a microsecond counting monster :-)

BTW, you have to weigh the time saved by using the dashes against the probability that the receiver gets an error hit within the first group of NR-TIME that causes one of the characters to turn into the LTRS shift Baudot code.  If that happens, you *may* be asked to repeat the entire exchange (experienced RTTY ops won't be fazed by it).  So you need to weigh the repeats against the savings that you have accrued.  Probabilistically, I myself would pick using dashes over using spaces between numbers. 

While you are shaving microseconds, here is another hint... the microKeyers and digiKeyers also suffer from the fact that its FSK interface cannot achieve 45.45 baud (if you use the Mac you'd already know this since it is in the documentation for µH Router :-).  The software has to choose either 45 baud or 46 baud.  

So, if you are a crazed microsecond counter, you might want to choose 46 baud instead of 45 baud when using FSK on a MicroHAM keyer.  As long as you are using inaccurate baud rate, you might as well be wrong on the higher speed side :-).  It will give pretty much the same error rate (46 baud only degrades from 45 baud by a practically immeasurable smidgen), but it is 2% faster than if you let the software round 45.45 baud down to 45 baud.  

> Kok, would you also like a bowl of Fish Head Soup?

You know that the cheeks are the best part of the fish head, right? :-) :-)  At least for Asian fish head dishes.

73
Chen, W7AY