Come portare corrente e dati su unico doppino?

Dispongo di una rete di sensori che attualmente 'parlano' via rs485 Un cavo da 4 poli che parte dal sistema centrale e viaggia attraverso tutti i sensori, 2 poli per l'alimentazione (24Vdc), altri 2 poli per la comunicazione Diciamo a 9600 baud giusto per dare un riferimento di velocita'

Volendo usare un cavo unico da 2 poli, come portare alimentazione e segnali sullo stesso doppino? C'e' qualche aggeggio gia' pronto per iniettare/decodificare i dati sulla linea alimentazione?

Un bel giorno RobertoA digitò:

Per una bit rate così bassa probabilmente te la cavi semplicemente con due condensatori. Guarda questa app note:

Il 05/05/2025 10:21, dalai lamah ha scritto:

Documento molto interessante Soprattutto per il fatto che a 100 nsec al bit, sembra stiano trasmettendo a 10 megabaud circa, notevolissimo

"RobertoA" ha scritto nel messaggio news:vv9pbb$3vmmk$ snipped-for-privacy@dont-email.me...

esistono oggetti gia' fatti per il segnale video composito, chiamati PoC, Power over Coaxial, forse possono andar bene anche per il tuo segnale seriale, che pero' dovrai convertire da differenziale a single ended e viceversa.

Il 05/05/2025 16:37, RobertoA ha scritto:

Probabilmente in questo caso i problemi nascono se diminuisci troppo il baudrate, in quanto il contenuto spettrale dei dati si potrebbe avvicinare troppo alla continua ed essere filtrato dai condensatori.

Usare baudrate molto alti aiuta la separazione tra l'alimentazione sul bus e i dati, ma porterebbe ad altri problemi di integrità del segnale, soprattutto su cavi lunghi e mal terminati.

Poi non ho capito quando dicono:

Stiamo parlando di un transceiver RS485 che viene tipicamente "alimentato" da una UART. Quindi il segnale è il classico della UART (start, data bits, parity bits, stop bits). Inoltre il contenuto in DC dipende anche dal protocollo. Se il master interroga gli slave ogni secondo, avrò un forte contenuto in DC.

Come posso cambiare questa forma d'onda con Manchester o similari?

Hai già il doppino che intendi usare? Nel senso che se la corrente di alimentazione e/o distanza sono importanti poi servirà una certa sezione del conduttore. Si trova un cavo UTP della sezione adeguata?

Un bel giorno pozz digitò:

Probabilmente loro assumono che si utilizzi una MCU in grado di generare dati codificati in manchester o 8b/10b. Qualche costruttore ti fornisce anche delle app notes al riguardo:

Al limite si può anche fare "manualmente" con dei GPIO, per 9600 bps non dovrebbe essere un problema anche se è piuttosto inelegante. Anche per questo ci sono alcune app notes:

Il 06/05/2025 11:12, dalai lamah ha scritto:

Ok, ma tu stai ipotizzando di "alimentare" il transceiver RS485 con un qualcosa di completamente diverso da una UART. Quindi, prima di tutto, se l'hw è già disponibile, non puoi semplicemente aggiungere l'alimentazione sul cavo dati con condensatori ed induttanze come mostrato nella app note della TI che avevi linkato all'inizio.

Poi certo, con dei GPIO o periferiche più esotiche, qualcosa si può implementare. Ma si tratta di abbandonare la comodità della UART e non so quanto ne valga la pena.

Un bel giorno pozz digitò:

La app note TI mostra un "proof of concept", non è un vero e proprio prodotto, tanto è vero che non lo vendono nemmeno sebbene forniscano gerber, bom ecc. Più che altro il mio era uno spunto per dire che probabilmente basta disaccoppiare con un paio di condensatori e usare una codifica a valor medio nullo.

Se non puoi usare una codifica a valor medio nullo allora dovrai implementare dei circuiti che operino la conversione UART-nullo e nullo-UART.

Se ti serve qualcosa di già pronto e lo devi collegare a una UART standard, sinceramente non saprei. Non ho trovato granché, a parte alcune pagine di prodotti di costruttori piuttosto oscuri.

Se dici che non ne vale la pena significa che hai un'alternativa migliore, qual è? :)

Un bel giorno dalai lamah digitò:

In realtà potrebbe valer la pena di fare anche una prova con la "normale" codifica UART. In teoria è sufficiente usare condensatori abbastanza grandi affinché nel caso peggiore (nove valori "1" consecutivi) il nodo disaccoppiato non faccia in tempo a tornare a tensione nulla (che corrisponde al valore "0"). Con i condensatori da 10 uF usati nell'app note TI per me ci si riesce.

Il 06/05/2025 15:24, dalai lamah ha scritto:

Forse dimentichi le pause tra un byte e l'altro che potrebbero essere importanti e dipendono da come è implementato il protocollo a livello software nei vari nodi.

Non solo, se un nodo muore e non risponde, il master va in timeout, probabilmente di qualche secondo e lì la continua non riesci a bloccarla.

