PIC to PIC Serial data using Cat5 cable

[Andy Wood]

Hello,

I am currently working on a project where two PIC's on two separate boards need to communicate serially over a distance of about 5 metres. I am looking to use UTP Cat5 cable to connect them together. As well as data, this cable will also carry the power supply from board 1 to board 2.

For noise immunity, is it best to use one of the twisted pairs for the power supply and another for the data, or will it not matter too much?

Thanks,

Andy Wood

[skimask]

Hello,
I am currently working on a project where two PIC's on two separate boards need to communicate serially over a distance of about 5 metres. I am looking to use UTP Cat5 cable to connect them together. As well as data, this cable will also carry the power supply from board 1 to board 2.
For noise immunity, is it best to use one of the twisted pairs for the power supply and another for the data, or will it not matter too much?
Thanks,
Andy Wood

Depends on what speed and how electrically noisy the area is and are you planning on using RS232 type connection, RS485, I2C, SPI, a differential signaling method, single wire, common grounds & power (which I'd assume based on what you said)?

[Andy Wood]

Depends on what speed and how electrically noisy the area is and are you planning on using RS232 type connection, RS485, I2C, SPI, a differential signaling method, single wire, common grounds & power (which I'd assume based on what you said)?

Hello Skimask,

Thanks for the reply. At this stage, data rate is 9600 baud using HSERIN/HSEROUT, logic level (no line drivers), common ground and power.

I suppose my question is, given the above, what is best practice?

Regards,

Andy Wood

[BrianT]

I regularly use 10-15 metre runs of cat5 cable between PICs. With a MAX232 interface chip I can get 115,200 bps at 15+ metres and at TTL I don't know the maximum because I have not had to go over 19,200 bps.

I find that the voltage drop in the pair(s) used for power means that I have to run 9+ volts and have a regulator at each remote PIC.

I use three wires for GND, 3 wires for PWR and the remaining two for data.

I wire these as
1 pair - PWR and PWR
1 pair - PWR and TxD
1 pair - GND and RxD
1 pair - GND and GND

I always use a checksum on every message passed and flash a LED when an error is detected. From the occasional flash of the error LED there are real world noise issues as with every form of serial comms beyond the PCB.

[Andy Wood]

I regularly use 10-15 metre runs of cat5 cable between PICs. With a MAX232 interface chip I can get 115,200 bps at 15+ metres and at TTL I don't know the maximum because I have not had to go over 19,200 bps.

I find that the voltage drop in the pair(s) used for power means that I have to run 9+ volts and have a regulator at each remote PIC.

I use three wires for GND, 3 wires for PWR and the remaining two for data.

I wire these as
1 pair - PWR and PWR
1 pair - PWR and TxD
1 pair - GND and RxD
1 pair - GND and GND

I always use a checksum on every message passed and flash a LED when an error is detected. From the occasional flash of the error LED there are real world noise issues as with every form of serial comms beyond the PCB.

Hello Brian,

That is excellent "real world" information you have supplied - thank you for sharing it. It certainly helps in establishing a few "rules of thumb".

Regarding the error checking - that was going to be one of my future questions. What did you find to be a reliable method without going overboard or having too much overhead. Is there any suggestions you have regarding which methods are better than others on a performance vs. overhead basis? I am only new to the serial comms aspect so any inforrmation would be appreciated.

Regards,

Andy Wood

[mackrackit]

The best error checking method? I would imagine every one here has their own preferences. It will depend some on the environment as to how much is needed or how much bad data is acceptable. ?

This is a good read http://www.linxtechnologies.com/Documents/AN-00160.pdf
It is for data over wireless, but the same applies. Page 4 starts the error checking methods.