RF Modules with AT89C51 and serial communication protocol

[Maverickmax]

at89c51 uart

Hi

I use serial communication to transmitt simple 8-bit data with start and stop bits.

In the transmitter circuit, you see two buttons which allow you to press one of them. When one of them has been pressed, I was expecting to see one LED to swtich on in the receiver circuit. But my receiver circuit sometime switch the LEDs on without me pressing the buttons.

So I had to identify the problem by disconnecting the power in the transmitter circuit in order to see if something affect my receiver circuit and I could not see any fault in my receiver circuit because both LEDs didn't turn on while the TX was disabled.

Then I connected the power to my transmitter and the LEDs started to switch on with out the button being pressed. I realised there was a problem in my transmitter circuit.

So far I could not identify any problem in my TX circuit and it has to be my codes:

Transmitter code

// header files
#include "main.h"
#include "port.h"
#include "delay_loop.h"

//Function Prototypes

void serial_init();
void send_serial(unsigned char *s);


void serial_init()
{
       SCON=0x50;              //Setup for 8-bit data
       TMOD=0x20;              //Setup timer 1 for auto-reload
       TH1=0xF3;               //Setup for 2400 Baud
       TR1=1;                  //Turn on timer 1
       TI=1;                   //Indicate ready to transmit
}

void send_serial(unsigned char *s)
{
       while(*s !=0x00)
       {
               SBUF=*s;
               while(! TI)
               {

               }
               TI=0;

               s++;
       }
}


void main(void)
{

serial_init();
//send_serial('1');

       while(1)
       {
       //      SECOND_LED=0;
       //      FIRST_LED=0;

               if (FIRST_BUTTON == PRESSED)
               {
                                send_serial('1');

                       while(1)
                       {
                               if (FIRST_BUTTON == NOT_PRESSED)
                               {
                               FIRST_BUTTON = NOT_PRESSED;
                               break;
                               }
                       }
               }

               if (SECOND_BUTTON == PRESSED)
               {
                       send_serial('2');
                       while(1)
                       {
                               if (SECOND_BUTTON == NOT_PRESSED)
                               {
                                       SECOND_BUTTON = NOT_PRESSED;
                                       break;
                               }
                       }
               }
               Delay_Loop(5);
       }


}

Receiver code

// header files
#include "main.h"
#include "port.h"
#include "delay_loop.h"

//Global variable
tByte received_data_G;
int received_flag_G;

//Function Prototypes

void serial_init();

void serial_init()
{
       SCON=0x50;              //Setup for 8-bit data
       TMOD=0x20;              //Setup timer 1 for auto-reload
       TH1=0xF3;               //Setup for 2400 Baud
       TR1=1;                  //Turn on timer 1
       TI=1;                   //Indicate ready to transmit
       EA=1;                   //Enable Interrupts
       ES=1;                   //Enable serial port interrupt
}

serial() interrupt 4
{
       if(RI)
       {
               received_data_G=SBUF;
               RI=0;
               received_flag_G=1;              //Set received flag
       }
}


void main(void)
{

received_flag_G=0;
serial_init();
FIRST_LED=OFF;
SECOND_LED=OFF;

       for(;;)
       {

               while(received_flag_G==0)
               {

               }

               received_flag_G=0;

               if (received_data_G==1)
               {
                       FIRST_LED=ON;
               //      SECOND_LED=ON;
                       Delay_Loop(50);
                       FIRST_LED=OFF;
               //      SECOND_LED=OFF;
               }

               if (received_data_G==2)
               {
               //      FIRST_LED=ON;
                       SECOND_LED=ON;
                       Delay_Loop(50);
               //      FIRST_LED=OFF;
                       SECOND_LED=OFF;
               }
       }
}

[/code]

 

[Maverickmax]

rlp434a

I have forgot to mention RF modules. I am currently using TLP-434A and RLP434A modules and each is connected to AT89C51 chip.

If you know why this happen, can you please point out anything that I may miss something important out?

Thank you

Maverick Max

 

[Buriedcode]

nrf401 protocol

Hi,

