sometimes these TX/RX modules aren't all that robust, especially the cheaper ones. It appears maybe the receiver needs to receive some data in order to get its data clock/PLL in sync. With the reduced delay, the clock hasn't had time to drift off yet. The only problem with this hypothesis is that it doesn't appear to happen when you first begin transmitting.
If this is the case, you may need to put together a simple packet, with a preamble long enough to get the RX clock in sync, and a header and trailer to tell you here the "real" data starts and stops.
Glancing at the data sheet, it looks to me that you have the MAX3223 is set up correctly.
-j
If this is indeed the case, why don't you just continously send "01010101"... through the RF-link, until there is actual data to send at which point you send a preamble of "11111111" or something easily destinguishable from the "01"-placeholder sequence?
I mean, the Arduino sends "010101010101010" constantly until there is data to be sent. Then, it (without delay) sends "11111111", a 2 byte thingie defining the amount of data, then the data itself.
The computer side would read 2 bits at a time and see "01" over and over and ignore it. If it reads 8 "1"'s after eachother, it reads the next 16-bits and converts it into a number representing the length of the data, and then reads that number of bits from the stream.
Example sending "Hey!":
010101010101010101111111111000000000000010001001000011001010111100100100001
...broken down is...
01010101010101010 //reads 2 bits at a time, ignores as long as it is "01"
1111111111 //reads 8 "1"-bits in succession, knows to start reading
0000000000000100 //16 bits telling the computer the length of the data (in this case, 4 bytes (32 bits) )
01001000011001010111100100100001 //the 32 bits to be read
H e y !
//the computer goes back to looking for 8 "1"-bits
I'm just guessing this would work, and I would suggest adding any extra protocol-stuff (like source/destination/group ID), inside the data-portion of this packet.