Comprensione delle velocità di trasmissione dei dati tramite filo di rame

Ho studiato i diversi modi per collegare i sensori a un Arduino e i2c sembra essere un metodo popolare. Ho letto che è affidabile solo a brevi distanze (pochi metri, al massimo), con una velocità dati di 400 o 100 kbps. Sto facendo fatica a capire perché i limiti di questo protocollo sono così bassi rispetto ad altre trasmissioni di dati su rame, come Gigabit Ethernet. Ho visto ragioni come capacità, caduta di tensione e resistenza fornite, ma Ethernet su cat5 / 6 non è soggetta a tutti quegli stessi problemi? Fondamentalmente, voglio sapere perché abbattere un po 'di tensione su un filo di rame non produce risultati più coerenti (larghezza di banda, distanza) quando si confrontano queste diverse metodologie.

Il teorema di Shannon imposta il limite ultimo della larghezza di banda delle informazioni su un cavo. Ecco alcune ulteriori informazioni a riguardo: https://www.gaussianwaves.com/2008/04/channel-capacity/

TL; versione dr: l'equazione di Shannon-Hartley:

• $C = B \; log_2 \left( 1 + \frac{S}{N}\right) \;\;\;\;\;\;\;\;\;\; \rightarrow (1)$

Dove è la larghezza di banda in Hz, è il rapporto segnale-rumore.$B$$\frac{S}{N}$

I2C ovviamente non è vicino al limite di Shannon per un cavo. Al contrario, è un protocollo leggero con tempismo intenzionalmente lento (100/400 kbit / s) che utilizza un bus open collector per semplificare l'implementazione per una rete di piccoli dispositivi con I / O e esigenze di controllo modesti. L'operazione lenta specificata da I2C evita la maggior parte dei problemi di integrità del segnale.

Esistono varianti più veloci di I2C che utilizzano velocità da 1 Mbit e 3,2 Mbit / s. Questi richiedono una maggiore attenzione al layout e alla terminazione rispetto al normale I2C e, naturalmente, hanno un tempismo più stretto e più impegnativo.

Salendo nella catena alimentare Shannon-saggia, Gbit Ethernet utilizza più tecniche per raggiungere il suo throughput:

• Segnalazione differenziale
• Coppie multiple (4)
• Segnalazione multilivello, chiamata PAM-5
• Preemphasis / Deemphasis
• Equalizzazione adattativa

Queste tecniche richiedono molto silicio, incluso un blocco ADC / DAC a segnale misto ampio e veloce per comunicare con il cavo e l'elaborazione del segnale abbastanza pesante per gestirlo. Aggiungi a questo, lo stack software molto più complesso per guidarlo. Questo rende Ethernet come un blocco su chip un po 'troppo per un microcontrollore di fascia bassa (alcuni dei quali scelgono invece di utilizzare un PHY esterno). La sua maturità lo colloca tuttavia alla portata di sistemi su chip più grandi.

Quanto siamo vicini al limite di Shannon, comunque? Altro qui: https://pdfs.semanticscholar.org/482f/5afbf88a06d192f7cb052f543625c4b66290.pdf

C'è di più nella trasmissione oltre al semplice cavo di rame. Hai visto l'hardware dietro Ethernet? Probabilmente no, perché è estremamente difficile trovare circuiti di livello base per ciò che sta realmente accadendo poiché le budella sono sempre nascoste in un circuito integrato. Il più vicino che abbia mai trovato sono i magnetici richiesti per Ethernet, che apparentemente non sono opzionali. Questo è solo un suggerimento di ciò che accade fisicamente con l'hardware Ethernet.

Pensaci in questo modo: l'aria è un mezzo. Perché il tipo di informazioni che possono essere trasmesse quando i cani parlano tra loro molto meno rispetto a quando gli umani parlano tra loro? Perché l'invio di alcune onde di pressione nell'aria non produce risultati più coerenti nella comunicazione tra questi due tipi di animali?

Solo alcuni dei fattori limitanti per I2C (e molti altri protocolli) sono:

1. unità open-collector
2. nessuna corrispondenza di impedenza
3. nessuna trasmissione bilanciata
4. nessun controllo errori
5. semplice schema di codifica
6. livelli di tensione relativamente elevati (se il passo della tensione non deve essere così grande, è possibile trasmettere più velocemente perché il tuo dV / dT non deve essere altrettanto elevato per velocità più elevate)
7. nessun isolamento
8. tensioni unipolari (Ethernet trasmette a +/- 2,5 V che probabilmente aiuta in qualche modo)
9. La trasmissione dello slave è sincronizzata dal master, quindi sostanzialmente l'orologio deve fare un round trip più veloce del segnale dati

Tutti questi sono buoni per rendere le cose semplici. Non così buono per velocità dati elevate o trasmissione a lunga distanza.

Probabilmente c'è anche qualche altro voodoo in corso nell'hardware che non conosco.