As far as I know, most RF systems can only transmit a 'DC- balanced' signal, with no DC component. You are transmitting standard serial (start, byte, stop) which has a DC bias, when its idle the line is high.

However, because the TX/RX can't convey the 'DC component' of the signal, at your Rx, the idle signal will just drop to zero, fooling your reciver micro into thinking thats a start bit, and so it reads in. But of course, when in comes to the stop bit, there is no '1', so your chip abandons the packet and looks for a new one.

Also, generally the PLL in the receiver module needs time to adjust to the incoming modulated signal, so, depending on the symbol rate, the first few bits will probably be garbled, while the Rx adjusts.

Finally, the output of a typical RX 433Mhz module is Noisy! Various RF sources are picked up and can trigger a change in state in the output. It might be triggering a 'start bit' then random noise makes up the byte thats read in, and then maybe the noise also causes a 'stop bit'. - Sounds unlikely, but at 2.4Kb/s its bound to happen at some point.

Here's my solutions:
I personally don't think a simple 'start-stop' packet is robust enough, but if you're curious, you could try inverting the signal from the Tx micro before it goes into the Tx module, and do the same at the receiver end. This way, a start bit is a 1, and the line is '0' when idle. I'm fairly sure you'll still get garbled and failed packets, but you never know...

Read up on Channel coding in RF. And 'DC-balancing'.

Probably the easiest thing for you to do is to use Manchester encoding.
It rectifies the DC problem quite nicely, although it halves the available datarate.
Theres loads of info on google, and in this forum (some written by myself) on how to do it. The good news is it can all be done in software, and you can even use your UART, (if you have one on chip). I've explained it in this forum a few times, so just search for my posts (and 'manchester').

If you're still having problems, there are many solutions, and alternatives to manchester encoding that vary in complexity and efficiency. I realilse you're only testing your RF modules, just try different things until you get a good stable link, and then you could use it in future projects.

Good Luck.

BuriedCode.

 

[Maverickmax]

correction at89c51

Hi

Since you mentioned Manchester coding, I learnt to understand the Manchester coding encoder and decoder but there are two things that I am not sure about:

[1] I want to use UART in RX and TX with A89C51 and I have to apply manchester encoded bits in the data bits? So do I need to add encoder in my TX code and decoder in my RX code? Is there anything that I need to modify my code? Serial Communication?

[2] Have anyone done manchester coding with UART in AT89C51 in C before?

Maverick Max

Added after 48 minutes:

Now I am very confused because someone just told me that I cannot implement UART and I have to use bit-banging codes and advise me to modify my schematic as well

Maverick Max

 

[Maverickmax]

microcontroller a89c51

Hello again

I am very frustrated with my wireless project because I could not get that far at the moment.

Since my codes could not transmit data very well across the RF channel, can you PLEASE tell me how to send the data from transmitter to receiver?

Remember that I am going to implment manchester encoding in transmitter and decoding in the receiver. So what is the best way of transmitting encoded bits and how the receiver capture the serial data?

Whoever manage to answer my question, will be rewarded with help point.

Maverick Max

 

[Buriedcode]

at89c51 manchester

MaverickMax,

Sorry for the delay, been a bit busy.

Well, if you checked the forum, you would have found code snippets and links on manchester encoding on a micro, I admit all my work was on the PIC micro, and written in assembly. But I'm sure you could convert pseudo-code to C.

Remember that I am going to implment manchester encoding in transmitter and decoding in the receiver. So what is the best way of transmitting encoded bits and how the receiver capture the serial data?

Firstly you need to encode your bytes to manchester bits. As I'm sure you know, in manchester encoding: 1 -> 01, and 0 -> 10. So data 1 is an upward transistion in the output, and a data 0 is a downward transistion. Someitmes its the other way around, as long as encoder and decoder agree it'll be fine.

So, because you're putting two bits in, and getting two bits out, you put a byte in and get two bytes out. The easiest way it to use a look-up table, with 16 entries.
I say 16 instead of 256 because you can encode in 'nibbles' (half a byte). This saves alot of memory. Pseudo-code goes something like this:

