Help Interfacing Futaba RC Receiver With Arduino Pro Mini

Dear Arduino forums,

I purchased an Arduino Pro Micro (5V) and a TB6612FNG motor driver for my class project (I'm a mechanical engineering major at UMBC, and the project is for my ENME304 machine design class). The problem I am having is reading signal from the Futaba receiver.

I used this code:

int pin = 5;
int duration;

void setup()
{
  pinMode(pin, INPUT);
  Serial.begin(9600);
}

void loop()
{
  duration = pulseIn(pin, HIGH);
  Serial.println(duration);
  delay(100);
}

And received this readout:

1492
1498
1922
1492
1498
1506
1801
2
1499
1506
2062
8
1499
1505
2139
3
1499
1514
2161
1
1492
1513
1742
1
1493
1570
1624
1
1493
1628
1597
1
1499
1637
1506
1
1498
1594
1509
1
1493
1594
1513
1
1492
1560
1506
1492
1492
1631
1492

The Futaba receiver was putting out a value of 1500. As you can see, it is usually in the neighborhood, but occasionally it returns values far outside the desired range. I tried using if statements to only show the values between 1000-2000 (the limits of the RC controller I'm using), but I still got occasional large jumps from the desired value. For example, when the stick was set for 1500, there would be jumps to values like 1700. I'm using this with the motor driver to control a motor which requires precise operation, so I can't have these deviations.

So my question is: what should I do? I know that interrupts are the better way to listen to an RC receiver, but I'm simply too inexperienced to figure them out without help. All the interrupt code for RC I've seen isn't for the Pro Micro, and I can't figure out which pins (if any) work for interrupt on the Micro. That, and the code is usually very involved and over my head. So please, any help would be greatly appreciated!

The code looks as if it ought to work. Can you get access to a 'scope and see what signal is actually being received at the Arduino? It's conceivable the problem is eternal to the Arduino and it's giving you an accurate measurement of the pulse it's receiving.

If the problem turns out to be mis-reading by the Arduino then there are a few things you can try:

Wait for the serial port output to clear before you try to capture a pulse. By my reckoning 100 ms should just about be sufficient time, but as a sanity check you could try increasing it to e.g. 500 ms and see whether that affects the behaviour.

Assuming that the spurious results are relatively isolated, you could perform smoothing in software to reduce the effect. An exponentially decaying average is easy to code and would work well in this situation:

smoothed = (0.9 * smoothed) + (0.1 * newValue);

Dear Peter,

Thank you very much for your reply. I will probably be able to get my hands on an oscilloscope on Monday, so I'll check it out. My inclination is that the receiver's isn't at fault though, I've used this receiver before for multicopters and the radio window in Arducopter showed the reported signal value. Who knows though, best to try everything!

Increasing the delay had no effect. However I tried the smoothign method you recommended, and it seems to help!

int pin = 5;
int duration;
int newValue;
int smoothed;

void setup()
{
  pinMode(pin, INPUT);
  Serial.begin(9600);
}

void loop()
{
  duration = pulseIn(pin, HIGH);
  if(duration < 2100)
  {
    if(duration > 900)
    {
      newValue = map(duration,2000,1000,255,-255);
      smoothed = (0.95 * smoothed) + (0.05 * newValue);
      Serial.println(smoothed);
      delay(10);
    }
  }
}

I added filtering for values outside the expected range, mapped the values to +-255 (the output values I'll be sending to the motor driver), and did the smoothing function. (I'm very new to Arduino code, so please excuse my coding. MATLAB is more my cup of tea!)

At rest, the serial window consistently reported 0 (good!), with occasional forays into + or - 1, with brief relatively infrequent spikes never going above 4! That is close enough for me. Similar behavior for any stick position. I think that the 95% 5% smoothing should work out fine, it will speed up considerably once I no longer have that delay in there for the benefit of the serial monitor.

So thank you very much Peter, this took my setup from a no-go to a, well, ready to go. I'll keep this open for now in case anyone has any more insight.