amplitude shift keying

[pebe]

Yes, that's the one. Here is the datasheet:

**broken link removed**

True, it has a micro on board but that is only used to accept signals to remotely change its channel or mode and interrogate the status of the device. It is not use, in any way, to modify data sent to it.

 

[Nigel Goodwin]

So what's the difference between 'digital data in' and 'direct modulation in', and have you tried both?.

I would suggest that the 'direct modulation in' is similar to that provided on normal RF modules (which won't work how you're using it, for the reasons previously explained), and that the 'digital data in' is perhaps processed through the micro?.

In any case, the X7000 isn't a normal RF module (and I'd love some to play with!), and you can't feed a normal module in the same way.

 

[pebe]

So what's the difference between 'digital data in' and 'direct modulation in', and have you tried both?.

See page 5 of datasheet. Direct modulation in (MIN) has no bandwidth filtering of the incoming waveform and could cause sidebands outside the permitted carrier swing. Hence, a new type approval is required.

No, I haven't tried it because I would rather have filtering done for me by the Digital Data in (DIN) input. Anyway, I could not stand the cost/hassle of an unnecessary TA application.

I would suggest that the 'direct modulation in' is similar to that provided on normal RF modules (which won't work how you're using it, for the reasons previously explained), and that the 'digital data in' is perhaps processed through the micro?.

No. Read page 4 of the spec. See SOX and STX/SRX

In any case, the X7000 isn't a normal RF module (and I'd love some to play with!), and you can't feed a normal module in the same way.

Apart from the (extra, optional) serial link to remotely control its parameters, as I described, it is perfectly normal. Data in = data out. It adds/ subracts nothing. No frills - no fuss. As far as its being a normal RF module, I used it as just that!

I programmed for the remote function but in the end it was not used in the application.

Believe me, I went through the spec with a fine toothed comb before embarking on the project. I've been there, dunnit and got the tee shirt!

 

[aang_fukakyon]

??

what should i do then?
i'm sorry, i don't understand what you're all talking about
i'm newbie in RF design

 

[Nigel Goodwin]

As I've said all along, either use NRZ coding or add hardware inverters to both transmitter and receiver.

 

[pebe]

what should i do then?
i'm sorry, i don't understand what you're all talking about
i'm newbie in RF design

You are either losing data or it's being garbled.
1. What is the steady state voltage on pin1 of the TLP and RLP units, - ie. with no data being sent from the com port?
2. When com port is sending, is data present at your micro?

 

[aang_fukakyon]

what kind of IC's i should use?

 

[Nigel Goodwin]

You can do it in the micro-controllers that you are presumably using?, or use seperate encoder/decoder chips (pre-programmed micros) like these!

 

[aang_fukakyon]

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!.

---------------
where i can find basic theory relationship 'bout rf module-rs232

 

[pebe]

---------------
where i can find basic theory relationship 'bout rf module-rs232

Aang, why do you need to know the basic theory of the module? You should be able to treat the radio modem tx/rx pair as a 'black box' where the data you get out is the same as the data you put in. As Nigel has said there is a limitation because the receiver circuit has a CR coupled output. Because of this you MAY need to a few alternate '0's and '1's to 'condition' or the receiver or 'DC restore' the signal before the real data is sent. Other than that, the setup you have is perfectly satisfactory without resorting to Manchester coding.

I asked you some questions earlier that would help diagnose your problem, but you have not replied. Checking for data being received at your micro will immediately tell you whether the RF link is working, ie. signals are being received.

No data = RF link fault. If data is present then the link is working but data is being garbled by the link and cannot be decoded by your micro - probably because of the need to condition the receiver output, as described.

 

[aang_fukakyon]

oh yeeeaaahhhh...

finally, i've passed the exam.
thanks to pebe & nigel, eventhough i still don't understand how to connect tlp/rlp module.

'but i still want to know why it doesn't work

pebe & nigel, have you already know that from PC i'd used IC MAX232 to covert 232 level from PC, to TTL level from microcontroller.

'cos my friend told me, that my TLP/RLP module doesn't work it's not because like what both you've said (manchester coding).

-----

pebe asked:

What is the steady state voltage on pin1 of the TLP and RLP units, - ie. with no data being sent from the com port? ---- i don't know (i used 5V DC power supply for TLP & RLP)

When com port is sending, is data present at your micro? --- yes when i'm using cable (PC-IC MAX232-microcontroller)

-----

i want to tell you something,

when i used configuration like this :[microcontroller-TLP ~~~~ RLP-microcontroller], they (TLP/RLP) connect.
from osciloscop i saw 'image' data sent is the same as 'image' data receive.

next, when i used configuration like this :
[PC-IC MAX232-TLP ~~~~ RLP-microcontroller], they don't connect
from osciloscop i saw 'image' data sent is NOT the same as 'image' data receive.
it's only 2 or 3 bit of the beginning is the same, the others is 'high' (from TLP)

so.....

 

[pebe]

In an earlier post you said

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)

So PC > MAX232 > micro worked OK. Therefore Micro data = inverted PC data.

Now you are saying

when i used configuration like this :[microcontroller-TLP ~~~~ RLP-microcontroller], they (TLP/RLP) connect.
from osciloscop i saw 'image' data sent is the same as 'image' data receive.

If that statement is true then TLP/RLP are working correctly.

next, when i used configuration like this :
[PC-IC MAX232-TLP ~~~~ RLP-microcontroller], they don't connect
from osciloscop i saw 'image' data sent is NOT the same as 'image' data receive.
it's only 2 or 3 bit of the beginning is the same, the others is 'high' (from TLP)

If that statement is true then one of the other two is not.

 

[aang_fukakyon]

yeah, that's why i'm so confused
in my previous post, like pebe said,

1. 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)
---> correct

2. when i used configuration like this :[microcontroller-TLP ~~~~
RLP-microcontroller], they (TLP/RLP) connect.
from osciloscop i saw 'image' data sent is the same as 'image' data
receive.
---> it means TLP/RLP working (but using microcontroller, not PC)

3. next, when i used configuration like this :
[PC-IC MAX232-TLP ~~~~ RLP-microcontroller], they don't connect
from osciloscop i saw 'image' data sent is NOT the same as 'image' data
receive.
it's only 2 or 3 bit of the beginning is the same, the others is 'high' (from
TLP)
---> it's true, now you can see everytime i use PC TLP/RLP is not working

 

[pebe]

We are going round in circles. I give up!

 

[aang_fukakyon]

yeah...
thanks anyway