Help me synchronize two PICs in a wireless comunnication

could any one help in syncronizing two pic in a wireless communication .now am trying with adding a preamble at the starting of each data frame ..and then from that finding the baud rate....please give some information on this.

syncronization

Yes that is very common. Even simple serial UART use it!

syncronization

Generally, you do not have the microcontrollers attempt to determine the baud rate from the preamble, especially in wireless communication. It is much easier to standarize on a common baud rate that both ends know to use.
The problem is not the baud rate, it is a framing issue of where exactly the data starts. This is a big problem in wireless communication because the AGC circuits in the receiver take some time to adjust to the start of the transmission. The preamble allows the receiver to adjust its gain which also clearly indicating at what point the first data element starts.
There are a couple ways of doing this. One simple method that has worked well for others is the NEC style IR communication of a very wide pulse followed by the data. The pulse is wider than any serial data packet of continuous "1" and therefore cannot be confused with data. Take a look at:
http://davehouston.net/rf.htm

Re: syncronization

thankx for replying
that is ok! but what the problem is with the data rate...actually my project is on secured inter com..here i have 4 hand sets and a bse station for switiching ...me self is doing the base station..i use a pic 16f877a for this purpose....and there are two channel for communication ..one for request signals and other for the data transfer(siMplex).. pic has only one usart...also data channel needs higher data rate.....

syncronization

Ok, you need two different baud rates, but you know in advance what these two baud rates are, so you are not having to experimentally determine them. Typically, you would send an alternating pattern like 0xa5a5 and then at the receiving end if you get the proper pattern 0xa5a5 then the baud rate is correct. If not, then you know to switch baud rates.
The PIC has only one hardware UART. However, there is nothing stopping you from using another timer to form a software UART. The code is all over the web and was commonly used back before they included UARTs in the microcontroller. You could also wire these two UARTs in parallel. Use the hardware UART for fast data transfer and use the software UART for slower speed request signals. Then the code needs only to decide which UART is in control based on contents of the control or framing packet.
Otherwise, using one UART, you have to send the framing packet, allow some time for the receiving end to decode the packet and adjust its UART if required, before blasting across the real data. Again, since the baud rates are known you can determine the max time required to make the switch and therefore adjust the delay time between the framing packet and the data.
In this way the framing packet is really a wake-up and switch your baudrate packet.

Re: syncronization

ok nw i under stood ur idea .......see can you just explai to me or suggest a site which could make me clear on this preamble syncronization) now what i am trying to do is that first ill sent the preamble in front of the data frame and then ill check whether the received data is preamble then if its so the remaining data is just from the particular pin where receive the data ..doing so am i going in the rigt way? or else please ...once again thank u for sparing time for me..
ok one more thing as you said 'software uart'---is it a pin progrmmed for serial to parrel coversion and vice versa.

now at present what i am basically doing is that i have two pic16f877a ..one for senting a serial data and another for receiving this at pin b0 and doing other thisgs like checking the preamble ..etc..two pics are connected through wires..so that if i succeded in syncronizing then ill substitute the wires with a rf module.

syncronization

The preamble is what you use for baud rate detection. Take a look at:
**broken link removed**

This describes an autobaud algorithm. You would only need to implement it to determine which of two possible ones are used.

Be care with the word "frame" as it means different things in different parts of the circuit. When you say data frame, you are talking about the block of data being sent. However on the communication channel, a framing error means that the bytes were not decoded properly because detection started on the wrong symbol.

On a wired system, the detection of the start bit is pretty reliable. In a wireless system with its usual noise problems, the start bit could be missed or a noise pulse could be mistaken for the start bit. This gives a framing error. Think of a picture frame that is not centered on the portrait. That is the context of a framing error.

The wireless channel is noisy and the microcontrollers and computers cannot ignore the random noises like you can. If you are listening to the radio and there is a static noise during a pause in the communication, you do not misinterpret the next spoken word because your brain knows to ignore that part. Computers are dumb, that noise pulse will trick the computer into believing that the next word is beginning to be sent.

I am concerned that you are presently designing with a wired connection. This is a very common error to design a hard wired system and then assume that it can easily be converted into a wireless one. The wireless communication channel is the limiting factor of the entire design. First you must choose the rf system and learn exactly what its requirements and limitations are. Then you can regress to a wired link for initial development. For example, inexpensive rf serial links are limited to baud rates less than 9600. Some only go to 4800 and also have lower limits of how slow they can go.

Software UARTs are doing serial to parallel conversion on the receive side and parallel to serial conversion on the transmit side. You do not have to do both of these in any particular chip. You could do a software UART for receive only. On the receive side, it must detect the start bit, sample the data bits close to their centers and then remember to discard any stop bits. On the transmit side, the software UART must append the start and stop bits to the data and then clock it out serially. Again, if you look at the MicroChip web site, I am sure they still have sample code. The limitation of the software UARTs is that the microcontroller cannot do any other labor intensive tasks or tasks that require interrupts during the time that data is being set or received. That is why later chips added hardware UARTs to allow then to do other things during data transmission and reception.

Re: syncronization

good evening banjo and every body...hw are u? fine na?
:|
now i am stuck with another problem .......... i programmed the first pic for bit by bit outputtig a 'preamble+data' sequence .. then my second pic is programmed to receive this bit by bit incomming data and checking whether it is preamble....and reading it ..
the second pic is programmed such that when ever it dectects an L_H or H_L edges then it calls isr to read 1..& o accordingly....but what the problem is that ------->when ever an interrupt occurs at the pin b0 the pic takes arround 50microseconds to goto its isr...during this time pic fails to detect the some of the edges of the data coming on..whats your opinion
the preamble byte is '10101010'
am using a crystal oscillator of 4megaHZ
...will this problem be solved by using a 20megaHZ:?:

syncronization

h**p://www.iol.ie/~ecarroll/autobaud.html

Re: syncronization

thank u banjo,,,
we completed our project successfully..