Move 'INbyte' to the accumulator
AND with 0x0F; - this gets rid of the 4 MSB's, 0x0F is 00001111.
Call lookup table.
Move result into LOWbyte.
Move 'INbyte' to the accumulator
Swap nibbles; dunno how to do this in C. Now we work on the other 4 bits.
AND with 0x0F; - again, gets rid of 4 MSB's.
Call lookup table.
Move result into HIGHbyte.

Lookup table:
00000000 - > 10101010
00000001 - > 10101001
00000010 - > 10100110

etc....
00001111 - > 01010101

Remember, only 'useable data' is encoded. Any other packets (described later) are sent 'as is'.

I'm sure you've probably done this, but just incase...

Right, so with that, you put one byte in, and get two bytes out. 8 data -> 16 manchester bits. Thats an easy way to encode, but you still need to send it.

Now, 'bit banging' is an option, it takes up instructions and time, but can run very quickly. But some may not realise that you CAN use a UART for manchester data.

Now I am very confused because someone just told me that I cannot implement UART and I have to use bit-banging codes and advise me to modify my schematic as well

Does this mean you are 'not allowed' to use your UART? From a teacher/lecturer/boss? Or did they say it 'cannot be done' with a UART?

Either way, I'll try and explain both. Firstly heres a great article on UART's and manchester encoding:

**broken link removed**

Firstly, using your UART:
The standard format for data transmission is : SDDDDDDDDS. Now, the whole point of manchester encoding, is that is easy to syncronize(many transistions), and is DC-balanced (equal number of 1's and 0's). However, if we use our UART we already have syncronization (it does it for us) but we still need DC balancing. You've already 'balanced' your data byte, giving you two data bytes, using the above method, and the START bit is 0, and the STOP bit is 1. So every packet is already balaced.


In order for you to keep it going, you must send packets 'back-to-back' wihtout large gaps (a few bits gap may be ok) . Just load your byte into your micro's Serial buffer (so it send it), then keep checking a flag to tell if its finished sending. Or you can use an interupt if your micro have one (just checked, it does).

I've just checked your chip, there are loads of AT89C51's, and I do not know if you have a 'hardware UART'. But looking at your C-code, you use 'SBUF' which I think means that it has indeed got a serial port.

Right, now remember I mentioned 'the first few bits of a packet will be garbled'??
Thats the PLL in the RX getting acustom to the incoming data, it needs to lock.
Your First packet, the 'Preamble', should be 0xAA. In binary thats '10101010'. This is just to 'wake up' the RF reciever, but is not needed by your reciver micro, and serves no other purpose. So, after that packet, the next packet you send would probably get to your reciever OK (not garbled) but how do we know whether its data or not?? Simple. If you read the 'Quick Builder' article you would have seen a 'sync pattern'. This 'sync pattern' is NOT manchester encoded, it purposefully violates the code, so its not mistaken for data. Usually its '00011101' or just '00001111'. After you've sent this, then you send your TWO bytes of manchester data (thats 8 data bits in total).

So, wrapping it all up, using your UART, you send 4 packets consecutively (one straight after the other). And your whole packet should look like this:

<Preamble><Sync pattern><Data HIGH><Data LOW> - each is a byte, with its own 'start and stop' bits.

If you sent this to a gneric manchester decoder (01 -> 1, 10 -> 0) then you would see this for your two data bytes:

0DDDD0DDDDD0

(The bold '0's are simply the stop bit from the previous packet, and the start bit from the next packet producing a '10', which in manchester, is a '0').

You may want to add a 'STOP packet' but I don' think its necassary, you just look for the sync pattern, then the next two bytes after that are your data.

At the reciever, you have another UART. This is connected directly to the DATAOUT pin on your RF receiver (maybe with a 'buffer' or a schmitt trigger to square it up). This, like a UART used for cabled links is constantly waiting for a start bit. And no doubt noise will still trigger it, and maybe even add a stop bit as well, so your receiver micro gets a whoel packet in. BUT.....your code should only look for the 'SYNC pattern'. Once it has this, it knows thats the next two bytes it will get, will be data, and you should save them as such. So when ever your UART interupt pings, the first thing you do is check whether its your sync pattern. If not, then discard it, and continue lookingfor the SYNC. Once you've received it, read in the next two packets.

