amplitude shift keying

[aang_fukakyon]

i' doing my project about sending data (8 bit), and when i used cable (with rs 232), everything's OK.
data can 'flow' from tx (input computer) to rx (dot matriks led).
but when i replacing cable with ASK module TLP/RLP434A, data can't 'flow'.
(https://www.electro-tech-online.com/custompdfs/2006/11/TLPRLP434A.pdf)

i thought it's because the syncronization or else?
please help me finish my project.

thanks

 

[Nigel Goodwin]

i' doing my project about sending data (8 bit), and when i used cable (with rs 232), everything's OK.
data can 'flow' from tx (input computer) to rx (dot matriks led).
but when i replacing cable with ASK module TLP/RLP434A, data can't 'flow'.
(https://www.electro-tech-online.com/custompdfs/2006/11/TLPRLP434A-1.pdf)

i thought it's because the syncronization or else?

It's because you can't send RS232 over a simple radio link - RS232 is DC coupled, radio is AC coupled. You need to add NRZ coding (Non Return to Zero), the most popular type is Manchester coding.

Your easiest option is to change your radio modules for ones that have internal Manchester coding/decoding - next would be to use PIC's to do the coding and decoding.

For a crude method you might try just an inverter feeding the transmitter, and one on the receiver? - this inverts the polarity of the data, and gives it more chance - but it's not a great solution!.

 

[aang_fukakyon]

what is that mean (manchester coding)?

i can't change radio module, coz it's listed in my project specification (using module TLP/RLP434A)

 

[penoy_balut]

no change in hardware aside from adding RF module, more on software, the basic components are synchronization pulses, receiver address (multiple receiver), data byte and checksum. all bits are manchester coded or you can make your own as long as its DC balanced. in my code i use 10 as zero and 1100 as one.

 

[pebe]

It's because you can't send RS232 over a simple radio link - RS232 is DC coupled, radio is AC coupled. You need to add NRZ coding (Non Return to Zero), the most popular type is Manchester coding.

Your easiest option is to change your radio modules for ones that have internal Manchester coding/decoding - next would be to use PIC's to do the coding and decoding.

For a crude method you might try just an inverter feeding the transmitter, and one on the receiver? - this inverts the polarity of the data, and gives it more chance - but it's not a great solution!.

Could you elaborate on the last para, please?

 

[Nigel Goodwin]

Could you elaborate on the last para, please?

Invert the polarity of the data, add a transistor inverter in the transmitter, and another in the receiver - this helps to prevent the radio link failing due to lack of DC coupling. If you're doing your serial routines in software you can invert it in the software, but if using a hardware UART you can't.


I've done this with FM modules, and it worked fine (if rather crudely) - but I only ever used it at short range.

 

[pebe]

Invert the polarity of the data, add a transistor inverter in the transmitter, and another in the receiver - this helps to prevent the radio link failing due to lack of DC coupling. If you're doing your serial routines in software you can invert it in the software, but if using a hardware UART you can't.


I've done this with FM modules, and it worked fine (if rather crudely) - but I only ever used it at short range.

I've used this technique to send data from the serial port of a PC to a terminal 2Km away via a UHF FM link. It went through several microcontrollers that were all too busy with other tasks to take time out to recode to Manchester. The data rate was unavoidably lower than that recommended for the link and the data was for the most part numbers below 8, so there was the risk of the received DC level 'drooping'.

Sending each byte normally and then repeating it inverted maintained the DC component of the received signal and also gave an error check. The system worked fine and reported errors were nil.

I don't see why you call it 'crude'.

 

[Nigel Goodwin]

I don't see why you call it 'crude'.

Don't you consider it crude?, using a proper coding system is a lot more elegant, and gives much better error checking.

Presumably, from your explanation, the data was a continuous stream with no breaks?, it's mainly the breaks that cause the 'droop' (nice word for it by the way!). Which is why inverting the data helps, as a blank space can't droop.

 

[pebe]

Don't you consider it crude?, using a proper coding system is a lot more elegant, and gives much better error checking.

The coding system has no bearing on the error checking - it is a separate process.

Presumably, from your explanation, the data was a continuous stream with no breaks?, it's mainly the breaks that cause the 'droop' (nice word for it by the way!). Which is why inverting the data helps, as a blank space can't droop.

No, they were typically sent in streams of 8 bytes. The space between streams of bytes is a '1' and if the data slicer in the receiver does not respond correctly to the '0' of the start bit, an error can occur. I always preceeded the data with two AA bytes to 'normalise' the data slicer.

But as I said, I had little option other than to send RS232 on the RF link, and in the circunstances I don't consider my solution was crude.

 

[Nigel Goodwin]

No, they were typically sent in streams of 8 bytes. The space between streams of bytes is a '1' and if the data slicer in the receiver does not respond correctly to the '0' of the start bit, an error can occur. I always preceeded the data with two AA bytes to 'normalise' the data slicer.

So you always send two AA bytes to start, and ignore the faulty byte sent after your 8 byte stream?, as the '1' droops to '0'. That's what an inverter cures, because it leaves a '0' between your streams.

As for 'crude', I consider adding the inverter crude, bodging the data stream to try and correct the hardware limitations is even more crude!

 

[pebe]

So you always send two AA bytes to start, and ignore the faulty byte sent after your 8 byte stream?, as the '1' droops to '0'. That's what an inverter cures, because it leaves a '0' between your streams.

As for 'crude', I consider adding the inverter crude, bodging the data stream to try and correct the hardware limitations is even more crude!

You misunderstand the reasoning behind the inversion. It has nothing to do with the AA bytes. The AA bytes are sent to normalise the data slicer, ie. get the 'C' in the CR coupling network charged to its correct value to prevent a fault in the first byte of the data stream.
As for 'crude', it depends on what your interpretation of 'crude' is. I am reminded of the instance where the American astronauts were having difficulty making notes because they could not get a ball-point pen to write under zero gravity. They spent millions of dollars in perfecting a ball-point pen that would.

The Russians used a pencil! . I rest my case.

 

[Nigel Goodwin]

You misunderstand the reasoning behind the inversion.

No, the inversion is required because you get a false byte received when the RS232 enters a rest state (sat at '1'), as the radio link droops (I'm going to steal that word!). This occurs after the end of the 8 byte stream, and causes a false start bit.

It has nothing to do with the AA bytes. The AA bytes are sent to normalise the data slicer, ie. get the 'C' in the CR coupling network charged to its correct value to prevent a fault in the first byte of the data stream.

AA (as it's a stream of 1's and 0's) is commonly used for this purpose, in fact the manchester routines in my tutorial do a similar thing, sending a stream of twenty 1's to syncronise the receiver.

As for 'crude', it depends on what your interpretation of 'crude' is. I am reminded of the instance where the American astronauts were having difficulty making notes because they could not get a ball-point pen to write under zero gravity. They spent millions of dollars in perfecting a ball-point pen that would.

The Russians used a pencil! . I rest my case.

That's class, not crude - and rather shows the American mindset

(It's also one of my favourite stories!).

 

[aang_fukakyon]

i'm newbie in RF communication, so just tell me more spesific, step by step.
tomorrow, i'll upload my schematic.

thanks

 

[pebe]

No, the inversion is required because you get a false byte received when the RS232 enters a rest state (sat at '1'), as the radio link droops (I'm going to steal that word!). This occurs after the end of the 8 byte stream, and causes a false start bit.

Do you mean the start bit of the data stream? I say again "......The AA bytes are sent to normalise the data slicer, ie. get the 'C' in the CR coupling network charged to its correct value to prevent a fault in the first byte of the data stream."

They are sent at the start of every data stream. Think about it.

 

[Nigel Goodwin]

Do you mean the start bit of the data stream?

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.

 

[aang_fukakyon]

1. schematic using RF module

schematic of tlp434a
input from computer, using serial (COM) port.
because output from serial port is 232 level, then I used IC MAX232 to convert to TTL level (in=pin13, out=pin12).
output from IC MAX232 to input TLP434A (pin2)
is this correct?
(**broken link removed**)

schematic of rlp434a
from RLP434A, i used hex schmitt-trigger 7414 to make wave's output more 'shape or box'.
then, from output 7414 to microcontroller AT89S52 (pin 11=P3.0=RX).
with these settings, data can't 'flow' from tx (PC) to rx (dot matrix).
what's wrong with my design?
(**broken link removed**)

2. using cable
when i'm using cable, they look like this:
input computer (COM port) - MAX232 - microcontroller - dot matrix
data from computer can 'flow' from tx (PC) to rx (microcontroller)

 

[pebe]

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?

 

[Nigel Goodwin]

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.

A MAX232 inverts the data, but leaves it the wrong way, which is why you need a hardware inverter if you want to use a UART, because the UART is the wrong way as well, because it's intended for use with a MAX232.

However, now you've mentioned what module you're using, all becomes clear!.

You're NOT using a basic licence free module, which is what we're all talking about, you're using one with all the encoding built-in, so you can just send standard serial data. The module will packet and Manchester encode it before transmission, and the receiver decodes it at the other end and outputs nice serial data. You probably don't need to use your extra schemes (such as the AA bytes and sending each byte twice inverted), as the micro-controllers on the modules should do all the work required.

 

[pebe]

......You're NOT using a basic licence free module, which is what we're all talking about, you're using one with all the encoding built-in, so you can just send standard serial data. The module will packet and Manchester encode it before transmission, and the receiver decodes it at the other end and outputs nice serial data. You probably don't need to use your extra schemes (such as the AA bytes and sending each byte twice inverted), as the micro-controllers on the modules should do all the work required.

You're looking at the wrong data sheet. The X7000 is a simple multi-RF channel licence-free transceiver. It is basically an audio link, but they have included a comparator on the Tx side to allow a signal to be digitised. At the Rx data goes through an adaptive data slicer to digitise it. So the measures I took were necessary as the data sheet stated.

The module does no encoding or packeting. Raw data sent in is received as raw data at the other end of the link, so there's nothing special about it except its high power and high price - now reduced from the £400 we paid 8 years ago!

 

[Nigel Goodwin]

You mean it's not this one? ?. That one has a micro on board, and accepts direct RS232 type serial - at least how I read the datasheet?.