Has anybody ever tried to use one of these?http://www.robotshop.ca/home/products/robot-parts/communication-control/data-telemetry/on-shine-low-cost-tx-rx.html
anyways, i have a sort of homebrew serial o'scope, and i checked out the output of the digital pin when the transmitter was sending a binay 0
here it is (the program is just something I did in Processing, the o'scope is just an analog pin on my arduino)http://i156.photobucket.com/albums/t31/frank26080115/robot_charlie/radiooutput.png
when i send a binary 1, it will go high for several milliseconds, it is perfectly capable of UART communication during that time, but after several milliseconds, the receiver goes back to idle
the problem is that, since the output transmits garbage out to your microcontroller's RX, it will keep tripping the serial interrupt and you can't do anything useful.
how about a small 8 pin co-processor on both the transmitter and the receiver?
the transmitter co-processor will output 0x00 forever on it's TX pin to the transmitter module, this way it at least the receiver side can verify that the transmitter is there and ignore the 0x00.
when your main microcontroller's TX outputs into the transmitter co-processor's RX, the co-processor will send a 0xAA (0b10101010) to the transmitter module, then another byte which is what you actually wanted to send.
mean while, the receiver co-processor gets the 0xAA instead of the 0x00, and thus prepares for the next byte, which is then stored and sent to the receiver's main microcontroller.
thus, only valid data is ever received. you can also add features such as device ID, apply math functions to the data, I^2C or SPI interfaces, and also various indicator LEDs
the TE pin on the receiver module is a very noisy and also it is always around 2.5V, BUT it will go to 5V for a very short period of time every time when the transmitter outputs binay 1. You can use a comparator so that only voltages over 4v will cause it to trip an interrupt pin, and in the interrupt routine, you can then enable the serial port, then exit the interrupt, and then the actual data will then trigger another interrupt, in which the byte is stored into a buffer