10

The asynchronous serial protocol supported an optional parity bit, which could make the total number of "1" bits an even number or an odd number. As discussed in this question, parity could theoretically detect an error in the transmission; but it also added additional time for transmission, errors were relatively rare, the parity scheme could only detect an error rather than identify the correct value, and ignoring errors was much easier than establishing a protocol to correct them. Thus, most of the equipment that I have seen ship with parity turned off by default. I have seen a few items that shipped with even parity.

However, I don't recall odd parity ever being chosen as the default setting. Did any equipment (e.g. computers, teletypes, modems) have odd parity as the default factory setting? (or perhaps the only available setting?)

The mere ability to choose another parity setting is not what is being asked; most equipment was capable of that. Rather, the question is about the manufacturer's default setting. Presumably, this would be the setting that the manufacturer thought would be most useful for that particular application.

Also, the question is about parity used for serial communication, not as used in memory or other contexts.

Improve this question
9
  • 1
    "ignoring errors was much easier than establishing a protocol to correct them." How do you know there is an error that should be ignored, if you don't detect it - e.g. a one-bit change from ASCII "A" to "B" in a text document.
    – alephzero
    Mar 9, 2021 at 18:42
  • 2
    Not asynchronous but the PS/2 interface uses odd parity according to wiki.osdev.org/PS/2 for the serial communication
    – Jeff
    Mar 9, 2021 at 18:59
  • @alephzero: To be sure, error detection and correction was used in critical applications, but In many cases, it wasn't worth it. If the transmission was human-readable text, an error would produce gibberish, which a human reader could then detect and maybe do something to fix it. Why write code to deal with the problem, when the human reader will do it for you?
    – DrSheldon
    Mar 9, 2021 at 19:37
  • With luck and local echo, the human might not even know his input was garbled on the way in :-)
    – another-dave
    Mar 10, 2021 at 0:58
  • 1
    @Raffzahn: That is addressed in the question's third paragraph, and is not what the question is asking about.
    – DrSheldon
    Mar 10, 2021 at 14:06

2 Answers 2

Reset to default
12

Just one example:

The Trimble GPS receiver's (used on agricultural positioning systems, for example) proprietary TSIP protocol (roughly end of the century, so somewhat retro already) uses odd parity by default.

Odd parity has one marginal advantage over even, at least for even bit-lengths: If you have the data input stuck at 0 or 1 (which is a probably more common basic problem than mingled bits, as it typicall will denote a broken connection), you will be able to detect this with odd parity (because both 0b11111111 and 0b00000000 have even parity).

Another (maybe more popular example):

The PS/2 interface between the IBM AT (and later, until it was replaced with USB) and its keyboard uses odd parity as well.

Improve this answer
3
  • "Odd parity has one marginal advantage ... If you have the data input stuck at 0 or 1 ..." -- What you're stipulating only makes sense if the input to the UART's shift register was stuck, which seems highly unlikely. Otherwise the "data input" would be from the RS-232 receiver, and start & stop bits are needed to frame every valid character. So your "marginal advantage" seems contrived.
    – sawdust
    Mar 11, 2021 at 5:26
  • 1
    @sawdust That's the reason for "marginal". It only applies to special cases, and normally not for cases where the parallel-to-serial conversion comes from a bus into an UART. But, apparently, the specifically rough conditions on a tractor or construction machine justified the choice.
    – tofro
    Mar 11, 2021 at 7:44
  • @sawdust, hardly. If you're going to use parity and have to pick odd or even, you could pick odd for the marginal advantage reason stated. That means fake triggering through noise, for example, such as by intermittent wiring, would have to look like valid data in 3 bit positions, not 2, just by choosing the advantageous parity type. If you've already decided to use parity, this decreases the odds for zero cost: odd instead of even. For electronics engineers, that's the difference between electronics and engineering. Good engineering choice.
    – TonyM
    Mar 13, 2021 at 12:57
6

Even parity has the advantage of making all zeroes a valid state and for even word lengths also makes all ones a valid state. Odd parity has the advantage of making all valid states contain at least one bit set. I don't know of asynchronous serial peripherals that used odd parity, since async signalling protocol guarantees that every byte will have a start bit with value 0 and a stop bit with value 1, but many synchronous serial protocols such as those used with magnetic stripes or NTSC video closed captions use odd parity. Since an all-ones character can only appear at the end of a magnetic stripe, using odd parity means that the maximum number of consecutive zero bits within the numeric portion of a magnetic stripe (4 bits plus parity) is eight, and the maximum number of consecutive one bits is 13 (a byte whose last three bits are set, followed by an end marker, followed by an xor-sum of all ones).

Improve this answer
8
  • 2
    I didn't think that the start bits and stop bit (or stop 1.5bit?) were included in the parity bit. I thought it was just the data payload? In fact, now that I stop and search for it, this wikipedia page says the parity bit does include only data bits. So I don't get your sentence 3.
    – davidbak
    Mar 9, 2021 at 21:17
  • 3
    @davidbak: In synchronous protocols, it may be useful to ensure that the data line never goes too long without "doing something" when data is being sent. When using asynchronous communication, the start and stop bits will ensure that the data line will never go more than ten bit times without a transition when data is being sent, no matter what parity settings are being used, but when using synchronous communications without start/stop bits, some other means must be used to limit the number of consecutive 0 or 1 bits.
    – supercat
    Mar 9, 2021 at 22:15
  • 2
    Parity is calculated on data+parity, excluding start and stop bits in asynchronous transmission. So even parity means that the number of bits in the data and parity fields is an even number and vice versa.
    – Graham Nye
    Mar 9, 2021 at 22:19
  • @GrahamNye: My point is that some forms of synchronous communication may allow a device to either repeatedly clock out zero bits when idle or repeatedly clock out one bits when idle. If a constant stream of zero bits could represent a transmission of all zero bytes, but could also be sent when idle, it would be impossible to distinguish an idle line from a long string of zero bytes. Using odd parity avoids that issue, since when using e.g. 8 bits plus odd parity, there could never be more than sixteen consecutive zeroes on the line. That issue is irrelevant when using asynchronous comms.
    – supercat
    Mar 9, 2021 at 22:25
  • Start and stop are just time periods and are not included in parity settings - that is how you can get 1.5 stop bits. If it takes 100ns to transmit 1 bit, then 1.5 stop bits is a wait of at least 150ns.
    – cup
    Mar 10, 2021 at 14:56

You must log in to answer this question.

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