Slave response delays due to cable length create a sync problem in SPI

A 4 metre cable of average sort of characteristics will delay a clock edge by about 20 ns from one end to the other. This is based on the edge travelling at about two-thirds the speed of light. In numbers, light takes 3.333 ns to travel 1 metre so, your cable will cause a clock edge to take 5 ns to travel 1 metre or, 20 ns to travel 4 metres.

So, when you initiate a master to slave transmission, it will take 20 ns for both clock and data to reach the slave. But, there shouldn't be any problem here because both clock and data are in phase and delayed the same amount. So, it's quite likely that your slave receives the master command and recognizes it.

The problem comes when the slave responds. It synchronizes its response to the clock it is receiving from the master and, that clock is fundamentally delayed by 20 ns so, by the time the slave response arrives at the master, it is 40 ns delayed from the master's clock edges.

This means that if the clock speed is such that slave data response (arriving at the master) is valid on the wrong clock edge from the master, you have garbage. That will happen at a clock speed of 12.5 MHz and you are wanting perfect operation at around maybe half this speed. However, that is the best case scenario.

Given that you have also termination issues (not the main problem) and multiple cable types (also not the main problem) I'm not surprised it doesn't work.

If you want to debug this, send a slave a message that doesn't require a response i.e. send it a simple message to toggle an IO line. I'd estimate that this type of message works just fine i.e. slaves are receiving data correctly. It then proves (fairly conclusively) that it is the return path that is the problem.

Slave response delays due to cable length create a sync problem in SPI

A 4 metre cable of average sort of characteristics will delay a clock edge by about 20 ns from one end to the other. This is based on the edge travelling at about two-thirds the speed of light. In numbers, light takes 3.333 ns to travel 1 metre so, your cable will cause a clock edge to take 5 ns to travel 1 metre or, 20 ns to travel 4 metres.

So, when you initiate a master to slave transmission, it will take 20 ns for both clock and data to reach the slave. But, there shouldn't be any problem here because both clock and data are in phase and delayed the same amount. So, it's quite likely that your slave receives the master command and recognizes it.

The problem comes when the slave responds. It synchronizes its response to the clock it is receiving from the master and, that clock is fundamentally delayed by 20 ns so, by the time the slave response arrives at the master, it is 40 ns delayed from the master's clock edges.

This means that if the clock speed is such that slave data response (arriving at the master) is valid on the wrong clock edge from the master, you have garbage. That will happen at a clock speed of 12.5 MHz and you are wanting perfect operation at around maybe half this speed. However, that is the best case scenario.

Given that you have also termination issues (not the main problem) and multiple cable types (also not the main problem) I'm not surprised it doesn't work.

If you want to debug this, send a slave a message that doesn't require a response i.e. send it a simple message to toggle an IO line. I'd estimate that this type of message works just fine i.e. slaves are receiving data correctly. It then proves (fairly conclusively) that it is the return path that is the problem.

• See also this answer
• And this answer
• And this answer

A 4 metre cable of average sort of characteristics will delay a clock edge by about 20 ns from one end to the other. This is based on the edge travelling at about two-thirds the speed of light. In numbers, light takes 3.333 ns to travel 1 metre so, your cable will cause a clock edge to take 5 ns to travel 1 metre or, 20 ns to travel 4 metres.

So, when you initiate a master to slave transmission, it will take 20 ns for both clock and data to reach the slave. But, there shouldn't be any problem here because both clock and data are in phase and delayed the same amount. So, it's quite likely that your slave receives the master command and recognizes it.

The problem comes when the slave responds. It synchronizes its response to the clock it is receiving from the master and, that clock is fundamentally delayed by 20 ns so, by the time the slave response arrives at the master, it is 40 ns delayed from the master's clock edges.

This means that if the clock speed is such that slave response data becomes valid on the wrong clock edge emanating from the master, you have garbage. That will happen at a clock speed of 12.5 MHz and you are wanting perfect operation at around maybe half this speed.

Given that you have also termination problems and multiple cable types I'm not surprised it doesn't work. If you want to debug this, send a slave a message that doesn't require a response i.e. send it a simple message to toggle an IO line. I'd estimate that this type of message works just fine i.e. slaves are receiving data correctly. It then proves (fairly conclusively) that it is the return path that is the problem.

Slave response delays due to cable length create a sync problem in SPI

A 4 metre cable of average sort of characteristics will delay a clock edge by about 20 ns from one end to the other. This is based on the edge travelling at about two-thirds the speed of light. In numbers, light takes 3.333 ns to travel 1 metre so, your cable will cause a clock edge to take 5 ns to travel 1 metre or, 20 ns to travel 4 metres.

So, when you initiate a master to slave transmission, it will take 20 ns for both clock and data to reach the slave. But, there shouldn't be any problem here because both clock and data are in phase and delayed the same amount. So, it's quite likely that your slave receives the master command and recognizes it.

The problem comes when the slave responds. It synchronizes its response to the clock it is receiving from the master and, that clock is fundamentally delayed by 20 ns so, by the time the slave response arrives at the master, it is 40 ns delayed from the master's clock edges.

This means that if the clock speed is such that slave data response (arriving at the master) is valid on the wrong clock edge from the master, you have garbage. That will happen at a clock speed of 12.5 MHz and you are wanting perfect operation at around maybe half this speed. However, that is the best case scenario.

Given that you have also termination issues (not the main problem) and multiple cable types (also not the main problem) I'm not surprised it doesn't work. 

If you want to debug this, send a slave a message that doesn't require a response i.e. send it a simple message to toggle an IO line. I'd estimate that this type of message works just fine i.e. slaves are receiving data correctly. It then proves (fairly conclusively) that it is the return path that is the problem.