This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

IR sensor is behaving weirdly?

Other Parts Discussed in Thread: EK-TM4C1294XL

Hello,

To get straight to the point, I'm using the EK-TM4C1294XL launchpad with the IR LED and receiver from the Boe-Bot kit (Board of Education development board). I seems to have everything working okay, but the only issue I'm having (if it really is an issue) is that when I place my hand in front of the LED as a reflector for the IR to reach the receiver, the receiver is displaying 0's, which means it is indeed detecting something. BUT after about 3 seconds, the 0's turn back to 1's (not detecting) while my hand is still in the way. Also, the sensor only detects when I move my hand up and down. When I move my hand horizontally toward the sensor, it does not detect. Does anyone have an idea on what might be the problem?

Thanks!

  • Hello Thomas,

    What are you seeing is detection of reflected energy when the delta change is large enough for the receiver due to change in the foreground. This I believe is akin to moving from the dark to ligh suddenly causing the pupils to dilate. On the other hand a slow increase in the light may not cause the pupil dilation (very crude)

    Now to facts: did you check if the same effect is visible when a strong reflective surface is introduced. Also what form of IR modulation is being done?

    Regards
    Amit
  • Hi Amit,

    I'm not sure what is considered a strong reflective surface or if I even have one, but I've tried it on a variety of different surfaces including phone screen, folder, mirror, hand, etc. Depending on the object, the speed at which I must move the object up/down into the receiver's view varies. None works for when I move up/down really slowly, or when I move from far to close.

    What are you specifically looking for when you ask for IR modulation? I have my PWM set up as such:

    	//
    	// Enable the peripherals to be used.
    	//
    	MAP_SysCtlPeripheralEnable(SYSCTL_PERIPH_PWM0);
    	MAP_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOK);
    
    	//
    	// Delay 6 clock cycles.
    	//
    	MAP_SysCtlDelay(2);
    
    	//
    	// Configure PK4 as PWM.
    	//
    	MAP_GPIOPinConfigure(GPIO_PK4_M0PWM6);
    	MAP_GPIOPinTypePWM(GPIO_PORTK_BASE, GPIO_PIN_4);
    
    	//
    	// Configure PWM clock = 120 MHz / 64 = 1.857 MHz
    	//
    	MAP_PWMClockSet(PWM0_BASE, PWM_SYSCLK_DIV_64);
    
    	//
    	// Configure PWM options.
    	//
    	MAP_PWMGenConfigure(PWM0_BASE, PWM_GEN_3, PWM_GEN_MODE_DOWN |
    			PWM_GEN_MODE_NO_SYNC);
    
    	//
    	// Set the period (expressed in clock ticks).
    	// N = (1 / f) * SysClk = (1 / 38.5 kHz) * 1.875 MHz = 49
    	//
    	MAP_PWMGenPeriodSet(PWM0_BASE, PWM_GEN_3, 49);
    
    	//
    	// Set PWM duty. 50%
    	//
    	MAP_PWMPulseWidthSet(PWM0_BASE, PWM_OUT_6, 25);
    
    	//
    	// Enable the PWM generator.
    	//
    	MAP_PWMGenEnable(PWM0_BASE, PWM_GEN_3);
    
    	//
    	// Turn on output pin.
    	//
    	MAP_PWMOutputState(PWM0_BASE, PWM_OUT_6_BIT, true);

    As you can tell, it is very basic as I'm still a beginner, but I'm relatively sure that I did the initialization correctly.

    Thanks,

    Thomas

  • Thomas Phan said:
    Does anyone have an idea on what might be the problem?

    Have you thought to measure the sensor's output (under identical test conditions) - to eliminate the MCU and/or your code handling as the issue's source?

    Further - most such "bored" kits are not famed for employing latest/greatest devices - might the sensor be a "fallout" device?   (that's not unknown)   You've purchased multiple sensors - have you not?   (you cannot compare/contrast/A-B test w/just ONE device!)

    And - the esteemed sensor provider (must) have heard this issue before - don't you think?   Question directed to the real killer source may prove more fruitful...

  • Unfortunately, I have not had the opportunity to measure the sensor's output as I do not personally own an oscilloscope.

    Actually, these sensors that I'm using were already available from the Boe-Bot kit that I purchased a few years back. Since I was trying to keep the cost as low as possible, I didn't buy new IR sensors since I thought that the Boe-Bot IR navigation system was still working, the sensors must still be fine.

    And yes, I will definitely contact them. I didn't think it was a sensor issue, but instead how I set up my PWM using this launchpad so this forum was the first I went to.
  • Are you sure that's not the way it's supposed to work?

    Robert
  • Yes I am sure.

    But I was able to figure it out by luck. I started with 0% duty cycle, then call a function to set it to 50%, checks for detection, and then set it back to 0% and loop it over. Also I added a 1 ms delay after every time I change the duty cycle, as well as when I read the signal. This works for some reason.

    Before I only had the delay after the read, and I left the PWM to run at 50% duty cycle for the entire time.

    Not sure what you guys make of this.
  • Sounds as if you were saturating the IR receiver. The break in pulse output enables the IR portion to (properly) recover...
  • Ah thanks for the explanation. I didn't know that it was possible to make the IR receiver function incorrectly by over-flooding signal. This is my first time working with peripherals.
  • That same "saturation" can occur w/op-amps & instrumentation amps (in-amps) and (effectively) "blinds" the amp until the input signal is removed or substantially decreased in amplitude.     As a "real-world" example - we needed to measure the VDS (voltage) across a power FET - which could range from less than 100mV to a high of 20V.    Our objective was to monitor this VDS (only) when the FET was enhanced (on) so that we could optimally introduce our gate drive signal.  

    Now when the FET was "on" - and only then - we employed a gain-selectable in-amp set to, "Max Gain."  (8 in our case)   This in-amp has an extremely high input impedance - could (easily) tolerate the full 20V across it's inputs - yet if would misbehave should we order "gain" when the 20V signal was present.   Our solution was to, again, "Dial up the gain" (only) when we knew the FET was (on) and VDS was at greatly reduced voltage levels.  

    Both high voltage level AND its duration (as illustrated) served to "blind" our in-amp.

    Note too that vendor's Amit spoke to, "delta change."    Your introduction of delay accommodated this (apparent) sensor requirement.

  • Thomas Phan said:
    Yes I am sure.

    I think you missed what I was asking. I was asking if the way you were using it was known to be correct.

    Thomas Phan said:

    But I was able to figure it out by luck. I started with 0% duty cycle, then call a function to set it to 50%, checks for detection, and then set it back to 0% and loop it over. Also I added a 1 ms delay after every time I change the duty cycle, as well as when I read the signal. This works for some reason.

    And apparently my suspicions were founded.

    I was wondering if this was the way it was supposed to work.

    It is quite possible that the sensor only works in a pulsed fashion. Particularly if it's a ranging sensor.

    Robert

  • Ah I apologize, I misunderstood your question.

    And thank you for all of your help.

    Thomas