|
|
View previous topic :: View next topic |
Author |
Message |
masary
Joined: 05 Jun 2006 Posts: 5
|
how to differentiate multi channel Rx and Tx |
Posted: Wed Jun 07, 2006 9:52 pm |
|
|
Hello,
I'm new in CCS. I have one Receiver and one transmitter which have 6 channels and working at same frequency. I'm using ccp1/2 to measure the pulse width. I only got 2 pulse width. With this condition, I only can built 2 tasks. I want to built each channel to do different task. Do you have any ideas how to do that?
Thanks |
|
|
SherpaDoug
Joined: 07 Sep 2003 Posts: 1640 Location: Cape Cod Mass USA
|
|
Posted: Thu Jun 08, 2006 6:47 am |
|
|
What are you transmitting or receiving? is it RF or IR or something else? How are these "channels" supposed to be differentiated? How is the data encoded on the signal? We really don't have enough information to start. _________________ The search for better is endless. Instead simply find very good and get the job done. |
|
|
masary
Joined: 05 Jun 2006 Posts: 5
|
|
Posted: Thu Jun 08, 2006 6:32 pm |
|
|
sorry..it is RF.
Actually the these Tx and Rx come from helicopter remote control. All channels working at the same freq, around 45hz. The pulse length (for every channel) is related to stick position, e.g: all the way to the left 1 ms, middle 1.5 ms and all the way to the right 2 ms.
How are these "channels" supposed to be differentiated?
I want my PIC can differentiate each channels. I dont have any idea besides measure the pulse lenght but this only have 2 conditions.
How is the data encoded on the signal?
actaully i dont really understand this. I got lil bit info. -->receiver does not have much signal processing to do - just to divide the pulses to each of it's servo outputs and watch out for the synchronization pulse to reset the channel counter |
|
|
rberek
Joined: 10 Jan 2005 Posts: 207 Location: Ottawa, Canada
|
|
Posted: Thu Jun 08, 2006 9:44 pm |
|
|
I'm still not entirely clear on what you are trying to do.
Are you trying to receive 6 PWM channels and transmit 6PWM channels simultaneously, or are you just trying to receive 6 simultaneously?
Either way, I don't see how that is possible with a single PIC. If you are processing 6 input channels simultaneously you need to capture data for all the channels at the same time, since input will be occurring all the time on every channel (I have 3 RC helicopters. Believe me, none of the sticks ever stops moving for very long).
With one PIC, you cannot process six channels at the same time. If you have a multiplexer in front of the PIC to select two of the six input channels, you will be able to process two data streams, but you will miss the data being transmitted on the other four channels during that time. And that is only if you are processing receive channels. If you are also trying to transmit data, you will have to split your processing time among twelve operations with two CCP modules. As well, if you intend on transmitting the PWM servo signals, which are nominally 500 Hz or so, you may find you have to run the PIC at a low clock frequency, which reduces your processing power.
Its late and maybe I'm not getting your point. Can you describe in more detail what you are trying to do?
r.b. |
|
|
Mark
Joined: 07 Sep 2003 Posts: 2838 Location: Atlanta, GA
|
|
Posted: Thu Jun 08, 2006 10:15 pm |
|
|
rberek wrote: | I'm still not entirely clear on what you are trying to do.
Are you trying to receive 6 PWM channels and transmit 6PWM channels simultaneously, or are you just trying to receive 6 simultaneously?
Either way, I don't see how that is possible with a single PIC. If you are processing 6 input channels simultaneously you need to capture data for all the channels at the same time, since input will be occurring all the time on every channel (I have 3 RC helicopters. Believe me, none of the sticks ever stops moving for very long).
With one PIC, you cannot process six channels at the same time. If you have a multiplexer in front of the PIC to select two of the six input channels, you will be able to process two data streams, but you will miss the data being transmitted on the other four channels during that time. And that is only if you are processing receive channels. If you are also trying to transmit data, you will have to split your processing time among twelve operations with two CCP modules. As well, if you intend on transmitting the PWM servo signals, which are nominally 500 Hz or so, you may find you have to run the PIC at a low clock frequency, which reduces your processing power.
Its late and maybe I'm not getting your point. Can you describe in more detail what you are trying to do?
r.b. |
I've used port b change on interrupt to capture 4 channels. RB0 could be used for another. The 2 CCP's would be 2 more. So it is certainly possible to do 7 channels without much hardware. Another option would be to multiplex these signals together and signal the pic. Use the RB0 int and generate your own sort of change on port b interrupt. If I remember correctly, the RC receivers I have used in the past never transmitted a pulse at the same time. Channel 1, then Channel 2, and so on. |
|
|
rberek
Joined: 10 Jan 2005 Posts: 207 Location: Ottawa, Canada
|
|
Posted: Thu Jun 08, 2006 10:32 pm |
|
|
Interesting. Shows how much I know! |
|
|
masary
Joined: 05 Jun 2006 Posts: 5
|
|
Posted: Fri Jun 09, 2006 2:23 am |
|
|
mark--> yes, the RC receiver never send the pulse at the same time. but i dont know how to make PIC recognize it. I use cpp1 and cpp2 to measure pulse width.
so, how to built/make PIC can detect pulse at different time by using port b? what kind of interrupt that you mention?
thanks.. |
|
|
Mark
Joined: 07 Sep 2003 Posts: 2838 Location: Atlanta, GA
|
|
Posted: Fri Jun 09, 2006 7:07 am |
|
|
If you don't want to add external IC's then do as I have said. The portb change interrupt will give you 4 channels. You will need to let a timer run. Anytime an interrupt fires, check to see if one of the outputs has changed. If so, then if it is high grab the timer value. If it just went low, then take the current timer value and subtract the previous timer value (the one when the timer went high). You will of course need to check for the timer roll over and handle it. The other 2 channels can be measured with the external interrupt or with the CCP module. If there is enough separation between the channels, you can OR them together and feed them to an external interrupt. Feed this signal into the CCP input as well. On the external interrupt, reset the timer and start the CCP to capture on falling edge. Also look at each channel to see which one is high. Set a variable (index) to represent this channel. On the CCP interrupt, store the CCP value into an array where the element is the index from the external interrupt. This will allow you to measure each pulse. You should make sure that the CCP interrupt has the higher priority since you will most likely be getting the external interrupt and CCP interrupt very close together. Since the pulse widths are relatively long (>1ms), if the 2 interrupts occurring about the same time give you too much trouble, then you could do an edge detect and delay the output and feed this into the external interrupt. Since the delay time is fixed, you would just adjust for it in the results. |
|
|
SherpaDoug
Joined: 07 Sep 2003 Posts: 1640 Location: Cape Cod Mass USA
|
|
Posted: Fri Jun 09, 2006 3:11 pm |
|
|
I have never used RC servos but I have heard that the signal is sent like this:
There is a burst of pulses sent at some regular interval. The width of the first pulse is for the first servo channel where 1ms is one extreem and 2ms is the other extreem. The width of the second pulse controls the second channel. Each successive pulse is for another channel. The gap between bursts reselects the first channel.
So the receiver detects the RF signal and demultiplexes the channels by just counting leading edges, and resetting when there is a gap. That should be an easy job for a PIC. The PIC doesn't need to time how wide the individual pulses are, just count the leading edges and time out when pulses stop comming. _________________ The search for better is endless. Instead simply find very good and get the job done. |
|
|
Mark
Joined: 07 Sep 2003 Posts: 2838 Location: Atlanta, GA
|
|
Posted: Fri Jun 09, 2006 4:40 pm |
|
|
SherpaDoug wrote: | I have never used RC servos but I have heard that the signal is sent like this:
There is a burst of pulses sent at some regular interval. The width of the first pulse is for the first servo channel where 1ms is one extreem and 2ms is the other extreem. The width of the second pulse controls the second channel. Each successive pulse is for another channel. The gap between bursts reselects the first channel.
So the receiver detects the RF signal and demultiplexes the channels by just counting leading edges, and resetting when there is a gap. That should be an easy job for a PIC. The PIC doesn't need to time how wide the individual pulses are, just count the leading edges and time out when pulses stop comming. |
I assumed that the poster was using the outputs of the receiver where they are already "demuxed". There are many kinds of RC controls. AM, FM, digital, analog. We use to race RC buggies and used PCM radios (pulse code modulation). |
|
|
Humberto
Joined: 08 Sep 2003 Posts: 1215 Location: Buenos Aires, La Reina del Plata
|
|
Posted: Fri Jun 09, 2006 6:42 pm |
|
|
SherpaDoug,
I�m agree with the exact and concise explanation of a today's normal operation of multi-channels R/C servos, except in the following paragraph:
Quote: |
The PIC doesn't need to time how wide the individual pulses are, just count the leading edges and time out when pulses stop comming.
|
Yes it is necessary, because in each pulse width there are information regarding the servo position, a pulse length of 1-2ms sent periodically around every 20ms. Counting the leading edges you get the channel number, it�s the "channel addressing" method used in R/C transmitters.
Regarding the poster problem, - I assume not just like Mark - that he is using the decoded TTL signal at the receiver output. I�m assuming that he is using the non decoded TTL signal at the receiver output. If so, I would do it using the INT_EXT plus the L_to_H edge detection feature. The very first task is to determine the end of frame: it is an idle LOW state of 5-7ms. Then with each raising edge, triggering n software up-counters (being n the channels involved) until the next falling edge, repeating this operation for each channel pulse.
At the end of the frame, inside main() it is a matter of examine the counters value to get the corresponding channels info sent.
Humberto |
|
|
Mark
Joined: 07 Sep 2003 Posts: 2838 Location: Atlanta, GA
|
|
Posted: Sat Jun 10, 2006 6:14 am |
|
|
Humberto wrote: | SherpaDoug,
I�m agree with the exact and concise explanation of a today's normal operation of multi-channels R/C servos, except in the following paragraph:
Quote: |
The PIC doesn't need to time how wide the individual pulses are, just count the leading edges and time out when pulses stop comming.
|
Yes it is necessary, because in each pulse width there are information regarding the servo position, a pulse length of 1-2ms sent periodically around every 20ms. Counting the leading edges you get the channel number, it�s the "channel addressing" method used in R/C transmitters.
Regarding the poster problem, - I assume not just like Mark - that he is using the decoded TTL signal at the receiver output. I�m assuming that he is using the non decoded TTL signal at the receiver output. If so, I would do it using the INT_EXT plus the L_to_H edge detection feature. The very first task is to determine the end of frame: it is an idle LOW state of 5-7ms. Then with each raising edge, triggering n software up-counters (being n the channels involved) until the next falling edge, repeating this operation for each channel pulse.
At the end of the frame, inside main() it is a matter of examine the counters value to get the corresponding channels info sent.
Humberto |
If you read his orginal post, he states that he is using 2 CCP's to measure 2 of the pulses and wishes to know how to measure the others. For this reason, I assume with great certainty that he is measure the outputs of the channels. That is, 6 different signals. |
|
|
Humberto
Joined: 08 Sep 2003 Posts: 1215 Location: Buenos Aires, La Reina del Plata
|
|
Posted: Sat Jun 10, 2006 6:54 am |
|
|
Mark wrote:
Quote: |
If you read his orginal post, he states that he is using 2 CCP's to measure 2 of the pulses and wishes to know how to measure the others.
|
In fact he does not know how to do it because he does not know how is codified a multi-channel info carried by an R/C RF signal, therefore conjectures possibilities of erroneous form.
Quote: |
I'm using ccp1/2 to measure the pulse width. With this condition, I only can built 2 tasks.
|
The first part is true, the second is false because the code is carrying information for 3 possible states/tasks:
1.0ms width = LEFT
1.5ms width = CENTER
2.0ms width = RIGTH
Quote: |
I want to built each channel to do different task.
|
Each channel can differentiate in reliable form only 3 defined states, therefore supposition that can be obtained other benefits is nothing but that a desire expression.
Humberto |
|
|
Mark
Joined: 07 Sep 2003 Posts: 2838 Location: Atlanta, GA
|
|
Posted: Sat Jun 10, 2006 1:59 pm |
|
|
Humberto wrote: | Mark wrote:
Quote: |
If you read his orginal post, he states that he is using 2 CCP's to measure 2 of the pulses and wishes to know how to measure the others.
|
In fact he does not know how to do it because he does not know how is codified a multi-channel info carried by an R/C RF signal, therefore conjectures possibilities of erroneous form.
Quote: |
I'm using ccp1/2 to measure the pulse width. With this condition, I only can built 2 tasks.
|
The first part is true, the second is false because the code is carrying information for 3 possible states/tasks:
1.0ms width = LEFT
1.5ms width = CENTER
2.0ms width = RIGTH
Quote: |
I want to built each channel to do different task.
|
Each channel can differentiate in reliable form only 3 defined states, therefore supposition that can be obtained other benefits is nothing but that a desire expression.
Humberto |
The poster is referring to a task as a channel, not a state of a channel. |
|
|
Humberto
Joined: 08 Sep 2003 Posts: 1215 Location: Buenos Aires, La Reina del Plata
|
|
Posted: Sat Jun 10, 2006 3:42 pm |
|
|
Mark wrote:
Quote: |
The poster is referring to a task as a channel, not a state of a channel.
|
The scope and possibilities that offers this type of codification are known widely and have been
clearly exposed in this thread. That does not inhibit that it can be used for any other application
or interpretation.
Humberto |
|
|
|
|
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
|