Right, Im getting tired

Bit Banging. Theres plenty of info on bit-banging on the net, and if you use the above methods (designed for a standard UART) you will only need bit banging routines for a standard UART. Since its just replacing hardware with software.
Juat make sure, in either case, that the baud is set the same for both the TX and RX.

Ok, well, thats it. I've explained this many times before, but I suppose it doesn't hurt. Sorry Admin if you think this is a repeated post.

Good Luck,

BuriedCode.[/b]

 

[Maverickmax]

rf module sync button

Hi Buriedcode

Thank you for your more information....

Can you please tell me more about 'buffer' that require to connect between RF module and microcontroller because I am not familiar with it.

I understand that

Start bit requires 0 bit

Data bits requires 1 or 0 bits

Stop requires 1 bits

So why I need to invert them with TTL inverter?

Maverick Max

 

[Buriedcode]

at89c51 dual serial

Hi,

just a quick reply here.
I always use 'buffers', its good design practice. Its just to separate/clean up any signals passing from one circuit to anther. Whether its inverting of not.

I suggested a simple 'NOT gate' purely because they are easier to obtain, and do that job. The fact that its inverting doesn't really make a difference, since you'll have one at your transmitter, and one at the receiver. (1 -> 0 -> 1).

However, don't quote me on this, but because the idle line for UART transmission is generally 'high' (5v) and because your RF modules cannot carry a DC component, your reciever will not 'see' a high line. If you transmit nothing, it will see 0v, which the receiver would think is a start bit, and read it in (not stop bit though, so it discards the packet). It will do this forever.

But, if you invert the signal before, and after the RF link, then the 'idle line' is 0. A start bit would be '1', and a stop '0'. So when you're not transmitting anything, the receiver will 'see' a high line (0v inverted is 5v), which is not a start bit, so it just waits for changes. Of course, the receiver needs the invrter so it doesn't keep checking for a start bit, but because you've inverted at the Rx, you must inverter at the Tx.

You can't experiment, try it with or without inverting the signal, but I'm willing to bet that inverting it will make the system more reliable.

Lastly, I don't know why I suggested using a UART at the receiver. Its fine for the Tx, but because the Rx is getting a lot of interference and noise, it will trigger the UART to receive. So it starts reading in a packet, and at the same time, your Tx could be transmitting, but you miss the data. So.....I'm afriad you're gonna have to bit-bang the receiver. Its not all bad, here's a little bit of peuso-code to help you along.


Set up timer interupt for the baud of your transmitter.

when it pings, you do this.
check what state the RF pin is (pin 10 on your schem)
Shift this into a temp register.
Check if the temp register is your 'sync pattern' (I use 00011101)
if not then return to main prog,
if it is then carry on reading in.


What that does is ignore everything that you recive until you have the 'sync pattern'. As soon as you have it, you know that the next bit, will be the 'start bit' of your first data packet, a 0. Check whether this is 0, if not, then its a flase sync, if it is then you must read in the next 8 bits, and store as something like (dat1h).

So, if you've used your UART in the transmitter, then you've sent 2 packets, manchester encoded, so thats a single byte of data. And remember, they have start and stop bits, which you don't need, but you can use them for error checking.

say you've found your sync
packet from RF : 0DDDDDDDDD10DDDDDDDD1

read in the D's, and after your first byte, check for a '1', then a '0'. Them read in the nect byte. Store them. And decode.

Its actually a bit easier in 'C' to do things like this than it is in assembly. Theres many example of shift registers in C.

Good luck.

BuriedCode.

Ps. thanks for the 'help points'. I'm glad I could help someone. And, if you're 'still' having trouble. I'll rig up my own system, with PIC's and RF modules, I've been meaning to do it anyway. My code will be in assembly, but well annotated.

 

[MADURAN]

manchester serial protocol

A possible solution is offered by the NORDIC (www.nvlsi.com) chip "nRF401". You can use a module
FM-RXQ1-433 from Farnell, or RXQ1-433.9 from TELECONTROLLI (www.telecontrolli.com).
The last one is cheaper (max. 20 EURO).

