IRRemote Pin 3 Confusion

I’ve gotten the IR receiver working and the codes pulled out that will be needed to turn on and off my projector. I’m having issues getting the IR LED to emit a signal that works.

I’ve followed as many examples and guides as I can without any results. In this documentation it says to use Pin 3. I just want to do a sanity check to make sure that is D3. I was looking at the datasheets and saw #3 might be TX. https://docs.particle.io/datasheets/photon-(wifi)/photon-datasheet/#jtag-and-swd

I want to say by default the output pin is set to A5 in the IRRemote library, see IRremoteInt.h:488

#elif defined(IR_USE_TIMER_PARTICLE)
#define TIMER_PWM_PIN        A5
1 Like

Are you missing a link in this?
What and where is "this documentation"?

The link you provided has no relation to IRRemote whatsoever.

If your code is using pin number 3 it's most likely originally targeting Arduino devices and #3 would translate to D3 in the Particle world.

Could it be that this might be a better match for the Particle ecosystem?
https://build.particle.io/libs/IRremote/0.0.3/tab/IRremote.cpp

The provided example uses int RECV_PIN = 11; which corresponds to A1 on Particle devices.

@BDub I’ll try that when i get home. Thank you. I completely missed this.

@ScruffR I already got receiving working. There was no provided example for sending.

@BDub That was exactly what i needed. Thank you so much.

1 Like

I’m working on a project which includes 3 sets of infrared transmitters and receivers. Can I use the IRremote library if it requires an output from 1 pin only? How would I connect three to the same output?

I’m using each one as a beam breakage test to determine the fill of a clothing donation bin. Could I hook them all up to 1 input if required but differentiate each signal perhaps so I can decipher the difference in the response for each receiver/transmitter module?

Sorry if this is a dumb question but I’m quite new to all of this.

@BDub

IRRemote is for “complex” IR transmissions but what you need won’t need such an elaborate library.
You just need to digitalRead() any three GPIO pins.

Thank you for the response @ScruffR.

To be clear I do need a digitalWrite as well since the particle board will be both outputting via an IR transmitter and receiving via an IR receiver.

The more I looked into the library it stated that it couldn’t do both simultaneously.

Are you saying I can simply digitalWrite the transmitter without specifying a frequency and then simply digitalRead the receiver without the need for such a library?

For a beam break detection you commonly would have the transmitting LED on permanently but if you only want to turn on temporarily I'd go with a common supply pin for all three transmitters and one pin per receiver.
For (considerably) more than three beams you could use one detector pin and use a multiplexer to read all sensors in a round-robin fashion.

To answer that we'd need to know which sensor you use.

I’m using 3 infrared transmitters ( https://www.jaycar.com.au/arduino-compatible-infrared-transmitter-module/p/XC4426 ) and 3 infrared receivers ( https://www.jaycar.com.au/linker-infrared-receiver-module-for-arduino/p/XC4583 ). The set up is to have them inside the bin and if receiver 1 beam is blocked the can is 25% full and if two blocked 50% etc.

Here is a very great blog about using IR receivers and transmitters to determine beam breakage I’d like to follow http://www.righto.com/2010/03/detecting-ir-beam-break-with-arduino-ir.html?m=1.

I will go with what you’re saying and connect the transmitters to one supply pin.

However, the IRremote api reference ( https://github.com/z3t0/Arduino-IRremote/wiki/IRremote-library-API ) states .

“The library cannot send and receive at the same time, but can switch between sending and receiving.”

So, I wonder if this is possible to be using IRremote as a beam blockage program since I’ll be both sending and receiving with the library.

As said, you don’t need a IRremote transmission but merely a steady beam.
IRremote is meant for sending or receiving data (e.g. like a TV remote control commands).
Hence the library would either take the role of a receiver or transmitter.

Rube Goldeberg Machine springs to mind :nerd_face:

Rube Goldberg's "Self-Operating Napkin" (cropped).gif
By Rube Goldberg - Originally published in Collier's, September 26 1931, Public Domain, Link

You don’t transmit data you only detect presence or absence of a “steady” beam.

Since your receiver expectes a 38kHz beam, you should be able to use any free PWM pin with analogWrite(pwmPin, 128, 38000); (50% duty cyncle at 38kHz).

1 Like

Perfect response and extremely helpful. I’m helping a year 12 student along with her project and am a bit out of my element here obviously but trying to give back to the community. Which I see you do all over these boards. Thanks again it really was of great help to me :smile:

2 Likes

IRremote .This library doesn’t seem to work any more . Keeps putting my proton into red signal after flashing. Do i have to change the library file to work with the newer version of firmware 1.5.0 ?

I’m running into the same issue - Red SOS error 14 when I use this library. Anyone have any ideas?

Interesting… I got the same problem myself… SOS on 1.5.2 on electron. It works fine on 1.4.4 - so your option might be downgrading.

It may have to do with the fact that IRRemote library uses version 1.3.7 of the SparkTimerInterval library.
If you can try the latest version 1.3.8 that might solve the issue.

It would also help if you could provide a simple test code that exhibits the issue for others to test for themselves.

I’ve thought so too - but upping to 1.3.8 didn’t help. As I don’t need 1.5 firmware, I’ve just downgraded.

I haven’t looked at this library in a while. I suspect it’s a class initialization sequence issue.

UPDATE: I testest the SparkIntervalTimer library example separately and it works fine so the culprit is most likely the IRRemote library.

1 Like