[GreenKeys] Stop bits and TTY-Connect

[gil at baudot.net]

Hi Jerry:

Yes, I have fifo buffers for both input and output streams, with
intelligence (diddle filters, auto-crlf...) in the middle.  Chars are
pulled out of the input buffer, processed as needed, and placed in the
output buffer.  There is no uart involved, as both the input and output
streams use an interrupt routine sampling/regenerating data at 250-us
intervals.  The input side only requires a minimum 0.5-bit stop, but
the output side sends a 1.5-bit stop.  It's actually a bit more
complicated, since these ports are bi-direcional (eg: a TU-to-TTY
stream using two buffers, and a TTY-to-TU stream also using two
buffers).  It's not likely people will be typing on their tty
keyboards, but the system is set up for full 2-way communication (as
well as optional speed conversion in both directions, and optional
baudot-to-ascii conversion in both directions).  There is a uart used
for the pc port, but that is not related to the data streams for the TU
or TTY ports.

I am just pointing out that the data regeneration on the output side of
things is designed for mechanical machines, and is set up to provide
1.5-bit stop bits.  Therefore, if the input stream has characters
packed tightly together at 1.42-bit stops, the input buffer will
overflow at some point.  You can make buffers bigger, but eventually
there will be characters lost.  Now if there is some delay time added
to the data stream (eg: dead time for a few seconds between stories),
this will also help by allowing the buffers to empty out further.

gil

> -------- Original Message --------
> Subject: Re: [GreenKeys] Stop bits and TTY-Connect
> From: "Jerry" <gh1lockett at bak.rr.com>
> Date: Fri, February 25, 2005 7:39 pm
> To: gil at baudot.net
> Cc: "John Strand" <sx43 at earthlink.net>, "Fred Caughell"
> <fcaughell at bak.rr.com>, "GeorgeH" <w7tty at readysetsurf.com>
> 
> Hmmm, don't you have a FIFO buffer of some sort in between the input and 
> output of the uart chip i.e. in the serial to parallel area?  I seem to 
> recall experimenting with all sorts of different chips and buffer sizes 
> to take care of things like that.  Of course its been a year or two 
> since I paid any attention to those old designs.  hi.
> 
> I remember Irvin had software built into his rtty program whereby you 
> could speed it up to one stop pulse or slow it down to 2 or 3 or more. 
> In fact there towards the end of that development of his rtty program he 
> had it setup automatically to change the length of the stop bits 
> depending on how full the buffer got.  As it started to fill up, the 
> output would speed up, but if you were typing slowly, it would add stop 
> bits and slow the entire stream down.  Geeze, its been years since I 
> thought about this stuff.
> 
> I originally built up a interface circuit always insured you were 
> sending letters as the fill character, even if you typed a number 
> character and then stopped typing, it would then send a letters to get 
> everything back down into normal case.  It also blocked more than one 
> letters fill character at a time, to the local computer, while sending 
> it out to the mechanical printer.  (I think, hi, would have to get out 
> my old drawings to recall exactly what it did!)   I know it evolved over 
> a period of time and made lots of changes in the logic to get it to this 
> and that... Only made one prototype and used it for several years. 
> Think its still over the drawer along with Bill's TU... hi.
> 
> Jer
> 
> 
> ----- Original Message ----- 
> From: <gil at baudot.net>
> To: "Jerry" <gh1lockett at bak.rr.com>
> Cc: <greenkeys at mailman.qth.net>
> Sent: Friday, February 25, 2005 6:14 PM
> Subject: RE: [GreenKeys] Stop bits and TTY-Connect
> 
> 
> : Hi Jerry:
> :
> : It's not the baudot input side of things -- actually, I am only
> : requiring a half stop bit on input.  But on baudot output, I use 1.5
> : stop bits to keep the  mechanical machines happy.  Just happens that a
> : half bit was easy to code.  I could add code to set it to exactly 
> 1.42,
> : but it is hopefully not needed.  And I figured that 1.5-bit stops 
> would
> : give the machine a little more margin to get back to an idle state.
> :
> : However, when the baudot input and output are at the same speed, the
> : input cannot arrive faster than the output is leaving, or the input
> : buffer will overflow.  In this case, 2-bit stops, as George has
> : implemented, is great.  My current concern is reading tapes from a TD.
> : I need to set one up and measure the data rate to see if the chars are
> : actually packed tightly enough to result in 1.42-bit (or anything less
> : than 1.5-bit) stops.  I also need to look at how closely they are
> : packed on typical rtty broadcasts.
> :
> : This is not an issue when baudot is being converted from low to high
> : speed.  And if baudot is being converted from high to low speed, a pc
> : must be in the loop to provide buffering, and is throttled with
> : xon/xoff, so there is still no problem.  It is also not a problem when
> : the ascii 232 port is connected to a baudot port, since the pc is 
> again
> : throttled with xon/xoff.  It is only an issue for baudot connections 
> at
> : the same speed, when the input is streaming continuously, and the stop
> : bits are less the 1.5-bits long.  May be an issue for tape reads, I'm
> : not sure yet.  But most people will be outputting to page printer or
> : tape, from an ITTY feed or radio feed.  Not sure if anyone wants to
> : read/send tapes.
> :
> : As Gilda Radner used to say, "It's always something."
> :
> : gil