Invio affidabile di I2C tramite cavi Cat5

Sto pensando di impiantare un sistema di automazione domestica attorno al mio Raspberry Pi, ma ho trovato il prezzo e lo spazio richiesto per inserire un Pi ogni posto in cui un certo controllo è richiesto troppo ma i cavi Cat5e richiesti per questo progetto sono già installati durante il rinnovo. Ho alcuni PCF8574, PCF8591 e SSR in giro, quindi è possibile guidarli usando cavi Cat5e?

Tutti i cavi Cat5e sono già cablati con pinout TIA / EIA 568B. Fanno parte del mio cablaggio strutturale e non sono schermati, quindi è necessaria una tensione di linea più elevata. Sto pensando di inviare linee di alimentazione e I2C sul cavo, con questo pinout:

Pin 1 (Pair 1): SCL+
Pin 2 (Pair 1): SCL-
Pin 3 (Pair 2): SDA+
Pin 4 (Pair 3): +12V
Pin 5 (Pair 3): +12V
Pin 6 (Pair 2): SDA-
Pin 7 (Pair 4): GND
Pin 8 (Pair 4): GND

La disposizione dei pin di alimentazione è la stessa del cablaggio PoE 100BASE-TX, quindi anche la potenza nominale sarà la stessa, e l'utilizzo del segnale differenziale bidirezionale si trova in 1000BASE-T che richiede Cat5e.

Le linee I2C SCL e SDA originali sono derivate in due coppie differenziali bidirezionali ai livelli TTL (lo scarico aperto non viene mantenuto sul filo, ma ripristinato nel dispositivo di terminazione / spostamento del livello che sto progettando)

Qualche suggerimento al riguardo? Inoltre, quale chip dovrei usare per convertire le linee I2C nella segnalazione differenziale? Per favore, suggeriscimi chip con l'opzione DIP through-hole. Non so come gestire le cose SMT.

MODIFICARE

Ho trovato questo chip, SN65LBC180, è una buona scelta? Come collegarlo in un'unità bidirezionale? Come spostare il livello (è una parte BiCMOS che richiede il livello TTL ma le unità Pi a livelli CMOS 3.3v) e renderlo compatibile con lo scarico aperto?

MODIFICA 2

I commentatori hanno suggerito RS-485 che mi è sembrato accettabile, ma le due coppie differenziali devono comunque essere bidirezionali e solo due coppie differenziali bidirezionali. Sto riproponendo i cavi Ethernet esistenti.

MODIFICA 3

Da quando qualcuno l'ha allevato, non posso usare CAN. Non è possibile adattare CAN su RPi senza sacrificare nulla (SPI è occupato da un touchscreen, quindi nessun convertitore da SPI a CAN)

Sono a conoscenza della limitazione di I2C PHY, quindi sto essenzialmente cercando di adattare 1000BASE-T PHY ad esso - segnalazione differenziale bidirezionale per segnali SCL e SDA, ma per di più esegue il protocollo I2C.

MODIFICA 4

Mi è venuto in mente un nuovo chip: NXP P82B96 che divide I2C in 4 linee unidirezionali, che a loro volta possono essere utilizzate per alimentare SN65LBC180 attraverso optoisolamento (solo lato Pi) per formare una segnalazione pronta a lunga distanza a 8 pin. Ora ho solo bisogno di capire come ottenere energia attraverso il filo o come determinare se il bus sta inviando e rendere bidirezionali le coppie.

MODIFICA 5

Dai suggerimenti di risposte, penso di aver bisogno di cambiare un po 'la potenza del pinout:

Pin 1 (Pair 1): SCL+
Pin 2 (Pair 1): SCL-
Pin 3 (Pair 2): SDA+
Pin 4 (Pair 3): +5V
Pin 5 (Pair 3): GND
Pin 6 (Pair 2): SDA-
Pin 7 (Pair 4): GND
Pin 8 (Pair 4): +12V

La tensione di segnalazione differenziale I2C è TTL. Il + 5V sulla coppia 3 proviene dal Pi, senza buffer ma fuso. La coppia + 12V + potrebbe non essere presente viene utilizzata solo per pilotare alcuni dispositivi ad alta potenza. Se necessario, il dispositivo può utilizzare il proprio alimentatore e lasciare entrambe le guide sospese non collegate o fornire la propria tensione più elevata ma utilizzare la guida 5V.

