0
\$\begingroup\$

I’m designing a master-slave, one way RS-485 over plastic fiber optic physical link layer network using low power PIC MCU. While I expect the link layer to be very reliable, nothing is ever perfect.

Since the network is unidirectional to keep costs down, I’m thinking some form of Forward Error Correcting code is in order. The data packet content is simple:

Slave address (one byte) Opcode (one byte) Operands (four bytes) So just six bytes of application data passing from Raspberry Pi transmitter UART at up to 56K baud -> plastic fiber optic transmitter -> PFO cable up to 20 meters -> PFO receiver -> PIC12LF1822 MCU UART as RS-485 slave node.

I could just use a CRC to detect errors but since the link is one way, there’s no way to NAK a bad packet for retransmission.

This seems like a good use case for forward error correction but I have no experience with FEC. What algorithm or other things should be considered, given I need as close to 100% reliability as possible. Preferably an FEC algorithm that can be implemented in C code on a PIC MCU.

\$\endgroup\$
5
  • \$\begingroup\$ Any error correcting code will do, depending on your expected error rate. \$\endgroup\$
    – Eugene Sh.
    Jul 8, 2019 at 17:53
  • \$\begingroup\$ What should the slave do if a bad frame were received? Answering this might help clarify the level of error correction needed (i.e. simple error sensing, or redundant data to rebuild a damaged frame.) \$\endgroup\$
    – rdtsc
    Jul 8, 2019 at 18:39
  • \$\begingroup\$ Good question. I'm unsure about how the PIC UART / interrupt would behave if the frame was invalid. Makes me think I should add even more redundancy by sending the message several times. \$\endgroup\$
    – rbraddy
    Jul 8, 2019 at 18:57
  • 1
    \$\begingroup\$ A pic microcontroller has no idea of the overall message and how the UART module behaves only depends on a single byte at a time. You will need to handle the errors of the UART module independently of the overall message. The UART module will typically throw an error that can be captured via an interrupt(s). That error should invalidate the entire packet. If all of that clears and the message is buffered, then you worry about the integrity of the message. \$\endgroup\$
    – vini_i
    Jul 8, 2019 at 19:58
  • \$\begingroup\$ What catastrophe occurs, if there is a bit error, or burst of bit errors? \$\endgroup\$ Jul 9, 2019 at 2:26

1 Answer 1

4
\$\begingroup\$

You will never, ever get the probability of an error occurring down to zero. Moreover, in this sort of link, the errors that you do stand to get are going to interrupt one or more entire packets.

It's a much better idea to design your protocol with some sort of reliable error detection (i.e., a CRC, with a length of your choice), and with an information content in the messages so that the receiver is robust to missed messages -- basically, so it can get itself into the correct state even after missing one or more messages.

In the extreme, you just continually send the receiver an entire frame that contains every bit of its desired state, all the time. "Commands" just consist of changing the receivers desired state in the transmitter, and waiting for that entire frame to be transmitted.

If that causes speed problems, then set up a scheme where the transmitter fills any dead time in the link with the desired receiver state, but will interrupt with new commands.

If that's just not going to work, then you either need a two-way link, or you need to accept that every once in a while your system will start misbehaving, and a human being will have to reset it.

\$\endgroup\$
4
  • \$\begingroup\$ State rather than event transfer is definitely important in situations like this. If necessary, idempotent events are a good idea, too. \$\endgroup\$
    – Dannie
    Jul 8, 2019 at 19:48
  • \$\begingroup\$ So based upon this, it sounds like I should send the same message multiple times to ensure the message gets through successfully, which is better than worrying about FEC, if I understood correctly. \$\endgroup\$
    – rbraddy
    Jul 8, 2019 at 19:58
  • 1
    \$\begingroup\$ Sending multiple messages with error detection is a form of FEC, actually. The important thing is that you should design your system so that it is robust to losing any number of messages in a row, but eventually recovering once the connection is restored. \$\endgroup\$
    – TimWescott
    Jul 8, 2019 at 20:08
  • \$\begingroup\$ I ended up using 16-bit CRC which works perfectly. No ECC was required and would’ve been overkill. \$\endgroup\$
    – rbraddy
    Jul 23, 2019 at 2:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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