[telecom] Bell System binary - one more item...

I would appreciate any clarification of the following:
> > The decimal system we humans use is not readilly adapted to machine > interpretative use. Machines usually work on 'binary' (two states), > where as a 'bit' of information is represented by a 0 or 1, such as > whether there is power or not or a hole or not. These bits are > combined to form numbers. There are a variety of coding schemes to > translate decimal numbers into binary machine usable format (octal, > hex, etc.) > > It seems that a number of applications within the Bell System used a > binary coding scheme called "2 out of 5" to represent a digit. It > seemed to mix well with crossbar applications. They used it to > identify routnig on long distance machine-readable cards, and on > trouble cards. > > They would have: > > 0 1 2 4 7 > > As I understood it, whichever of the above was punched out added > together would indicate the digit. For example, if the 2, 4 were > punched out it would mean 6. > > My questions: > > 1) did this code go from 0 to 9 or 1 to 10? Or didn't it matter since > it was representating a phone number? > > 2) For 0 , only one item had to be punched. Since this was called 2 > out 5, didn't two items have to be punched (as a kind of parity > check)? (I guess for 1 they'd punch 0 and 1?) > > 3) Most computers used a real binary, such as 1 2 4 8, to represent a > digit. I don't recall applications outside the Bell System that used > the 7 as part of the representation. Now, in Bell System practice, > the phone numbers could be thought of as an alpha-numeric field, that > is, the phone numbers were identifiers, not used in arithemetic. > Phone numbers were often translated, that is exchange LI 8 (548) might > be translated as 'trunk group 3142" and the switch would go to > terminals at 3142. > > 4) Is this system still in use in telephone applications? > > > *Binary (and hex and octal) have never been my strong suits. (I work > with hex on occassion). Years ago word-oriented architectures used > octal coding. The IBM 650, a popular machine of the 1950s, used > something called quinary for its magnetic drum. > > > Thanks! [public replies please] >

There is still a present day use for a five bit, 2 of 5 coding system. Dig out yesterday's mail and look at the bar code printed along the lower edge of an envelope. That's a 2 of 5 code with bit values of 0, 1, 2, 4 and 7! (The "0" bit value could, of course, be a parity bit - I'm not sure now how it is considered. To my way of thinking and training the zero value bit would have been referred to as a parity bit).

Regardless, the decimal to "2 of 5" conversion works like this:

1 = 00011

2 = 00101

3 = 00110

4 = 01001

5 = 01010

6 = 01100

7 = 10001

8 = 10010

9 = 10100 and (hold onto your hats, sportsfans!)

0 = 11000

On the envelope you'll find long bars represent "1" bits and short bars represent "0". Each bar code has a long bar at the beginning and end of the code that is not part of the coding - sort of like a Start and Stop bit, if you will. Between those two long bars are the five bits of each character of the addressees Zip Plus-4 code. Some bar codes include an additional pair of "mystery characters" at the end of the code but before the closing long bar. I suspect this is for further sorting within the Zip Plus-4 destination. So, reading from left to right, mark off the bars in five bar groups. Then decode the characters according to the coding shown above and, voila!, you'll have the destination's zip code! Find some pre-printed Business Reply Mail envelopes to practice on - that will give you some addresses other than your own.

To keep this on a Telecom related theme. Data communications equipment from the 1960s (or probably earlier) used parity bits with each character as an error checking scheme. But character based parity would detect fewer than

50% of the possible errors and could easily CAUSE errors instead of detecting them (that is, an error that changed two or four bits of a character would not be detected by an odd or even parity check!). So why was parity checking such a popular feature of data communications? Was it cheap to implement? Was it just comforting to customers? Or did it actually work pretty well in its day to day application? (The latter is what I think - that it was not perfect but just good enough to be useful until the electronics or computing power came along the make Cyclic Redundancy Checks practical).

Thanks!

In the above post I forgot to mention that the last character in the bar code is a mod-10 check digit. That is, add up all the individual digits in the bar code and you should find the result is a multiple of 10 (10, 20,

30... 80 or 90). If the sum is not a mod-10 0 then an error has occurred!

(Sorry to use more of your bandwidth with my forgetfulness!)

I believe the chance of _two_ bits being altered within a character were extremely low as compared to one bit being altered, so parity was a pretty good error check. If a line was so 'dirty' that there were many errors, the line was not useful for data transmission. Parity was cheap to implement and useful for "start stop" asynchronous transmissions.

Early data transmission over telegraph lines had to make do with the Baudot code of 5 bits which didn't give much leeway and was slow. (This was done in the 1940s). But transmission over voice grade phone lines allowed faster speeds and more sophisticated transmissions, including error checking routines. I don't have descriptions handy, but if I find them I'll post them. (See the book, "IBM's Early Computers").

IBM did a lot of work on this in the 1950s and earlier (IBM sought to acquire microwave channels for after WW II). But IBM was hesitant to step on the Bell System's toes since Bell was a major customer of IBM machines and non Bell equipment could only be used, after approval, on private lines.

In the 1940s, IBM had fancy punched-card to paper tape converter machines; later models had sophisticated controls.