Error checking/correction - Small packs

[atferrari]

I am linking two micros via IR, one way only, thus repetition can not be asked to the emitter.

I am using the Sony's SIRC protocol. Speed is the same used for remote controls for domestic appliances.

Whatever is received altered should be discarded or corrected (?).

I've been reading a lot starting with parity check, checksum, Hamming code, FEC, SECDEC and more :shock:

My concern: what should be the balance between the small size of the message (one, eventually two packs with commands) and eventually robust but long and complex routines that could delay (?) a lot the process.

While I want to keep all simple, I also want it roubust enough.

It's just a robot but I want it running properly. Any rule of thumb :?:

Repeating the packs three or five times for majority voting, is it an option :?:

Changing the order and quantity of packs sent may be done any time but my problem is not there.

Sorry if I sound vague but have no previous experience.

Comments / suggestions anyone :idea: :?: Muchas gracias :!:

 

[Joel Rainville]

You could send a packet twice, one being inverted. The receiver ANDs them together to make sure P1 && P2 == 0, if not, discard the packet. This is pretty lightweight in both processing and bandwidth.

 

[Jay.slovak]

You could send a packet twice, one being inverted. The receiver ANDs them together to make sure P1 && P2 == 0, if not, discard the packet. This is pretty lightweight in both processing and bandwidth.

That is simple, but how are you gonna recover from receiving error, if you can't ask for retransmission?

 

[Joel Rainville]

You could send a packet twice, one being inverted. The receiver ANDs them together to make sure P1 && P2 == 0, if not, discard the packet. This is pretty lightweight in both processing and bandwidth.

That is simple, but how are you gonna recover from receiving error, if you can't ask for retransmission?

From atferrari's post, it seems that merely discarding the erroneous packets is acceptable...

 

[Jay.slovak]

You could send a packet twice, one being inverted. The receiver ANDs them together to make sure P1 && P2 == 0, if not, discard the packet. This is pretty lightweight in both processing and bandwidth.

That is simple, but how are you gonna recover from receiving error, if you can't ask for retransmission?

From atferrari's post, it seems that merely discarding the erroneous packets is acceptable...

Ok, If you wanted to send the same command let's say 10 times (5times normal + 5times inverted), then do the AND check and then pick the command that has the bigest number of correct receptions, then I think this will work fine. (you didn't menation you want to do multiple receptions of the same byte/command).

PS: You can also send all 10bytes/commands non-inverted and XOR them together.

 

[Joel Rainville]

If he's gonna send the same command multiple times, I think there's no point in using the AND/XOR method...

You could try to reconstruct the "signal" or commands from what you receive. If you have a well defined set of commands, it shouldn't be too hard to figure out from the packet which bit is wrong... But it all depends on what kind of data you're transmitting and what it looks like.

All methods will eventually fail anyway. The question is, is packet loss acceptable or not? If 100% transmission is required, there should be a separate line to ask for retransmission, or at least use the one line you have in "duplex" (2 way communication).

 

[atferrari]

Starting to experiment

I found Hamming code technique appealing and simple. :idea:

Perhaps I will do my first testing with that and revert with the outcome.

Thanks for helping with your ideas.

 

[Joel Rainville]

To be nice to people who'll find this thread by searching the forum in 2 years :

https://www.cs.fiu.edu/~downeyt/cop3402/hamming.html



Looks like a nice solution. I had never heard of it.

 

[NJ Roadmap]

More than a year later I have come across this. Cheers Joel!