Cannot go for ACK because i use a CAN Bus like specification. Every packet is a broadcast and the number of receivers can change. The packet can be lost for one receiver but all the others receive it and say ACK. Another problem is the ACK spam that the receivers send. It slows the bandwidth down significantly.
On CAN Bus the ACK is used to detect if smth is wrong with the transmitter. If no ACK is sent then the receiver repeats to send the packet for a fixed number of times and shuts into listen only mode after reaching the limit. This prevents the Bus from being blocked. This procedure makes sense because you don't get random packet loss on the wired Bus.
No it is not nasty nor embarrassing! Repetition is often used in commercial products! There are RC protocols based on repetition and some on repetition AND inversion (the same data but inverted).
With the hamming code, an 8-bit byte is turned into a 12-bit (4 control bits are added). Maybe you should consider split data in half, add some error correction and send them. This way you have again the same result with repetition, as well as error correction. Only advantage with hamming code over repetition is that with hamming code you can correct the error on the receiver while with the repetition the code must be resent (you cannot tell which one is the correct one).
It IS embarrassing because the bandwidth is half the bandwidth before and if the conditions get worse it will not prevent packet loss. To split the packets and add parity is smth i was thinking about too. I ran some tests and my double send method has still 0.0047% packet loss. Wireless can be so painful :/
The module has itself a CRC check included. If a packet is bad then it will not be saved as received.
For now i do not bother with the packet loss anymore. I have to hurry and put the collision avoidance together. I want to finish this sucker before Christmas
