How crystal stability affect RS232 communication?

[young]

I had some gabage data sometimes dealing with wireless communication send from a RS232 port using a ZTT 4MHz Ceramic resonator. I want to know what is the reason behind this?

[EdWaugh]

I'd be surprised if its your oscillator, as long as the compiler approves the values you've picked (it follows the datasheets I think). Try enabling parity on the link and see if that helps.

ed

[Ttelmah]

I'd have to agree that it is unlikely to be the resonator, but obviously, if the timings are 'borderline' to begin with, temperature drift, and aging could just take you over the edge.
Start with what baud rate you are using?. If (for instance), you are using 9600bps, then if your oscillator was 'perfect', your error should only be a tiny fraction of 1%. The initial quoted accuracy of the resonator is +/-0.5%, and both temperature, and aging together, only move this a total 0f 0.61% max. If everything worked together for the 'worst case', you are still only talking a maximum of 1.1% error. The worst case total would then still be well inside the normally accepted 'allowable' margin of around 4%. However if the baud rate selected already has (say) a 3% error, then changes in the resonator could take you over the edge. Are you sure your resonator is properly configured?. changes to the load capacitors could have a significant effect. What baud rate are you using?. If it is one that is not easily/accurately synthesised from 4MHz, it might be worth shifting to a clock rate to help this (3.6864MHz is the usually 'prefered' one).

Best Wishes

[Humberto]

young wrote:

[young]

Thank you all:
I am using a RWS434 TWS434 from rentron.com.

the code that I am using is

[Humberto]

Hi young,

As I guess you have a the "second-case problem". This is because you are modulating
an milliwatt range AM transmiter with an unbalanced signal like pure ASCII.
The work around this is to encode your data with an balanced modulation like
Manchester or similar wich has data and sync signals impossed in the
same signal.
Anyway the max baud rate you will expect using this technique is around 2kbaud, also
I suggest to use some sort of error detecting to get a reliable link and keep the
data integrity.

Humberto

[Mark]

Better give him a link to the Manchester encoding

[Humberto]

Yes Mark, you are rigth.

I just give him a spot ligth were to find the problem.
I would give him some links but this matter is concerning with his
knowledgements, needs and "taste" that I don´t know.
Finding "manchester code" in Google, result in 6.590.000 links
regarding this issue.

Humberto

[Guest]

HT648L and HT640 is a hardware Manchester Encoder and decoder. I already tested them in my system. and It was too slow compared to the code that I am using. and as I mentenion that the final result is a eight pin output, it is really hard to syn the data for receiver to get the data correctly ( I mean the output from the HT648L is a eight pin data, If I want to read this data from another microchip. How could I syn the HT648L and this microchip).

[Ttelmah]

It is worth perhaps being aware, that Manchester encoding may not be needed. If your radio 'link', allows 10000 transitions per second to be sent, Manchester encoding the signal, will only allow 5000bps to actually be sent. Given that for most radio links, it is only necessary to be close to 'balanced' in the long term, it is simpler in many cases, to send the byte required, and then the bitwise not of the byte. Provided you select one start bit, 8 bits, and one stop bit (which ensures that the start and stop bits themselves are balanced), then you can send the byte '0D', by sending 0D, F2. This in bit patterns on the transmission, is sent as:
0101100001 0010011111
which has the required balanced number of 1's and 0's, but only guarantees it over the period of two byte times, rather than in the shorter term.
For many simple signal transmission systems, this is much simpler to encode, and given the slow response of the typical radio system to a signal imbalance, works fine. :-)
It involves the same potential loss of 50% in the actual bit rate.
I have done this in the past, with data encoded using a hamming code, and then transmitted like this, to give a very good data recovery reliability.
Just a thought...

Best Wishes

[languer]

Ttelmah, that is a very interesting approach. I have used something similar, but by doing what you proposed you actually get built-in error detection (0D ^ F2 == FF always, for any valid combination).

Very clever.

[Humberto]

In the thread tittled
"Sending and Receiving Radio Signals "
Posted: Tue Apr 27, 2004 4:07 pm

I suggested a similar trick:

A) Rigth way to solve this is using Manchester encoding. Not so easy for
begginers.

B) A "dirt" an easy solution -if your packet is very short- is to send each
ASCII chars precedded by an "balanced" char like 'U' whose binary
equivalent is 0b01010101 in this fashion :

Data packet:
"G021D"

Sending :
"UUGU0U2U1UD"

Then, in the receiver side just through away the 'U's and tell us your result

Humberto

[languer]

That thread is actually where I got it from (plus another dead-easy example you had on ring-buffering). I have been using this on-and-off, but the technique provided above gives you the added buit-in error detection.
I just thought it was very clever.