1
\$\begingroup\$

I currently have a setup where I take serial output from Arduino 1 and push it through a transmitter to the receiver of Arduino 2 where it is fed back into the serial input and further processed. I want to ensure that there is as little error as possible and recover the data wherever possible.

I have come across the syndrome decoding technique which seems to be the ideal one for me, but I am confused as to how I would go about implementing it.

I know that the Arduino Serial transfers data byte by byte, each being 8 bits, but do not know how this data is sent over the serial connection (i.e. how the start & stop bits & parity is implemented).

I would assume that a solution to this could either involve modifying the data in the buffer or reading it from the buffer and then operating upon it. I could also use adjacent bytes of data for error correction, but this seems wasteful.

How should I proceed with this?

\$\endgroup\$
  • \$\begingroup\$ The sending UART adds the start, parity, and stop bits around the data byte, and the receiving UART strips those bits, and delivers the original data byte to the receiving program. On the serial line between UARTs, the transmitted "byte" will actually occupy 11 bit times. \$\endgroup\$ – Peter Bennett Mar 13 '15 at 4:50
  • \$\begingroup\$ Is it possible to access that parity bit and try implementing an error correction scheme around it? It would be great if I could read about the type of parity being implemented from somewhere. \$\endgroup\$ – thirdattempt Mar 13 '15 at 11:23
  • \$\begingroup\$ The datasheet (linked in my answer) has all information about the parity. The parity error detection is done through hardware, and a register is set when the parity didn't match the parity bit. "Correction" would be re-sending? As I would consider the byte that caused the error as a lost byte, if you lose one bit in the transmission, you can't be a 100% sure what the character was.. Or well, if you only sent 10 types of characters, you can check on which looks the most like the "wrongly received character". Though I would encourage re-sending. Also see my answer for the other types of errors. \$\endgroup\$ – Paul Jun 2 '15 at 8:01
4
\$\begingroup\$

Easy software solution

An easy software solution would be to send the data twice, first receive it and then verify it. It's highly unlikely that exactly the same bits fail twice. Maybe, for educational purposes, you can try to make an algorithm that sends a checksum.

So when sent twice, and received twice (exactly the same), it'll be verified. If this fails, your communication line would be too noisy.

Though, for a stable solution, you should always check hardware errors, as some microcontrollers simply stop receiving/sending at a hardware errors. Also if you don't like the overhead of the verification software, hardware errors actually give a good view on what happened and are likely to detect errors even withouth additional software (other than the handling).

Hardware solution

The UART itself actually has error checking built in. And when you use a correct baud-rate (something that scales nice on your clock-speed), it's unlikely to mis-receive uart characters. But for the sake of stability you should handle these errors. And if you really need to catch every character, you should even implement that it discards and asks for re-transmission on an error (as the character which generates the error should be considered lost). Also, if you happen to have a lot of errors on your UART, please note that it's likely a hardware error, i.e noise on the line or wrong baudrate

You must handle UART errors if you want to create a stable system.

over-run errors, when a new character is received before the character in the receive buffer is handled. (Your code should read characters faster than your baudrate is (short interrupt-driven uart receive code will help).

parity error, a parity bit determines wethether the complete message is odd or even (simplified) so if one bit fails, the parity bit will not correspondent with the message, thus the receiver hardware knows one bit was miscreceived. While unlikely, this won't work well if an even amount of bits fail, so that the parity is justified again.

Framing error, as UART has start and stop bits, it's possible to tell whenever you've received a complete message. When this message is too long/ too short or simply doesn't fit the settings (apart from baudrate?) it'll create a framing error.

More info in the datasheet 20.7.4 Receiver Error Flags

So at least, you should check the hardware errors, this gives quite a stable connection. Make sure you implement something that'll clear the error-registers (they might cause additional receive/sending to fail) and re-sent the message, so that the other device is 'synched' again.

| improve this answer | |
\$\endgroup\$
0
\$\begingroup\$

The UART should have a control/error register that has a parity error flag. Styudy the Atmel ATMega328 datasheet to find the details.

| improve this answer | |
\$\endgroup\$

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.