next topic »

[on:]

Hi
People who needed RC for their projects know that you can use pulsein() to read the signal on any pin you like.
As Duane points out very clearly on his website pulsein() is not something you want to use in a "real life" project.
see following posts of duane that explain this principle
http://rcarduino.blogspot.be/2012/01/how-to-read-rc-receiver-with.html
http://rcarduino.blogspot.be/2012/01/how-to-read-rc-receiver-with_20.html

As the excellent code duane provides is impacting the sketch readaility I decided to put the code in a library. Using my 6 channel RC receiver I made following snapshots of my arduino scope
Here with the duemilanove on A0 til A5

Here with the mega on A8 til A13

You can see peeks on both images but these can easily be ignored. you can also see that all 6 channels are changing.
The library is available at github https://github.com/jantje/libraries
I included the code I used for the mega in the library as an example.
As I'm using eclipse I did not provide a keyword.txt. Feel free to fork the repository and add a keyword.txt.
If you like it feel free to use it.
If you don't like it feel free to provide better code.

Best regards
Jantje

The example code extract

Code:

#define NUM_RC_CHANNELS 6 //You need to specify how many pins you want to use
#include "PinChangeInt.h"  //If you need pinchangeint you need to include this header
const uint8_t RC_Channel_Pin[NUM_RC_CHANNELS]={  A8,A9,A10,A11,A12,A13};//Here I specify I want to listen to pins A8 to A13 of my mega

uint16_t RC_Channel_Value[NUM_RC_CHANNELS]; //This variable will contain the values read from the RC signal
#include "RCLib.h" //This include needs all declarations above. Do not try to move it up or it won't compile


void setup()
{
  Serial.begin(57600);
  SetRCInterrupts(); //This method will do all the config foe you.
                    //Note some problems will be reported on the serial monitor
}

void loop()
{
  int flag;
  if(flag=getChannelsReceiveInfo()) //Here you read the RC flag contains all the channels that have a response
                                    // see duane's excellent articles on how this works
  {
     //do your stuff here
  }

}

[Reply #1 on:]

You can see peeks on both images but these can easily be ignored.

What are they peaks, how do you know they are they safe to ignore, whats causing them ?

EDIT - I think I know, you need to take another look at the way you are accessing shared values.

Duane B

[Reply #2 on:]

EDIT - I think I know, you need to take another look at the way you are accessing shared values.

Can I buy a vowel? 
Best regards
Jantje

[Reply #3 on:]

EDIT - I think I know, you need to take another look at the way you are accessing shared values.

Eh ?

Duane B

[Reply #4 on:]

EDIT - I think I know, you need to take another look at the way you are accessing shared values.

Can I buy a vowel? 
Best regards
Jantje

Duane
I mean can you give me a hint on what I could take another look at?
Best regards
Jantje

[Reply #5 on:]

Hi,
   I had a look this morning and thought it might be to do with the way you are using the shared variables, but I have had another look and your usage looks fine.

   From what I can see, the peaks are always positive, a problem in variable handling would usually generate some negative peaks as well.

   This makes me think that at some point you are blocking interrupts for too long and a pulse edge is getting missed, your pulse will then be as long as the entire frame - does that look consistent with the full graph ?

  Duane B

rcarduino.blogspot.com

[Reply #6 on:]

Duane
I investigated the peeks a bit more in detail and it deemed on me this is probably cause by the oscilloscope (or transport to) and not the interrupt or other arduino code.
So I tried this code

Code:

if(flag=getChannelsReceiveInfo())
{
plot(RC_Channel_Value);
for (int var = 0; var < NUM_RC_CHANNELS; ++var) {
if(RC_Channel_Value[var]>30000)
{
Serial.println(RC_Channel_Value[var]);
}

}
}

No prints were generated even though the oscilloscope showed values of +30000.
As the oscilloscope is brand new and I only tested it with values up to 1025 I can safely conclude the peeks are not on the arduino.

Best regards
Jantje

[Reply #7 on:]

After more investigation I found the oscilloscope is working as it should.
The value received from the interrupt is around 6788 which is smaller than the 30000 trigger in the code I posted before.
I changed the code to trigger on 3000 and now it logs values.

I tested this without the pinchangeint library and 4 RC channels and I do not see the peeks.
I tested this with the pinchangeint library and 3 RC channels and I see the peeks.
So my conclusion is that the peeks are caused by the overhead of code. This makes me think that some RC peek down signals are delayed which causes values bigger than 3000 are received. I don't think a RC signals are missed because that would give values in the area of multiples of 20000. So I expect there is some delay somewhere caused by pinchangeint library or a combination of my lib and pinchangeint.

As to the solution: I think ignoring the value is safe because I can only get this value when I move to a certain position (a bit above but close to center) when I get out of the peak it continues as if the peek was never there.
It may be related to my RC receiver who may fire all the channels at the same time making that similar values on multiple channels are hard to detect because they all trigger at the same time. I haven't done any physical measurements on the behavior of my receiver to confirm this but given it's intended usage it seems logical all channels would fire at nearly the same time.

Best regards
Jantje