I use an RF 315/434 MHz ASK RECEIVER and 315/434 MHz ASK TRANSMITTER for the communication between two 89c52 microcontrollers. I am a beginner. In the transmitter microcontroller i use the normal code for transmission of 1,2,3... by using sending some filters 'A' then 'B' and data and then 'Z' to check whether the data is receiving correctly. i use SMOD 0x50 TMOD 0x20 baud rate 9600. in the main loop
for(i=0;i<100;i++) { led=0x00; serial_tx('A'); led=0x01; serial_tx('B'); led=0x01; serial_tx(i); led=0x01; serial_tx('Z'); led=0x01; msdelay(); }
in debugger when i is 0 it shows the value i=0x00; when i is 1, i=0x01...
and in the receiver same SMOD 0x50, TMOD 0x20 baud rate 9600, in serial_read() temp=SBUF is stored
unsigned char temp, temp1, store; while(1) { serial_read(); if(temp=='A') { serial_read(); if(temp=='B') { serial_read(); temp1=temp; serial_read(); if(temp=='Z') { P1=temp1; // data stored and sent to port1 } } } }
here port 1 is connected with 8 led. but i am not sure of how the data sequence is being received. The lights are blinking with some randomness. Any solution regarding this. And the data sent to P1 is in binary ? Thanks in advance.
Why not count number of received values?
Note that a constant transfer rate will give a constant number of updates of that port every second. It's just that a binary conversion of a number results in the least significant bit changing value every tick. That is why it has a value of 2^0 = 1. Next bit will only change value every second update, since it has a value of 2^1 = 2. Next bit will only change value every four updates, since it has a value of 2^2 = 4. Next bit will only change value every eight updates, ...
If you do care about the received data, then you should modify the code so that you use a dual-direction transfer and send back acknowledges. And you should consider using a checksum to know if a received record is correct.
If all you can do is send in one direction, without feedback functionality to tell the transmitter that everything is ok you will be left with the option of trying to send in a safer way. Maybe send the same value multiple times. Maybe add ECC (Error Correcting Code) that allows you to figure out what bits have been incorrectly transmitted and how to recreate the actual transmission. However, such improvements will not work if the radio outage is too long. Only feedback between the two sides can handle a situation where there is active radio jamming resulting in significant data loss for longer time intervals.
Thanks for the useful points sir. So I should edit the code in such a way that after sending the data(a byte), i need to send another data which is checksum of the byte which is previously send and then later on compare both and then verify. Sir is this method ok ?
Your first step is to figure out what tools you have available. Such as the ability to send in both directions.
Your next step is to figure out if it is more important to only accept correct data, or to tranfer quickly? Or if old data is irrelevant so it's always the most current data that must be transmitted.
Your next step is to figure out how fast you must be able to transmit new data - is it ok to send the same data multiple times over a one-second span or not?
Note that a checksum can help you figure out if the transfer is correct or broken. But if the transfer is broken, you have not managed the transfer - so is it then important to try again? Obviously, the transmitter side will not know unless you have two-way communication.