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?)

  • 2
    You may also be interested in the whole shebang.
    – Leo B.
    Commented Feb 15, 2017 at 19:48
  • Packages like Kermit had nothing to do with modems per se. They sat at a higher level and would transmit, with handshake, over any transmission medium
    – Chenmunka
    Commented Feb 16, 2017 at 8:32
  • 1
    I always had assumed that 7Ex was a way to encode ASCII that would allow senders/receivers without hardware parity checking to do the parity checking in software (which would be difficult with 8Ex, because that would produce 9-bit symbols). And of course it's used for error detection, not error correction; error correction would need to be done by the application. Transmission errors were much more frequent on older hardware, even though transmission speeds were slower.
    – dirkt
    Commented Feb 16, 2017 at 10:42
  • I seem to dimly remember that CompuServe used 7E1 for some reason. Does anyone have any of their old ads, which would be a source for this if I am correct. (I never used it except once at a computer museum.) Commented Feb 24, 2017 at 16:50

6 Answers 6


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.

  • 1
    TDD support would have made it possible to use the TDD equipment found on some public telephones to phone into a computer system.
    – supercat
    Commented Feb 15, 2017 at 23:26
  • As for parity, I'm somewhat curious what it really accomplishes beyond maybe allowing a dumb terminal to output a "glitch" character when it would otherwise have output a seemingly-valid-but-wrong one. Data errors are so often combined with framing errors that forward error correction is often of limited use within a packet. Better would be to guard each little packet with an 8-bit CRC, and each group of packets with a 32-bit CRC (if the 8-bit CRCs match but the 32-bit one fails, either negotiate the 32-bit CRCs of all the packets or else retransmit the entire group).
    – supercat
    Commented Feb 15, 2017 at 23:32
  • @supercat I don't know the history, but the major protocols improved greatly over time. The very name "Modem7" (one of the most popular BBS packages) tells a story of major enhancement. What I do know is that whatever the modems and supporting software were doing, they were really solid. The only fails I can remember is if there were a major line glitch -- little brother picks up phone in other room and starts dialing, that sort of thing. Downloads improved to the point that they could continue from a complete disconnect or power loss.
    – RichF
    Commented Feb 15, 2017 at 23:42
  • It is not that the noise was so low, it's the MNP. At 2400 baud or more, working without MNP was virtually impossible, and as soon as you have MNP, you don't need any additional error detection above it.
    – Leo B.
    Commented Feb 16, 2017 at 2:32
  • @LeoB. Thank you for the info. I started at 300 baud. But I upgraded gradually as better modems were offered. I probably had 1200, 2400, 9600, 19.2k, and 56k over the years. ... And now I think 6 Mbps is slow. 🤓
    – RichF
    Commented Feb 16, 2017 at 2:44

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.

  • What do you mean by 8P[1-2]? E = even, O = odd, N = no parity, P = ?
    – dirkt
    Commented Feb 16, 2017 at 15:42
  • 1
    I think here p is a stand-in for either E or O, it's the selected parity option. A better notation might be 8[NEO][1-2] Commented Feb 16, 2017 at 16:00
  • Yep. Wasn't that difficult, apparently ;)
    – tofro
    Commented Feb 16, 2017 at 17:11

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.

  • Chenmunka, I am confused. Does not "7E1" mean 7-bit data, even parity, 1 stop bit? If so, what would 7E1 with 2 stop bits mean? Also, how does parity help improve security (as opposed to reliability)? (This sounds sort of negative. I don't mean it to be. I'm just curious.)
    – RichF
    Commented Feb 16, 2017 at 10:40
  • @RichF: Whoops, well spotted - 7E2! Direct modem links - as opposed to LAN - are considered more secure as the only way to inject fake commands is to physically intercept the cable. Something that is easily detected.
    – Chenmunka
    Commented Feb 16, 2017 at 10:52
  • Ah, makes sense. More secure, both because of not being on the network and because the parity data streams are sensitive to any sort of violation. Cool. Is twisted-pair style wiring quiet enough to avoid passive invasion, or do such systems use fancier techniques to minimize data leakage along the wiring?
    – RichF
    Commented Feb 16, 2017 at 11:59
  • @RichF: Don't forget that LAN systems use some form of Longitudinal Parity Checking too. The forms vary but the principle is the same.
    – Chenmunka
    Commented Feb 16, 2017 at 12:22
  • 2
    Some terminals (the venerable ASR-33) had internal parity generation and detection; it wasn't the modem (in the dumb-modem 110/300 baud days) that knew to check parity.
    – Whit3rd
    Commented Feb 20, 2017 at 10:26

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.


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.


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.

  • Transistors!? Many of the devices may have had a few transistors for the line interface, but otherwise controlled everything with cams, levers, electrical contacts, solenoids, and motors.
    – supercat
    Commented Jan 25, 2021 at 20:23
  • @supercat - you are right of course but I thought that idea might be so far retro that even readers here would think I was blowing smoke.
    – davidbak
    Commented Jan 25, 2021 at 20:45

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .