Here is what works:
Raspberry Pi (I²C) <-> 1 m cable <-> sensor (I²C)
Here is what I'm trying to do (doesn't work, hence question):
Raspberry Pi (I²C) <-> 30 m cable <-> sensor (I²C)
The "equation" to solve is thus:
Raspberry Pi (I²C, SPI, and other) <-> X <-> 30 m cable <-> Y <-> sensor (I²C/SPI)
Solve for X and Y
I'm working with a bunch of sensors configured in a star network/topology.
A Raspberry Pi Zero is used as a central "hub", where all the sensor data is collected and processed. All the sensors are the same and use an I²C protocol (they also offer an SPI bus interface). That being said, I currently have an I²C multiplexer connected to the Raspberry Pi Zero to enable multiple devices configured with the same I²C hardware address. All sensors are wired to the Raspberry Pi Zero, using 26/4 shielded cable. Everything currently works as intended.
Having the proof of concept in place, I now want to extend the reach of the star network/topology by 20-30 m on each sensor-hub connection. I thought I could just use longer wire, but apparently the I²C protocol limits the length of wire extension. I've read various tricks/solutions on how to extend the length, such as lowering the frequency, changing resistors, etc.
I'll be honest; I'm not an electrical engineer, so some of that stuff seems a bit more advanced, and I don't really have the knowledge or tools to assess the effectiveness of those types of altercations.
Anyway, I've done some digging, and I've found various chips I can potentially implement as more of a "plug and play" solution. That being said, much of the material I read was from years ago, and I don't know if those solutions are still viable. Here are the chips I've found
- P82B96, which apparently has a successor: PCA9600?
Comparing the two, I've read the first item is more versatile. I've also read the second item is older and requires a lot of power, making remote deployments (battery powered) less practical. I recently came across another solution, where you use an I²C to 1-wire converter since the 1-wire protocol isn't as sensitive to increases in wire length
- DS28E17 (and potentially add DS2484 at hub)
This seems like a potential solution, but I haven't heard much about it being used by others. The only source of information I got was from the company webpage and videos. If I read the datasheet correctly, the solution doesn't require much power either. I'm wondering if others are buying what they're selling and if it works?
Anyway, again, I'm not an electrical engineer, so I could really use some advice. It seems like the I²C protocol is what a lot of sensors are using (at least the DIY embedded market), so I imagine I'm not the only one facing the issue of extending the I²C communication.
Here are my solution requirements:
- extend each sensor out from the central hub 20-30 m
- must be wired connection
- low power consumption (I'm running the network on battery power)
I've done some more digging over the weekend and I've come across this chip set (MCP25*), which sounds like a CAN-to-SPI interface. THIS WON'T WORK...SEE @Maple's comments below.
I'm certainly not saying that's the only chip set offering this conversion, it's just the first one I came across. The sensors that I'm using do have a SPI bus interface, so I think I might be able to directly connect one of these chips to each sensor? I only have 5 sensor nodes connected to the Raspberry Pi in my star topology, so I believe I'm well within the constraints on the number of nodes the CAN bus can support. The question would be then how to configure the rest of the bus. Would I simply connect one end of a Cat 5 cable to one of the CAN-to-SPI chips? The wire would then run 20-30 m to the Raspberry Pi. Could I then add one more chip at the Raspberry Pi to "invert" the conversion an communicate with the Raspberry Pi? Would there be a way to connect all five nodes to the same interface/chip? I don't think the Raspberry Pi has a native CAN bus support, but obviously does have SPI (I think you can only connect two devices?). If those chips could be added on the sensor nodes, what would be needed to interface the Raspberry Pi?
EDIT_2: After gathering further knowledge from everyone's feedback (thanks), I decided to keep digging. To no surprise, I came across yet another potential solution! I was reading through the comments on one of the links I pointed to above, and someone mentioned a PCA9615 chip. A quick Google search on this chip introduces "differential I²C". From a layman point of view, this sounds like a solution which wouldn't require me to change my software. Aside from that, I don't fully know the pros/cons or if it meets my three requirements listed. I will read further into the datasheet, but if anyone has feedback on this solution, I'm all ears!