GRATTALO

Pinout è ancora il mio design originale, che è compatibile con 802.1af.

Cercare di fare con IIC è una cattiva idea. IIC è davvero pensato per la comunicazione tra chip su una singola scheda. Poiché la corrente massima richiesta per abbassare una linea è limitata, le linee hanno un'impedenza relativamente elevata (alcuni kΩ). Ciò significa che possono captare facilmente il rumore, il che è un grave problema quando si esegue un cavo non schermato nelle pareti, probabilmente proprio accanto ai cavi di alimentazione CA.

Vorrei usare CAN per questo. CAN utilizza una singola coppia intrecciata unita con solo 60 Ω in un punto qualsiasi e il segnale è differenziale. Ciò significa che la maggior parte dell'inevitabile rumore di modo comune che verrà rilevato a causa dell'accoppiamento capacitivo può essere annullato dai ricevitori. CAN in esecuzione a 500 kbit / s può coprire qualcosa delle dimensioni di una casa normale.

Molti microcontrollori sono oggi disponibili con CAN integrato. Di solito è necessario un chip tranceiver fisico separato (come il comune MCP2551), ma i pochi strati più bassi del protocollo sono implementati in silicio nella periferica CAN. Il firmware interagisce con il bus CAN a livello di invio e ricezione di pacchetti completi. Il rilevamento e il tentativo di collisione, la generazione di checksum, i dettagli della segnalazione del pacchetto bus, la convalida del checksum ricevuto e la regolazione della deriva dell'orologio sono tutti gestiti per voi.

Non cadere per RS-485. È una reliquia di un'epoca passata. Utilizza anche un singolo segnale differenziale come CAN, quindi ha anche una buona immunità al rumore. Tuttavia, la gente di solito si innamora di RS-485 perché sembra "più semplice". Questo solo perché non guardano l'intero sistema. Innanzitutto, non è davvero meno complesso elettricamente. Avrai ancora bisogno di una sorta di transciever per guidare e ricevere il segnale differenziale. Che tu abbia un ricetrasmettitore RS-485 collegato all'UART del microcontrollore o un MCP2551 collegato alla periferica CAN è praticamente irrilevante in termini di costi e complessità hardware. La grande differenza è che RS-485 ti lascia al livello di byte non elaborato (tramite UART). Ciò significa che per implementare qualsiasi sistema significativo e robusto, devi inventare il tuo protocollo per gestire il rilevamento delle collisioni, decidere come gestire i tentativi, la pacchettizzazione, la generazione e il controllo di checksum, il controllo del flusso, ecc. È possibile utilizzare un'unica architettura master, ma ottenere i dettagli giusti è molto più complicato di quanto si pensi che non li abbia analizzati attentamente. Con CAN è sufficiente inviare e ricevere pacchetti e l'hardware si occupa dei dettagli.

I2C non è la strada da percorrere. I trancievers CAN costano un dollaro ciascuno e puoi usarli come trancieves uart e scrivere il tuo protocollo in modo da non aver bisogno di un micro compatibile can di te non vuoi usare l'intero stack.

Mi sento sempre un po 'a disagio quando vedo i conduttori cat5 correre in parallelo per più corrente. Mi dà fastidio perché se un conduttore si rompe, l'altro porterà tutta la corrente del sistema. Le valutazioni attuali di cat5 sono molto conservative, quindi le probabilità di un incendio sono piuttosto basse ma non mi piace la possibilità.

Il modo sicuro per farlo è quello di avere un polifusibile su entrambe le guide di alimentazione e unire i terreni all'alimentazione e collegare ciascun dispositivo a uno e un solo set di alimentazione / terra. In questo modo se un filo si guasta, i dispositivi che usano quella linea perdono energia invece che una linea sia costretta a trasportare la potenza di due.

A molte persone piace mettere potenza e terra in entrambe le coppie intrecciate per motivi EMI invece di avere una coppia di potenza e una coppia di terra. Se si hanno due coppie di potenza / terra, la linea di alimentazione sarà più vicina a terra e i campi si annulleranno, riducendo le onde radio trasmesse o ricevute dalle linee di alimentazione. Non necessario, ma bello se c'è un sacco di rumore elettrico che canticchia.