This modules are based on nRF401 chip that is a dual band transceiver. The main advantage of this
chip is the possibility to work without any Manchester encoding (as I know a Manchester encoding
reduce the the data rate by two).

You can find a lot of useful files on the NORDIC site for the nRF401 product.

I use this module since 2002 and I do not have any problem.

 

[Maverickmax]

article serial communication in at89c51

Hi Buriedcode

Thank you Buriedcode and another points for you. There is one thing that I need to be sure before writing bit-banging algorithm for the receiver.

Imagine that:

I get the bits - 1111000

When logic goes high at the begining, it stays there for a while. How my microcontroller know that bit stay high at three times?

Because I need to store each bit in my buffer for further processing such as manchester decoding. Should I implement interrupt or summat else?

Can you please provide me another psuedo-code for that stuff?

Maverick Max

 

[Buriedcode]

rf simple communication protocol

Maverick Max,

Long old thread this isn't it

Imagine that:

I get the bits - 1111000

When logic goes high at the begining, it stays there for a while. How my microcontroller know that bit stay high at three times?

Good point. But, imagine that you're bit banging a standard UART packet, (SddddddddS) what is the data is 11111111?? The line won't change through out the whole packet (except for start bit). Thats what bit-banging is. As long as you know the baud rate of the incoming data, you know the period of each bit. Example:

Baud = 5000 bps. Period of each bit = 1/baud = 1/5000 = 0.0002 seconds = 200us.

Because of this, you know when to look at the incoming data stream, and when to sample it. This page has a good explaination:

http://www.rentron.com/Myke7.htm

The second example there, talks of 'tri-poling'. Don't worry about that. Its the first one you're after. I think its even got C code examples.

Thats what your interupt is for. Its set on a timer that is equal in delay to the bit period. So, firstly, you look for transitions. Say the first bit you get from the preamble is '1'. Keep checking the state of the pin. As soon as it changes, (to 0) you start a counter, and then when it changes again (back to 1) you stop your counter. Then this value is the number of counts per bit period. Divide this value by 2 (to get a half-bit period) and wait this time. Then, when the counter has finished, you check your input pin again, and now you should be looking right in the middle of a bit. (sampling at the bit boundries can lead to errors). Now all you have to do is read it in, wait one bit period (which you know), and then read again.

All your interupt routine has to do is shift the input into a register. And your main program can determine what you do with that data.

Again, some quick pseudo-code.

Check input.
Wait for input to change (constantly checking)
Once changed, wait bitperiod/2 - (you can work this out in advance)
Check to make sure the input hasnt changed - (we should be looking at the same bit, right in the middle of it)
Now wait one whole bit period - (this is you timer interupt)
Read in input.

The usual technique is 'over-sampling'. Checking the incoming stream 16 times the bit rate. But google has all the answers, theres a wealth of information on this technique (UARTs are older than I am) on the web.

BuriedCode.

Btw: I forgot to give you this link right at the begining Its only for PIC micro's, with assembly code...........but the principle is identical to your needs:

http://ww1.microchip.com/downloads/en/AppNotes/91045a.pdf

 

[Yin-Yang]

rf modules schmitt trigger

Lastly, I don't know why I suggested using a UART at the receiver. Its fine for the Tx, but because the Rx is getting a lot of interference and noise, it will trigger the UART to receive.

Hiya Buriedcode

Out of curosity, have you experienced this problem in your previous project?

I found your posts very interesting about manchester coding and bit-bashing. But would you save a lot of time if you buy Radio chip with features like linear coding and RS-232? This would speed the process up for me, maverick max and people in EDAboard.

If it is possible to get one, do you know any good RF chip?

Yin-Yang

 

[Maverickmax]

find pseudocode and modules

Hiya Buriedcode

Out of curosity, have you experienced this problem in your previous project?

I found your posts very interesting about manchester coding and bit-bashing. But would you save a lot of time if you buy Radio chip with features like linear coding and RS-232? This would speed the process up for me, maverick max and people in EDAboard.

If it is possible to get one, do you know any good RF chip?

Yin-Yang

