CAN-Bus, one 60-Ohm instead of two 120-Ohm resistors

If one listener is close and another is far away on the cable, then the message takes different time to reach them.

And the buffers used means that from the transmitter wanting to send something, it takes some while until the signal have jumped through the transceiver or opto-isolator and even reached the bus.

So the transmitter must be patient and make sure that all listeners have had time to get the bit and sample it - and potentially respond and have this response reach back to the transmitter - before the transmitter can check if cable is in dominant or recessive state.

But if the cable is improperly terminated, or there are long stubs cables from the bus cable out to some listeners, or someone have splitted the bus, then there will be reflections in the cable. These reflections are added to the actual transmitted signal. The reflection will also move with the same propagation speed of the cable, so for a longer cable, the reflection will manage to destroy a longer part of the initial part of a transmitted bit. That is why you need to switch to slower transfer speeds when you increase the cable length - so your initial sampling happens after the reflections no longer affects the correct detection of low/high signal state.

Several of the links I posted do show oscilloscope images showing the result on the signal from these reflections. As can be seen, it is vital to minimize reflections if you want to run a high bitrate on a long cable.

So, this is very similar to, several persons A/B/C yell to a valley. A starts to talk. A has to wait for the first voice arriving B/C, after the first voice, if it is necessary; B or C yells back (replace recessive with dominant). Everyone has to wait a while to listen the word clearly; after that, everyone has to wait for the echo. After the echo, one word communication finishes, next word communication starts.

We need to minimize the echo; or we need to slowdown the talking speed. The propagation delay segment provides some buffers for replacing recessive with dominant, also provides some buffers for echo waiting. But with the same baud-rate, propagation delay segment can not provide enough buffers. If the propagation delay (the content of the word) has some good relationship with the echo, we may be still able to hear the word clearly; but it depends on luck.

Am I right?

And the echo may change the word unknowingly. everyone hears a wrong word without any problem noticed.

No - no buffering. The propagation delay segment is just how long to wait before starting to sample the contents of the bit.

When the frame starts, all receivers starts their timing clock - after that, they will just count time to figure out how far they are inside all the individual bits of a frame.

Signal delays affects how much error there will be for the different listeners to pick up the start of the transmission and start their individual stop watches.

And an echo that destroys a part of the beginning of every bit will further introduce errors in how well the different listeners can figure out where the bit starts.

So a bit can't be just sampled once. Instead, each individual bit is separated into a large number of small time slots. The first time slots are ignored because of the problem starting the stop watch at the same time - every listener must wait enough time that they are sure that what they read haven't already been overwritten by a competing transmitter. After having ignored the start of the bit, the CAN receiver can then start to sample the bit to figure out if it is recessive or dominant.

Your analogy with shouting fails a bit because there every token is a full word containing lots of information. In CAN, every token is a single bit.

So the guys in the mountains aren't shouting words. They are whistling morse, and the other guys needs to know if what they hear is whistling or the echo from whistling. So each beep of the morse code must be so slow that you really know if you hear whistling or if you hear silence - the echo of the whistling must end well before someone starts to whistle again so you know you hear silence.

Another difference in the analogy is that if I whistle for 10 seconds, the echo will also continue to echo that full 10 second sound (+ number of reflections etc). With reflection in the cable, it isn't the DC state that gets reflected but the flanks of the pulse. So for a high bit speed compared to cable length, the reflection will be as long as (or longer) than the pulse sent. For lower bit speeds, the reflection will end well before the pulse ends, since the reflection is just an edge that bounces (actually multiple times but weaker for every reflection). So a listener close to the end of the cable will instantly hear both original signal and reflection. A listener in middle of cable with start hearing a good signal, and after the signal have continued to the end of the cable and then bounced back, the reflection will start to interfere.

That is why you need to have a dead zone at the beginning of bits to compensate for cable delays and for any reflections to be low enough that they don't destroy the bit. And with a lower bit rate, each bit will be longer in time. So you can support a longer cable with correspondingly longer transfer times of signal and reflection.

If you look at water rippling, you can see how two waves can either cancel each other or magnify each other. Each edge of the CAN signal produces such a wave when the signal reaches some part that isn't 100% impedance-matched. With reasonably good matching, the new wave will have low amplitude and can be mostly ignored. With bad matching of impedance, the new wave will be very strong - almost as strong as the original signal. And sometimes it will add to the original bit data. Sometimes it will cancel.

A single 60 ohm resistor is always a bad match for a cable that have 120 ohm characteristic impedance. So there will always be strong reflections. If the cable is very short in relation to baudrate, the reflections will jump forward/backward many times in the cable but still lose enough amplitude before it's time to start actually sampling the data. If the cable length is increased, you will quickly get lots of transfer failures - the real data will drown in all the ripples that goes forward/backward in the cable.

Hi Per,

Many thanks for sharing your experiences and wisdom.

I am very sorry for my lack of hardware and signal knowledge.

I had read once, and will read your post many times until I really get a clear image.

Many thanks.

Think about a "cloud" of whistlers in the mountains.

Whistling is dominant.
Silence is recessive.

If I whistle, I will not know if others are also whistling - I'm too noisy.
If I stop whistle, I may still hear echos from my own whistling, so I need to wait a while before I can decide that there are silence - or if someone else is whistling.

That wait time depends on time until echo dies (travel time to bouncing location and back) and time to the other people (time for their sound to reach me).

If two people whistle at same time, neither will notice.
If one whistle and one is silent, the silent guy will notice (taking into account the delay for transfer of sound, and the delay for echo to end).

If the mountains are removed or covered with dampening material, then the speed to whistle or be silent will much be controlled by just transfer time to/from all other people. When there is echo, the transfer times for the echo must also be taken into acount.

So the bigger distance you have, the lower whistle speed you may have.
The more echo you have, the lower whistle speed you may have.

Because of this, CAN controllers starts with a specific synch pattern before every frame - besides collision detection it's also important that they have a reasonably good idea when time windows starts for each bit of the frame. Think about whistlers. The guy who whistles can't know if someone else whistles. But when silent, he can detect if someone else whistles. CAN isn't unique in sending a synchronization pattern before the frame (or sometimes called packet in other protocols).