EIA 485 over unused pairs of ethernet cable
Posted: | More posts about electronics arduino
To carry out my plan of a DIY home automation system (domotics) I am experimenting the use of the EIA 485 communications protocol. Having wired the house with lots of cat5 cables and knowing that two of the four pairs of which it is composed are not used for the 100Mbps, I tried to pass the signal on these wires to see if the two streams (TCP/IP and the EIA 485) could coexist without major problems. Here's how the test was performed.
I defined my own communication protocol as the EIA 485 only defines the physical parameters, as Master-Slave, half duplex with 14-byte frame consisting of address, the slave's actions, 5 bytes for data and one byte for checksum and other embroidery. For each frame received correctly, the slave sends an acknowledge to the master after performing the required action. The baud rate was set to 9600 bits/s serial communication 8-n-1 (8-bit data, no parity, 1 stop bit). To test these, the master cyclically sends once per second, request to slaves to put high one of their pins to turn on and off a LED. One of the pins of the PIC was connected to another LED programmed to turn on in case of the frame error, the bit FERR in the RCSTA register is set to 1 if the stop bit is erroneously detected as zero.
I've programmed a simple Arduino as a master, another Arduino and a pic 16f88 as a slave. In the photo appear beside the master and slave, the PIC16F88 is placed at the other end of the network cable about 10 meters long. For the test I did not use terminating resistors nor bias resistors since with these distances it' not required. A pair of wires is connected to pins A and B integrated the MAX485, the other was used for the reference (connected to ground, to avoid groundloops …) it according to a daisy chain connection scheme. Throughout the test I have maintained a steady stream of TCP/IP traffic node continuously pinging the node at the other end of cable. Result is that in over an hour of practice there was never a frame error (FERR bit was never set) and all the frames have been received correctly (no checksum errors). The TCP / IP traffic has not suffered any errors or delays (1% packet loss and response times in the standard).
Now we have to run the test with a much longer cable!