Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

Baud rate transmission problem

Status
Not open for further replies.
I am using a PC to transmit data using the serial port. The signals will go through a MAX232 chip before going into the RF transmitter module that i got. At the receiver module, it is connected to a PIC microcontroller.

The PIC can't seem to respond to the RF tranmission (it was ok without RF transmission)

I tested the RF transmitter and receiver using switches, LEDs and encoder / decoder chips and it was working.

Using:

Transmitter AM-RT4 https://www.electro-tech-online.com/custompdfs/2005/02/33590.pdf

Receiver AM-HRR3 **broken link removed**

So is the problem something to do with the baud rate? The transmission baud rate is currently 9600. According to the transmitter datasheet, it can only accept data rates of up to 4000Hz. The receiver can have data rate of only 2000Hz. Is this enough for a 9600 baud transmission?
 
try dropping down the baud rate , it couldent hurt..
from what i see your reciever is capable of 4800 baud ..
 
Spectacular Butter said:
williB said:
try dropping down the baud rate , it couldent hurt..
from what i see your reciever is capable of 4800 baud ..

May i know you came to the conclusion that it might be capable of up to 4800 baud? thanks

It usually tells you in the spec!.

But you should be aware that generally you can't send plain RS232 via these radio modules, you need some kind of encoding (None Return to Zero - NRZ) for it to work.

I have done it (for a crude example), but I had to invert the RS232, as the modules won't transfer a continuous high level (as RS232 sends in between bytes). You can buy more expensive modules which provide the encoding/decoding in the modules (usually with on-board PIC's) - these allow standard RS232 to be sent and received.
 
From a quick reading of the datasheets it infers that you can connect a TTL/CMOS level signal directly to the transmitter module and it will be transferred to the output of the receiver. You have demonstrated this with your switches and LEDS. An external modem should not be necessary.

The receiver is stated to allow a signal of 2000hz. This is your problem if running at 9600 bits/sec.

Consider a data signal with alternating 0 1 0 1 0 1 etc.
This is a squarewave with a frequency of half the bit rate. so a 9600 bps signal will be equivalent to a 4800hz square wave.
To transmit this you need AT LEAST 4800 hz frequency response through your system.

Try turning your speed down to 1200 bps and try again, it should work ok.
When you have that working, try turning the speed up. I guess it will stop working around 4000 bps (+/- a lot!).


JimB
 
Spectacular Butter said:
I tested the RF transmitter and receiver using switches, LEDs and encoder / decoder chips and it was working.
Do I see a deliberate mistake here ? I would love to know what these chips were ...

If the radio link can cope with 50 to 2000 Hz then I suspect it will need more than a 'simple' data stream to be successful. I have a hunch you will need something along the lines of a modem at each end to turn data into tones (encoder / decoder?), transmit two tones and then decode them back to data.

If I am right then your data rate may end up below 1200 baud before it works reliably.

You also mentioned a MAX232 line driver - NO !
 
Nigel Goodwin said:
But you should be aware that generally you can't send plain RS232 via these radio modules, you need some kind of encoding (None Return to Zero - NRZ) for it to work.

May i know how did you implement the NRZ encoding?

I tried with baud rates as low as 300 but it still won't work. It displays lots of weird symbols and characters when i just send an ASCII code.

P.S: Is it just me or is the forum server facing problems because it seems to be down quite often
 
Spectacular Butter said:
Nigel Goodwin said:
But you should be aware that generally you can't send plain RS232 via these radio modules, you need some kind of encoding (None Return to Zero - NRZ) for it to work.

May i know how did you implement the NRZ encoding?

The usual method is Manchester coding, a web search will provide details, but actual code seems fairly thin on the ground!. I keep meaning to have a play with it, but I've not got round to it yet!.

I tried with baud rates as low as 300 but it still won't work. It displays lots of weird symbols and characters when i just send an ASCII code.

As I said previously, you can't send RS232 over these radio links - if you invert it at both ends, it will then work to some extent (but it's somewhat crude!). Using a lower baud rate with standard polarity RS232 will just make it worse!.

P.S: Is it just me or is the forum server facing problems because it seems to be down quite often

Yes, I find it's down quite a lot as well!.
 
Nigel Goodwin said:
It usually tells you in the spec!.

But you should be aware that generally you can't send plain RS232 via these radio modules, you need some kind of encoding (None Return to Zero - NRZ) for it to work.

I have done it (for a crude example), but I had to invert the RS232, as the modules won't transfer a continuous high level (as RS232 sends in between bytes). You can buy more expensive modules which provide the encoding/decoding in the modules (usually with on-board PIC's) - these allow standard RS232 to be sent and received.

Would it make a difference if i send the PC serial data to a PIC after RS232/CMOS conversion and then the PIC will send the data through the RF into another PIC to process the data. Would this work? (Currently i don't have another PIC to test this out)

The project in this link seems to be able to send serial data in this way:
 
Spectacular Butter said:
Nigel Goodwin said:
It usually tells you in the spec!.

But you should be aware that generally you can't send plain RS232 via these radio modules, you need some kind of encoding (None Return to Zero - NRZ) for it to work.

I have done it (for a crude example), but I had to invert the RS232, as the modules won't transfer a continuous high level (as RS232 sends in between bytes). You can buy more expensive modules which provide the encoding/decoding in the modules (usually with on-board PIC's) - these allow standard RS232 to be sent and received.