Alcune semplici regole empiriche: non esiste un terreno. Tutti i fili sono antenne. Tutti i fili sono linee di trasmissione. C'è sempre rumore.

Se un filo è corto rispetto al tempo di salita del segnale, allora si può ignorare i disallineamenti e le riflessioni di impedenza della linea di trasmissione (a differenza di Ethernet, che richiede terminazioni complesse e modulazione di impulsi). Se il filo è lungo, allora le tensioni indotte sul filo e sui differenziali di terra hanno maggiori probabilità di rendere i livelli del segnale digitale all'estremità remota indeterminati o errati. Ma Ethernet utilizza la segnalazione differenziale a doppino intrecciato, riducendo notevolmente il rumore indotto e i problemi di riferimento a terra. Il ricevitore Ethernet utilizza anche ingressi analogici più sensibili rispetto ai tipici ingressi digitali, consentendo così una maggiore perdita di linea. Aggiungete la codifica Ethernet e la correzione degli errori per superare le statistiche del rumore e potete andare più velocemente e in modo più affidabile.

I2C è un bus di drain aperto , è attivamente abbassato, ma i pull up (almeno per le normali varianti da 100kHz, 400kHz) sono resistori passivi.

Per questo motivo esiste un limite alla velocità con cui la cosa può funzionare in base alla velocità con cui i resistori di pull-up possono caricare la capacità del bus, a volte puoi ottenere un po 'più di velocità abbassando i valori di pull-up, ma ciò significa che i nodi devono affondare più corrente per ottenere una logica bassa .... Oppure puoi andare dall'altra parte, rallenta il bus per consentire l'uso di resistori pull up di valore più elevato per una minore dissipazione di potenza (vedi ad esempio bus PM).

È istruttivo accendere un campo di applicazione e notare che il fronte di discesa su I2C è MOLTO più nitido di quello in aumento.

Per l'uso previsto, fondamentalmente sensori di temperatura e piccoli dispositivi di configurazione all'interno di una singola scheda (o al massimo un singolo chassis), ciò si rivela praticamente all'altezza tra complessità di implementazione, numero di pin basso e hardware semplice. L'intento progettuale non era quello di "collegamenti dati veloci e di lunga distanza" e, nonostante tutto, trovo che SPI sia generalmente più facile da gestire, I2C si adatta molto bene al caso d'uso previsto.

Una volta che le distanze aumentano, qualcos'altro diventa più adatto, ma su una scheda con interfacce di configurazione eeprom / temperatura / dispositivo modeste, funziona abbastanza bene (vale la pena notare che l'interfaccia di gestione PHY sembra MOLTO come I2C).

I diversi risultati sono perché il circuito del driver è diverso per ogni tecnologia.

I2C a 100 kHz utilizza in genere un resistore pullup per mettere il segnale a un livello elevato e driver a drain aperto per portare il segnale a un livello basso.

Le resistenze pullup sono in genere diversi chilo-ohm. Più lungo è il cavo, maggiore sarà la capacità che avrà. Il tempo impiegato dalla linea per passare da 0 a 1 sarà proporzionale alla capacità totale sulla linea e al valore della resistenza di pullup. Da qualche parte nell'intervallo di circa T = 2 * R * C sarebbe giusto.

Ad esempio, se si disponesse di un cavo da 10 piedi con 20pF per piede di capacità e si utilizzasse un resistore pullup da 10K, sarebbe necessario T = 2 * 20pF / ft * 10 ft * 10K = 3,6us per passare da basso ad alto.

In questo caso, ovviamente, non potresti avere nessun bit dopo uno zero che fosse largo meno di 3,6us, quindi la tua velocità di trasmissione sarebbe limitata a 277kHz.

In un vero sistema I2C, la specifica I2C impone ulteriormente i tempi di configurazione e di attesa relativi alle transizioni di dati e clock. Quei tempi sono centinaia di nanosecondi o microsecondi. Il tempismo è stato reso molto lento di proposito in modo che i dispositivi potessero essere implementati a buon mercato (centesimi) e consumare pochissima energia (milliwatt).

D'altra parte, Ethernet può funzionare più velocemente nonostante la capacità del cavo perché non utilizza una resistenza di pullup. Guida attivamente verso l'alto o il basso nel cavo. Il driver ha una bassa impedenza e può caricare qualsiasi capacità di linea molto rapidamente. Certo che tutto ha un prezzo. La rete Ethernet consuma in genere centinaia di mW di energia e costa almeno qualche dollaro per porta da implementare.

Una configurazione simile a I2C potrebbe funzionare più velocemente, sicuramente, basta cambiare il pullup da 10K a 100 ohm e ora il tuo tempo di salita in 10 piedi di cavo scende da 3,6 a 36 ns. Probabilmente potresti quindi correre a circa 10 MHz senza troppi problemi (a parte il fatto che i normali chip I2C non possono parlare così velocemente).