Per portare avanti il progetto di realizzare un mio sistema di automazione domestico (domotica) sto sperimentando l’utilizzo del protocollo di comunicazione EIA 485. Avendo cablato casa con molti cavi di rete e sapendo che 2 delle quattro coppie di cui è composto sono inutilizzate per la velocità di 100 Mb, ho provato a far transitare il segnale su questi fili per vedere se i due flussi (quello TCP/IP e l’EIA 485) potessero coesistere senza troppi problemi. Ecco come si è svolto il test:
Ho definito un mio protocollo di comunicazione dato che l’eia 485 definisce solo parametri fisici, di tipo Master-slave half duplex con frame di 14 byte composto da indirizzo, azione che lo slave deve eseguire, 5 byte per i dati, ed un byte per il checksum ed altri ricami. Per ogni frame correttamente ricevuto lo slave invia un acknowledge al master una volta eseguita l’azione richiesta. Il baudrate è stato settato a 9600 bit/s e la comunicazione seriale 8-n-1 (8 bit per i dati, nessun bit di parità, 1 stop bit). Per il test il master inviava ciclicamente, una volta al secondo, agli slave la richiesta di mettere alta e bassa una delle loro uscite in modo da accendere e spegnere un led. Uno dei pin del pic è stato collegato ad un altro led programmato per accendersi del caso di frame error, il bit FERR nel registro RCSTA è messo ad 1 nel caso che lo stop bit sia erroneamente rilevato come zero.
Ho programmato un Arduino come un semplice master, un altro Arduino ed un pic
16f88 come slave. Nella foto a lato compaiano il master e uno slave, il pic16f88 è posto all’altro capo del cavo di rete lungo circa 10 metri. Per il test non ho usato resistenze di terminazione ne resistenze di bias dato che le distanze in gioco cavo non lo richiedevano. Una delle coppie di cavi è stata collegata ai piedini A e B degli integrati MAX485, l’altra è stata usata per il riferimento (collegata a ground, occhio ad evitare groundloops…) il tutto seguendo uno schema di connessione daisy chain. Durante tutto il test sul cavo ethernet ho mantenuto un flusso costante di traffico TCP/IP pingando continuamente il nodo all’altra estremità. Risultato è che in oltre un’ora di prove non c’è stato mai un frame error (il bit FERR non è stato mai settato) e tutti i frame sono stati ricevuti correttamente (nessum checksum error). Anche il traffico TCP/IP non ha subito errori o rallentamenti (0% packet loss e tempi di risposta nella norma). Ora non resta che eseguire il test con un cavo molto più lungo.


Good job! I have a question, which software do you use to make the “cartoon schematics” ?
The Fritzing way!
Hi, I am really curiuos of the future of his project. Did you test with longer cables?
Thanks for reading. Hope to have time to do more tests in near future.