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
_______________________________________________
RTTY mailing list
RTTY@contesting.com
http://lists.contesting.com/mailman/listinfo/rtty
|