Timeline for Why bother with even parity?
Current License: CC BY-SA 3.0
22 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Dec 26, 2020 at 23:45 | vote | accept | Rocketmagnet | ||
| May 3, 2019 at 13:52 | answer | added | TopCat | timeline score: 0 | |
| Jan 11, 2018 at 18:02 | comment | added | TonyM | @Lundin, you are right that a parity check can only detect 50% of the possible errors in a parity-protected block. However, it's far from a 'moronic' idea and the inventor made no stupid or wrong assumptions. It does indeed have a function and a value. You appear to have strong and definite, but I would say flawed, views on the subject. May I recommend that you post a question on this that can be discussed and debated. That would seem to be constructive, while throwing around insults clearly isn't. I look forward to reading your posted question and justifications. Thanks. | |
| Jan 11, 2018 at 11:42 | comment | added | marcelm |
@Lundin ".. you take the whole data package in account, not just the payload." - I did. Consider a 7-bit payload with 1-bit even parity code. The resulting code word is 8 bits. Any code word with an even number of high bits is a valid code word. Any code word with an odd number of high bits is an invalid code word. So changing any bit in a valid code word (0 to 1 or 1 to 0) will change the number of high bits from even to odd, resulting in an invalid code word. Regardless of which bit you change. For example: 0b1001010+1. Even number of 1s, so valid. Change any bit, and parity fails.
|
|
| Jan 11, 2018 at 8:46 | comment | added | dasdingonesin | This is still mostly useless in most situations. ⁽ᶜᶦᵗᵃᵗᶦᵒᶰ ᶰᵉᵉᵈᵉᵈ⁾ | |
| Jan 11, 2018 at 2:46 | comment | added | tom r. | It has a 50% probability of catching errors involving more than 1 bit assuming random/normal distribution of error length. But 100% of catching a single bit. This is still mostly useless in most situations. | |
| Jan 10, 2018 at 19:13 | review | Close votes | |||
| Jan 15, 2018 at 3:02 | |||||
| Jan 10, 2018 at 17:17 | answer | added | Stephan Samuel | timeline score: 5 | |
| Jan 10, 2018 at 15:16 | comment | added | Adam Haun | @Lundin If the parity bit flips, the parity check still fails. | |
| Jan 10, 2018 at 15:15 | comment | added | Lundin | @marcelm When calculating effectiveness of error detection mechanisms, you take the whole data package in account, not just the payload. The single bit error can hit the parity bit as well as any other bit!!! EMI is not kind enough to leave your checksum alone and just occur on the payload bits. This is why parity is a stupid invention - the person who invented it made the same fundamentally wrong assumption as you just did. | |
| Jan 10, 2018 at 15:13 | comment | added | W5VO | I mean, assuming that the main goal of the device was to make a 14-bit widget, I'd guess that these are not a primary design focus. They could have just stuffed those two bits with 0's, and then they wouldn't have you complaining about tertiary features. | |
| Jan 10, 2018 at 14:56 | answer | added | dreamcatcher | timeline score: 0 | |
| Jan 10, 2018 at 14:37 | history | edited | Rocketmagnet | CC BY-SA 3.0 |
Clarified
|
| Jan 10, 2018 at 14:32 | history | edited | Rocketmagnet | CC BY-SA 3.0 |
Fixed table image
|
| Jan 10, 2018 at 14:25 | comment | added | Rocketmagnet | @Lundin - Please address your comments to the makers of AMS, who make these chips. | |
| Jan 10, 2018 at 13:07 | history | tweeted | twitter.com/StackElectronix/status/951078080851922944 | ||
| Jan 10, 2018 at 13:07 | comment | added | marcelm | @Lundin "It has a probability less than 50% of catching single bit errors, and worse still for multi-bit errors." - If a single bit is wrong, the parity will be wrong. Simple parity has a 100% chance of catching single-bit errors, not "less than 50%". (similarly, it has 0% chance of catching 2-bit errors, and 100% again at catching 3-bit errors). | |
| Jan 10, 2018 at 12:09 | comment | added | Lundin | Please note that "parity", even or odd, is dinosaur technology, it should not be used in modern, professional systems. It has a probability less than 50% of catching single bit errors, and worse still for multi-bit errors. Just forget about using parity, using it was a moronic idea even back in the 1960s. If you need to validate an SPI data line, you should supervise the data on a lower layer, by using an input capture timer or similar. Also check SPI flags for buffer overrruns etc. | |
| Jan 10, 2018 at 11:34 | answer | added | TonyM | timeline score: 4 | |
| Jan 10, 2018 at 11:29 | history | edited | Rocketmagnet | CC BY-SA 3.0 |
Clarified
|
| Jan 10, 2018 at 11:10 | answer | added | Andy aka | timeline score: 16 | |
| Jan 10, 2018 at 10:56 | history | asked | Rocketmagnet | CC BY-SA 3.0 |