12 V secondo me è troppo basso per la distribuzione di energia quando 24 V è ancora ragionevolmente sicuro e molto più efficiente.

Se l'automazione sta semplicemente accendendo e spegnendo le cose in casa, semplificherei questo:

• Mantenere tutti i "cervelli" in un unico posto. Utilizzare gli espansori I / O I2C, se necessario, ma tenerli tutti con il raspberry pi. Avrai anche bisogno di hardware adeguato per assicurarti di non provare a ricevere troppa corrente dai pin GPIO del pi.
• Utilizzare i cavi Ethernet per guidare semplicemente i relè. È possibile costruire la propria scheda o ottenere relè a stato solido 120 / 240V montabili a pannello che verranno montati in una scatola elettrica. I fili nei cavi Ethernet Cat5 possono gestire fino a 50 V a 320 mA ciascuno, il che è più che sufficiente per pilotare un relè. In effetti, potresti guidare 7 relè da un singolo cavo (più un filo per terra). Oppure lascia un filo per un'uscita non commutata a 12 V, in modo da poter installare anche un interruttore manuale. Se durano molto a lungo, potrebbe essere necessario tenere conto della caduta di tensione, ma è possibile ottenere relè che passeranno a 3-32V. 12V dovrebbe essere più che sufficiente, anche con caduta di tensione.
• Si consiglia inoltre di consultare i codici di costruzione locali per consigli sulla miscelazione di cavi ad alta e bassa tensione nella stessa scatola.
• I semplici switch possono anche essere fatti attraverso i cavi Ethernet, ancora una volta fino a 7 per cavo, e semplicemente collegati agli ingressi del pi. La caduta di tensione può essere un problema per cavi molto lunghi.
• Potresti anche voler usare optoisolatori per proteggere il pi da danni.
• Per i pochi dispositivi che richiedono più di un relè (come un pannello di controllo) utilizzare i cavi Ethernet come Ethernet effettiva. Non dovrebbe essere una spesa enorme se non ci sono molti di questi dispositivi. Potrebbero essere un altro pi o un microcontrollore con Ethernet.

^{simula questo circuito - Schema creato usando CircuitLab}

EUREKA! Capito! (non testato, lo testerà questo fine settimana)

I chip di interfaccia sono NXP P82B96 buffer I2C / splitter e 2 chip di interfaccia CAN bus SN65HVD251P TI. In sostanza, sto eseguendo I2C su CAN PHY.

P82B96 comprende il protocollo I2C e gestisce l'arbitraggio del bus per me e mi dà pin Tx e Rx separati che possono essere collegati insieme. Le inserisco nel ricetrasmettitore CAN SN65HVD251P e mi dà la coppia differenziale bidirezionale da inviare via cavo.

I pin di alimentazione provengono direttamente, senza buffer dalla guida 5V del mio Pi. (Non userò la tensione e l'alimentazione di segnalazione a 12V per un po ')

Indipendentemente dal merito di IIC a livello di chip, l'implementazione proposta sarà molto difficile. Il problema è l'arbitrato del bus. Sebbene sia possibile mettere in parallelo più unità utilizzando, ad esempio, RS485, la grande domanda sarà:

Come fa qualsiasi unità a sapere se può assumere il controllo del bus per inviare i dati?

In IIC, con linee di segnale di drain aperte, il trasferimento bidirezionale è semplice, ma con i bus tristate è necessario un modo per garantire che solo un'unità tenti di guidare il bus alla volta. Questo sarà difficile. Puoi farlo, in particolare se stabilisci un unico master e richiedi che tutti gli slave abbiano vincoli di temporizzazione rigidi per l'invio dei dati e che inviino dati solo se richiesto dal master, ma ciò richiederà un notevole sforzo da parte tua nella progettazione del schede di interfaccia per master e slave.

Per quanto riguarda i driver / ricevitori fisici, RS485 ti farà bene e ci sono molti chip di interfaccia disponibili. Solo Google.

Non so se sei interessato a una soluzione premade invece di costruire il tuo circuito, ma ho pensato di sottolineare che Pololu vende queste schede di estensione differenziale a lunga distanza I²C realizzate da SJTbits, che sembrano fare praticamente esattamente quello che stai cercando. (Informativa completa: lavoro per Pololu.)

