The strange character is
Ç. It is code C7 (11000111) in ISO 8851-1. The code for
y is 79 (01111001). If we add start and stop bits we get 0110001111 and 0011110011. And of course the idle level in RS232 corresponds to 1.
You can see there are similarities at the binary level, so that if somehow the reception of start and stop bits is unreliable or whatever, it could explain how
y turns to
A correct bistream of back to back
yyyy looks like:
Now you have to understand that in RS-232 there can be a synchronization problem! The only framing information is the 0 start bit and the 1 stop bit. If the start bit is not received correctly, and there is back-to-back continuous transmission, the only way that the receiver can detect that it is in error is if it receives a 0 at a point where the stop bit is expected! If a variety of characters are transmitted, hopefully it will lock in on the correct framing eventually. If there is a pause in the transmission, of course, that helps too.
In repeating sequence of 10 bits, any 0 which is preceded by a 1 could be the start bit. So in a repeating sequence of
y, assuming 8 bits, no parity and 1 stop bit, there are two possible frame starts:
So assuming a correct receiver and a reliable link (except for missing the start bit), a stream of
y could be misinterpreted as a stream of
g. You don't need bad hardware to get this screwup.
g has code 67, which isn't C7, but some other problem can perhaps explain that one, and also the fact that you were consistently getting the C7 character.