[GreenKeys] Why and When 7.00 vs. 7.42 unit code?

Mon Mar 10 22:57:19 EDT 2014

I think you will find that mechanical TTY receive hardware actually ran at a
7.0 rate. The extra .42 or 1.5 or even 2.0 allowed the async stop to sit at
rest (un-clutched) until the start bit came along, tripping the clutch,
starting the rotation again. 

One practical result (of the greater than 1.0 stop bit length) is that,
starting machine on an active traffic stream, the longer the stop bit, the
faster it will sync up with the "async bit pattern". That is, it is easier
to find which bit is the actual stop bit in a continuous stream of async
characters.

Never got to try this on a mod 15, but 28s and 32s ran fine on 7.0 pattern.

I would put it to you that the move from 1.42 to 1.5 and 2.0 stop bits had
to do with ease of implementation in digital circuitry rather than any
mechanical reliability concerns.

Lester B Veenstra  MØYCM K1YCM W8YCM
lester at veenstras.com

US Postal Address:
5 Shrine Club Drive
HC84 Box 89C
Keyser WV 26726
GPS: 39.336826 N  78.982287 W (Google)
GPS: 39.33682 N  78.9823741 W (GPSDO)

Telephones:
Home:                     +1-304-289-6057
US cell                    +1-304-790-9192 
UK cell                    +44-(0)7849-248-749 
Guam Cell:              +1-671-929-8141
Jamaica:                 +1-876-456-8898 

This e-mail and any documents attached hereto contain confidential or
privileged information. The information is intended to be for use only by
the individual or entity to whom they are addressed. If you are not the
intended recipient or the person responsible for delivering the e-mail to
the intended recipient, be aware that any disclosure, copying, distribution
or use of the contents of this e-mail or any documents attached hereto is
prohibited.

-----Original Message-----
From: greenkeys-bounces at mailman.qth.net
[mailto:greenkeys-bounces at mailman.qth.net] On Behalf Of Jim Haynes
Sent: Monday, March 10, 2014 11:55 AM
To: Nick England
Cc: Greenkeys
Subject: Re: [GreenKeys] Why and When 7.00 vs. 7.42 unit code?

I can't answer your late-term questions, and I thought I had told the story
of 7.00 vs. 7.42 many times already, but here it goes again.

For start-stop synchronization to work the receiver has to stop between
characters.  Morkrum accomplished this by running the receiving shaft a bit
faster than the transmitting shaft.  The transmitter sent 7.00 code and the
reciving shaft completed its rotation by about the middle of the stop pulse
so it could stop to wait for the start pulse.

Prior to purchasing Teletype, Western Electric had their own line of
teleprinter equipment.  They used rotary faceplate distributors and the
transmitting and receiving faceplates were on opposite ends of the same
shaft.  Maybe this was a leftover from some kind of synchronous operation -
I don't know.  Anyway to allow the receiver to stop between characters they
had to delay the transmitting shaft.  This was done with a latch and a
relay.  When Teletype entered the picture they needed interoperability with
the W.E. machinery.  They measured the time delay introduced by the relay
and found it was equal to 0.42 of a pulse time.
So they required Teletype to stretch out the transmitted character stop
pulse to 1.42 unit.

W.U. didn't have the interoperability requirement, and presumably
appreciated the increased speed they could get by operating 7.00 code.
Also they were buying machines from both Morkrum and Kleinschmidt when they
were separate companies.  Perhaps Kleinschmidt never had the requirement for
interoperability with W.E. machines and thus was
7.00 code all along, but I don't know.

Teletype receiving machines have no trouble receiving 7.00 code since they
kept the principle of running the receiving shaft faster.  Hence there is no
difference in receiving machines whether receiving 7.42 or 7.00 code.
Only the old W.E. machines can't handle 7.00 code.  I don't know why the
7.42 was continued after the W.E. machines became extinct.  But it was.

Now when we move into modern times we have Teletype at 7.42 at 100 wpm, or
10 chars/sec, which works out to 74.2 baud.  And the European standard seems
to have been 7.50 code at 50 baud for Telex.  I have no idea why they went
to 7.50.  And then ASCII with 11.0 unit code because the Teletype equipment
at 100 wpm couldn't get by with a single stop pulse.

Then the military decided to standardize on baud speeds.  They pushed 74.2
baud up to 75 to make a round number.  That's only a little ofer a one
percent change, so I assume equipment geared for 74.2 baud can tolerate
75 without hardly any trouble.  Maybe slightly reduced range.  So that's how
we get the speeds that are a power-of-two multiple of 75: 150, 300, 600,
1200, 2400,...  With 100 wpm ASCII being non-compliant, along with IBM 2741
that runs at something like 134.5 baud.

I don't know how the Navy got a mixture of 7.00 and 7.42 machines - maybe
some equipment supplied under Western Union contracts.  And if you put
100 wpm gears in a 7.00 machine I guess you get 106 wpm.

When it comes to crypto, there were what seem like some terribly bad ideas
to me, but then I know nothing about crypto machinery.  You'll see in the
Teletype parts books keyboard parts for "synchronous pulsed operaton"
where there is an electromagnet to release the keyboard clutch of tape
reader clutch.  I have some pieces of stuff that are called "TD Steppers"
and these were used in encrypted systems to operate the tape reader clutches
and keyboard pulse magnets to assure that characters aren't sent into the
crypto machine too fast.

Teletype made some time-division multiplex equipment for the military
(AN/FGC-5, AN/UGC-1).  The multiplex had to run slightly faster than the
start-stop signals coming in, so now and then it got far enough ahead that
it had to insert a multiplex blank into the output stream.  In ancient
multiplex work the all spaces blank character was used for this purpose, but
in modern military systems the blank was considered a legitimate character.
So the multiplex actually transmitted a six-unit code, where the sixth pulse
simply told whether the character came from the input or was a multiplex
blank; multiplex blanks were no sent to the output but simply caused a pause
in the character stream.  And the real characters were shorter than 7.42
code because the mux was running fast.

Apparently this was a problem for crypto equipment, which wanted a steady
7.42 character stream.  So they had developed a "printing telegraph signal
normalizer" to slow down the multiplex output slightly and paste over the
pauses.  See Dingley, "The Printing Telegraph Signal Normalizer"  I.R.E.
Transactions on Communication systems, Vol. 4 No. 3, 1956, p. 18.  And
Steeneck, "Teleprinter Signal Normalizer"
Western Union Technical Review Vol 11 No. 1, January 1957, p. 10.

jhhaynes at earthlink dot net
______________________________________________________________
GreenKeys mailing list
Home: http://mailman.qth.net/mailman/listinfo/greenkeys
Help: http://mailman.qth.net/mmfaq.htm
Post: mailto:GreenKeys at mailman.qth.net

2002-to-present greenkeys archive:
http://mailman.qth.net/pipermail/greenkeys/
1998-to-2001 greenkeys archive:
http://mailman.qth.net/archive/greenkeys/greenkeys.html
Randy Guttery's 2001-to-2009 GreenKeys Search Tool:
http://comcents.com/tty/greenkeyssearch.html

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html