Bell System 'binary'? [telecom]

The combination 4-7 was used to represent the zero or ten in a phone number. Every legitimate digit was represented by exactly two wires. This allowed asynchronous operation - as soon as you get two wires energized you have a digit, and when you got no wires energized you were in between digits. (And more than two wires indicated an error.)

Eons ago, my late father received something with holes and punchable slots on large index cards refered to as the McBee Keysort System. The idea was that they in the technical support department would use that to find answers to their problems, as a crude database.

The punch slots were marked for 7, 4, 2 and 1, but no 0. So he devised a way to minimize the punches to represent letters A-M, overlapping with N-Z. In my youth, that would have been the first time I saw the 7-4-2-1 combination for representing a digit. I was told that punching a 7 once on the card was easier on the card rather than a 4 + 2 + 1, reducing the likelihood of punched card spikes hanging up in the holes.

The sales rep supplying the keysort cards must have provided enough for him to punch his record collection as well as his recipes. I'll put up a URL of a scan of such a punched card if there is a demand.

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:

2 = 00101

4 = 01001

6 = 01100

8 = 10010

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

Thanks!

It actually worked _quite_ well. One has to consider the 'probability distribution (it's _not_ linear) of error bits, the duration of the interference burst, and the relative probability of bits getting flipped in each direction (usually *NOT* symmetric). Real-world data showed that, for example, multi-bit errors were *much* rarer than single-bit ones, And the '1 in n' chance (the odds that if a bit -was- 'flipped' that it was the parity bit) that the error indication was a false positive was considered acceptable. People were more concerned with the degree of assurance that the data had arrived correctly than they were with the occasional 'un-necessary' re-transmit.

In addition, even though the error-checking was only on a single character, characters -were- primarily organized in 'groups' (lines, records, whatever) of some sort. And a detected error in -any- character in the group would lead to a retry for the entire group.

Thus, as long as there was _one_ DETECTED 'character in error' in the group, it didn't matter how many 'undetected errors' there were.

If you start looking at 'burst errors' of varying lengths, you find that an awful lot of them result in 'at least one' character with a parity violation.

This combination of factors pushed the typical real-world use of 'just simple parity' to levels where the vast majority of errors =were= detected.

Where higher 'reliability' was needed one could devote 'extra bits' to each character, and use some form of ECC coding, or add 'LRC' characters 'every once in a while' -- basically a 'parity byte' every n bytes, where each bit position across the sequence of bytes was treated a separate block, and had to have the specified even/odd number of set bits. Parity by 'row', and by 'column' of a matrix of bits.

Various kinds of 'checksums' appended to a group of data were also used. a 16-bit summation of the values of a reasonable number of bytes requires 'mirror image' errors in pairs of bytes to generate a 'false negative'. combined with parity 'across' the byte, you have to have 'mirror' two-bit errors in (not necessarily adjacent) pairs of bytes. use multiple checksums with different 'strides' down the string of bytes, and you can get _very_ high confidence levels without requiring a lot of computational effort.

As computing power became available, using a CRC approach became practical, and traded increased computing effort for a reduction in the amount of data 'overhead' that one needed to carry along.