From: Marq R. <mar...@ya...> - 2007-12-21 19:22:48
|
I have been researching how to input 7-channel RC (radio control) data into the robostix but have come across a problem. I am working with a JR Propo 7-channel spcm receiver and after looking into the information Dave Hylands gives for inputting RC data on the wiki I am not sure I can follow the same procedure. I am unable to find any information on the chips inside my receiver so that I can locate where each channel is output. The largest chip on the receiver has the following 3 part numbers on it: 402082, sc442114, xctab513e Searching the SC part number I came up with a page that said Motorola but was unable to find out anything about it. If anyone knows where I can find some info about this chip that would be great. Because I could not access the receiver like Dave did, I decided that I would read in each channels PWM value and decode it this way. I tried to read the values in on the a2d channels, but could not get anything. I imagine it is because the signal is a PWM value, so I was wondering what abilities do I have to read this signal in? Can I use the GPIO ports to decode this? If so how would I calculate the value? Would I want to look for the time in between each pulse or could I read the average voltage and do my own a2d conversion? Thanks for your help -Marq -- View this message in context: http://www.nabble.com/How-to-read-in-PWM-on-Robostix-tp14460836p14460836.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Dave H. <dhy...@gm...> - 2007-12-21 19:41:04
|
Hi Marq, > I have been researching how to input 7-channel RC (radio control) data into > the robostix but have come across a problem. I am working with a JR Propo > 7-channel spcm receiver and after looking into the information Dave Hylands > gives for inputting RC data on the wiki I am not sure I can follow the same > procedure. I am unable to find any information on the chips inside my > receiver so that I can locate where each channel is output. > The largest chip on the receiver has the following 3 part numbers on it: > 402082, sc442114, xctab513e > Searching the SC part number I came up with a page that said Motorola but > was unable to find out anything about it. If anyone knows where I can find > some info about this chip that would be great. Actually, the chip you'd be looking for would probably be fairly small. Normally it's a shift register. To locate the chip that's the likely candidate, follow the signal trace from the 3-pin connector and find out which chip it goes into. The signal we're looking for is the one that connects to the white or yellow wire on your servo. > Because I could not access the receiver like Dave did, I decided that I > would read in each channels PWM value and decode it this way. I tried to > read the values in on the a2d channels, but could not get anything. I > imagine it is because the signal is a PWM value, so I was wondering what > abilities do I have to read this signal in? Can I use the GPIO ports to > decode this? If so how would I calculate the value? Would I want to look for > the time in between each pulse or could I read the average voltage and do my > own a2d conversion? These kinds of signals are not appropriate for connecting to A2d. You really need to use a GPIO and measure the width of the pulse. Unfortunately, there aren't any convenient ways to detect edges on 7 different signals on the robostix unless you either add some external logic, or use a different chip. The newer atmega chips (like the atmega88) has pin change interrupts on every pin, so it would be pretty straight forward to implement something with that type of processor. -- Dave Hylands Vancouver, BC, Canada http://www.DaveHylands.com/ |
From: Marq R. <mar...@ya...> - 2007-12-26 20:55:53
|
Dave thanks for your help!! I have done some more looking around and I have found a few things. The PWM pin for each channel go to the chip I was refering to earlier and it is a Motorola Freescale chip but could not find any info on it. I emailed Motorola and am hoping they get back to me. I hooked each PWM channel up to an oscilloscope and probed around the chip until I found something that looked like data. Here are a few screen shots of the scope: channels D1-D7 are the PWM signals that would normally go to the servo D0 is the data coming into the chip http://i98.photobucket.com/albums/l249/TurboFiero/test_4.jpg http://i98.photobucket.com/albums/l249/TurboFiero/test_3.jpg http://i98.photobucket.com/albums/l249/TurboFiero/test_2.jpg I also probed around the receiver and found what I think to be the shift register and also a place that I can easily solder to. My problem now is that I need to decode the information. Any ideas on where I can look to try and figure this out? Thanks for your help -Marq Dave Hylands wrote: > > Hi Marq, > >> I have been researching how to input 7-channel RC (radio control) data >> into >> the robostix but have come across a problem. I am working with a JR Propo >> 7-channel spcm receiver and after looking into the information Dave >> Hylands >> gives for inputting RC data on the wiki I am not sure I can follow the >> same >> procedure. I am unable to find any information on the chips inside my >> receiver so that I can locate where each channel is output. >> The largest chip on the receiver has the following 3 part numbers on it: >> 402082, sc442114, xctab513e >> Searching the SC part number I came up with a page that said Motorola but >> was unable to find out anything about it. If anyone knows where I can >> find >> some info about this chip that would be great. > > Actually, the chip you'd be looking for would probably be fairly > small. Normally it's a shift register. > > To locate the chip that's the likely candidate, follow the signal > trace from the 3-pin connector and find out which chip it goes into. > The signal we're looking for is the one that connects to the white or > yellow wire on your servo. > >> Because I could not access the receiver like Dave did, I decided that I >> would read in each channels PWM value and decode it this way. I tried to >> read the values in on the a2d channels, but could not get anything. I >> imagine it is because the signal is a PWM value, so I was wondering what >> abilities do I have to read this signal in? Can I use the GPIO ports to >> decode this? If so how would I calculate the value? Would I want to look >> for >> the time in between each pulse or could I read the average voltage and do >> my >> own a2d conversion? > > These kinds of signals are not appropriate for connecting to A2d. You > really need to use a GPIO and measure the width of the pulse. > Unfortunately, there aren't any convenient ways to detect edges on 7 > different signals on the robostix unless you either add some external > logic, or use a different chip. The newer atmega chips (like the > atmega88) has pin change interrupts on every pin, so it would be > pretty straight forward to implement something with that type of > processor. > > -- > Dave Hylands > Vancouver, BC, Canada > http://www.DaveHylands.com/ > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > -- View this message in context: http://www.nabble.com/How-to-read-in-PWM-on-Robostix-tp14460836p14506364.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Richard T. S. <rs...@pa...> - 2007-12-26 22:24:20
|
Marq Rasmussen wrote: > Dave thanks for your help!! > > I have done some more looking around and I have found a few things. The PWM > pin for each channel go to the chip I was refering to earlier and it is a > Motorola Freescale chip but could not find any info on it. I emailed > Motorola and am hoping they get back to me. > > I hooked each PWM channel up to an oscilloscope and probed around the chip > until I found something that looked like data. Here are a few screen shots > of the scope: > channels D1-D7 are the PWM signals that would normally go to the servo > D0 is the data coming into the chip > http://i98.photobucket.com/albums/l249/TurboFiero/test_4.jpg > http://i98.photobucket.com/albums/l249/TurboFiero/test_3.jpg > http://i98.photobucket.com/albums/l249/TurboFiero/test_2.jpg > > I also probed around the receiver and found what I think to be the shift > register and also a place that I can easily solder to. My problem now is > that I need to decode the information. Any ideas on where I can look to try > and figure this out? > > Thanks for your help > -Marq > > > Even if you could get interrupts on both edges of the pulses and could somehow timestamp the interrupts to calculate pulse width, I'm not sure what kind of resolution you would get. Interrupt latency would probably get in the way. Maybe you could run the pulse into an integrator (1k resistor from signal to 1 ufd capacitor to ground, measure voltage across the capacitor) and, assuming a 5V pulse voltage and a 20 mS rep time, a 1.5 mS (center) pulse would give (1.5 / 20) * 5 or about 0.375V. Not especially useful. But, let's assume that 2.0 mS is as wide as the pulses get. Then you would get 0.5V and you could use an op amp to multiply by 10. Your voltages would vary between (1.0 / 20) * 5 * 10 (2.5V) up to (2.0 / 20) * 5 * 10 (5.0V). Now you can run them to the A/D inputs. As the pulse varies from 1.0 mS to 2.0 mS, the voltage varies from 2.5V to 5.0V. There is also a scheme to offset and rescale all in one operation using a single op amp. See "Op Amps For Everyone" Chapter 4 http://focus.ti.com/lit/an/slod006b/slod006b.pdf Now you can have 0V at the minimum pulse and 5V at the maximum. Given the high input impedance of the op amp circuit, you don't need to worry about the discharge of the capacitor into the op amp. The pulse high-low ratio is the only thing changing the voltage on the capacitor. You may want to experiment with the values for the resistor/capacitor. I just picked numbers... The low output impedance of the op amp is perfect for driving the A/D inputs. Just a thought... Richard |
From: Dave H. <dhy...@gm...> - 2007-12-27 01:58:54
|
Hi Marq, > Dave thanks for your help!! > > I have done some more looking around and I have found a few things. The PWM > pin for each channel go to the chip I was refering to earlier and it is a > Motorola Freescale chip but could not find any info on it. I emailed > Motorola and am hoping they get back to me. > > I hooked each PWM channel up to an oscilloscope and probed around the chip > until I found something that looked like data. Here are a few screen shots > of the scope: > channels D1-D7 are the PWM signals that would normally go to the servo > D0 is the data coming into the chip > http://i98.photobucket.com/albums/l249/TurboFiero/test_4.jpg > http://i98.photobucket.com/albums/l249/TurboFiero/test_3.jpg > http://i98.photobucket.com/albums/l249/TurboFiero/test_2.jpg > > I also probed around the receiver and found what I think to be the shift > register and also a place that I can easily solder to. My problem now is > that I need to decode the information. Any ideas on where I can look to try > and figure this out? Not sure. I don't see the pattern myself. -- Dave Hylands Vancouver, BC, Canada http://www.DaveHylands.com/ |
From: Dave H. <dhy...@gm...> - 2007-12-28 17:52:43
|
Hi Marq, > > I hooked each PWM channel up to an oscilloscope and probed around the chip > > until I found something that looked like data. Here are a few screen shots > > of the scope: > > channels D1-D7 are the PWM signals that would normally go to the servo > > D0 is the data coming into the chip > > http://i98.photobucket.com/albums/l249/TurboFiero/test_4.jpg > > http://i98.photobucket.com/albums/l249/TurboFiero/test_3.jpg > > http://i98.photobucket.com/albums/l249/TurboFiero/test_2.jpg > > > > I also probed around the receiver and found what I think to be the shift > > register and also a place that I can easily solder to. My problem now is > > that I need to decode the information. Any ideas on where I can look to try > > and figure this out? It may be that your receiver uses PCM encoding. This page has a tiny amount of information: <http://raph.people.8d.com/arm-linux-notes.html> And going back to your original post, I see that you're using an SPCM receiver. This page has some more details: <http://www.aerodesign.de/peter/2000/PCM/PCM_PPM_eng.html#Anker144351> After a bit more research, I discovered a package called SmartPropo. An older version, which includes source code (for Windows) is available here: <n.ethz.ch/student/mmoeller/fms/alpha/smartpropoplus.zip> Apparently, it's been converted into a sourceforge project, although this doesn't seem to have any source. <https://sourceforge.net/projects/smartpropoplus> This seems to be the home page: <http://www.geocities.com/shaul_ei/SmartPropoPlus.html> and it has links to the latest sources (Dec 2007) Some other random links which seem to relevant: <http://www.runryder.com/helicopter/t229035p1/> -- Dave Hylands Vancouver, BC, Canada http://www.DaveHylands.com/ |
From: Marq R. <mar...@ya...> - 2007-12-28 21:24:00
|
Dave, Thanks a ton for your help. I have been researching and have came across the same stuff. I have downloaded the SmartPropo program and tried it with my remote. I tried to configure the remote to the flight simulator but it cant seem to make sense of the data the remote is giving it. After playing with it for a while I could not get it to work and decided to go a different direction. Also looking into their web page some more I think they only support the older JR pcm coding. I have found an older style receiver the uses the ppm setup and changed my remote to work with it. Reading your code you say that you want to give the clock signal from the receiver to robositx. How can you tell what the remote it doing from a clock signal? Reading the third document that you reference on the wiki and in the RCInput.h file figure 29 signal A is only a clock and does not correspond to the input data. I was under the assumption that I would want to read in signal E as in figure 30 in the same paper or signal D0 from a scope reading I collected for this receiver: http://i98.photobucket.com/albums/l249/TurboFiero/pin_8.jpg I am also trying to understand the code in the RCInput.c file and am having a hard time seeing what is going on. Is there somewhere I can read about some of the variables/functions you are using. I would have a hard time writing code like this, but need to learn how.... any suggestion on where to start? I have got the RC-Test code up and working with 2 channels and am working on getting it reading all 6. I have changed the Num_Channels to 6 and a couple of the conditional statements from 2 to 6 but it is still only reading 2 channels. Do I need to change the Num_Avg_Samples to a different value? I am not using a LCD and change all of the LCD print statements to regular ones and am using serial_log to view the data. Thanks -Marq Dave Hylands wrote: > > Hi Marq, > >> > I hooked each PWM channel up to an oscilloscope and probed around the >> chip >> > until I found something that looked like data. Here are a few screen >> shots >> > of the scope: >> > channels D1-D7 are the PWM signals that would normally go to the servo >> > D0 is the data coming into the chip >> > http://i98.photobucket.com/albums/l249/TurboFiero/test_4.jpg >> > http://i98.photobucket.com/albums/l249/TurboFiero/test_3.jpg >> > http://i98.photobucket.com/albums/l249/TurboFiero/test_2.jpg >> > >> > I also probed around the receiver and found what I think to be the >> shift >> > register and also a place that I can easily solder to. My problem now >> is >> > that I need to decode the information. Any ideas on where I can look to >> try >> > and figure this out? > > It may be that your receiver uses PCM encoding. This page has a tiny > amount of information: > <http://raph.people.8d.com/arm-linux-notes.html> > > And going back to your original post, I see that you're using an SPCM > receiver. > This page has some more details: > <http://www.aerodesign.de/peter/2000/PCM/PCM_PPM_eng.html#Anker144351> > > After a bit more research, I discovered a package called SmartPropo. > An older version, which includes source code (for Windows) is > available here: > <n.ethz.ch/student/mmoeller/fms/alpha/smartpropoplus.zip> > > Apparently, it's been converted into a sourceforge project, although > this doesn't seem to have any source. > <https://sourceforge.net/projects/smartpropoplus> > > This seems to be the home page: > <http://www.geocities.com/shaul_ei/SmartPropoPlus.html> > and it has links to the latest sources (Dec 2007) > > Some other random links which seem to relevant: > <http://www.runryder.com/helicopter/t229035p1/> > > -- > Dave Hylands > Vancouver, BC, Canada > http://www.DaveHylands.com/ > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > -- View this message in context: http://www.nabble.com/How-to-read-in-PWM-on-Robostix-tp14460836p14531633.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Marq R. <mar...@ya...> - 2007-12-29 01:35:34
|
Dave, After doing more research I understand the RC-Test program much better. My problem is that I don't understand how gPulsewidth, gPulseAggr and gPulseIdx get initialized or where PulseDetected is called from. Is RC-Test calling/using functions from RCinput? If so where is it being called? Thanks Marq Marq Rasmussen wrote: > > Dave, > > Thanks a ton for your help. I have been researching and have came across > the same stuff. I have downloaded the SmartPropo program and tried it with > my remote. I tried to configure the remote to the flight simulator but it > cant seem to make sense of the data the remote is giving it. After playing > with it for a while I could not get it to work and decided to go a > different direction. Also looking into their web page some more I think > they only support the older JR pcm coding. > > I have found an older style receiver the uses the ppm setup and changed my > remote to work with it. Reading your code you say that you want to give > the clock signal from the receiver to robositx. How can you tell what the > remote it doing from a clock signal? Reading the third document that you > reference on the wiki and in the RCInput.h file figure 29 signal A is only > a clock and does not correspond to the input data. I was under the > assumption that I would want to read in signal E as in figure 30 in the > same paper or signal D0 from a scope reading I collected for this > receiver: http://i98.photobucket.com/albums/l249/TurboFiero/pin_8.jpg > I am also trying to understand the code in the RCInput.c file and am > having a hard time seeing what is going on. Is there somewhere I can read > about some of the variables/functions you are using. I would have a hard > time writing code like this, but need to learn how.... any suggestion on > where to start? > > I have got the RC-Test code up and working with 2 channels and am working > on getting it reading all 6. I have changed the Num_Channels to 6 and a > couple of the conditional statements from 2 to 6 but it is still only > reading 2 channels. Do I need to change the Num_Avg_Samples to a > different value? I am not using a LCD and change all of the LCD print > statements to regular ones and am using serial_log to view the data. > > Thanks > -Marq > > > Dave Hylands wrote: >> >> Hi Marq, >> >>> > I hooked each PWM channel up to an oscilloscope and probed around the >>> chip >>> > until I found something that looked like data. Here are a few screen >>> shots >>> > of the scope: >>> > channels D1-D7 are the PWM signals that would normally go to the servo >>> > D0 is the data coming into the chip >>> > http://i98.photobucket.com/albums/l249/TurboFiero/test_4.jpg >>> > http://i98.photobucket.com/albums/l249/TurboFiero/test_3.jpg >>> > http://i98.photobucket.com/albums/l249/TurboFiero/test_2.jpg >>> > >>> > I also probed around the receiver and found what I think to be the >>> shift >>> > register and also a place that I can easily solder to. My problem now >>> is >>> > that I need to decode the information. Any ideas on where I can look >>> to try >>> > and figure this out? >> >> It may be that your receiver uses PCM encoding. This page has a tiny >> amount of information: >> <http://raph.people.8d.com/arm-linux-notes.html> >> >> And going back to your original post, I see that you're using an SPCM >> receiver. >> This page has some more details: >> <http://www.aerodesign.de/peter/2000/PCM/PCM_PPM_eng.html#Anker144351> >> >> After a bit more research, I discovered a package called SmartPropo. >> An older version, which includes source code (for Windows) is >> available here: >> <n.ethz.ch/student/mmoeller/fms/alpha/smartpropoplus.zip> >> >> Apparently, it's been converted into a sourceforge project, although >> this doesn't seem to have any source. >> <https://sourceforge.net/projects/smartpropoplus> >> >> This seems to be the home page: >> <http://www.geocities.com/shaul_ei/SmartPropoPlus.html> >> and it has links to the latest sources (Dec 2007) >> >> Some other random links which seem to relevant: >> <http://www.runryder.com/helicopter/t229035p1/> >> >> -- >> Dave Hylands >> Vancouver, BC, Canada >> http://www.DaveHylands.com/ >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by: Microsoft >> Defy all challenges. Microsoft(R) Visual Studio 2005. >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >> _______________________________________________ >> gumstix-users mailing list >> gum...@li... >> https://lists.sourceforge.net/lists/listinfo/gumstix-users >> >> > > -- View this message in context: http://www.nabble.com/How-to-read-in-PWM-on-Robostix-tp14460836p14533909.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Dave H. <dhy...@gm...> - 2007-12-29 07:46:18
|
Hi Marq, > After doing more research I understand the RC-Test program much better. My > problem is that I don't understand how gPulsewidth, gPulseAggr and gPulseIdx > get initialized or where PulseDetected is called from. > > Is RC-Test calling/using functions from RCinput? If so where is it being > called? Yeah - there aren't many functions though. The 3 functions are: RCI_Init, RCI_SetPulseCallback, RCI_SetMissingPulseCallback All 3 functions are called from within main just before interrupts are enabled. Everything else is interrupt driven. There is one interrupt which is assigned to a timer overflow, and one interrupt is assigned to rising edges on the clock. These interrupts then make calls to the callbacks registered through the Callback functions. -- Dave Hylands Vancouver, BC, Canada http://www.DaveHylands.com/ |
From: Marq R. <mar...@ya...> - 2007-12-31 19:13:05
|
Dave, I have been trying to read up on interrupts and how they are called/setup in the code, but haven't found much that seems to follow the way you have codded the RC-Test program. Any suggestions on where to read about interrupts? I have added print statements to see what each variable is in the PulseDected function and am trying to modify it to read 6 channels instead of 2. I am unsure what the variables gPulseAggr and gPulseWidth do for the program/ what you are using their values to calculate. Is the variable Num_Avg_Samples have to do with the clock rate you are running the counter at to figure out the pulse width? Thanks for your help Marq Dave Hylands wrote: > > Hi Marq, > >> After doing more research I understand the RC-Test program much better. >> My >> problem is that I don't understand how gPulsewidth, gPulseAggr and >> gPulseIdx >> get initialized or where PulseDetected is called from. >> >> Is RC-Test calling/using functions from RCinput? If so where is it being >> called? > > Yeah - there aren't many functions though. The 3 functions are: > RCI_Init, RCI_SetPulseCallback, RCI_SetMissingPulseCallback > > All 3 functions are called from within main just before interrupts are > enabled. > > Everything else is interrupt driven. There is one interrupt which is > assigned to a timer overflow, and one interrupt is assigned to rising > edges on the clock. > > These interrupts then make calls to the callbacks registered through > the Callback functions. > > -- > Dave Hylands > Vancouver, BC, Canada > http://www.DaveHylands.com/ > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > -- View this message in context: http://www.nabble.com/How-to-read-in-PWM-on-Robostix-tp14460836p14561175.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Dave H. <dhy...@gm...> - 2007-12-31 19:38:11
|
Hi Marq, > I have been trying to read up on interrupts and how they are called/setup in > the code, but haven't found much that seems to follow the way you have > codded the RC-Test program. Any suggestions on where to read about > interrupts? This page: <http://members.shaw.ca/climber/avrinterrupts.html> has a decent introduction. Note that the use of SIGNAL and INTERRUPT macros is now deprecated, and the ISR macro is used instead. This is the official avr-libc documentation: <http://www.nongnu.org/avr-libc/user-manual/group__avr__interrupts.html> > I have added print statements to see what each variable is in the > PulseDected function and am trying to modify it to read 6 channels instead > of 2. I am unsure what the variables gPulseAggr and gPulseWidth do for the > program/ what you are using their values to calculate. Sometimes, doing things like printing from an interrupt handler can cause problems. It depends on how the print routine has been written. Since the pulse widths come from an analog source, they will have some jitter. gPulseWidth and gPulseAggr are used to average out the pulse widths. Tweaking NUM_AVG_SAMPLES will depend on what you're using it for. Too big or too small both have their own set of problems. The way gPulseWidth and gPuleAggr works is that gPulseWidth is like a circular buffer of pulse widths (in particular there are NUM_AVG_SAMPLES entries in the circular buffer). gPulseAggr maintains the aggregate, or sum of the pulse widths contained in the circular buffer. So each time a new pulse width comes in, we subtract out the pulse width that is going to be overwritten, and add in the new pulse width being added. That way, at any given time we can compute the average by simply dividing the aggregate by the number of samples. > Is the variable Num_Avg_Samples have to do with the clock rate you are > running the counter at to figure out the pulse width? It's more about how responsive/twitchy you want your system to be. Larger values make it slower to respond to changes from the transmitter. Too large, and everything feels unresponsive and sluggish. Smaller values make it respond quicker. Too quick, and it becomes twitchy. Since most transmitters send about 50 updates/second, NUM_AVG_SAMPLES of 8 causes about 160 milliseconds of delay before a change is fully reflected. -- Dave Hylands Vancouver, BC, Canada http://www.DaveHylands.com/ |
From: Marq R. <mar...@ya...> - 2008-01-01 02:08:26
|
Dave, Thanks for the links, those are great and you might want to add those to the wiki with the RC-Imput example. I now have all 6 channels working! -Marq Dave Hylands wrote: > > Hi Marq, > >> I have been trying to read up on interrupts and how they are called/setup >> in >> the code, but haven't found much that seems to follow the way you have >> codded the RC-Test program. Any suggestions on where to read about >> interrupts? > > This page: <http://members.shaw.ca/climber/avrinterrupts.html> has a > decent introduction. > > Note that the use of SIGNAL and INTERRUPT macros is now deprecated, > and the ISR macro is used instead. > > This is the official avr-libc documentation: > <http://www.nongnu.org/avr-libc/user-manual/group__avr__interrupts.html> > >> I have added print statements to see what each variable is in the >> PulseDected function and am trying to modify it to read 6 channels >> instead >> of 2. I am unsure what the variables gPulseAggr and gPulseWidth do for >> the >> program/ what you are using their values to calculate. > > Sometimes, doing things like printing from an interrupt handler can > cause problems. It depends on how the print routine has been written. > > Since the pulse widths come from an analog source, they will have some > jitter. gPulseWidth and gPulseAggr are used to average out the pulse > widths. Tweaking NUM_AVG_SAMPLES will depend on what you're using it > for. Too big or too small both have their own set of problems. > > The way gPulseWidth and gPuleAggr works is that gPulseWidth is like a > circular buffer of pulse widths (in particular there are > NUM_AVG_SAMPLES entries in the circular buffer). > > gPulseAggr maintains the aggregate, or sum of the pulse widths > contained in the circular buffer. So each time a new pulse width comes > in, we subtract out the pulse width that is going to be overwritten, > and add in the new pulse width being added. > > That way, at any given time we can compute the average by simply > dividing the aggregate by the number of samples. > >> Is the variable Num_Avg_Samples have to do with the clock rate you are >> running the counter at to figure out the pulse width? > > It's more about how responsive/twitchy you want your system to be. > Larger values make it slower to respond to changes from the > transmitter. Too large, and everything feels unresponsive and > sluggish. Smaller values make it respond quicker. Too quick, and it > becomes twitchy. > > Since most transmitters send about 50 updates/second, NUM_AVG_SAMPLES > of 8 causes about 160 milliseconds of delay before a change is fully > reflected. > > -- > Dave Hylands > Vancouver, BC, Canada > http://www.DaveHylands.com/ > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > -- View this message in context: http://www.nabble.com/How-to-read-in-PWM-on-Robostix-tp14460836p14563913.html Sent from the Gumstix mailing list archive at Nabble.com. |