Anche se non vuoi usarlo direttamente, forse guardare il circuito che usa potrebbe darti alcune idee. Puoi vedere lo schema nel foglio dati; utilizza un buffer NXP PCA9600D, un driver di linea differenziale TI AM26LS31CDR e un ricevitore di linea differenziale TI AM26LS32ACDR.

So che questo è un po 'vecchio e una soluzione sembra essere stata risolta da qualche parte tra le risposte, ma ho avuto questo suggerimento da offrire. Esistono dispositivi come il PCA9614 / 5/6 di NXP che sto cercando in questo momento come una soluzione per un bus I2C a lunga distanza più robusto (buffer I2C-bus differenziale I2C multipunto Fast-mode Plus a 2 canali PCA96) . Essenzialmente è vero che sta diventando qualcosa di diverso dal vero I2C, ma alle estremità del bus è invisibile ai dispositivi. Questa particolare famiglia traduce i segnali in 2 coppie differenziali bidirezionali e ci sono anche dispositivi simili come già menzionato nei commenti, che si traducono in 4 coppie differenziali unidirezionali. La traduzione in sole 2 coppie ti consente di utilizzare il cavo CAT e di avere ancora 2 coppie per alimentazione / terra.

Pollice su! Attualmente sto cercando di risolvere praticamente lo stesso problema. Sto anche cercando di utilizzare I2C su cat5 per l'automazione domestica con il mio pinout personalizzato. Il motivo è il costo, voglio che sia molto conveniente e componenti I2C ancora almeno 5 volte più economici di persino attiny13 uC (AFAIU uC è richiesto per CAN e RS485).

1) Attualmente sono in fase di prova per la prima parte di un sistema e ora riesco con un cavo lungo 15 m con 5 V e connessione SCL e SDA diretta! Uso PCF8574 e 2 relè per attivare le luci della mia stanza. Pinout è

1
2 INT
3 +5V
4 SCL
5 SDA
6 GND
7
8

2) Capisco che non permetterà un paio di relè in più o altri 10 metri ... Una caduta di tensione è significativa (da 5,5 a 4,7). Quindi, per il problema della caduta di tensione, inserirò invece 12 V su una linea e aggiungerò regolatori di tensione 5 V sulle schede per mantenere la tensione fine ovunque, indipendentemente dall'intera caduta di linea. Metterò comunque alimentatori aggiuntivi durante le linee future.

3) Il segnale stesso può essere migliorato usando P82B96 o P82B715 economico senza suddividere in linee differenziali. Un NXP stesso usa Cat5 in alcune presentazioni ma non riesco a trovare la loro piedinatura. Una parte importante qui è che usano chiaramente linee di segnale in coppie diverse ... ad esempio una coppia è GND + SDA l'altra è VCC + SCL.

4) Un altro punto interessante: questo buffer può semplicemente aumentare un'ampiezza fino a 12V per aumentare la resistenza al rumore. Quindi, probabilmente proverò a mettere anche il 12V su una linea di segnale e questo dovrebbe consentire di inserire un pullup direttamente dal filo 12V ... Ma questo mi costringerà a mettere qualcosa come P82B96 su ogni dispositivo.

Come avrai notato, uso anche una linea di interruzione separata ... Il master è attualmente sulla scheda arduino collegata al PC. Il software principale principale sarà comunque su un PC 24x7, quindi arduino traduce solo il segnale e gestisce l'interrupt. Posso inviare una configurazione specifica per la gestione degli interrupt a bordo, ad es. Per gestire la comoda commutazione degli interruttori tramite interrupt ... Ciò mi consente di dimenticare eventuali ritardi quando si accende la luce manualmente. La gestione delle interruzioni è un ulteriore vantaggio di i2c.

Quindi la mia idea è che I2C sia abbastanza semplice da essere applicabile nel cablaggio di un appartamento in città <= 100m. Invece di andare al segnale differenziale, spero di poter invece ridurre la frequenza aggiuntiva.

Mi piace la tua idea di mettere sia 5V che 12V poiché questo riduce la necessità nei regolatori e riduce i costi ... l'intera idea del bus multi-filo per ridurre il costo degli endpoint, lo prenderò in considerazione anche per il nuovo pinout :)