Continue to Site

Welcome to

Welcome to our site! is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

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

Not open for further replies.


Advanced Member level 5
Jun 13, 2021
Reaction score
Trophy points
Activity points
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?


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.

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.

Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to