Timer selection in IRremote on Teensy 3.5

Status
Not open for further replies.

Gronnesby

Member
Hi,

I am currently using a Teensy 3.5 as a basis for a bigger project that includes Audio, SD, IR transmission and reception, screens etc.
When trying to connect the different components, it seems that the IR receiver stopped working for some reason.
I suspect that it might be because of timers that are used by multiple libraries (though I'm just speculating), like the Audio or SD libraries perhaps.
So I want to change the timer in the IRremote library to see if that solves the problem.

However, I'm a bit confused as to what the different timers are named, and where to find an overview of it?
I tried to change the timer in the boarddefs.h from the IRremote library from this:
Code:
// Teensy 3.0 / Teensy 3.1
#elif defined(__MK20DX128__) || defined(__MK20DX256__) || defined(__MK64FX512__) || defined(__MK66FX1M0__)
	#define IR_USE_TIMER_CMT // tx = pin 5

To this:
Code:
// Teensy 3.0 / Teensy 3.1
#elif defined(__MK20DX128__) || defined(__MK20DX256__) || defined(__MK64FX512__) || defined(__MK66FX1M0__)
	#define IR_USE_TIMER_FTM0 // tx = pin 5

Which results in an error:
Code:
# error "Internal code configuration error, no known IR_USE_TIMER# defined\n"

I've read many places that to use a different timer, you need to "change the timer in IRremoteInt.h" (or boarddefs.h now in the later version) but not what you can change it to.
If anyone can shed some light on what timers are available and their names, it would be greatly appreciated :)

EDIT: Is there any issues with using the same teensy for both sending and receiving IR signals?
 
Last edited:
Hopefully someone who uses this library can chime in and give you a more complete answer.

Looks like boarddefs.h has lots of stuff in it that is configured when IR_USE_TIMER_CMT is defined.
Look in the same file in the lines about 423-515...

There are several lines that have to do with configuring FTM1... Plus probably the pins and the like. My guess is if you were to define a new section that duplicates most of this for your #define and then change all of the references to FTM1 to FTM0? Plus all the other indirect things like configuring the IO pin...
 
I believe the conflict is between Audio and the simple way IRremote does transmission, which basically amounts to a busy loop with delays turning PWM on/off. If other libs run lengthy interrupts, as Audio does, during that time when IRremote is transmitting, they can disrupt the delay-based timing.

Using a different timer in IRremote will not help.

You could try surrounding the IR transmission with AudioNoInterrupts() and AudioInterrupts(), so the audio lib doesn't try to updating during the moment when IRremote is sensitive. I'm pretty sure that will make IRremote work, but it could glitch your audio signals if the audio update interrupt is disabled too long.

I'm afraid there isn't any easy solution, like simply changing which timers or interrupts are used. A "real" solution would involve a major redesign of how IRremote does transmission.
 
Then again, there may be some other conflicts I'm not imagining. Please let me know how AudioNoInterrupts() around only the moment IRremote is transmitting works for you? Are you able to receive IR data while audio plays? Some confirmation of which specific things do and do not conflict would go a long way towards putting specific changes on my long-term TODO list....
 
I tested a bit with two different teensys (teensies?) sending signals to eachother, IR send and receive actually works fine with audio, even with several audio streams playing on top of eachother.
AudioNoInterrupt does not seem to be needed, and it cuts out the sound every time you send a signal.
I do think receiving while playing audio also works, but it will need some more testing to be sure.

I realised it makes sense that you would not be able to send and receive the same IR signal on the same teensy :)
 
It's been a while since I've worked with the IRremote code, but I believe it's designed to never transmit and receive at the same time.

Even if you could do full duplex from the software, to really make that work each direction would need its own optical path without interference from the other direction. Even the IR LEDs which claim to have a narrow angle, like 30 degrees, tend to spill quite a lot of light in all directions. The same is true for visible LEDs... even though it's brightest looking directly at it, you can still see the light to a lesser intensity from almost any angle.

The trouble with trying to both send and receive at the same time is you'll have two of those IR LEDs in the same room, shining their infrared light all over the place. Both receivers would likely hear a jumbled mess of pulses. It would only be reliable if you could somehow arrange for each receiver to only see the infrared light from the distant transmitter LED and ignore the light (and reflections off objects) from the very close-by transmitting LED.
 
It's been a while since I've worked with the IRremote code, but I believe it's designed to never transmit and receive at the same time.
Yea I think the IRsend object disables the receiver before sending.
It is sufficient to just re-enable the receiver after each transmission though.

In the project we're using IR for, full duplex is not really required (a DIY laser-tag system as an educational project for teenagers, will make a post in the blog forum when it is done).
The time window the sender is on is so small (67.5 ms for the NEC protocol i think) that it is not noticeable if the receiver miss a value or two.

Earlier versions were based on the Arduino Uno, so using a Teensy is a vast improvement with regards to computing power (and reducing perceived delays).
From what we've seen and tested so far, the Teensy seems to be more than capable of playing audio and doing either IR transmission or reception at the same time.
You can consider the problem solved, thanks for the input :)

On a side note: Is there any overview of the timers available on the different Teensy models?
Just for future reference.
 
It's been a while since I've worked with the IRremote code, but I believe it's designed to never transmit and receive at the same time.

FWIW, if you use two different timers, you can receive your own transmits! I have tested that on dragonfly and maple. Seems like i did it on some other non-teensy MCUs, but I can't remember which .... (EDIT: pyboard and mbed K64F)

Here is 2012 scope shot of maple doing concurrent IR xmit (blue) and recv(red)

irsndrcv1.png
 
Last edited:
Status
Not open for further replies.
Back
Top