Does the RS-485 Standard include an error detection/correction scheme?

RS-232 has a parity bit for error detection, but I do not know anything related to error detection/correction in the RS-485 interface.


RS-485 and RS-232 a electrical-only standards. The same data encoding scheme is usually used on both. The difference is that RS-232 uses a single wire for the signal with levels below -5 V and above +5 V, while RS-485 uses a differential pair with 0-5 V levels. RS-485 is also intended to be multi-drop whereas RS-232 is point to point.

You can chose to use a parity bit, or not, on either physical layer.

In practice, parity bits are not used much since they give a poor level of protection for the number of bits spent. When reliability is important, chunks of data are usually wrapped in packets with more sophisticated checksums, then with a ACK/retry scheme at the level above the packets.

  • \$\begingroup\$ @Pipe: If I remember right, RS-232 is -5 to +5 volts minimum when sending, but a receiver must accept -3 to +3 V. \$\endgroup\$ – Olin Lathrop Jul 27 '16 at 12:42

RS-485 has several advantages over RS-232.

  • Multi-drop from one master to multiple slave nodes.
  • Differential signals for higher noise immunity.
  • Lower voltages means that a 5 V PSU can be used.

With the multi-drop facility it is necessary for the transmitter and receivers to be a little smarter than may be required for RS-232 communications as addressing has to be handled. Once a micro is involved it is not to difficult to add checksum calculations too.

The parity bits are a very crude protection and will detect a single or odd number of bit errors in a character. An even number of bit errors will go undetected. In contrast, a one-byte checksum has 256 possible values and the likelihood of an undetected error is far less. For additional security a two-byte, 16-bit checksum can be used.

Does the RS-485 Standard include an error detection/correction scheme?

No, that's up to the system designer.

For a recent question on the topic see How to calculate checksum by hand.

  • \$\begingroup\$ My absolute favourite here is Fletcher-16. It's trivial to calculate with the tiniest 8-bit micro if you have an add-with-carry (no expensive tables), while still offering close to the same protection as CRC-16. (Don't confuse this with Adler, who actually managed to mess it up) \$\endgroup\$ – pipe Jul 27 '16 at 13:24
  • \$\begingroup\$ Thanks, I've never come across Fletcher-16 before. Another one for the toolbox! \$\endgroup\$ – Transistor Jul 27 '16 at 13:30
  • \$\begingroup\$ I don't like 255 as a modulus, since every third byte only contributes a one-in-85 choice, every fifth byte a one-in-51 choice, every fifteenth byte a one-in-17 choice, and every seventeenth byte a one-in-15 choice. By contrast, in an Adler sum every byte contributes a one-in-251 choice. An alternative approach is to keep two running checksums and multiply one of them by 3 with each byte (so the second-to-last byte has a 3x contribution, the third-to-last byte has a 9x contribution, etc.) The pattern of contributions repeats every 64, but there are ways of dealing with that. \$\endgroup\$ – supercat Jul 27 '16 at 16:27
  • \$\begingroup\$ BTW, I think it's also important to note that--for better or for worse--Fletcher's checksum regards 00 and FF as identical. \$\endgroup\$ – supercat Jul 27 '16 at 16:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.