PIC to PIC Serial data using Cat5 cable

[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



From the website http://www.homestead.co.uk/productca...tegoryid=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