[RTTY] A thought on FSK timing

[Joe Subich, W4TV]

> 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 at 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 at contesting.com
> http://lists.contesting.com/mailman/listinfo/rtty
>