Great explanation John.
Best Regards,
Jason Turner
[hidden email]
-----Original Message-----
From:
[hidden email]
[mailto:
[hidden email]] On Behalf Of John
Dammeyer
Sent: Friday, 24 August 2007 10:52 AM
To:
[hidden email]
Subject: RE: [CANLIST] Anybody ever run an MCP2515 at greater than
1Mbps?
Hi,
> The major limits in CAN are the transceivers, termination and
> bus capacitance.
Well, yes but also not quite.
>
<snip>
>
> At very much higher speeds (if you could reach them),
> propagation speed could be a consideration too.
It's the biggest consideration even at 100kbps and above
> Remember that a CAN state propagation looks like this:
> 1. Drive state onto bus.
> 2. Wait a bit.
> 3. Read back state to check for bus fails or arbitration.
>
Almost right but misses the point of how the CAN protocol works.
> That bit timing needs to allow for the propagation time to
> drive the state, charge the bus capacitance and the return
> propagation time before measurement. Thus, the bus cannot be
> more than a fraction of a wavelength. That limits the speed
> considerably when compared to, say, Ethernet.
>
> In Ethernet the cable can be many times the wavelength.
> Consider 100mbits/sec Ethernet. The wavelength is 2-3m yet
> there is no problem using cables up to 100m.
>
Using the above math that would imply the maximum distance for CAN at
1MBps would be 300m when in fact it's closer to 30m. It's just not that
important to consider the wavelength of the signal compared to
propagation delay.
Here's why:
Remember that if you are setting up the bit rate the spec sheet always
talks about time quanta or Tq. Each bit is divided into a minimum of 8
Tq or at 1Mbps that's 125nS. The optimal place to sample the bit is at
around the 87% point for high speed long buses. That just happens to be
Tq #7 for 87.5%.
So picture what the sender does using the above sequence.
1. Drive state onto bus.
2. Wait 7 Tq and sample the bus (as opposed to wait a bit).
3. Read back bus to check if what's transmitted matches what's received.
So what happens during those 7 Tq (875nS)?
A) The signal appears at the output pin of the CAN device at the
beginning of Tq 0.
B) assume the delay through driver and bus capacitance means it's not
really there on the wire until a 1/2 Tq later assuming about 50nS delay
through the driver.
C) Now it travels down the bus and the time it takes to reach the other
end is 1 Tq (Total elapsed time is now 1.5 Tq)
D) A node at that end of the bus sees the falling edge 0.5 Tq later
(receive driver delay) and starts it's state machine to recognize a
start bit. The receiver is now lagging the sender by 2 Tq in real time.
Because the entire bit interval is delayed by this 2 TQ the receiver
still physically sees 8 Tq, but just skewed by 2 Tq.
E) The sending node continues to send out bits and the receiver gets
them at the other end of the cable always sampling at Tq 7 and always
skewed by 2 Tq.
...
F) The last bit sent by the sender is the ACK slot bit and it's
recessive so 2 Tq later the receiver also expects the ACK slot to be
there and if all was received correctly puts a dominant out its transmit
pin. As in A..D above, it takes 2 Tq to get this dominant back to the
transmitter of the message.
G) The dominant ACK therefore shows up at the receive pin of the message
sender 4 Tq after it's internal start of message bit counter. Not a
problem. It doesn't sample until 7 Tq so it will see the Dominant ACK.
Now add an extra 1.5 Tq to the length of the bus. That is, the signal
takes an extra 187.5 nS to arrive at the other end of the bus in
addition to the original 250nS (2 Tq).
And even though the other end is now skewed by 437.5 nS (3.5 Tq) it
still issues the ACK at the beginning of what it understands to be the
ACK slot. That signal also takes 437.nS to return the original sender.
Total elapsed time is 875nS or 7 Tq.
The sender may or may not see the signal at this point. It all depends
on the shape of the rising edge of the bit and when it crosses the
receivers differential receiver threshold. Bus capacitance and
inductance plays a huge roll here. So does the internal state machine
logic inside the CAN device.
So to summarize: The length of a CAN bus is dependant on the time it
takes a signal to travel between nodes, through both transceivers,
times 2 less the Tq after the sample point.
If someone is working on a mission critical application, take two CAN
transceivers and the length of cable that will be used for the project.
Terminate both ends and put one transceiver at each end. Apply a 1
microsecond TTL pulse into one of the transceivers and look for the TTL
pulse out the other transceiver at the other end. Simple with a dual
trace scope.
The time between edges times two is the maximum theoretical bit rate
assuming the bit level was measured at the end of the bit. This is not
the practical bit rate. So although you can look up the speed of a
signal through a wire and determine from the capacitance per metre and
the inductance per metre the propagation time, none of that deals with
reflections that add to and subtract from the signal at the various node
stubs etc.
That's the real limitation to the speed of the CAN bus.
John Dammeyer
>
> --
> Archives and useful links:
http://groups.yahoo.com/group/CANbus> Subscribe and unsubscribe at www.vector-informatik.com/canlist/
> Report any problems to <
[hidden email]>
>
>
--
Archives and useful links:
http://groups.yahoo.com/group/CANbusSubscribe and unsubscribe at www.vector-informatik.com/canlist/
Report any problems to <
[hidden email]>
--
Archives and useful links:
http://groups.yahoo.com/group/CANbusSubscribe and unsubscribe at www.vector-informatik.com/canlist/
Report any problems to <
[hidden email]>
Locked
