Nigel Goodwin said:
No, at the end of the data stream - as the RS232 goes to rest it leaves the line set at '1' (which is the STOP bit condition), the receiver is then sat waiting for a START bit, a drop to '0'. Because the radio link is AC coupled the '1' condition will fairly shortly drop to '0', in a fairly messy way! - this causes the receiver to start reading a byte, which hopefully (if you're checking for a stop bit) will fail - but the messy way the link drops might occasionally generate a correct stop bit as well.
By using a simple inverter (either in software or hardware) the rest condition becomes '0' and you don't have the droop problem, and the receiver waits for a '1' to signify a START bit.
We appear to be talking at cross purposes. You were talking about inverting RS232 data as sent from a micro to an RF link so that a ‘1’ is high and a ‘0’ is low to prevent ‘droop’ between bytes. I think that in most systems a micro would be handling RS232 signals in that way because the data coming in would be via a MAX232 to get the signals down - with inversion - to 0-5V levels as aang_fukakyon is doing. I used an X7000 transceiver in which the input was DC coupled and whose data threshold was +2.5VDC, so it did not matter what the data polarity was. The signal levels now didn’t conform to RS232, but the data type, ie start, data, parity and stop bits did.
On the other hand, I was talking about sending a byte normally followed by the same byte inverted, in order to keep the DC level of the data stream constant as recommended in the X7000 data sheet .
Quote: “The DOUT output signal is a digitised version of the AOUT analogue signal. The peak and trough limits of AOUT are measured and a midway level is generated. A comparator compares the level with AOUT and the digitised DOUT signal is produced.
When transmitting a long data stream it is important to transmit an equal mark and space ratio if possible. A long stream of either marks (FFH) or spaces (00H) can cause problems. In addition a preamble such us 55H, AAH, or CCH is required at the start of each data stream so that the midway level can be established before the data is received”.
The purpose of my AA bytes was to establish that midway level, and the byte inversion was to keep it at that level throughout the data stream.
To aang_fukakyon:
Your wiring of the MAX232 and TLP434A appears to be correct. I assume your Vcc is 5V. Also the receiver section appears OK according to the RLP434A datasheet. I wonder if the 7414 is necessary, bearing in mind that the application example of the RLP showed it driving a decoder direct, so I assume it has fast rise and fall times.
If the circuit worked with the link bypassed, then that would indicate that the PC output was OK.
The nominal data rate for the TLP is 4.8Kbps with a minimum of 512bps. Is your data rate above the minimum limit?
Do you have access to the software providing the RS232 source at the PC, or can you write a small program to send test bytes?