RE: How slow is too slow and timing settings

Hi Chuck,
In either case as long as all are the same bit rate the actual base band
protocol doesn't really care.  For long bus lengths the further into the bit
you sample the better.   Not for the regular bits but the ACK bit has to
travel twice the length of the wire.

Think of it this way when the bit rate is on the edge of the maximum cable
length. .  The sender at one end creates the ACK slot which is one bit wide
delimited on both sides by a recessive bit.  The ACK slot is also recessive
so it looks like 3 recessives in a row but it's there from perspective of
the internal state machine inside the hardware.  Let's assume you have 10 Tq
in a bit.

Now suppose this ACK slot takes 40% of a bit time to travel to the other end
of the bus and the capacitance and inductance causes the edges of a bit to
be a bit rounded.   The receiver at the other end has synchronized onto the
edge of the message original start bit and considers that the start of the
bit stream.   Everything is timed from there. (I'll ignore the resync on
edge stuff for now).

The receiver determines the message is starting when the Sender is already
at Tq 4!  The receiver maintains that timing and sends the ACK when it has
calculated the ACK slot has arrived.  This ACK now also takes 40% of a bit
time to return to the sender.  That means the dominant rounded edge of the
receivers ACK doesn't show up until the senders Tq 8.  

With the signal edges rounded by the wrong type of cable the sender who is
expecting an ACK may not really see a solid dominant level it until Tq 9
even though the dominant edge began at Tq 8.  Even without the rounding if
the Sender is sampling at 70% of a bit time it won't see the ACK.  If it's
sampling at 80% of a bit time it might see the ACK.  If sampling at 87% of a
bit time it will see the ACK.

If you cut the bit rate in half and double the number of Tq per bit for the
sake of this example, it still takes 4 Tq for the ACK slot to reach the
receiver.  But that's now at the 20% of a bit time.  And the return trip is
the same so the ACK arrives at 8 Tq which is at the 40% part of a bit.
Sampling at 75% now easily detects the ACK.

It doesn't matter what the bit rate or frequency is when you think of the
length of the bus in terms of the number of Tq.  More Tq within the limits
of the registers allows you to position the bit sample point more accurately
and if you use 3 samples per bit to still position it near the end of a bit.
But you need a high enough oscillator frequency for this or a low enough bit
rate.

Hope that makes sense.

One other thing.  A node much closer will of course  see the ACK slot sooner
relative to the senders timing and assert the ACK sooner.  On a scope you'll
see normal length bits but the ACK could be almost two bits long.  When it's
too far away the closer nodes will see it overlap past the ACK delimiter and
create a bit error and error flag and destroy the message with an error
flag.

John Dammeyer




> All of the devices on my bus are of my own design (same board in fact) and
> are all ATMega1284p based so I only need to be compatible with myself.  I
> suppose there is a very remote possibility that something could come up
> that
> might want to co-exist but I doubt it.  But, I do agree that I should have
> used standard CAN bus speeds for the sake of industry compatibility.


> At the time I designed the board I had used RS-485 but never CAN so I knew
> about RS-485 bit rates but was naive on CAN requirements.  In fact, my
> board
> has solder jumpers that would have allowed me to fall back to RS-485 if
the
> CAN experiment had not worked out ... now I wish I had gone with an Atmel
> device with built-in CAN as interfacing would have been easier and I would
> have saved board real estate.  Just another step in the learning process
:-)
> 
> Cheers,
> 
> Chuck Hackett

--
Archives and useful links: http://groups.yahoo.com/group/CANbus
Subscribe and unsubscribe at www.vector.com/canlist/
Report any problems to <[email protected]>