Welcome to EDAboard.com

Welcome to our site! EDAboard.com 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?

cupoftea

Full Member level 6
Joined
Jun 13, 2021
Messages
331
Helped
5
Reputation
10
Reaction score
12
Trophy points
18
Activity points
2,059
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

Super Moderator
Staff member
Joined
Apr 17, 2014
Messages
20,490
Helped
4,461
Reputation
8,931
Reaction score
4,490
Trophy points
1,393
Activity points
135,472
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
 

cupoftea

Full Member level 6
Joined
Jun 13, 2021
Messages
331
Helped
5
Reputation
10
Reaction score
12
Trophy points
18
Activity points
2,059
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.
 

LaTeX Commands Quick-Menu:

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Top