Greeting Yin-Yang

Good Point. It has been a great learning curve for me but RF module with manchester coding and RS-232 would be useful for my future project. The only problem is I don't know which RF module would be best for my application

Maverick Max

 

[Buriedcode]

at89c51 send packet uart

Hi all,

There are many RF modules that are 'transparent', these provide their own Error correction, spectrum spreading and many other 'bells and whistles'. I haven't actually used one I've always liked to try and design things from scratch, it helps me learn, and it means I have complete control over everything. Plus, buying pre-made modules is the easy way out

That said, although some are very expensive (like the Nordic modules, and ones from microlinear) which are 2.4Ghz, 500m, low power comsuption, high speed, FHSS) in recent years some really cheap ones have come out, that are not as fancy, but make it a whole lot easier to setup a link.

**broken link removed**
**broken link removed** for 433Mhz

**broken link removed**
**broken link removed** for 868/900Mhz.

Both the above are simplex links (one way) and interface to RS232 (given the proper level shifting). But can interface directly to a UART on a micro, without any form of coding, sdince the micro in the module does it for you. Basically Maverick, you microcontroller is in there already.

Also, if your app simply requires 'control', like a gate control, car alarms, security etc... There are loads of ASIC's that are dirt cheap and do all the encryption, channel coding, packeting etc.. Although these generally cannot send actual 'data', only a few switches on/off.

https://www.rentron.com/PicBasic/RemoteControl.htm

This site has tons of stuff for sale, although maybe a bit expensive compared to buying from a distributor (farnell). I would look at the Holtek chips. Some are for a few switches (probably used in car alarms worldwide) and some can be configured to send user data. Again, all the complicated stuff is done for you.
Maverick, these recommend that you use the RF modules you have

Hope this helps. And as I said, I like to design things from scratch, I would use many of the chips/module mentioned above, but my latest project runs at 4Mb/s, with low latency, and I have yet to find a chip that does the channel encoding for me.

BuriedCode.

 

[Maverickmax]

serial communication protocol with rf

Hi

http://www.rentron.com/ruf-bot.htm

This link show you that guy have done the similar project like mine but he didn't use manchester coding, preamble or NOT gate. He just used the serial communication.

So far I know he is using PIC 16F84 and BASIC langauge whereas I use AT89C51 and C language. What else?

Maverick Max

 

[Jacksparrow88]

Re: at89c51 manchester

MaverickMax,

Sorry for the delay, been a bit busy.

Well, if you checked the forum, you would have found code snippets and links on manchester encoding on a micro, I admit all my work was on the PIC micro, and written in assembly. But I'm sure you could convert pseudo-code to C.



Firstly you need to encode your bytes to manchester bits. As I'm sure you know, in manchester encoding: 1 -> 01, and 0 -> 10. So data 1 is an upward transistion in the output, and a data 0 is a downward transistion. Someitmes its the other way around, as long as encoder and decoder agree it'll be fine.

So, because you're putting two bits in, and getting two bits out, you put a byte in and get two bytes out. The easiest way it to use a look-up table, with 16 entries.
I say 16 instead of 256 because you can encode in 'nibbles' (half a byte). This saves alot of memory. Pseudo-code goes something like this:

Move 'INbyte' to the accumulator
AND with 0x0F; - this gets rid of the 4 MSB's, 0x0F is 00001111.
Call lookup table.
Move result into LOWbyte.
Move 'INbyte' to the accumulator
Swap nibbles; dunno how to do this in C. Now we work on the other 4 bits.
AND with 0x0F; - again, gets rid of 4 MSB's.
Call lookup table.
Move result into HIGHbyte.

Lookup table:
00000000 - > 10101010
00000001 - > 10101001
00000010 - > 10100110

etc....
00001111 - > 01010101

Remember, only 'useable data' is encoded. Any other packets (described later) are sent 'as is'.

I'm sure you've probably done this, but just incase...

Right, so with that, you put one byte in, and get two bytes out. 8 data -> 16 manchester bits. Thats an easy way to encode, but you still need to send it.

Now, 'bit banging' is an option, it takes up instructions and time, but can run very quickly. But some may not realise that you CAN use a UART for manchester data.



