Segnale I2C e alimentazione a lungo raggio (cavo da 10 metri)

9

Dopo alcune letture / test sono riuscito a stabilire una comunicazione stabile tra 2 dispositivi utilizzando I2C con cavo twistato in rame FTP CAT5.

Filo verde - SCL
Cavo bianco / verde - GND
Filo blu - SDA
Cavo bianco / blu - GND

GND è collegato solo a un'estremità del cavo, l'orologio del bus I2C è a 10Khz e ho usato resistori pullup 10Kom per VCC

Funziona bene e stabile. Quando ho deciso di utilizzare altre 2 coppie di cavi per l'alimentazione (+ 12V), ha smesso di funzionare. Ho provato + 12V su una coppia GND sull'altra coppia, anche + 12V / GND sulla stessa coppia: stesso risultato, ha smesso di funzionare. L'intero bus I2C ha smesso di funzionare, anche altri dispositivi collegati.

Mi chiedo se posso usare lo stesso cavo o andare alla scelta più sicura - un altro cavo per l'alimentazione.

power i2c

— user3503519
fonte

3

Hai verificato che l'alimentazione sul lato ricevente sia abbastanza buona? Nessun problema tecnico, nessuna caduta ... I cavi CAT5 sono piuttosto sottili, ecco perché PoE utilizza> 40 V per l'alimentazione.

— Vladimir Cravero,

4

Qui è dove hai bisogno di un oscilloscopio. Tutto il resto saranno congetture (istruite).

— pipe

1

Non distorcerei SDA o SCL con GND perché non vuoi alcuna capacità tra di loro. Avrei attorcigliato + 12V con GND perché vuoi capacità tra di loro. Quale corrente (di ritorno) ha il + 12V? (potresti avere un rimbalzo a terra)

— Huisman,

5

GND è collegato solo a un'estremità del cavo? A meno che non mi fraintenda, ciò non suona bene.

— mkeith,

1

Intendevi cavo UTP ? Sono sicuro che può essere utilizzato per più protocolli rispetto al solo FTP;)

— Andrew Morton,

15

Forse eccessivo se funzionava prima, ma un'opzione è quella di utilizzare un convertitore da I2C a differenziale come PCA9615 , LTC4331 , ecc. Se rendere le resistenze più piccole non funzionano o è necessario estendere il cavo, considerare di non utilizzare I2C direttamente.

Non solo la gamma verrà estesa, ma avrai anche una migliore immunità al rumore.

— Wesley Lee
fonte

1

Ottima risposta, questo è esattamente ciò che dovrebbe essere fatto, ma ovviamente potrebbe essere un cambiamento radicale per il PO.

— Jack Creasey,

Voglio dire, sono super facili da implementare (se paragonati allo spostamento su RS-485, CAN, ecc.), Ma sì rispetto al cambiamento di alcuni resistori è un cambiamento radicale.

— Wesley Lee,

1

Il problema di @JackCreasey OP non è solo la capacità del cavo, ma sembrano soffrire di disturbi sulla linea 12V che hanno aggiunto. L'abbassamento delle resistenze pull-up fornisce un'ulteriore immunità al rumore, ma non possono continuare a ridurre indefinitamente quella resistenza.

— Dmitry Grigoryev il

@DmitryGrigoryev Dato che l'OP non ha fornito dettagli, non sono sicuro di come si possa suggerire che il rumore sia stato iniettato. Sono d'accordo che non puoi semplicemente abbassare la terminazione / pullup ... ma l'OP è troppo grande di 10: 1.

— Jack Creasey,

9

Come ho notato in un commento, è difficile eseguire il debug senza una traccia dell'oscilloscopio, ma la prima cosa che si distingue dalla tua domanda è il resistore pull-up da 10 kOhm. Questo è insolitamente alto per I2C, anche se potrebbe facilmente funzionare in molti casi.

Vorrei provare ad abbassarli prima a 1 kOhm, per vedere se influenzerà qualcosa. Se aiuta, puoi gradualmente aumentarli, anche se ciò influirà sui tuoi tempi di salita.

— tubo
fonte

10 k non è così grande per un bus I2C a 10 kHz, però? (O dovrebbe essere 100 kHz OP?)

Ω

$\Omega$

— Huisman,

@ Huisman Due buoni punti. 10 kOhm non mi preoccuperebbero a 10 kHz su un normale PCB ma forse non è abbastanza tramite il cavo. E 10 kHz è insolito ma non pazzo insolito, immagino.

— pipe

7

10k Ohm è enorme per I2C su qualsiasi distanza. Questo è il problema principale dell'OP.

— Jack Creasey,

1

Immagino sia meglio dividere i resistori e usarne uno su ciascuna estremità. 2 resistori pullup da 4,7 kΩ, uno su ciascuna estremità, dovrebbero essere una scelta migliore di un singolo resistore pullup da 2,2 kΩ.

— 12431234123412341234123

Proverò ad abbassare i resistori, questo è tutto ciò che mi viene in mente dopo tutti quei commenti.

