Advanced daisy-chaining of I2C bus - Page 1
Forum section: electronics / beginners

author: LoveLaika
author_rank: Frequent Contributor
timestamp: September 07, 2021, 08:03:56 pm
content: I am making a board, but I am running into an issue of how to wire it, if possible. Let me see if I can explain it first.So, I'm trying to use I2C to read from sensors. That's straightforward. The I2C bus, theoretically, can hold up to 127 slaves to 1 master. Now, say I have all the same sensors, hardwired to the same address (like an I2C sensor from Adafruit). Because each sensor has the same address, I'll have to use an I2C MUX to address each sensor. I can do that by addressing each of the MUX's I2C port to get each sensor's I2C address. That's well documented onAdafruit's site.Now, for long distances without attenuation and noise, I can convert the serial I2C to a differential I2C pair of signals, use an Ethernet cable to go as long as I want, use another converter to convert back to serial I2C, and read from sensors normally. You can see this in block diagram #1 below. This worked on a breadboard with no issues using Sparkfun'sQuiic Bus. The problem now is when I want to daisy-chain my differential I2C signal. I want to daisy-chain my differential I2C signal so I can address different MUXs coded to different addresses. Can I do this by simply routing the same signals to another Ethernet port (as shown in Block Diagram #3), or do I have to convert it to serial and back to differential again (as shown in Block Diagram #2)? Unfortunately, I can't just put a MUX between the Master and the initial Differential I2C converter because of space. It sounds like it would be possible to accomplish this, but I don't know of the best way to do it.

author: viperidae
author_rank: Frequent Contributor
timestamp: September 08, 2021, 03:38:17 am
content: What are the sensors? There may be others with a more suitable interface for long distance, like 1wire.Alternatively you could use a little 6 or 8 pin MCU for each sensor and use rs485 or something.Both of those options will resolve your addressing issues.

author: LoveLaika
author_rank: Frequent Contributor
timestamp: September 08, 2021, 01:44:27 pm
content: Thanks for replying. Sorry, but after doing some researching, I think I found something that may be what I'm looking for: theSparkfun Endpoint.Looking at theschematicfor theproduct, the RJ-45 pins are connected to each other, and their design doesn't require another usage of the PCA9615 IC. It's just straight differential-to-differential. Seeing a design like this makes me curious in incorporating it in a future design, though I'm a bit concerned about power when using it with the endpoint and the Master. An Arduino only outputs 5-volts and 3.3-volts, whereas the endpoint and midpoint takes 5-volts on VCC_1, 3.3-volts on VCC, and up to 36-volts on the differential GRN-P/GRN-W pair.

author: LoveLaika
author_rank: Frequent Contributor
timestamp: September 14, 2021, 05:19:14 pm
content: Apologies for asking another question so late, but I wanted to get your opinion after some research. My sensors are magnetometers, like the AdafruitLSM9DS1. They're to be read in a noisy environment over a long distance (estimated to be around 20 meters, perhaps longer). Previously, we used straight ribbon cable, but in order to accommodate for longer distances, we decided to try a different method of communication.Doing some research, we found the aforementioned SparkfunEndpointandMidpoint. Converting the I2C digital signal to a differential signal seemed to fit our needs. Sparkfun's schematics also prove to show an easy to follow schematic allowing to incorporate the design in my own way. Looking at Digikey, the key component of it all, thePCA9615, is sold out.In light of this, what otherprotocols/ICscan be used to extend I2C for my needs? You mentioned 1-Wire, but it seems to have a lower data rate? All the testing my team has done has revolved around the PCA9615 because that's what Sparkfun has provided, but I'm open to anything else.

author: Ian.M
author_rank: Super Contributor
timestamp: September 14, 2021, 05:52:49 pm
content: Have you considered putting a MCU at each sensor, to allow you to use a more robust communications bus and protocol?Depending on the sensor data bandwidth you need, you may consider serial comms over LIN bus hardware, RS-485, CAN bus or even Ethernet.

author: LoveLaika
author_rank: Frequent Contributor
timestamp: September 14, 2021, 06:11:25 pm
content: Thanks for the reply. No, I haven't considered that. I'm not sure if we can do that to be honest. Each sensor is in its own area, and we deliver power to the sensors through I2C or RJ-45 (in our test cases). I'm not sure if we have enough room to include an MCU. I'll check on that, but perhaps if possible, something like the Teensy might fit. Though, with it, there's not many communication protocols that are usable on board immediately.Currently, we're using an Arduino Nano Every (and/or maybe an Arduino Portenta) to read our sensors via I2C. That was how the walkthroughs were designed, so that's what we went with, and what we are limited to. The issue is that our master computer (in this case, the Nano) has to fit within a specific size. The smaller, the better. I was informed that we did try using a Raspberry Pi Zero to cut out the Arduino, but there were timing issues when reading from the Pi Zero. Thus, our set up is Pi-Zero to Arduino to I2C sensors.Sorry, forgot to mention; we're trying to read a LOT of sensors (for a rough estimate, let's say 40), all spaced around different locations.

author: Ian.M
author_rank: Super Contributor
timestamp: September 14, 2021, 06:51:33 pm
content: An 8 pin ATtiny MCU (with UART and I2C) and an 8 pin LIN or RS-485 transceiver (+ minimum ancillary components) don't take up much board area. Also, odds are a Pi Zero (or Zero W with Bluetooth disabled to free up the hardware UART) can reliably handle serial comms with the now smart sensor nodes with no Arduino, so you'd only need the SBC + a LIN or RS-485 transciever at the master.

author: LoveLaika
author_rank: Frequent Contributor
timestamp: September 14, 2021, 07:34:45 pm
content: So, if I understand correctly, using an ATtiny MCU to read the sensor via I2C and to use another protocol like RS-485 to send data back to the master through something like Shielded CAT-5, which would also allow for power/ground to be transmitted. That sounds interesting; hardware aside, it seems challenging on the software side as well, though it seems there are libraries that would make it easier.How does RS-485 work with multiplexing? We used an I2C multiplexer to read duplicates of the same sensor. We could give each sensor their own unique address. How would the host handle reading from all those sensors at once?

author: Ian.M
author_rank: Super Contributor
timestamp: September 14, 2021, 08:18:01 pm
content: RS-485 is a physical layer, not a protocol. Its a multi-drop serial bus. Its usual to use asynchronous serial data over the RS-485 physical layer, and on top of that, whatever protocol you desire. e.g. set up the UART for 9 bit data, and use the extra bit to signal address bytes which select a specific sensor to poll, then send a command byte for what data the sensor should reply with. An alternative is to use 8 bit data, but send a break to signal the start of each packet and thus identify the address byte. Of course each sensor needs a unique hardware address, but there are various ways of handling that that don't need you to physically set it on each sensor board, e.g. have a 'global call' address to which all sensors respond, and commands to read back a unique serial number with random backoff and retry if the slave detects a bus collision (i.e. it doesn't see the same data it sent) and to allocate a short address to a particular serial number. It does need some way of identifying where each sensor is physically located, one possibility is to connect new sensors one at a time, so they can be logged by the master and the user asked where each is located.

author: LoveLaika
author_rank: Frequent Contributor
timestamp: September 14, 2021, 08:37:10 pm
content: Thank you. If worst comes to worst, we'll have to get creative, start off with one sensor and work our way up. This would be entirely new, but it doesn't seem like we're all alone on this.Forgive me if I'm beating a dead horse, but if there were a replacement to the PCA9615, what would you recommend? I think I may have limited myself by focusing on that one chip. Searching around, there seems to be some older alternatives, such as thePCA9614and thePCA9616that can be used as an alternative while achieving the same thing. They may be end of life, but they may serve our needs. (Makes me wonder if the lack of stock is because of the worldwide chip shortage or if this is just an outdated product)