Procedure for prooving that hardware is to blame for comms channel problems?

[cupoftea]

Hi,
I dont think i have ever worked on a project where the software engineers didnt endlessly blame the PCB and layout, noise etc, for problems with their comms channels...and hence the reason for their software not working.....
Is there not a "comms channel byte correspondance procedure" to proove beyond doubt that its the hardware thats messing up the software? (ie, messing it up by changing the bits of the bytes due to noise)

Surely all that needs to be done is have a microcontroller on one board, transmit a byte to a micro on the other board...then that micro transmit the byte back, (the byte that it 'thought' it received).....then do this 100000 times.......if every byte sent, correpsonds to every byte received...than that surely confirms that noise in the comms cables is not the problem? (and vice versa)
Why is this not done? why is this not a standard procedure? or is it?

 

[KlausST]

Hi,

There are several possible reasons for a fail.
...(besides PCB layout) bad wiring, wrong cables, wrong termination, too big noise, insufficient filtering, ground loops, bad timing, power supply and so on.

Indeed I tend to say there is no 100.000% reliable communcation interface.

So either live with these errors,
or check on errors (CRC, hash...) and do error handling (dismiss data, re send data...)

That´s one reason why we have protocols.

for a test:
I recommend for sending packets with random data and a hash. So you are able to detect wheter there is a problem with send or receive.

Klaus

 

[dick_freebird]

Software that requires perfect inputs is doomed.

 

[cupoftea]

Thanks, i think your point about timing is a very good one....its a shame each bit isnt sampled three (maybe more) times at equal intervals...and only deemed high or low if each sample was high/low.