Would it make a difference if i send the PC serial data to a PIC after RS232/CMOS conversion and then the PIC will send the data through the RF into another PIC to process the data. Would this work? (Currently i don't have another PIC to test this out)

There doesn't seem much point in doing that, if you're using a hardware UART simply add a simple transistor inverter between PIC and TX (or MAX232 and TX, if using a PC), and between RX and PIC.

The project in this link seems to be able to send serial data in this way:

Yes, I did something similar a number of years ago (see ), which is how I know about the inversion problem.

The link you posted solves the problem the same way I did, by using a software UART (there is no hardware one in the F84). By using a software UART you can invert the serial data in the software - if you use a hardware UART you can't do that!.
 
Nigel Goodwin said:
I have done it (for a crude example), but I had to invert the RS232, as the modules won't transfer a continuous high level (as RS232 sends in between bytes). You can buy more expensive modules which provide the encoding/decoding in the modules (usually with on-board PIC's) - these allow standard RS232 to be sent and received.

I dont really get it. By inverting the RS232 we would get a continous low level signal. Would that help? Usually encoding is perform to minimise DC signals. I dont see how it would make any difference
 
ok i think i beginning to get what u mean. So is it something like the picture below?


So the problem is caused because the signal will have a sequence of highs until the next byte of message is sent. These highs will cause problems in the transmission (synchronization??). So we need to invert the signals at transmission and then invert back at the receiver side to eliminate these continuous highs.

Am i correct on this??

Really thanks a lot. This is a real mystery problem to me until now... i think
 

Attachments

  • seriallink.gif
    seriallink.gif
    5.1 KB · Views: 1,184
Spectacular Butter said:
So is the problem something to do with the baud rate? The transmission baud rate is currently 9600. According to the transmitter datasheet, it can only accept data rates of up to 4000Hz. The receiver can have data rate of only 2000Hz. Is this enough for a 9600 baud transmission?

Since the transmitter can accept a 4Khz rate and the receiver can only accept a 2Khz rate, I think you wont get any better than a 2Kbps (Kilo Bits per second). Let's ignore the 9600, because 9600 is too much for these devices.

You can either set your connection speed to 2Kbps or change your FM receiver to 4Khz so that you can get a 4Kbps data rate.

By the way, I take that "whatever" baud equals "whatever" bits per second, but baud rate doesn't always mean bits per second.
 
fabbie said:
Nigel Goodwin said:
I have done it (for a crude example), but I had to invert the RS232, as the modules won't transfer a continuous high level (as RS232 sends in between bytes). You can buy more expensive modules which provide the encoding/decoding in the modules (usually with on-board PIC's) - these allow standard RS232 to be sent and received.

I dont really get it. By inverting the RS232 we would get a continous low level signal. Would that help? Usually encoding is perform to minimise DC signals. I dont see how it would make any difference

That's why I advised using Manchester coding!.

The 'crude' inverter way, as you say, gives a continuous LOW signal - that's the reason for doing it!. Standard RS232 would give a continuous HIGH signal, and the transmitter can't handle that - by inverting the RS232 it then works, but it's a bit of a bodge!.
 
Spectacular Butter said:
ok i think i beginning to get what u mean. So is it something like the picture below?

Yes, but i would place the TX inverter between the MAX232 and the transmitter.

So the problem is caused because the signal will have a sequence of highs until the next byte of message is sent. These highs will cause problems in the transmission (synchronization??). So we need to invert the signals at transmission and then invert back at the receiver side to eliminate these continuous highs.

Am i correct on this??

Yes, the transmitters (or it might be the receivers?) are designed for only AC signals, so you can't send a HIGH longer than a few milliseconds. If you have a double beam scope, stick one beam on the transmitter input, and the other on the receiver output - you will see that continuous high levels break up and fall back to zero.
 
I followed Nigel's suggestion of adding the inverters at the input and output and it works!! Thanks Nigel :D

But it only works at 1200 baud. I know it can't work at higher baud rates because the receiver can only accept up to 2000 bps. But why can't it work for baud rates below 1200 like 300?
 
Spectacular Butter said:
I followed Nigel's suggestion of adding the inverters at the input and output and it works!! Thanks Nigel :D

But it only works at 1200 baud. I know it can't work at higher baud rates because the receiver can only accept up to 2000 bps. But why can't it work for baud rates below 1200 like 300?

Perhaps because of the longer 'high' period of the slow baud rate?.

One bit is 3.3mS at 300 baud, if you have a word where all bits are the same, this means almost 30mS (9 x 3.3) of continuous HIGH. I doubt it would work over that long a period?.

Manchester coding helps this as you don't get long high or low periods in a byte - each bit is represented by a change in level, rather than a level itself.

You could really do with finding out what the link is capable of, a double beam scope (one beam on TX and one on RX) would be useful so you can compare the waveforms. I did my tests at 9600 baud with the modules I used.
 
Status
Not open for further replies.

Latest threads

New Articles From Microcontroller Tips

Back
Top