— user3503519

5

Devi assolutamente far cadere le resistenze di pullup a lunghe distanze, e 10m è una lunga strada e 10k Ohm è molto alto.

Il valore del resistore pullup è legato a tre cose:

Capacità del cavo
Mirare alla tensione e al senso del livello Rx.
Velocità

Prova a utilizzare uno dei calcolatori disponibili e inizia a leggere qui con l'appnote TI sui valori di pullup o qui con lo standard NXP I2C (7.1).

In termini di problema riscontrato, dovrebbe essere ovvio che la messa a terra di coppie addizionali (12V, Gnd) nel cavo cambierà la capacità ai fili del segnale I2C.

— Jack Creasey
fonte

2

Sono d'accordo, si può presumere che il cavo CAT5 abbia circa 50pF per metro, quindi 10 metri superano il limite di capacità di 400pF delle specifiche I2C. E il raggiungimento del clock I2C a 400kHz non può essere raggiunto con capacità di 400pF utilizzando la corrente di pull-up 3mA specificata dai resistori. Fortunatamente, il rallentamento della velocità aiuterà, a meno che i dispositivi non abbiano una limitazione minima della velocità di clock. Non sappiamo quali siano questi dispositivi e quali siano le tensioni del bus I2C, ma in effetti i pullup dovrebbero essere regolati per fornire almeno 3 mA e se i dispositivi consentono e concordano la tensione di basso livello del bus, allora ancora di più.

— Justme,

Sì, ci proverò con quello, ma la mia domanda è: perché funziona se non c'è alimentazione su quel cavo?

— user3503519

Una coppia di cavi fluttuanti non ha la stessa capacità della coppia di segnali che ha quando il cavo è collegato a terra. Per la tua configurazione, sia il +12 che il Gnd sono essenzialmente gli stessi ... hanno una capacità al cavo di segnale che influisce sul tempo di attività. .

— Jack Creasey,

2

Alcune note:

Ottenere i giusti valori pull up è vitale, in particolare per SDA. Dispositivi diversi possono assorbire quantità diverse di corrente. Ho visto configurazioni che generano 1 extra nei dati a causa di un resistore pull-up troppo piccolo, dopo essere passato a un chip sensore più piccolo. Le geometrie più piccole significavano che non poteva portare il bus a zero pulito.

La velocità uccide. Un cavo lungo è effettivamente un filtro LRC passa basso. Per molte applicazioni I2C è possibile rallentare il tempo senza perdere nulla. Un clock più lento può compensare un pull-up debole e una grande capacità (ma non un pull-up troppo forte).

I cavi lunghi sono un invito a EMI. Ho visto un'implementazione I2C che aveva bisogno di un morsetto in ferrite per superare i test di immunità. La terminazione finale, il cavo schermato o i filtri possono aiutare.

Attenzione alla resistenza parallela. Se hai un pull-up di 1k sul master e quindi un 1k su ciascuno dei quattro dispositivi client sul bus, allora hai un pull-up netto di 200 Ohm. Non funzionerà.

— Jason Treon
fonte

0

La breakout board Sparkfun I2C è una bella soluzione che presenta:

PCA9615 buffer
I2C Supply voltage range 2.3-5.5V
Differential Supply voltage range 3-5.5V
draws 16µA of current
Extends I2C bus up to 100 feet
Data rate up to 400kHz
2x Qwiic Connectors

— Gatorback
fonte

-1

Primo: voglio ringraziare la community per aver pubblicato una risposta.
Secondo: ho trovato una soluzione basata su quelle risposte, ecco cosa ho fatto:

Resistenze di pullup abbassate testate a 4.7K e 2K. Su 2K comincio a ricevere di tanto in tanto delle risposte, quindi mi abbasso a 1K, quindi comincio a ricevere risposte, ma una parte dei dati mancava da ognuna di esse. Dopodiché, la resistenza pullup è stata commutata sul pin SDA con 10K e tutto inizia a funzionare in modo stabile.
Quindi la soluzione nel mio caso è 1K pullup su SCL e 10K su SDA.

Grazie per il tuo tempo.

— user3503519
fonte

1

È pazzo però. Che tipo di hardware usi qui? Forse qualcosa non è configurato correttamente.

— pipe

1

Da un lato è ESP32 con micropython, dall'altro è atmega8 programmato con IDE arduino. Alla fine non lo considero una comunicazione sicura, quindi passerò al seriale (RS232), poiché l'ho testato funziona benissimo su quelle gamme

— user3503519

1

Se fossi in te darei anche un'occhiata a RS-485 che sarebbe ancora più robusto e ancora più semplice. Lo svantaggio è che richiede più cavi di segnale ma ne hai già molti nel tuo CAT5.

— pipe

1

Bene, non vedo come implementare direttamente RS-485 sul processore atmega o ESP 32 senza convertitori e hardware aggiuntivi, quindi RS-232 è la scelta migliore qui. Verrà utilizzato solo un cambio di livello TTL.

— user3503519