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.

[malc-c]

From memory standard cat5 cable is not screened, its simply 4 sets of twitsted pairs. You might be better off using some form of screened cable like this

http://www.homestead.co.uk/CategoryImages/WTMm.jpg

From the website http://www.homestead.co.uk/productcategorydetail.aspx?categoryid=51023


100% overall foil screened multicore cable manufactured to UL2464
100% overall foil screened multicore cable with drain wire and PVC outer sheath. Enables data to be transmitted over longer distances. Suitable for RS232 applications. 7/0.2mm tinned copper conductor, PVC insulated. Conductor resistance 79Ohms/Km, voltage rating 300V, temperature rating 80'C.
Send data over longer distances using twisted pair cable. Conductor resistance 79ohms/km, voltage rating 300v,temperature rating 80'c.

[BrianT]

The robustness of the error checking methodology needs common sense understanding of the sources and consequences of any error. Even a board with no outside communications can be knocked over by electrical interference and your system must cope with this. In most of my systems, there is plenty of redundancy and feedback that allows the system to recover gracefully from an error. Mostly, an error will become pretty obvious to the system and it will adopt some failsafe strategy until a clean data packet next comes along or the world is saved by the watchdog timer. If a single bit error cn blow up your plant then you have not designed it properly.

Error detection and correction is a very big field and there are many many books on the topic. Not for the faint hearted however and mostly very academic.

Checksums are regarded as the poor cousins. The best are the Cyclic Redundancy Check or CRC but the simple checksum (and there are many variants possible) is plenty good enough for most real world applications. There are many forms of CRC depending on the channel characteristics your message will experience. CRCs can only detect as many bit errors in the message as the length of the CRC. CRCs are computationally fairly heavy and IMHO if you really need a CRC your overall system probably needs more grunt than a humble PIC.

One simple but very robust system is to have the receiver immediately send the message back to the sender. If the sender got what he knows he sent he can be pretty sure it receiver has it too and can stop sending. The receiver only acts on the message after it stops flowing or via some other strategy. This will fall over where identical errors in both paths cancel each other but that is usually a vanishingly small probability.

Another method is to have the sender repeat the message several/many times and the receiver must get two or more identical versions before acting.

The quick and dirty checksum works for me. These are a simple addition of the bytes in the message. The checksum can be as long as you want but 8 bits (one byte) will catch 99.99% of all errors.

I always send a throwaway flag character, or force the line to a steady mark (-ve on the RS232 send pin, i.e. make the serout pin high at TTL level) for 25 mSecs or so before starting the data. Radio systems need a different preamble. The message starts after a flag character, typically the $ sign. The data string follows and then an 8 bit checksum. I usually start my checksum with an offset added to cope with the all 1 or all 0 case. It can help if you keep the messages all the same length even if the payload in the message varies.

Declare an array at the start

A var byte
B var byte
MSG var byte[8] ' or as long as you need
Chek var byte

Fill the array with your data. For example
Msg[0] = "M"
Msg[1] = "e"
Msg[2] = "s"
Msg[3] = "s"
Msg[4] = "a"
Msg[5] = "g"
Msg[6] = "e"
Msg[7] = " "

Calculate the checksum

Cheksum = 39 'This can be any number but preferably not zero. It serves to make the cheksum nonzero when the message is all zeros which could be a fault condition at the sender.

For a = 0 to 7
cheksum = cheksum + msg[a]
next a

send the message
serout pin, mode, [$FF, "$", Msg[0], msg[1], ......., msg[7], cheksum]


At the receiver
SERIN Pin,Mode,Timeout,Label,[$], msg[0], msg[1]........msg[7], cheksum

The Rx will wait for the $ then load from there.

Now check a locally generated checksum against the appended checksum from the sender.

B = 17 ' same seed value as the sender, obviously.
for a = 0 to 7
B = B + msg[a]
next a

if b = cheksum then we have clean data within the accuracy limits of a checksum.

HTH
Brian