Ok, I'll try and clear up some of this, I see this topic time and again here...
It's a little confusing to begin because it's not immediately obvious how to go about this...
Using NRZ (Non Return to Zero) like you are doing just now has two problems, firstly there is no common ground reference potential, it's wireless. Secondly, and more importantly, there is no synchronised clocking scheme. Manchester encoding solves this problem by embedding the clocking signal within the data stream.
Using NRZ to send one byte at a low data rate will most likely succeed, however sending several bytes will most likely fail. This is due to the clocking between sender and receiver not being synchronised. If the local clocks are off by even a smidgen, the clock error will be cumulative, the more data you send the worse it gets.
You will want to provide a mechanism for synchronisation of transmitter and receiver. You will also want to provide an error checking mechanism,but I'll get to that in a minute...
I find most folk don't understand the receiving end and hence have no clue how to go about transmitting data, so I'll describe the receiving end and leave the rest to you.
Quick note:
NRZ has bit periods, each bit takes a predefined time, sometimes called a bit slot, and only changes level or transitions at the bit period/slot boundary.
Manchester also has bit periods/slots, as in NRZ. However, level changes or transitions can occur at both bit period/slot boundary, and also in the middle of the bit period/slot. A level transition in the middle of the bit period is what dictates a 1 or a 0. A transition from low to high in the middle of the bit period defines a 1, likewise a transition from high to low in the middle of the bit period defines a 0.
For Clarity:
I prefer to call each bit time as the bit period, because that's exactly what we are working with, small periods of time stacked end to end, so from now on, I'll call them bit periods, and not slots. Also I will call level changes transitions, because that's what happens, the level transitions from one state to the other.
On to my example:
Lets assume that you want to receive a single byte of 0F in hex, or 15 in decimal (00001111 in binary). See the drawing.
Listen for a level transition, any level transition will do, then set your bit period timer to roll over just short of half your bit period. When it times out note the current level, if it's the same set your bit period timer again but for a little short of your bit period, if not go back to listening for a transition. The reason for setting the bit period timer for a whole bit period is because we are currently in the middle of our first detected bit period. Each successive roll over of our timer will land us in the middle of the next bit period ready to listen for a transition. Each transition effectively resets our local clock so that it never goes out of sync.
Essentially you are listening to the incoming data stream (a stream of bits) for two special bits. These special bits are nothing more than the level at the end of one bit period, and the level at the start of the next bit period.
What makes them special is that they will show you where the bit period boundaries are. These two levels can be either way round, i.e can both be high, or both be low, it makes no difference, we are only interested in finding two of the same level in our data stream.
These two levels mark a bit boundary, and we use this detected condition to set our bit period timer so that we land in the middle of our first detected bit period. After that each timer roll over lands us back in the middle of the next bit period etc, you then simply note each level when the timer rolls over, and wait until the level transitions, noting obviously which way round it went so you know if it was a 1 or 0 that you received.
Now, I mentioned earlier about synchronisation and error detection...
Synchronisation doesn't merely happen by detecting a bit period boundary, you need to prepare the receiver before dumping your guff to it. This is called a preamble. Now a preamble can consist of any bit level pattern, however, some bit patterns make more sense to use, otherwise you will be spending all your time checking if it was a valid byte you received as opposed to just getting your clocks in order.
Preambles are packets of bytes, i.e more than one or two bytes long, and usually consist of all 1's or all 0's.
The reason why you use all 1's or all 0's will be obvious if you look at my drawing. Each bit of an all 1 or all 0 bit pattern will always provide you with a transition at the bit boundary, i.e exactly opposite to what we would regard as a valid start of reception. You use this continuous bit level transition to synchronise your local clock to that of the transmitter.
Error correction is obvious, you need a way to know if you received a wanted byte, or the dog barking next door. The easiest way to do this is with a parity bit check, odd or even parity is optional.
Basically parity checking would be calculated by adding the number of 1's received in each byte. For even parity checking, the parity bit will be zero if the number of bits in the received byte was an even number. If it was an odd number, the parity bit would be a 1, i.e to make it an even number again.
Odd Parity checking is the opposite way round, i.e if the number of bits received in the byte were to be an even number, then the parity bit would be a 1 to make it an odd number, likewise if it was already an odd number of bits received, then the parity bit would be 0.
This type of error detection is only good on a per byte basis, to detect other anomalies in longer strings of bytes, you would send as the last byte or last couple of bytes, a checksum calculated at the transmitter. After performing your checksum calculation on the receiver, you would compare the value transmitted to that calculated, if the two are different then you have an error in transmission, if they are the same then the entire stream was received properly and is valid data. Most checksums use modulo schemes of one sort or another, but can be as complex as needed for your application.
It is also common to send the actual number of bytes being sent as the first byte or bytes, this allows you to prepare your buffers ready to receive the stream etc.
Basically, everything you can do with any other serial receiving scheme, can be done with a Manchester encoded stream, it's just a little more involved because you need to recreate the clocking locally.
I hope this helps out folks struggling to understand how Manchester schemes work