Design Opinion Req: IR Receiver as an I2C slave

[bobslawblog]

I am thinking of using some ATTiny84's as I2C slaves for a series of sensor clusters with the ESP32 as the master. Part of those clusters include an IR Rx TSOP. The reason I am thinking of using the ATtiny and I2C is to simplify the cabling between sensors and also make them expandable to allow me to add a few more sensor clusters easily. (4 wire cable runs that allow me to daisy chain sensor clusters)

The intent of the cluster is to be able to tell which cluster received properly encoded data so I can deduce the direction of the signal as well as control other things at that sensor like a series of PWM controlled RGBW LEDs.

My question is around the concept of polling the I2C slaves for IR data from the ESP32 I2C master. I haven't found many projects where IR rx are being used as slaves so I want to make sure this is a sound concept before proceeding. My only alternative is to do a home run wire from each sensor back to the ESP32 and use it's channels to receive all of the IR. This makes my wiring bundles a little less clean and I am limited to the 8 channels available on the ESP (should be enough, but mainly want to keep wiring clean).

I found this project for inspiration on the AtTiny:
https://github.com/fotisl/ir2i2c

I know I can poll the I2C pretty rapidly. I am a little concerned that it may be difficult to deduce the order that the signals are received by the clusters. Perhaps I need to include a value similar to millis() in the I2C traffic to indicate when the signal was processed to help the master determine which cluster received data first?

Any links to similar efforts or wise words on the concept of the solution would be valued.

Thanks!

[ESP_Sprite]

You seem to imagine timing is important here; can I ask why? I'm decently sure you're not gonna be able to deduce the direction by time-of-flight calculations on the IR light, and aside from that I'm not sure if timing matters that much...

Regardless, you can do a few back-of-the-envelope calculations to see if you can make it fit. Say an IR signal is 16 bit, your I2C bus runs at 100KHz, and you have 25 clusters. To poll them all (given that software latencies are ignored), you're gonna need at least 24 bits per cluster (8 for i2c address, 16 for data bits), plus a start and stop condition, plus perhaps some overhead; let's call it 40 bits per transaction. This means that you can do (100K/40=)2.5K transactions per second, which means you can poll your 25 clusters at a rate of (2.5K/25=)100Hz. In other words: as long as your IR sender sends less than 100 16-bit messages per second, your I2C bus can sustain that rate.

Note that if you're going for a larger-scale design (e.g. a few meter between nodes), I2C is not the best protocol... I'd move to something differential, e.g. a RS485 or CAN-bus if you want to make sure there's no EM fields or capacitances disturbing your communication. You can make similar calculations for those to see if a given rate fits your use case.

[bobslawblog]

Awesome, thanks for the reply.

Just for clarification, the objective isn't to do a TOA calculation. It is just to determine which quadrant received a properly encoded lens focused IR signal which direction in turn indicates direction. The master just needs to know which sensor was hit by which signal and ideally the order in which the array received the signals. At the polling rates suggested it seems this should be no issue.

Right now the sensor clusters are around a 24" circumference. I don't plan to get bigger but I might expand with a few more sensor clusters. I am originally starting with four, one for each quadrant.

Also, I apologize if this posted twice. I attempted to post this message once and it looked like the browser lost the information but I now see it in fact did take the post. I will delete the other one.

Thanks again!