0

I am looking to send data through a uart communication link that is very noisy (BER can reach up to 1E-13). I was thinking of sending data that is 64 bytes long. However, these packets are of varying lengths and should be self decodable using reed solomon with X FEC bytes that are set according to another function in the program.

The packet should be divided according to the following scheme:

byte    |     1      | 2..64 |    64..X      |
meaning | Seq number | DATA | RS FEC bytes |

What I am now thinking about is how I can be able to delimit the packet to be recognizable by the receiver. I have thought about two major choices:

  • COBS
    • Using COBS sounds like a good option, however, since it's a noisy channel, I am afraid that an error that affects the delimiting characters will break the whole packet.
  • Add a header
    • Adding a header telling how big is the packet feels somewhat bad, since it would be only one byte long, there is no option for error correcting with reed solomon, and writing another error correcting algorithm is overkill.

What are other options I have at my disposal for this problem?

Helder Esteves
  • 451
  • 4
  • 13
  • *"I was thinking of sending packets that are 64 bytes long. These packets are of varying lengths"* -- You are contradicting yourself. If you want a reliable channel, you're also going to need ACK/NAK responses with resend capability. Use of error correction is probably questionable, since it can only be applied after frame synchronization has been achieved.. – sawdust Nov 25 '17 at 05:36
  • Yes that was my bad, I wanted to say data of 64 bytes, but varying RS bytes, changing the packet length. The system will also use ARQ, but I didn't think its mention would be of use in this post. – Helder Esteves Nov 25 '17 at 14:17
  • Seems like you're trying to find the magic bullet to solve the message frame alignment problem. Since you're dealing with binary data, IMO there is no such perfect solution, even with COBS. The best that you could come up with would be sync byte(s) that lead to a faster (i.e. fewer false indicators) determination of the frame alignment. See my answer to https://stackoverflow.com/questions/16177947/identification-of-packets-in-a-byte-stream – sawdust Nov 26 '17 at 01:53
  • Thanks for the tip, I'll look into it further. – Helder Esteves Nov 27 '17 at 11:50
  • @Berd - you don't mention why or by how much the number of RS ECC bytes will vary. In this prior question, 16 bytes of RS ECC were generated, but only 8 of them transmitted. If that failed (reply with NAK), then the missing 8 would be transmitted. This is explained in [this answer](https://stackoverflow.com/questions/47337992/using-reed-solomon-for-incremental-redundancy/47365556#47365556) . – rcgldr Dec 15 '17 at 22:00

0 Answers0