[GreenKeys] Stop bits and TTY-Connect

[gil smith]

At 08:16 AM 2/25/2005, George Hutchison wrote:
>The extended stop bit was implimented because, back in them greasy,
>smelly days, the U.S. power grid was not a locked-in...

At 08:20 AM 2/25/2005, Bob Camp wrote:
>My biggest concern is that if somebody *is* using a computer to generate a 
>signal that they do it in a fashion that does not mess up a mechanical 
>machine....


Hi George and gang:

Yes indeed, we need to make this internet system work for both computer and 
mechanical machines.  Let me make a quick point on stop bits and throughput:

By making stop bits longer, you effectively insert a delay between 
characters, since the stop bit is mark, which is the same state as line 
idle.  Using 1.42 bits for stop is the fastest that chars should be 
streaming to your typical baudot tty.  Pushing the envelope (eg: western 
union) by shortening stop bits can improve throughput a bit, but throughput 
should not be of concern to us today.  We just want to get our machines 
printing properly.

I'd rather see longer stop bits than shorter, since there is a practical 
implication with my TTY-Connect system, as I regenerate the data with a 
1.5-bit stop.  So a constant stream of packed 1.42-stop-bit baudot text 
will overflow my input buffer at some point.  I have not looked at stop 
bits on M14 or M28 TDs -- anyone know whether the chars are packed that 
closely when reading a tape?

This does not seem to be an issue with ITTY, as I measured 2-stop-bits on 
George's stream.  A 2-bit stop is good --  the absolute minimum TTY-Connect 
can tolerate is a 1.5-bit stop, without the input buffer creeping 
full.  Could likely tweak this to 1.42, but I'd rather not.

So if the incoming stream is packed and constant with 1.5-bit or greater 
stop, the system will keep up.  But there is also the issue of 
automatically inserting a CRLF string when line length is exceeded.  In 
TTY-Connect, you can configure it to insert up to an 8-character string 
when you hit a certain number of chars (after the previous CR) on a 
line.  The default  string is CR CR LF LTRS LTRS sent at 72 chars.  Now 
this will prevent overprinting at the end of the line, but it still takes 
time to send these chars, and they get inserted into the output buffer to 
do this.  If the incoming stream is at a constant 1.5-bit stop, repeated 
auto-CRLF action will overflow the output buffer at some point.

Delays between text bursts are needed to allow auto-CRLF insertions (and 
the resulting lengthened text block), to empty from the output buffer.

Of course this is not an issue with George's feed, which includes a proper 
end-of-line sequence, but I mention it here since it is related to 
throughput.  So George, if you keep the line lengths under 72, and use 
2-bit stop pulses, as you are currently, TTY-Connect will be happy.

gil




Vaux Electronics, Inc.
480-354-5556
(fax: 480-354-5558)
www.vauxelectronics.com