Custom Address Translation for I2C Sensors

I am trying to use a lot (>30) of I2C sensors (all with the same address) connected to an ESP32 (or something similar) without the use of a mux.

One solution I have found so far is an LTC4316 from Linear that can do I2C/SMBus address translation. The problem with this solution is that it requires the setting of address values via resistors and it is expensive.

But I found some posts with recommendations to use a PIC or AVR microcontroller with each I2C to provide address translation.
https://forum.sparkfun.com/viewtopic.php?t=45462

This solution is ideal because, in theory, I can use software to control and assign the addresses for each I2C sensor and cheaper than using a LTC4316.

Is there any source code, examples, or libraries out there that can program a PIC or AVR microcontroller to do address translation for an I2C device?

I have seen a few articles about turning an ATTiny85 into an I2C slave using the TinyWireS library. But I do not think this would work in my application. None of the examples I found had I2C devices attached to the ATTiny85.

what are the I2C devices?
do they have an address pin(s)?
if so you could change the I2C address using digital IO pins

also have a look at the TCA9545A I2C switch

One solution I have found so far is an LTC4316 from Linear that can do I2C/SMBus address translation. The problem with this solution is that it requires the setting of address values via resistors and it is expensive.

Why is an address translator OK but and I2C multiplexer is not?

This solution is ideal because, in theory, I can use software to control and assign the addresses for each I2C sensor and cheaper than using a LTC4316.

I don't see why an AVR processor is cheaper than an LTC4316. The circuit is definitely much more complex.

Is there any source code, examples, or libraries out there that can program a PIC or AVR microcontroller to do address translation for an I2C device?

You usually do that by using the I2C slave mode of the hardware interface and connect the sensor using a software emulation of the I2C protocol.

I have seen a few articles about turning an ATTiny85 into an I2C slave using the TinyWireS library. But I do not think this would work in my application. None of the examples I found had I2C devices attached to the ATTiny85.

But that's the only solution that keeps the costs in an acceptable range. The Tiny can be slave using the USI hardware and it can run the same software I2C emulation, at least for most sensors. It won't work if the sensor uses clock stretching.

horace:
what are the I2C devices?
do they have an address pin(s)?
if so you could change the I2C address using digital IO pins

also have a look at the TCA9545A I2C switch

horace, we plan on using MMA8451 accelerometers. Yes this sensor has an address pin, but I only have 2 addresses to choose from.

Unfortunately a mux would not work in my application, because these sensors will be spread out over 300ft. So a star topology is not really practical for this type of use case. In addition, the number of sensors might grow to 100.

pylon, Our devices will be spread out over a linear distance of 300ft. With the LTC4316, I could put one of each I2C sensor and connect all devices to the same 2 wires. With the mux I would have to run many wires over great distances.

One installation of these sensors could easily be 1000 units. The LTC4316 in volume could cost $2 each. Where as a PIC would be $0.50. An ATTiny85 is not ideal at $1 each but its better than the LTC. The problem with the LTC also is the fact that the addresses have to be set with resistors or dip switches. Because we are dealing with so many sensors, a software based approach to setting the addresses would be better.

I don't mind using the ATTiny85 I2C slave solutions that I found, I just don't know how to get the I2C sensor to work with the ATTiny85, when it is slave.

Do you know of any articles or libraries that I can look at that would allow me to connect the sensor using a software emulation of the I2C protocol, while the ATTiny85 is slave using the USI hardware?

you could use a digital IO pin to select the I2C device address see

for a large number of devices you have you would require a digital extender

pylon, Our devices will be spread out over a linear distance of 300ft. With the LTC4316, I could put one of each I2C sensor and connect all devices to the same 2 wires. With the mux I would have to run many wires over great distances.

I2C is the wrong technology to cover a distance of 100m. You need a technology that uses differential signals (RS-485, CAN, Ethernet, etc.). You will never get an I2C running over 100m reliably.

One installation of these sensors could easily be 1000 units. The LTC4316 in volume could cost $2 each. Where as a PIC would be $0.50. An ATTiny85 is not ideal at $1 each but its better than the LTC. The problem with the LTC also is the fact that the addresses have to be set with resistors or dip switches. Because we are dealing with so many sensors, a software based approach to setting the addresses would be better.

An I2C bus can have about 120 slave devices in theory. In reality you may get about 10 up and working if you carefully design your bus and keep the capacitance low. Again, I2C is the wrong technology for this.

