RTTY
[Top] [All Lists]

Re: [RTTY] A thought on FSK timing

To: rtty@contesting.com
Subject: Re: [RTTY] A thought on FSK timing
From: "Joe Subich, W4TV" <lists@subich.com>
Date: Sat, 21 Sep 2013 21:40:38 -0400
List-post: <rtty@contesting.com">mailto:rtty@contesting.com>

There are more than a handful of people with strange or varying stop
bits, including many big-gun contesters. My hunch is that this is a
result of MMTTY's "pacing" not being completely stable or accurate in
some systems or configurations out there in the wild, but maybe it's
something else.

I suspect you are seeing the effect of having the MMTTY "Char. Wait"
and or "Diddle Wait" sliders (Setup MMTTY | TX) other than at full
left.  Note:  "Char. Wait" and "Diddle Wait" extend the stop bit
(time) between characters and/or before starting diddles if MMTTY
is still in transmit and the buffer is empty.  Note: "Char. Wait"
and "Diddle Wait" *also* effect character timing in AFSK.

One should not need MMTTY's pacing with an 8250 compatible UART
("serial port") - particularly is the UART transmit FIFO is turned
off in Windows Device Manager - and pacing is not an issue with
EXTFSK since that driver paces based on the 22/33 msec bit length
- not the 165 ms character length - although the windows timer and
USB latencies can result in (measured) bit length errors of up to
+/- 2 ms at 45.45 baud.

73,

   ... Joe, W4TV


On 9/21/2013 8:54 PM, aflowers@frontiernet.net wrote:

Peter's question about 75-baud brought to mind something I've been
pondering for a while....I'm not convinced that the "MMTTY + UART" is
always optimal from a timing perspective, though it probably is much
better than EXTFSK by itself.  The question in my mind is that since
MMTTY is pacing the characters every ~165ms you are still at the
mercy of it's timing jitter at the character level. There are more
than a handful of people with strange or varying stop bits, including
many big-gun contesters.  My hunch is that this is a result of
MMTTY's "pacing" not being completely stable or accurate in some
systems or configurations out there in the wild, but maybe it's
something else.  Surely this matters to pseudo-synchronous
demodulators that rely on tracking the start-stop bit timing to get a
bit more SNR than asynchronous demodulators. I suppose how much is
going to depend on the demodulator implementation at the receiving
end.

Anyway, I'm curious if anyone has another explanation for the
funny-stop-bit phenomenon.

Andy K0SM/2
> _______________________________________________
> RTTY mailing list
> RTTY@contesting.com
http://lists.contesting.com/mailman/listinfo/rtty

_______________________________________________
RTTY mailing list
RTTY@contesting.com
http://lists.contesting.com/mailman/listinfo/rtty

<Prev in Thread] Current Thread [Next in Thread>