Does you RF reciever output ttl? or raw analogue? A dataslicer might be a better idea.
Also even if it is digital you can get rid off quite a few noise spikes by over sampling the incoming data. I'm not sure if this will solve your problem but there are many things one can do to improve RF comms, I'm just starting with simple things to try (like NOT buying a new TX/RX pair
).
Providing you know the data rate, which you do....you can sample the data very quickly, perhaps 16-32 times in the chiprate...then take a majority vote. Often when an analogue signal is sliced into ttl...the noise spikes make it jitter, so you can filter them out digitally.
Also I assume your 'packet' is a common format?
<Preamble><sync><header><data><control> type thing.. Obviously 'data' and 'control' are just random names but a preamble is a must...it'll allow your RF reciever AND the digital clock recovery logic (be it software, PLL, CMOS) to syncronise well enough for the whole packet.
With a few lil cheap 433Mhz RF modules I've used, I got good results just using a hardware UART on the PIC, and manchester encoding using a look-up table. The start and stop bits between every byte are handy for byte syncronisation too.
Also as someone has already pointed out....'burst' communications can help a lot. Max datarate, blast out the bytes, then sleep. As it is unidireciotnal, you're limited to either sending the data three times (longer packet, more chance of errors) or...forward error correction. FEC is though on a PIC, unless the datarate is really low, but it can be done.
I would first 'ignore' the error correction part, and start with a long preamble, a sync, then some dummy bytes - 'in system'! Once you have the most reliable RF comms you can get, start making the packets longer and longer, until you get to your 255. Debugging comms can be a bit of a bugger :/
Blueteeth