Checksums, what to pick

I'm sending messages of around (I'm still finalising some details) 15 bytes over an infrared communication channel between an arduino uno with an IR LED and another uno with an IR receiver. This channel is going to be particularly susceptible to noise as it will be operating in a situation where other infrared signals are also being sent between other devices at occasional times. I can cope with a fraction (perhaps a fraction as high as 2/3 but lower is better) of the messages being corrupted by other infrared signals and/or environmental noise but must be able to recognise corrupt messages from valid ones such that corrupt messages can be discarded rather than wrongly listened to and obeyed. I'm hoping to include a checksum at the end of each message (a few bytes extra after the 15 bytes of data) so I can tell which are valid and which have been corrupted. Can anyone advise on choosing a checksum method/algorithm. I've been reading about CRC8/16/32 but am aware other checksum algorithms exist too. Any suggestions at to which sort of checksum is best for a message of this sort of size?

Thank you

If you are willing to throw away as much as 66% of the messages, you are setting the bar pretty low. Even an 8-bit CRC will work fine for that.

An n-bit CRC applied to a data block of arbitrary length will detect any single error burst not longer than n bits and will detect a fraction (1 − 2−n) of all longer error bursts.

Send multiple copies of the message in the hope that one gets through with a valid checksum.

For very noisy environments, you can also use an error correcting protocol, which involves sending additional check bits to correct a certain number of bit errors.

The only way to be sure of your choice is to try various options in the target environment.

If you're willing yo give up 50%, have the receiver repeat to sender.

For information, the 8-bit CRC most commonly used is that with the Dallas/Maxim inverse polynomial. The cost is 1.25us (20clks) plus 8.3125us (133clks) per character.

Thanks, I found one that worked well in the end, CRC16 based.

As for your note in post #2, yes there is plenty of repeating going on, which is fine for this application, but I still need a checksum because I must be able to recognise which messages are corrupt so the receiever knows what to ignore.