It looks to me as though you are doing 'bit level' decoding'. That is, you are getting your manchester 'chips' in (sub bits) and getting normal bits out.
The problem is you don't know where a byte begins and where a byte ends...thats where framing comes into its own. As I said before, its a great idea to have a sync byte that purposefully violates the manchester coding algorithm, whilst still being 'DC balanced'. The simplest would be 00001111. Note you can't decode that with your software, as it sin't strictly speaking man coding.
I would send a packet as follows:
<preamble><syncbyte><payload (your data)><end of transmittion byte>.
Preamble: A series of 0's and 1's. You're really just sending all 0's or all 1's through a manchester encoder, as 0 = 0-1, and 1 = 1-0. This is purely to wake up your RF reciever, and to get it nicely DC balancing before you start sending any real data. Your Rx micro can ignore this if you wish, but not only can it sort out the analogue side, it can also 'train' your reciever (micro) to get in sync. Note: because there is ALWAYS a bit transition in manchester coding...you could encode 0101 which would be 01100110. That way the only transistions in the bit stream are in the 'middle' on the coding. There will always be transistions there regardless of what data you send.
Sync byte:
As before 00001111 *after* manchester coding. This should be sent 'as is'. It is DC balanced, cannot be mistaken for data is all your data is properly coded, this isn't. It tells your reciever that not only is it properly syncronised, but also that the bits after this are data.
Payload: Your data, man encoded.
End of transmission: this is optional, but might be handy if you plan on sending varying lengths of packet. It tells your reciever that the data has ended, and it can go back to waiting for a sync again. Or power down the reciever.
Of course you can add otrher types of header bytes, but you'll want to keep the preamble and sync. Premable can be quite long, I would start off making it a good 10 bytes or so..to make sure everything is in sync. You can always shorten it later until you run into problems.
Good luck..soory for the long post...got pretty obsessed with RF comms in my uni projects years ago. My head is still full of various channel coding/line coding and error correction techniques. Most of which can applied from the humblest ASK 2.4kb/s system all the way up to 5.8Ghz.
Blueteeth
Sounds complicated, but once done, it proves to be pretty damn reliable (well, as far as RF comms goes anyway).