|
Posted by Al Gillis on February 17, 2008, 9:13 pm
If you were Registered and logged in, you could reply and use other advanced thread options >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!
| ![Bell System 'binary'? [telecom]](/images/header.jpg)
Yahoo! 
Google 
Windows Live 
del.icio.us 
digg 
Netscape 
XML site map