I get the impression you should explain your project in much more detail. The base architecture seems to have ignored the hardware limitations so you probably have to do a complete re-make of it.

Do you know of any articles or libraries that I can look at that would allow me to connect the sensor using a software emulation of the I2C protocol, while the ATTiny85 is slave using the USI hardware?

A single library won't work. And I won't invest much time before the base architecture is fixed in this project. It will never work the way you're currently planning it if the above specification is true.

Hi pylon
You are absolutely right, standard I2C cannot support these kinds of distances. I plan on solving the distance problem with NXP PCA9615 differential I2C bus extenders. Even if I am only able to go 100 ft using the PCA9615, that is still good.

I also agree with you on the number of devices, I might not be able to get 120 I2C sensors working on the same bus. I am hoping the PCA9615 will help with the capacitance problem. But right now, I cannot even get 3 to work, let alone 10. This unique address problem has me stumped, and my focus has been trying to resolve this problem first and then move on to the next. If I cannot figure it out, then I will have to throw out this idea altogether.

The project:
My in-laws have a ranch in a remote part of south Texas and they have had problems with people trespassing and stealing their property, not to mention illegally poaching on their land. Nobody lives on the land, so its very easy for intruders to enter undetected. My idea is to put accelerometers on the barb wire fence all around their property to detect when someone tries to cross the fence. If all goes according to plan when someone crosses the fence, the ESP32 (or whatever else I use) will send out a message and we will be able to pinpoint the exact location on the fence where and when they entered. We will then be able to notify someone who lives nearby to check it out.

I have looked at other sensors to detect when someone has crossed, but nothing else would really work that well in an outdoor environment. Detecting vibration seems like the most obvious choice.

There are fence monitoring/protection systems out there already, but they are very expensive. We are dealing with about 3 miles of fence to cover, so the cost would be high. I was hoping to be able to come up with a cost effect DIY off-the-shelf solution. So far, I have been able to find all the hardware pieces off-the-shelf. Now I just need to figure out how I can get a master MCU to talk to as many accelerometers as possible over great distances, without spending a fortune.

have you considered using wireless such as Lora for communication?
if you do a web search for lora crop monitoring or similar you will get plenty of links

What was the dollar quote for a commercial system?
How much are you prepared to spend on a DIY system?

You are absolutely right, standard I2C cannot support these kinds of distances. I plan on solving the distance problem with NXP PCA9615 differential I2C bus extenders. Even if I am only able to go 100 ft using the PCA9615, that is still good.

The PCA9615 might give you 3m which is way below the 30m you're dreaming about. I repeat: I2C is the wrong technology for this and it stays being the wrong technology with all extenders you might find.

I also agree with you on the number of devices, I might not be able to get 120 I2C sensors working on the same bus. I am hoping the PCA9615 will help with the capacitance problem. But right now, I cannot even get 3 to work, let alone 10. This unique address problem has me stumped, and my focus has been trying to resolve this problem first and then move on to the next. If I cannot figure it out, then I will have to throw out this idea altogether.

I don't agree. If you have 3 devices running on the bus you still use the wrong technology and you won't solve that other problem so you don't have to solve that one first.

My in-laws have a ranch in a remote part of south Texas and they have had problems with people trespassing and stealing their property, not to mention illegally poaching on their land. Nobody lives on the land, so its very easy for intruders to enter undetected. My idea is to put accelerometers on the barb wire fence all around their property to detect when someone tries to cross the fence. If all goes according to plan when someone crosses the fence, the ESP32 (or whatever else I use) will send out a message and we will be able to pinpoint the exact location on the fence where and when they entered. We will then be able to notify someone who lives nearby to check it out.

In that case the biggest problem is the power supply for the sensors. As far as I know Texas is a quite sunny state so you might use solar panels to power each of these sensors with a backup battery for the night. The solar panel might be a problem because the potential intruders may observe that there is a sensor and circumvent that in any way.
To transfer the data I would definitely recommend a wireless solution but ESPs use WiFi and that's not power-efficient enough for your task. A LORA based solution may work. Choose a sensor that is able to provide an interrupt in case of a programmed threshold, that way you can send the processor to sleep most of the time.

How many fence posts are on that ranch? I guess you need one sensor (and MCU/LORA transceiver) for every wire part between two posts. Can be quite costly.

I would try an electric fence charger. Just check on the returning wire if there is still charge so you can detect a cut wire. The probably won't cross the wire without cutting it if it's charged at least not carrying a prey animal.