I am using a raspberry pi 0 and a bunch of i2c sensors, some doubled up with only 1 address choice so i'm also using an i2c switch.

However the problem is I need to go about 9ft. I am using the PCA9615 which converts I2C to differential https://www.nxp.com/docs/en/data-sheet/PCA9615.pdf and advertised to go up to 10ft (longer at lower speeds).

But as a contingency plan I'd like to have more margin from failure and my thought was to go to CAN bus.

I was hoping there was a transceiver out there that would take I2C and output CAN. But I haven't found it. Any suggestions of part numbers or a different approach to interface I2C sensors with a pi zero at 10ft ultra reliably?

Thanks!

 

I am using a raspberry pi 0 and a bunch of i2c sensors, some doubled up with only 1 address choice so i'm also using an i2c switch.

However the problem is I need to go about 9ft. I am using the PCA9615 which converts I2C to differential https://www.nxp.com/docs/en/data-sheet/PCA9615.pdf and advertised to go up to 10ft (longer at lower speeds).

But as a contingency plan I'd like to have more margin from failure and my thought was to go to CAN bus.

I was hoping there was a transceiver out there that would take I2C and output CAN. But I haven't found it. Any suggestions of part numbers or a different approach to interface I2C sensors with a pi zero at 10ft ultra reliably?

Thanks!

That is most certainly NOT happening. I2C and CAN are completely different, incompatible protocols. What led you to believe that this was possible? Your best bet is to build an I2C to CAN bridge. The CAN cable will easily accommodate up to 500 meters @ 125 kbaud

 

Encapsulating I²C in CAN shouldn’t be very hard, but you will need a μP on each end, on to encapsulate and one to decapsulate —so to speak. I am guessing you’d be better off with a proxy arrangement where the far end transaction is done by the processor on that end rather than trying to make some realtime connection end-to-end.

 

What I have seen done is to employed is to have a remotely located slave MCU to handle the addressing and reading of all the I2C sensors, then convert the data to TX,RX to drive a CAN transceiver.
At the end of the CAN bus on the receiving end, you would have a similar arrangement to reconvert back to I2C.
I have seen it done in mid-volume industrial and vehicular applications.

EDIT: Y got there first with the answer.

 

Great responses, thank you all for the input.
I understand the dual microcontroller approach.
What is a i2c canbus bridge? I’ll start some research.

 

Great responses, thank you all for the input.
I understand the dual microcontroller approach.
What is a i2c canbus bridge? I’ll start some research.

An I2C to CAN bridge is a separate processor with both an I2C and a CAN controller. What comes in or out on one hose goes out or in on the opposite hose. It bridges two networks together.

 

An I2C to CAN bridge is a separate processor with both an I2C and a CAN controller. What comes in or out on one hose goes out or in on the opposite hose. It bridges two networks together.

Ok so it needs to have firmware written to handle the traffic in that way. Thanks for info!

 

Hey Everyone, what about this chip:

https://www.mouser.com/ProductDetail/Analog-Devices/LT3960JMSEPBF?qs=T94vaHKWudRnIMk%2BVuDr2A==

 

Hey Everyone, what about this chip:

https://www.mouser.com/ProductDetail/Analog-Devices/LT3960JMSEPBF?qs=T94vaHKWudRnIMk%2BVuDr2A==

It converts I2C to the CAN physical layer, not to the higher layers of the CAN protocol.
If all you want to do is link two I2C devices over a long distance it will do the job.
if you want to talk to anything else that uses the full CAN protocol, then it won't.

 

It converts I2C to the CAN physical layer, not to the higher layers of the CAN protocol.
If all you want to do is link two I2C devices over a long distance it will do the job.
if you want to talk to anything else that uses the full CAN protocol, then it won't.

perfect, thank you.