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