|
|
View previous topic :: View next topic |
Author |
Message |
IzzyPrad Guest
|
A newbie question about Radio Communication |
Posted: Sun May 27, 2007 6:21 am |
|
|
Hello everyone,
I am kinda newbie into these stuff, so please bare my stupidity.
I am currently working in a Robotic swarm project and I am assigned for Radio communication and software in this project.
I have already written the codes to send data from a Robot to the base station. The robot sends data one integer at a time.
For eg. If the Robot wants to send "352637494853034" (Which is the value from compass, Ultrasonic cencors, encoder, etc.) to the base station, it will send 3 in into the 8 pin of the pic, then 5, then 2 and so on.
So From Robot:
PIC>encoder>Transmitter> Antena
PC base station:
Antena>receiver> decoder>PIC
Now my question is how does base station knows when to read the input pin? I mean the Robot cant acess the Read() function of the base station to make the base station read the input as soon as the robot sends it. So I am confused here.
Please someone shed some light here.
Thanks in advance |
|
|
Izzyprad Guest
|
Re: |
Posted: Sun May 27, 2007 6:44 am |
|
|
And the PIC controller we are using here is PIC18f4520. |
|
|
Guest
|
|
Posted: Sun May 27, 2007 6:45 am |
|
|
Sorry I mean PIC18f4250
|
|
|
rberek
Joined: 10 Jan 2005 Posts: 207 Location: Ottawa, Canada
|
|
Posted: Sun May 27, 2007 10:11 am |
|
|
It all depends on the interface that your radio modules use.
For example, I have some radio modules that use an RS232 protocol for input and output.
When I need to transmit data, the PIC will send the data to the transmitter using RS232. The transmitter takes care of sending the data over the appropriate air interface, and the receiver at the other end will convert the data into an RS232 output. You then only need to program your PIC to receive RS232 data, and then you can do with it as you like. The receiving PIC doesn't have to be told when to read, it just continually monitors the Rx signal for vaild data, and stores it when it receives it.
r.b. |
|
|
Izzy
Joined: 27 May 2007 Posts: 106
|
|
Posted: Sun May 27, 2007 11:20 am |
|
|
Thank you sir for your response.
So that means we dont have to write code for PIC to tell when to read the data?
Can you explain me more how does this work?
Sorry, I am absolutely new to this.
Here is my breadboard; hope this will help to understand more.
http://img293.imageshack.us/img293/2124/dsc00012ku4.jpg
Last edited by Izzy on Mon May 28, 2007 1:58 pm; edited 1 time in total |
|
|
rberek
Joined: 10 Jan 2005 Posts: 207 Location: Ottawa, Canada
|
|
Posted: Sun May 27, 2007 12:12 pm |
|
|
You're going to have to look at the datasheets for the radio transmitter and receiver modules. It will tell you in what format and with what protocol it needs to see the data.
You'll have to then write code for your Transmitter PIC to get the code to the transmitter with that protocol.
Then you'll have to look at your receiver module's datasheet to see how it will send out the data, and you'll have to write code for the receiver PIC to receive that data. If it sends it out as RS232, or SPI, or I2C, the PIC has built in functions for that, but you'd still have to write code to control these functions.
So yes you'll have to write code for both PICs.
Your breadboard doesn't tell me much (but you do breadboard very neatly!), as I can't see what any of the modules are.. You'd get more help from me or others if you gave more details about your radio modules and any other circuitry involved. For example, what interface do they use? What is the datapath from the PICs to their respective radio modules, etc.
r.b. |
|
|
Izzy
Joined: 27 May 2007 Posts: 106
|
|
|
rberek
Joined: 10 Jan 2005 Posts: 207 Location: Ottawa, Canada
|
|
Posted: Sun May 27, 2007 1:29 pm |
|
|
OK, I see your issue. The Rentron decoder just outputs 8-bit parallel data, with no other signals which would help you determine that you have new valid data on the bus (i.e. a data strobe, chip select, etc). The only thing you do know is the baud rate (2400 or 4800) at which you can receive your data.
You're going to have to develop your own protocol so that you know when your message starts. The only way to do that with just 8 data bits and no other synchronization signal is to reserve one or two of your 8-bit words as start and stop words respectively.
So, an example.
* You will always send groups of 4 8-bit words
* You have reserved 0xA5 as the START word (this means you can never use 0xA5 as data)
* You are sending data at 4800 baud
Thus your robot will transmit
0xa5 -> integer -> integer -> integer -> integer
with each 8-bit word arriving at the receiver every 1.7 ms (4800 baud)
For your receiver PIC, what you would do is write code that polls PORTD. Since, at 4800 baud, you will receive an 8-bit word every 1.7 ms, you should poll the port much more frequently than that (say 16 times faster. This oversampling will mean you don't miss a word).
When you detect 0xA5 on the port, you wait 1.7ms (plus a little bit) and sample the port again, and that will be your first integer. Store it and wait 1.7 ms for the next one. Loop until you have received your 4 integers and you can stop, and poll the port until you see 0xA5 again.
If you want to send variable length groups of integers, you will need to reserve a STOP word, for example, 0x5A. Now, instead of looping and storing four times, you will loop and store until you see 0x5A.
This is just an example. Other folks here may have some better ideas.
r.b. |
|
|
Izzy
Joined: 27 May 2007 Posts: 106
|
|
Posted: Sun May 27, 2007 2:36 pm |
|
|
Thank you sir for your brilliant post!
I am definately going to try that.
So can I do this way? ...
The first 8-bit word that the first robot (there will be around 5-10 swarm of robots) is going to send will be, lets say 0x0A (where A will signify that the info is from the first robot). So when ever that robot send 0x0A to the PC base station, it will be ready to read the input pins of the PIC.
So as you said that there will be a delay of 1.7ms at 4800 , the PIC will have to wait 1.7 ms after it receives the first data (i.e. 0x0A), then read the input pins for the second data again wait 1.7 ms, then read the pins for third third......and so on. Right?
I think I am going to have fixed no. of integers from robot, probably around 15-19 integers. So after the robot has sent 15-19 integers, the robot will send 0x0A again to signify end of transmission, right? Or do I even have to send that 0x0A again, If the no. of integers sent each time is fixed?
Is there anyway to do this using interrupts? Not that I know a lot about it, but just curious.
Once again thanks for being a great help! |
|
|
Izzy
Joined: 27 May 2007 Posts: 106
|
|
Posted: Sun May 27, 2007 2:44 pm |
|
|
Oh wait!
But how will the PIC first know that it has received 0x0A?
Do I have to put "input_c" in a loop as soon as I call a robot to send information?
Or is there any other effective way? (May be interrupts? but I dont know how to use it ) |
|
|
Spode Guest
|
|
Posted: Mon May 28, 2007 12:42 am |
|
|
Nice wiring but your bypass/filter caps are a mile away from the ICs
You should have 10 - 100nf ceramic caps right on the supply pins of
the ICs. |
|
|
rberek
Joined: 10 Jan 2005 Posts: 207 Location: Ottawa, Canada
|
|
Posted: Mon May 28, 2007 7:02 am |
|
|
Quote: | So as you said that there will be a delay of 1.7ms at 4800 , the PIC will have to wait 1.7 ms after it receives the first data (i.e. 0x0A), then read the input pins for the second data again wait 1.7 ms, then read the pins for third third......and so on. Right? |
Yes.
Quote: | I think I am going to have fixed no. of integers from robot, probably around 15-19 integers. So after the robot has sent 15-19 integers, the robot will send 0x0A again to signify end of transmission, right? Or do I even have to send that 0x0A again, If the no. of integers sent each time is fixed? |
No. As I mentioned in my previous post, if you know that you will send a fixed number of integers, you don't need a STOP word.
Quote: | Is there anyway to do this using interrupts? Not that I know a lot about it, but just curious |
The best way to do this is with interrupts.
Because you are periodically sampling a port, you will set up a timer interrupt. I'd set the timer to some fraction of the expected data period (i.e. 1/16th of 1.7ms)
You will essentially have a little state machine, and every time the timer interrupt goes off, you will evaluate your current state and see if it is necessary to change states.
When the PIC powers on, it will come up on monitor_state. In this state, every time the timer interrupt goes off, you will check portD. If you see your START word, you increment the state variable and go to start_state.
In start_state, I'd wait for another timer interrupt and check port D again to make sure the START word is still there. Since this is asynchronous sampling, you need to make sure you aren't catching data changes just on the edges.
If you detect START word again, go to wait_state, where you stay for 16 timer interrupts. You are now 1.7ms from where you took the second sample of START word. Now you can sample the port and get your first integer. Increment a word counter to one and then wait for 16 more timer interrupts, and so on. When you get the number of words you need. go back to monitor-_state and wait for the START word.
The code itself is an exercise left to the reader!
BTW, if you have 5-10 robots all transmitting to the base station, how do you make sure they don't all transmit at the same time? Are they interconnected somehow? They'll need some kind of common time base to make sure that they take turns sending their data to the base station.
r.b. |
|
|
Izzy
Joined: 27 May 2007 Posts: 106
|
|
Posted: Mon May 28, 2007 2:05 pm |
|
|
Thanks for your very helpful reply.
But today I went to my university and first tried to have communication between the robot and the PC base station with this following code and it didnt work.
I dont know why.
The robot is transmitting data, which can be seen on LEDs as blink that I installed in the data sending pins of the PIC. But the LEDs that I installed in the pins of data receiving PIC doesnot show any blink.
here is the code I used to check the communication:
Receiver:
Quote: |
#include <protoalone.h>
void main()
{
int i;
int input[18]={0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0};
int Command;
While(TRUE)
{
for(i=0;i<18;i++)
{
Command=input_c();
input[i] = Command;
printf("Command = %d\n\r",Command);
delay_ms(1.7);
}
for(i=0;i<18;i++)
{
output_d(input[i]);
delay_ms(500);
output_d(0x00);
delay_ms(500);
}
}
} |
Transmitter:
Quote: | #include <protoalone.h>
void main()
{
int i;
int Data[18] = {0,1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7};
while(TRUE)
{
for( i=0; i<18; i++)
{
output_d(Data[i]);
delay_ms(1.7);
output_d(0x00);
}
}
} |
|
|
|
rberek
Joined: 10 Jan 2005 Posts: 207 Location: Ottawa, Canada
|
|
Posted: Tue May 29, 2007 6:30 am |
|
|
You haven't shown that the robot is transmitting data. You've shown that the PIC's outputs are changing. You are going to have to take a logic analyzer or oscilloscope and see if the encoder is outputting to the transmitter, and then see if the receiver is sending data to the decoder and the decoder sending data to the receiving PIC. If the receiving PIC is seeing data on its PORTC, then you can look at the code.
Also, I don't think the delay_ms statement can take a float as its argument.
r.b. |
|
|
Izzy
Joined: 27 May 2007 Posts: 106
|
|
Posted: Tue May 29, 2007 12:49 pm |
|
|
Sorry Sir.
I changed the Delay_ms(1.7) to delay_us(1700).
Now, today I was able to get the data transfered from Encoder to decoder (through a wire) and the PIC did received those data, which was displayed through blinking LEDs in different port at the receiving end.
But when ever I tried to do a wireless transmission it doesnot work.
I dont understand why.
Please help me out here. I am in desperate need of help.
Thanks in advance. |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|