Does this mean you are 'not allowed' to use your UART? From a teacher/lecturer/boss? Or did they say it 'cannot be done' with a UART?

Either way, I'll try and explain both. Firstly heres a great article on UART's and manchester encoding:

**broken link removed**

Firstly, using your UART:
The standard format for data transmission is : SDDDDDDDDS. Now, the whole point of manchester encoding, is that is easy to syncronize(many transistions), and is DC-balanced (equal number of 1's and 0's). However, if we use our UART we already have syncronization (it does it for us) but we still need DC balancing. You've already 'balanced' your data byte, giving you two data bytes, using the above method, and the START bit is 0, and the STOP bit is 1. So every packet is already balaced.


In order for you to keep it going, you must send packets 'back-to-back' wihtout large gaps (a few bits gap may be ok) . Just load your byte into your micro's Serial buffer (so it send it), then keep checking a flag to tell if its finished sending. Or you can use an interupt if your micro have one (just checked, it does).

I've just checked your chip, there are loads of AT89C51's, and I do not know if you have a 'hardware UART'. But looking at your C-code, you use 'SBUF' which I think means that it has indeed got a serial port.

Right, now remember I mentioned 'the first few bits of a packet will be garbled'??
Thats the PLL in the RX getting acustom to the incoming data, it needs to lock.
Your First packet, the 'Preamble', should be 0xAA. In binary thats '10101010'. This is just to 'wake up' the RF reciever, but is not needed by your reciver micro, and serves no other purpose. So, after that packet, the next packet you send would probably get to your reciever OK (not garbled) but how do we know whether its data or not?? Simple. If you read the 'Quick Builder' article you would have seen a 'sync pattern'. This 'sync pattern' is NOT manchester encoded, it purposefully violates the code, so its not mistaken for data. Usually its '00011101' or just '00001111'. After you've sent this, then you send your TWO bytes of manchester data (thats 8 data bits in total).

So, wrapping it all up, using your UART, you send 4 packets consecutively (one straight after the other). And your whole packet should look like this:

<Preamble><Sync pattern><Data HIGH><Data LOW> - each is a byte, with its own 'start and stop' bits.

If you sent this to a gneric manchester decoder (01 -> 1, 10 -> 0) then you would see this for your two data bytes:

0DDDD0DDDDD0

(The bold '0's are simply the stop bit from the previous packet, and the start bit from the next packet producing a '10', which in manchester, is a '0').

You may want to add a 'STOP packet' but I don' think its necassary, you just look for the sync pattern, then the next two bytes after that are your data.

At the reciever, you have another UART. This is connected directly to the DATAOUT pin on your RF receiver (maybe with a 'buffer' or a schmitt trigger to square it up). This, like a UART used for cabled links is constantly waiting for a start bit. And no doubt noise will still trigger it, and maybe even add a stop bit as well, so your receiver micro gets a whoel packet in. BUT.....your code should only look for the 'SYNC pattern'. Once it has this, it knows thats the next two bytes it will get, will be data, and you should save them as such. So when ever your UART interupt pings, the first thing you do is check whether its your sync pattern. If not, then discard it, and continue lookingfor the SYNC. Once you've received it, read in the next two packets.

Right, Im getting tired

Bit Banging. Theres plenty of info on bit-banging on the net, and if you use the above methods (designed for a standard UART) you will only need bit banging routines for a standard UART. Since its just replacing hardware with software.
Juat make sure, in either case, that the baud is set the same for both the TX and RX.

Ok, well, thats it. I've explained this many times before, but I suppose it doesn't hurt. Sorry Admin if you think this is a repeated post.

Good Luck,

BuriedCode.[/b]

hey buriedcode u talked about manchester coding in u r post for rf data transmission
i ve got a assembly language program to transmitt data using uart bt i'm not able to uderstand in..plz help me out...here's the code..the program is done on at89c51


MOV A,RAM1
SWAP A
ANL A,#0F0H
MOV B,A
MOV A,RAM2
CLR C
SUBB A,#30H
ADD A,B
MOV PACK1,A