How was parity used with modems?

Question

On the back of this question which talks about 5- and 6-bit communications, I remember back in the BBS days that it was common to set your terminal to 8N1, (a.k.a. 8 bits, no parity, 1 stop bit) to communicate with most BBSes. It was a bit of a curiosity why there was also 7E1 ('E'ven parity) amongst other configurations since I don't recall ever going to a board that required anything other than 8N1.

Considering that parity is sometimes (always?) used for error correction, was the purpose of having a 7E1 connection a way of doing simple error detection in your transmission? If so, did anything ever use it at least in the PC modem communications world or is it just a relic of (say) tn3270 communications or something like that?

I can imagine that 8N1 was popular since the home micros of the 70s and 80s had 8 bit bytes and thus was necessary for transferring files without the help of something like Kermit which I believe accounted for bit and character code differences (e.g. IBM System 360's EBCDIC to ASCII). But if it was just a text service, a parity bit could be useful? (Come to think of it, was 8E1 possible?)

Answer 1

By the time I got my first analog modem, around 1980, my experience was the same as yours. Even and odd parity on 7-bit data was available, but almost all the BBSs featured 8N1. (The modems even still supported 5- and 6-bit data streams.) Apparently noise on phone lines by that time was so low that parity detection was considered superfluous for a large number of users. The BBSs would allow you to use a parity protocol if you wanted, though.

Note that parity in itself cannot correct errors. It is used for error detection. Software protocols were developed to flag a detected error and signal the sending computer to resend the bad packet. As Leo B.'s link shows, there were more complex, actual error-correcting, protocols as well. For these, data would seldom need to be resent, because the packets already had enough information to find and correct a certain number of bad bits.

The main problem with 7-bit data is that it is inefficient in handling binary information, or anything other than ASCII and other 7-bit character encodings. You could send binary data, but it would greatly increase the amount of data to transfer. The simplest protocols encoded each 8-bit byte into two printable ASCII characters, doubling the data size. Smarter protocols could encode more efficiently and send, say 4 ASCII characters representing 3 binary bytes. The one saving grace is that the data was almost always compressed. So even with the extra bytes caused by 7-bit data, the transferred number of bytes might even be smaller than the original file size.

One useful feature I wished they had added to the modems and BBSs of the day was support for the protocol used by a telecommunications device for the deaf (TDD). It is apparently a 5-bit protocol, but as far as I know, no non-specifically deaf-related BBSs used it. I think, though, even they favored common packages such as Kermit and Modem7. Being deaf didn't limit folks from using a full computer keyboard, and, hey, mixed upper and lower case is kind of nice. I think the only reason you would want access to the old, deaf-only protocol is to communicate with someone who just had the TDD equipment, and no networked computer. That probably was not a big enough market for modem manufacturers, but it would have been nice to have available for anyone who did need it.

Answer 2

Parity is a "one-bit checksum over a single character". It can be used to detect single-bit errors in a serial asynchronous link (As the checksum is only one bit, two or more bits/char failed transmission can go undetected).

Parity "even" adds a bit so that the sum of all data bits in the byte frame is even, while "odd" parity does the same so that the sum turns out to be odd.

Parity is generated and verified normally by the UARTs in both the modem and the computer, and (at least in newer modems starting from ~1990) not transmitted over the modem link (which is typically syncronous and has no room for parity, but rather uses a much more complicated overlaid frame structure over the data to check for transmission errors and even do retransmissions over the phone line).

Parity on "dumb" (or older) UARTs normally sacrifices one of the eight data bits in the byte frame for parity - effectively shortening the byte to 7 bits, and limiting the range of transferrable bytes to 0-127, which is still enough to transmit the full range of ASCII characters. For binary transfers, some sort of Escape mechanism needs to be employed to be able to transfer the full range of 0..255. More modern UARTS newer than 1980 could (and can) transmit 8+P bits per frame and thus normally transfer a full byte in one character frame.

Parity is useful when you have very long lines between the RS-232 comms participants, as was the case in ancient building-wide (or even larger) RS-232 communications between terminals and the mainframe (or terminal server) where the long cables were prone to induced electrical disturbances. As mostly text was transferred, the missing data bit didn't really hurt. On a short piece of RS-232 cable between a computer and a modem, it's pretty unlikely to be needed.

8P[1-2] was used for binary transfers with non-terminal installations where the capability to transfer complete bytes was a must. The parity bit obviously produces a 12.5% overhead on transmission, wich is quite a bit - So transmissions using parity have less free bandwidth than such without. Note the start and stop bit also create some overhead. On an 8E1 connection (1 start bit, 8 data bits, one parity bit and one or two stop bits), you normally have up to 50% overhead bits to transfer, which is not really effective. So: parity makes a line slower, but more safe.

Answer 3

The main benefit of parity is that it was detected within the modem. It did not require processing power within the computer itself. Although, usually the modem would generate a "Parity Fail" interrupt if it occurred.

Depending upon the protocol, the receiving modem would reply to the sending modem with a parity fail e.g. NAK instead of ACK and the message would be resent. In some modems, if using 5-wire connections instead of 3-wire then this could also be done by flashing the CTS line.

I could show you any number of modem systems still in use that use 7-bit data, even parity, with 2 stop bits (7E2). Indeed, such systems are still being installed in quite large numbers because of their security.

Answer 4

I worked with serial-based systems in the 80's and don't ever remember parity being useful for anything; it was simply something to get right when you set devices up. The effect of receiving bad parity was device-specific: some devices would simply ignore the character; some would show a character even though received incorrectly; at least one type of dumb terminal I remember printing a funny character (perhaps a tilde ~ ) in place of the incorrectly received character.

The original idea of parity checking was obviously to detect gross errors where 1 of the 8 bits in the character had got flipped in transit (perhaps in noise on a long cable). Obviously, it's of limited use, as a run of bad bits could easily render the parity overall as being correct.

If the 'end-application' is an interactive terminal or printer, you can obviously spot that the characters are corrupt, as a stream of rubbish comes out on the paper or screen. For file-transfer applications, or some kind of serial-based protocol (like the IBRO protocol they used to use in card-swipe terminals), you wouldn't depend on parity, but rather there would be some kind of better checksum. I remember sending frames that consisted of STX + data + ETX + plus a one-byte checksum that was calculated from the data bytes. If the checksum calculation didn't work out the same at the receiver, you would send a NAK, and the sender would send the frame over again. Some similar kind of logic exists in Kermit, IIRC.

You mention tn3270, but this is really on a different timeline to the one you suggest. IBM networks used synchronous links carrying SNA protocol encapsulated in SDLC frames at the low level this data was sent serially but with special start/stop patterns that couldn't appear in the data, and with a 16-bit cyclic redundancy check (CRC) to make sure the data was good at the receiver. The terminal protocol was 3270 (using EBCDIC coding, as you mention), and this was a whole parallel world to ASCII-based PCs with their asynch serial communications. This proprietary world of SNA communications lasted through the 90's until TCP/IP and the Internet ultimately displaced it. The tn3270 that you describe is a way of encapsulating 3270 data into TCP/IP (telnet) packets, as a way to integrate the last few distributed IBM mainframe users into the new world of TCP networks.

CRCs of varying lengths are used in modern communications, as it allows you to detect more than one error in frame, and is a good indication of the frame being overall somehow corrupted. Going further, there are forward error correction systems in use now that allow you to correct a small number of bits in error, as well as detect a frame that is corrupted beyond repair.

More detail about how serial communications works can be found in the data sheets for UART chips. PC designs used chips like the 8250 and 16550, but their modern descendents (like the Maxim MAX3109) have all the same ideas built-in.

Answer 5

Parity is generally used with unidirectional transmission where a recipient who observes an error would be able to take into account that the received data might be incorrect. When used with teleprinters, a parity error would often cause an "error" character to be printed in place of some other character. If, for example, there was a newswire story about Betty Smith, but bit 2 of the second character of her name got corrupted, use of parity would cause the name to be printed as B_tty Smith, B?tty Smith, B█tty Smith, or something similar, rather than as Batty Smith, thus reducing the likelihood of a human typesetter committing the error to print.

The most recent use of parity I can think of within a half-duplex streaming transmission protocol is with the Closed Captioning data encoded in US television signals, which will generally cause characters received with incorrect parity to appear as block characters. Interestingly, closed captioning data features a form of forward error correction: certain special characters including formatting codes are sent as a pair of bytes on a frame (each frame has two bytes, each with its own parity bit), but if the same pair of special characters is received on two consecutive frames, receivers will ignore the second. If a special character needs to be shown twice (e.g. the ♪♪ at the end of a singing section) it will be transmitted four times. If a parity error occurs on any one of those, the result will be that a receiver will end up receiving three note characters and ignoring one (rather than two), thus correctly showing two.

Answer 6

To amplify on previous fine answers and also comments (e.g., @Whit3rd) - the stuff at one end or the other - or even both ends - of an RS-232 connection weren't necessarily smart enough to run an error-detecting protocol that layered block parity or CRCS on top of data, like Kermit or even XModem. RS-232 was standardized ~1960, about 10 years before the first UART-on-a-chip became available. The communication stuff at both ends was built from discrete components - and, typically, the interesting stuff that was using the RS-232 line to communicate was too, and it didn't have to have any computing power (as we know it today) at all. (Specifically: Much of that equipment had no software of any kind: You wanted something done, you wired up transistors and such.) Parity gave them something for communication error detection that everyone could agree on and everyone could build.