I2C multidrop ramified over long cables PCA9600 PCA9615 PCA9517 PCA9518

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

I2C multidrop ramified over long cables PCA9600 PCA9615 PCA9517 PCA9518

1,818件の閲覧回数
NicoDy
Contributor I

Well... 

I have read many application notes, datasheets and forums and there is so many information that I though I would better ask for a second thought. 

I am building a multidrop ramified I2C system over long distances. I am aware that I2C might not be the best but we are unfortunately constrained by some sensors, and as NXP seems to offers great solutions for this, this might be good. Here is the overall architecture and below the detail of a node:

Capture d’écran 2023-08-24 165148.jpg

 

 

Capture d’écran 2023-08-24 172731.jpg

 

 

 

The total lenght of the bus should not exceed 70 meters but it may have up to 10 nodes, and be more ramified than this. Each node is composed of a microcontroller which is in slave mode on one of its I2C bus, and in master on the second I2C bus (it also gathers some analogic sensor's values which is not shown here). All nodes will be identical but with a unique address.

So I am looking for the best PCA_____ choices for  AAA, XXX, YYY, ZZZ and VVV

AAA: I though on going to PCA9615 first, but PCA9600 seems finally a better choice. But I would have to withstand the 70m on its own and the sink current. Do you think it is ok? Or does it need regeneration? 

XXX: the same as AAA ()PCA9600) since they work as a pair, except if we go for a complete other architecture. 

ZZZ: is an hypotheytical regeneration system. I read on some Q/A App Note that placing 2x PCA9600 (or PCA9615) wouldn't help for regeneration, but I can't see why. So.. do I need 2 x I2C buffers on a single I2C Node? Will it help? 

YYY: On the other side of the I2C Node the problem is less the distance than the multiplexing (same sensor's addresses). I was thinking PCA9518A. Will it be able to handle the distance on it's own? And better question is maybe with what sort of cable will it be able to do this? 

VVV: If the PCA9518A is not capable of that with what could we pair it (PCA9515, etc. seems to be out of the game). 

 

An extra question with the use of the PCA9600 in this architecture is: where should we place the termination resistors? The actual diagram makes the nodes appears in a daisy chain, but all the SDA_P, SDA_N, SCL_P, SCL_N will actually be the same wires. Is only one termination nescessary for the entire bus? 

Note that up to now it also possible to go on a completely different architecture. This is whatr I came up after some times reading. 

 

Kind regards, 

Nico

0 件の賞賛
返信
5 返答(返信)

1,788件の閲覧回数
NicoDy
Contributor I

Hi, 

 

Thank you for your reply. What do you mean by "not suitable", is it that it won't work, or just there is a better solution? 

The PCA9646 + PCA9605 seems to resemble more my application indeed. I am not sure to quite understand what the "Interface Delay Module" is. Is there a specific chip that is used to correct the delays induced by the several buffers, or it just the denomination of the fact there is a delay? 

Also the PCA9605 is surprinsingly hard to source, at least in Europe. I might be a no go, is there an alternative? 

 

Kind regards, 

Nico 

 

 

0 件の賞賛
返信

1,727件の閲覧回数
Lorenzo_Mch_IT
Contributor IV

Don't do that, you will get (metaphorically) hurt.

Documentation can be misleading, for example the PCA9615 datasheet says:
"The dI2C-bus buffers were designed to solve these problems and are ideally suited for
rugged high noise environments and/or longer cable applications, allow multiple targets,
and operate at bus speeds up to 1 MHz clock rate. Cables can be extended to at least
3 meters (3 m), or longer cable runs at lower clock speeds."

While PCA9600 datasheet says:
"1 MHz operation on up to 20 meters of wire (see AN10658)".

Then if you spelunk into AN10658 you find stuff like:
"With a short cable, say 2 m, the clock speed may be selected as 1 MHz on the USB Lite
interface screen, and communications will be fine, but the true speed will be lower than
the displayed value due to clock stretching by the buffer. For example when using P82B96
the actual clock rate will be measured at about 725 kHz. For 100 kHz operation, the 1 µs
rise time limit will be reached when the cable length is about 50 m. For 400 kHz, the
300 ns rise time limit will be reached with just 14 m of cable but those timings are only the
specification requirements and typical operation at higher frequencies will be found
possible."

That is, for PCA9615 it actually says "this is a big bad main battle tank designed to survive in heavily hostile environments, you can run it at 1MHz with AT LEAST 3 meter cable lenghts". 

While for PCA9600 it actually says "it MAY operate at 1 MHz with UP TO 20 m cable lenghts in fair weather and with a bit of luck if you closely follow what's explained in AN10658 and fully understand the implications of some subtle wording there".

My advice is, before trying the PCA9600 route, order a few of ready-to-use COTS hobbyst QwiicBus boards from Sparkfun and give a try to what you can get with a PCA9615-based solution
https://learn.sparkfun.com/tutorials/sparkfun-qwiicbus-hookup-guide ).

N.B. The Sparkfun stuff is just to give a quick run to a PCA9615 solution, to use as a starting point for your final hardware (i.e. adding power over the cable, further EM hardening where it makes sense, etc).

 

 

0 件の賞賛
返信

1,722件の閲覧回数
NicoDy
Contributor I

Thank you @Lorenzo_Mch_IT for the contribution. What I understand now: 

  • All theses technologies seem old and it's not very clear what reaplaced what. I am not sure they are still widely used, but the poject is for now stucked with wired connections.
  • Sparkfun did choose this technology for a reason, so I guess 9615 might be OK

but

  • I am still not sure on where to put termination resistors since this a is a kind of multi droplet / star combined configuration
  • And the 50m lenght might be short for some aplications.

What I came up with is: 

  • AAA = PCA9646 since each branch of the star can be can be isolated from each other (each branch up to 25m).
  • coupled with 4x P82B96 (on per branch) pulled up with 12V.

I might try the PCA9615 solution but I am not sure if it can follow a multiplexor.

 

Kind regards,

Nico

0 件の賞賛
返信

1,712件の閲覧回数
Lorenzo_Mch_IT
Contributor IV

PCA9646 is just a 4-way I2C multiplexer, so you can connect to it any I2C device, including four PCA9516 (each one is just an I2C <--> diff. I2C converter).

Termination resistor are really required at the  "differential I2C bus" ends because those are the parts that can be long.
For example (using the QwiicBus differential I2C breakout modules), look here:
https://cdn.sparkfun.com/assets/c/4/7/0/9/SparkFun_Differential_I2C_Breakout_PCA9615_Qwiic.pdf


The I2C sections are quite short, for those you usually just need a pull-up resistor.

1,794件の閲覧回数
JozefKozon
NXP TechSupport
NXP TechSupport

Dear Nicolas,

yes, the PCA9600 is a better option. Since you need 10m cable length and the PCA9615 recommended is 3m. But I guess non of these is suitable for your application. From the picture it looks, best option for you would be PCA9646 as a multiplexer and PCA9605 as the I2C buffer. Please refer to the Figure 6 in the AN11084 attached.  

JozefKozon_0-1692949252426.png

With Best Regards,

Jozef

0 件の賞賛
返信