Il 06/05/2025 15:17, dalai lamah ha scritto:

Porti l'alimentazione con altri due conduttori :-)

Un bel giorno pozz digitò:

La continua la blocchi sicuramente, visto che ci sono i condensatori. Col bus "idle" la tensione ai capi del nodo disaccoppiato tenderà sempre ad andare a 0V, che corrisponde al livello "0" (di solito la soglia dei transceiver RS485 è intorno ai -100 mV) e quindi a uno stop bit.

Il caso peggiore è quello opposto, ossia quello dove i byte sono inviati continuamente. In questo caso il bit di stop lavora contro di te, perché riporta la tensione sul nodo a un valore positivo, per cui allo start bit successivo avrai meno margine.

Ho fatto un piccolo circuito LTspice per descrivere la cosa, vedi sotto. Ho assunto di impiegare un transceiver a 3.3V (che quindi genera segnali differenziali -3.3V e +3.3V) e di partire da condizione idle (quindi nodo a

-6.6V come per il primo byte). A regime avremo che in corrispondenza del bit di start la tensione scenderà solo fino a -1.2V, e durante la trasmissione degli "1" risalirà fino a -0.27V. Quindi siamo molto vicini alla soglia, ma probabilmente ancora sotto.

Diciamo che se si sta parlando di un'applicazione industriale, dove magari è presente anche una certa quantità di rumore, questi margini non sono rassicuranti... ma in linea teorica potrebbe funzionare.

Bisognerebbe fare l'analisi anche per il caso opposto (trasmissione anziché ricezione) ma assumendo che anche il resto del bus sia terminato a 120 ohm probabilmente dovrebbe essere simile.

Version 4.1 SHEET 1 880 1236 WIRE 176 80 80 80 WIRE 256 80 240 80 WIRE 304 80 256 80 WIRE 80 128 80 80 WIRE 304 128 304 80 WIRE 80 272 80 208 WIRE 176 272 80 272 WIRE 304 272 304 208 WIRE 304 272 240 272 WIRE 304 320 304 272 FLAG 304 320 0 FLAG 256 80 A SYMBOL voltage 80 112 R0 WINDOW 0 -249 26 Left 2 WINDOW 3 -527 59 Left 2 WINDOW 123 0 0 Left 0 WINDOW 39 0 0 Left 0 SYMATTR InstName V1 SYMATTR Value PULSE(3.3 -3.3 0.1 1u 1u 900u 1000u) SYMBOL cap 240 64 R90 WINDOW 0 0 32 VBottom 2 WINDOW 3 32 32 VTop 2 SYMATTR InstName C1 SYMATTR Value 10µ SYMBOL cap 240 256 R90 WINDOW 0 0 32 VBottom 2 WINDOW 3 32 32 VTop 2 SYMATTR InstName C2 SYMATTR Value 10µ SYMBOL res 288 112 R0 SYMATTR InstName R1 SYMATTR Value 120 TEXT -312 344 Left 2 !.tran .2

Credo che si potrebbe fare qualcosa di simile al circuito di clampa del sincronismo che si usava per ricostruire la DC del segnale TV composito accoppiato in AC. In realta', essendo un segnale con due soli livelli, e' molto piu' facile e si puo' resettare la clampa ad es. al livello del bit di start usando qualunque bit con lo stesso livello (mark), per cui non servirebbe neanche sincronizzarsi col frame. Un po' di complicazione deriva dal segnale differenziale, sarebbe piu' semplice modulare con accoppiamento AC una sola delle linee in RS-232, lasciando il riferimento freddo. Ad esempio, per ispirazione:

non si potrebbe usare il segnale da inviare sul doppino per modulare in AM una portante, e mandare quella sul doppino ?

No, non ho ancora niente, volevo prima capire se era cosa fattibile senza tanti smadonnamenti Corrente e distanza sono limitate, circa 250mA di consumo totale, circa

Una semplice AM richiederebbe una portante a frequenza ben piu' alta del baud-rate per essere demodulabile coi fronti che preservino il timing, per cui avrebbe problemi di attenuazione col doppino lungo. Si potrebbe implementare una ASK sincrona: ad es. trasmettere una singola sinusoide (intera e lunga quanto un bit) al posto di un bit a 1, nulla al posto di un bit a zero. Ma occuperebbe comunque parecchia banda e sarebbe piu' complicato che recuperare la DC con una clampa.

Ciao,

Nel tu caso, avendo una velocità di trasmissione di 9600bps e 50m di linea, il terminatore probabilmente non è indispensabile. Altrimenti al consumo degli slaves bisognerebbe poi aggiungere il consumo dovuto al terminatore di linea.

Twistato ok, i cavi per rs-485 hanno però impedenza caratteristica attorno ai 120 Ohm; il doppino per videocitofono non lo so.

Credo che alla velocita ipotizzata, e con le lunghezze indicate, anche se la linea non e' chiusa perfettamente, problemi non dovrebbero esserci Spero... :)