Dealing with IR polling

I would like to start and stop a project using an IR sensor. It seems to me that I need two processors. One processor does the dedicated IR polling and sets a flag when commands arrive and the other processor runs the project. What would be the ideal Arduino board to poll the IR sensor and interface with the Uno? The board should have a small form factor and draw low power.

It seems to me that I need two processors.

No everyone else does it with one processor. See:-
http://playground.arduino.cc/Code/InfraredReceivers

What would be the ideal Arduino board to poll the IR sensor and interface with the Uno?

The Uno nothing else needed. Or in fact any other Arduino board.

OK, that may work. I also have a processor timing limitation. I'm taking a measurement every 5 ms. How fast is the IR polling routine?

Gerry48:
How fast is the IR polling routine?

That depends on your sensor...

How does the speed of the polling routine depend on the sensor used? What parameter in the datasheet should I be looking at?

It depends on the IR protocol you use, there are lots of them. Typically there are bursts of 38KHz pulses and gaps. Depending on the length of an encoded message will depend on how long it takes.
The receiver normally demodulates this into a solid logic signal and your decoding system uses edges to determine the pattern in the IR.

I'm taking a measurement every 5 ms.

Any idea what you are doing with these measurements? Were are they being stored and what are you going to do with them?

It depends on the IR protocol you use, there are lots of them. Typically there are bursts of 38KHz pulses and gaps.

Is the data rate also 38kHz? I don't have any idea how many bits are sent when the remote button is depressed. Perhaps 40? Would that tie-up the processor by 40/38kHz = 1 ms?

My project is pretty much complete. I'm using an accelerometer to record x,y,z g-forces every 5 ms into ram. When the measurement is stopped, the data is transferred from ram to SD memory. Currently I start and stop measurements with a toggle switch that's on a 10 ft long cable. It would be great to do that wireless.

The data goes into excel and FFT is calculated to get frequency and magnitude of the oscillations. 5 ms is the time base for the FFT calculation. It must be kept constant. I could probably handle a 1 ms processor delay, but anything longer could undermine the 5 ms time base. That's why I was thinking of using a dedicated processor (something like LilyPad) for receiving IR data.

s the data rate also 38kHz?

No that is the modulation carrier frequency.

Would that tie-up the processor by 40/38kHz = 1 ms?

It depends on how you decode it, not necessarily.
But if you only send stuff when you want to stop the recording of data why is it a problem of how long it takes to receive the message. You only process it when it is coming in not when it is not. You can arrange the incoming to trip an interrupt to start the process so it does not consume any CPU cycles until the message starts to arrive.

That’s why I was thinking of using a dedicated processor (something like LilyPad) for receiving IR data.

You would still have the problem of communicating between the two processors.

But if you only send stuff when you want to stop the recording of data why is it a problem of how long it takes to receive the message.

That's correct. It shouldn't be any problem But here's the deal. I'm getting the IR sensor & remote on a slow boat from China. I couldn't wait, so I took a power saw to an old circuit board to cut out the IR sensor. Maybe this sensor is 20 year old technology, but I was surprised by how much data the sensor was spitting out without depressing any remote button. My optical desktop mouse is in the vicinity. Could that be creating the data noise? I probably should wait and get the new IR sensor before going to extreme measures.

You would still have the problem of communicating between the two processors.

That communication is done in microseconds. The sensor processor would just set a flag.

Could that be creating the data noise?

Probably not.

I was surprised by how much data the sensor was spitting out without depressing any remote button.

Then it is not data it is noise. Do you know anything about this sensor? There are many types. They have not changed much in the last 20 years either.

Then it is not data it is noise.

It outputs the correct data format of 8 HEX characters. They are all F's. I taped the red plastic filter to the front. I have no idea what brand or type of sensor it is. It's encased in aluminum sheet metal. It has your standard 3-pin connections. I used an ohm meter to determine what's what.

I took some measurements of the IR run time:

void loop() {
  lastReadTime = micros();
  if (irrecv.decode(&results)) {   
    
    irrecv.resume(); // Receive the next value    
  }
  MeasurementTime = micros() - lastReadTime;
    Serial.println(results.value, HEX);
    Serial.println(MeasurementTime);
  delay(100);

}

The times are all over the map. Many 4 - 10 us, others about 332 us, then a few are 11.6 ms & 10.9 ms.

That doesn't look good.

I was surprised by how much data the sensor was spitting out without depressing any remote button.

If you are not putting anything in but getting signals out then it is oscillating.
These receivers are prone to doing this if they do not have the correct decoupling components on them. See any data sheet of an IR reciever for details.

You can also get this from placing the IR receiver in bright light. Keep it shaded.

If you are not putting anything in but getting signals out then it is oscillating.

Good call! The section of circuit board that I cut out also contains a 10 uF capacitor and a couple of surface mount resistors. I thought the cap was adequate in cleaning up the 5V supply. It's not. One of the resistors on the board (220 ohm) connects to the + side of the cap. I connected the 5V to that resistor. The signal is now cleaned up. No more FFFFFFFF.

In conclusion:

  1. It takes 4 to 20us to go through the IR code when the remote is not depressed.
  2. It takes 450 to 600 us delay when remote is depressed.
  3. It can also take over 9 ms to go through the IR code when remote is depressed. It takes longer if the remote button activation isn't short and crisp.

I can live with that.
Thanks,
Gerry