[RTTY] Serial port Stop Bit Lengths

[Joe Subich, W4TV]

There has been quite some interest recently in serial data rates
and stop bit length for FSK signals.  I finally gathered the material
necessary to measure data on the various common ways of generating
an FSK signal (other than software generated FSK - EXTFSK, MMVARI
FSK, WriteLog Software generated FSK, p-FSK (2-Tone, fldigi, etc.)).

Some of my interest was generated by work in progress on new firmware
for the microHAM DigiKeyer II, microKEYER II, MK2R+ and micro2R which
fixes data rate to 45.45 baud (Windows sets to 45 baud), adjusts the
internal buffer and inserts LRTS/FIGS diddles in the data stream
whenever there is not a character available at the end of the current
stop bit due to USB latency.

 > stop bit time reported by 2-Tone and time to send a typical contest
 > CQ - <CR><LF>CQ TEST de W4TV W4TV TEST:
 >
> Motherboard (COM 1)
>    MMTTY - no pacing		34 ms        5.5 sec
>    MMTTY - pacing        	45 ms        5.75 sec
>    WriteLog - Hardware        34 ms        5.25 sec
>
> PCI Serial (VScom PCI-410HSP - Oxford chip set)
>    MMTTY - no pacing        	43 ms        6    sec
>    MMTTY - pacing        	46-47 ms     6.25 sec
>    WriteLog - Hardware        43 ms        5.75 sec
>
> PCI-e Serial (StarTech PE2S1P - MOSchip chip set)
>    MMTTY - no pacing        	42 ms        5.75 sec
>    MMTTY - pacing        	46 ms        6.25 sec
>    WriteLog - Hardware        42 ms        5.75 sec
>
> Edgeport/4
>    MMTTY - no pacing        	38 ms        5.5  sec
>    MMTTY - pacing        	40-42 ms     5.75 sec
>    WriteLog - Hardware        38 ms        5.5  sec
>
> microHAM (DK II, MK II, MK2R+, micro2R)
>    MMTTY - no pacing        	33 ms   (w/strict BPS  - 6.75 sec)
>    MMTTY - pacing        	33 ms   (wo/strict BPS - 5.75 sec)
>    WriteLog - Hardware        33 ms   (w/strict BPS  - 6.75 sec)
>
> The message length numbers are an attempt to measure the number of
> LTRS/FIGS that get stuffed into the data stream under various
> conditions for the microHAM case and an attempt to quantify any
 > slowdown due to pacing for MMTTY in the serial port/Edgeport case.
 > Note: pacing is *not necessary* with serial ports/Edgeport - it
 > was measured to determine its impact if the user enabled it.
>
> Because both MMTTY and WriteLog activate PTT 300 ms before starting
 > data transmission, the microHAM UART implementation will always begin
 > with two LTRS characters which should speed ATC setting.
>
 > After looking at stop bit durations as measured by 2-Tone, MMTTY was
 > set to diddle nulls (so the wave form was a "long" space for the
 > Start and 5 data bits and a mark for the stop bit) and measured
 > stop bit length directly.  The measurements are an average of
 > multiple characters.
>
>              		MMTTY        MMTTY
>                      "normal"    "Limiting Speed"
> MB port
>   Measured Baud rate	44.80        44.80    baud
>   Stop bits         	 1.43         1.96    bits
>   Stop length        	31.95        43.70    ms
>
> PCI Port
>   Measured Baud rate	44.89        44.89    baud
>   Stop bits         	 1.89         2.14    bits
>   Stop length        	42.00        46.20    ms
>
> PCI-e Port
>   Measured Baud rate	44.94        44.94    baud
>   Stop bits         	 1.84         2.05    bits
>   Stop length        	40.85        45.65    ms
>
> Edgeport/4
>   Measured Baud rate 	45.30        45.30    baud
>   Stop bits         	 1.72         1.81    bits
>   Stop length        	38.05        40.00    ms
>
 > 1) "Baud Rate" is determined from the length of the Start + data bits
 >    divided by six.
> 2) I have no explanation for the long stop bits in the PCI and PCI-e
>    cards but have heard similar reports from others.
> 3) Windows sets the baud rate to 45.0 baud in all cases so the slight
>    differences are due to the system clock or crystal on the individual
>    device.
> 3) MMTTY's "limiting speed" paces at 7.7 bits per character.  Although it
>    is not needed in these serial port implementations, reducing the time
 >    for each character to 7.5 or even 7.4 bits per character would be
 >    beneficial with some USB devices.
> 4) The Edgeport/4 results appeared to reflect the effect of 5 ms
>    USB latency.  Subtracting 5 ms from the measured values would
>    put the Edgeport "on the money" in both cases.

73,

     ... Joe, W4TV