Go Down

Topic: radio control reciever spektrum ar6100 ar6200 signal noise (Read 7247 times) previous topic - next topic



Glad you found the code useful, don't forget to go back and look at the 'confidence' algorithm before connecting a servo or ESC.

I found that without the confidence I would be sending 10 or 20 commands to the servo every second, this caused a lot of unnecessary jitter. I am not sure whether this jitter is caused by the stream of small changes or whether at some low level the new command resets the signal timing - either way its easy to avoid with the 'confidence' trick.

I thought you mentioned that you are using a Mega which has sufficient interrupt pins for your purpose, I am using a UNO which does not have enough pins for my project, luckily there are a few libraries which enable the underlying ATMega interrupt functionality on any Arduino PIN. I will be investigating PCInt for this purpose, you might also want to have a look over it, its doing something similar to your interrupt mapping but possibly more efficiently (note I have not looked at it in detail yet, so maybe it isn't )

I would also suggest that you change the method you use to track which PIN a new signal is available on. If you are using 8 or less channels, a single BYTE combined with BIT masks will allow you to track 8 channels, this is more efficient that using 8 Bytes and array operations. Its trivial, but to those of us in the UNO world, its a criminal waste of memory.

Example of bit flags-

BYTE bChannelActive = 0;
#define CHANNEL1_ACTIVE 0x1
#define CHANNEL2_ACTIVE 0x10
#define CHANNEL3_ACTIVE 0x100
#define CHANNEL4_ACTIVE 0x1000
etc etc

if(bChannelActive) // if its anything but 0 we have a new signal
if(bChannelActive & CHANNEL1_ACTIVE)
   // channel 1 was active
// here I am using if to give every channel equal priority, we could use if else to implement a simple priority system
if(bChannelActive & CHANNEL2_ACTIVE)
   // channel 2 was active   

You could also get rid of the ulEndPeriod array as well, its only used as a temporary holder for the end period value in calcInput, if you make it a locally declared variable there, thats another 20 Bytes saved -

in the calc input function -

unsigned long ulEndPeriod = micros();

I believe (need to read up to be sure) volatile variables are slower to operate on so by removing the array references and the volatile keyword, we get two optimisations in one.

This lot might not matter to you much at the moment, but by the time you have code managing 6 channels you will wish you started with size and speed in mind - hope it helps

Good call on the bInit by the way,

Read this
then watch this



I like the changes you propose, particularly with the ulEndPeriod. That should be a local.

I'll have to spend a little more time thinking about the binary register. What I'm passing to the Interrupt handler is the Interrupt index which I use as the index for multiple arrays (although probably more than necessary). I'll have to spend some time in front of the code to see what I could do to optimize.

ThanX for the feedback.

I'll also look into PCint.
Arduino Beginner, but I catch on quick!


Jan 09, 2012, 07:45 pm Last Edit: Jan 09, 2012, 09:16 pm by prdufresne Reason: 1
I was looking at your example with bit flags, and I'm not sure I can save any memory with that.

The way I structured the program, I'm passing the active channel to the calcInput() function using a constant, which would be replaced during compilation. Once we get to calcInput, the channel (rxChannel) and interrupt (rxInt) identifier variables are local variables. Since I'm using rxInt to index the arrays, I don't think I could use bit flags without increasing the code a fair bit, and since they are local, I'm not sure I really gain any space.

I did modify the code to remove the ulEndPeriod Array. I replaced it with a local variable ulTimeStamp that stores the value of micros() at the start of the function and assigns it either to the ulStartPeriod[] or uses it to calculate the pulse width depending on the condition. Seems more efficient and more accurate to do it this way.

The only arrays I have remaining are:

nChannelIn[] - This stores the pusle width that was calculated for each channel.

ulStartPeriod[] - This stores the starting time stamp for each interrupt. I understand that with most R/C systems, the signal pulses are sequential and that I could probably get away with using only one variable for this, but I've read that some of the newer spread spectrum radios don't observe this convention and I could be receiving overlapping signals. This seemed to be the safer approach since I'm using a spread spectrum radio system.

bNewSignal[] - Used to confirm a new signal was received for each channel.

I'll start digging into PCint now.

EDIT: Take a look at the following link:

I think this will simplify your need for additional interrupts.

Arduino Beginner, but I catch on quick!


I pulled out some Futaba 1270's and dug for quite a while to find a matching tx and rx crystal pair. The futaba and hitech recievers do not provide a ground test port, on the JR radios have this feature. When they correct the site issues and I remember, I'll upload some screenshots of the waveforms if you all would like. You could pack alot of additional control data past the 7th servo signal and well before the frame boundary.


We finally received some cables we were waiting for to connect all the Rx channels and servos to the Arduino Mega. What we discovered is that the I/O shield isolates the Vcc for the various sensor/servo ports from the +5V of the Arduino. As a result, the ESC was able to provide power for the Rx and the other servos as it would if the Arduino wasn't there, but that it won't power the Arduino.

Fortunately, the ESC has a auxilliary power output connector which I was able to wire into the barrel plug on the Arduino Mega. The Mega takes care of regulating that to +5V.

I have noticed an increase in servo jitter since connecting the ESC. I'm further assuming that noise is on the Vcc line, as it is affecting some of the other servos. I'm debating whether to try to filter it or simply write the code to smooth it out. It seems as though I'll either have to sacrifice responsiveness or accuracy if I do it in code.

Other than that, my echo code takes what it receives from the radio, and passes it on to the servos. This is exactly what the robot will do in manual mode, so that's half the battle. Once we smooth out the signals, we can start on the autonomous functions.

Let me know what you think.

Arduino Beginner, but I catch on quick!


   I would work on eliminating issues at the hardware level rather than code around them. In my projects I have added decoupling capacitors, .01 .1 1 and 47uf across the power into the arduino, probably overkill but seems to help.

Duane B


Read this
then watch this


Go Up

Please enter a valid email to subscribe

Confirm your email address

We need to confirm your email address.
To complete the subscription, please click the link in the email we just sent you.

Thank you for subscribing!

via Egeo 16
Torino, 10131