Hi Chen,
Got the last name, first name thing right this time. Microsecond counting
monster eh! Nah, at least not until I can find a stopwatch with greater
digit resolution.
However, changing the baud rate in MMTTY to 46 now yields 8:00 seconds on
the test exchange message. Every little 5/100's of a second counts right?
Lets see now, if I can save 1 second every 20 QSO's divided into the 660 Q's
logged = 33 seconds saved over 19 hours of operation. Not quite enough time
for one more exchange. Maybe there are limits to this quest.
As for the fish heads, yup we always make sure to get the Halibut cheeks
when cleaning the fish. Mmm mmm good!
73,
Gary AL9A
----- Original Message -----
From: "Kok Chen" <chen@mac.com>
To: "RTTY Contesting" <rtty@contesting.com>
Cc: "Gary AL9A" <al9a@mtaonline.net>
Sent: March 21, 2011 3:16 PM
Subject: Re: [RTTY] RTTY
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
|