tips for patching - multiple receivers at once to determine direction

[dragoncoder047]

It is my understanding that this library kind of supports multiple receivers on different pins, but not listening to multiple at once cause they all share the same interrupt routine.

However, I want to use two receivers to left and right and with a baffle in between them, to determine what direction the signal came from. The idea is, if only one receiver receives a signal, it came from that direction, but if both receive the signal simultaneously then it came from the front.

I can not just repeatedly switch back and forth between polling the two receivers, since the tasks that must be run alongside this loop take an unpredictable amount of time, and I already have bluetooth etc. tasks occupying the other core. So I need to set it to interrupt when either of the two receivers gets something.

Do you have any tips on where I should start to make those modifications?

[crankyoldgit]

Don't. I've tried multiple times. It hasn't ended well.

If you do want to tackle it, fork the library because it will require a lot of changes that really are not that useful to others and will take up too much space (code & memory) if it was to be merged into the library as a whole.

To do it, you will need to duplicate the buffer & state-machine variable where the raw data is collected. i.e. You can't have two different readers writing to the same buffer. Then you will have to change each interrupt handler to write to their respective buffers. Then you will need two different timers to mark the state-machine/buffers as finished capturing etc.

Or,
Do it in hardware/software.
A hack could be to have the IR demodulators also connect to other input GPIOs on the ESP. e.g. The first IR demotulator connected to (making crap up here) pins 13 & and to an input of an OR gate connected to 14. And the second demodulator connected to pin 15, and to the other side of the OR gate connected to 14.
Attach the IRrecv() object to pin 14. (which is a combined view of both IR demodulators.) i.e. It will always get the signal to decode. You could put an interrupt handler on pin 13 to write to a common variable that "pin 13" has just seen a pulse.
Ditto for the interrupt handler for pin 15. "pin 15" saw a pulse.
When you check if the library has decoded a message, check the variable to see which IR demodulator wrote last. It's likely but not certain, that that demodulator was where the signal came in from.
i.e. if a signal is received on pin 14, when you check the common variable, if it has 15 in it, then it's likely that the demodulator connected to pin 15 as well was probably the one sending it.
It doesn't help with if both are seeing the message at the same time. But you get the idea. If both are seeing it, with that setup, there are going to probably be too many interupts and it will make a garbled message.

Hence this is a hack. It kind of works to let you know if the message came on, say the "left" demodulator, or the "right" demodulator, if & only if, both can't see the same signal at the same time. It should work most of the time, but if there is an overlapping message being received at the same time which is very rare typically, if isolated and the environment is not noisy)

In short, there isn't a good solution. Heck .. use two ESP (They are only $5 after all) and use timestamps from them for the message and to determine what they saw etc.

[dragoncoder047]

Well, yes, I was going to do it as a fork anyway if I did :)

I hadn't though of an OR gate, but that might work, considering that if anything is in the overlapping fields of view, then it's only a couple of centimeters distance-wise apart, and that means less than a nanosecond of time difference. The common variable can function as a state machine, and if both pins see it at once then when it goes to write "15" and sees "13" already there it can instead write "both". When the decoded signal is read out of the buffer, the state variable can also be reset to "nothing".

I'm a bit cramped for components space and pins, so I was hoping to be able to do it all in software and only use 2 pins, versus using the OR gate which uses a 3rd pin. If it can't be done easily in software, I don't have space for a large OR gate chip, so I would probably make it out of 3 transistors. However, a NOR gate is only 2 transistors. Can I set it to look for an inverted infrared signal instead? If so, how?