CAN Bus

Anybody ever run an MCP2515 at greater than 1Mbps?

Classic

List

Threaded

18 messages Options

Michael J. Noone

Anybody ever run an MCP2515 at greater than 1Mbps?

Hi there - Does anybody here have any experience with using an MCP2515
on a CAN bus running faster than 1Mbps? I am interested in using a
number of them on a bus that is running at at least a couple Mbps. They
are being powered with 5V and have a 40MHz clock, if it matters.

Thanks!

-Michael

--
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]>

viks

Re: Anybody ever run an MCP2515 at greater than 1Mbps?

Hi,
I always thought that 1Mbps is the max we can that on CAN.
Good to know that its not true :)

On 8/21/07, Michael Noone <[hidden email]> wrote:

> Hi there - Does anybody here have any experience with using an MCP2515
> on a CAN bus running faster than 1Mbps? I am interested in using a
> number of them on a bus that is running at at least a couple Mbps. They
> are being powered with 5V and have a 40MHz clock, if it matters.
>
> Thanks!
>
> -Michael
>
> --
> 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/CANbus
Subscribe and unsubscribe at www.vector-informatik.com/canlist/
Report any problems to <[hidden email]>

Michael J. Noone

Re: Anybody ever run an MCP2515 at greater than 1Mbps?

Hi Vikram - you are certainly right about 1Mbps being the maximum speed of the official CAN spec. However, some of us like to break the rules :)

I have heard various success stories of running CAN at speeds much greater than 1Mbps. However, I have never heard somebody mention doing so with the MCP2515.

-Michael

Vikram Rajput wrote:

Hi,
I always thought that 1Mbps is the max we can that on CAN.
Good to know that its not true :)

On 8/21/07, Michael Noone [hidden email] wrote:

Hi there - Does anybody here have any experience with using an MCP2515
on a CAN bus running faster than 1Mbps? I am interested in using a
number of them on a bus that is running at at least a couple Mbps. They
are being powered with 5V and have a 40MHz clock, if it matters.

Thanks!

-Michael

--
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/CANbus
Subscribe and unsubscribe at www.vector-informatik.com/canlist/
Report any problems to [hidden email]

Uday_Gokhale

RE: Anybody ever run an MCP2515 at greater than 1Mbps?

In reply to this post by viks

The speed at which CAN can operate is defined by speed and length
combination.

As receiving node need to put acknowledgement bit on the bus.

Regards

Uday Gokhale
Integrated Engineering Services - Embedded Practice
Ph: +91 80 6780 8285 / M: + 91 9886 838 319

PS: Please note change in Phone number

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Vikram
Rajput
Sent: Wednesday, August 22, 2007 1:43 AM
To: [hidden email]
Subject: Re: [CANLIST] Anybody ever run an MCP2515 at greater than
1Mbps?

Hi,
I always thought that 1Mbps is the max we can that on CAN.
Good to know that its not true :)

On 8/21/07, Michael Noone <[hidden email]> wrote:
> Hi there - Does anybody here have any experience with using an MCP2515
> on a CAN bus running faster than 1Mbps? I am interested in using a
> number of them on a bus that is running at at least a couple Mbps.
They

> are being powered with 5V and have a 40MHz clock, if it matters.
>
> Thanks!
>
> -Michael
>
> --
> 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/CANbus
Subscribe and unsubscribe at www.vector-informatik.com/canlist/
Report any problems to <[hidden email]>

DISCLAIMER:
This email (including any attachments) is intended for the sole use of the intended recipient/s and may contain material that is CONFIDENTIAL AND PRIVATE COMPANY INFORMATION. Any review or reliance by others or copying or distribution or forwarding of any or all of the contents in this message is STRICTLY PROHIBITED. If you are not the intended recipient, please contact the sender by email and delete all copies; your cooperation in this regard is appreciated.
--
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]>

Heinz-Jürgen Oertel-2

Re: Anybody ever run an MCP2515 at greater than 1Mbps?

In reply to this post by Michael J. Noone

Am Dienstag, 21. August 2007 schrieb Michael Noone:
> Hi Vikram - you are certainly right about 1Mbps being the maximum speed
> of the official CAN spec. However, some of us like to break the rules :)
>
> I have heard various success stories of running CAN at speeds much
> greater than 1Mbps. However, I have never heard somebody mention doing
> so with the MCP2515.
>

One small problem to solve is increasing the speed of electrons in copper
cables. I think this is solvable, and CAN can replace 10 Gibit Ethernet
easily.

Heinz
--
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]>

John Dammeyer

RE: Anybody ever run an MCP2515 at greater than 1Mbps?

In reply to this post by Michael J. Noone

Although not with an MCP2515, I have run up to 2.666Mbps for a very
short distance. It would be possible to run it further but the nature
of electrons in the wire and propagation times through buffers are the
real limiting factor.

John Dammeyer

Automation Artisans Inc.
http://www.autoartisans.com
Ph. 1 250 544 4950

> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On
> Behalf Of Michael Noone
> Sent: Tuesday, August 21, 2007 12:08 PM
> To: [hidden email]
> Subject: [CANLIST] Anybody ever run an MCP2515 at greater than 1Mbps?
>
>
> Hi there - Does anybody here have any experience with using
> an MCP2515
> on a CAN bus running faster than 1Mbps? I am interested in using a
> number of them on a bus that is running at at least a couple
> Mbps. They
> are being powered with 5V and have a 40MHz clock, if it matters.
>
> Thanks!
>
> -Michael
>
> --
> 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/CANbus
Subscribe and unsubscribe at www.vector-informatik.com/canlist/
Report any problems to <[hidden email]>

heikki.saha

RE: Anybody ever run an MCP2515 at greater than 1Mbps?

Hello,

There is implementations, where arbitration and ack fields are driven
in standard 1Mbps baudrate and data and crc-fields in much higher speed.
Typically those solutions use more than 8 bytes data.

BR,

-Hessu
----------------------------------------------------------------------
Heikki Saha SMC Oy Tel(dir): +358 (0)400 346 537
M.Sc. P.O. Box 100 Tel: +358 (0)205 44 121
Research Engineer FIN-33311 Tampere Fax: +358 (0)205 44 120
Automation Systems Finland Email: [hidden email]

John Dammeyer <[hidden email]>

Sent by: [hidden email]

22.08.2007 10:54
Please respond to canlist_NOT

To:	[hidden email]
cc:
Subject:	RE: [CANLIST] Anybody ever run an MCP2515 at greater than 1Mbps?

Although not with an MCP2515, I have run up to 2.666Mbps for a very short distance. It would be possible to run it further but the nature of electrons in the wire and propagation times through buffers are the real limiting factor.
John Dammeyer

Automation Artisans Inc. http://www.autoartisans.com Ph. 1 250 544 4950

> -----Original Message----- > From: [hidden email] > [mailto:[hidden email]] On > Behalf Of Michael Noone > Sent: Tuesday, August 21, 2007 12:08 PM > To: [hidden email] > Subject: [CANLIST] Anybody ever run an MCP2515 at greater than 1Mbps? > > > Hi there - Does anybody here have any experience with using > an MCP2515 > on a CAN bus running faster than 1Mbps? I am interested in using a > number of them on a bus that is running at at least a couple > Mbps. They > are being powered with 5V and have a 40MHz clock, if it matters. > > Thanks! > > -Michael > > -- > 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/CANbus Subscribe and unsubscribe at www.vector-informatik.com/canlist/ Report any problems to <[hidden email]>

John Dammeyer

RE: Anybody ever run an MCP2515 at greater than 1Mbps?

Hello Heikki,

Yes. You are right. Although I believe I'm still under NDA for that
approach I can tell you that we were running MPEG4 video using 29 bit
IDs concurrent with standard 29bit, 8 byte standard CAN messages all on
the same bus.

John Dammeyer

Hello,

There is implementations, where arbitration and ack fields are driven
in standard 1Mbps baudrate and data and crc-fields in much higher speed.

Typically those solutions use more than 8 bytes data.

BR,

-Hessu
----------------------------------------------------------------------
Heikki Saha SMC Oy Tel(dir): +358 (0)400 346 537
M.Sc. P.O. Box 100 Tel: +358 (0)205 44 121
Research Engineer FIN-33311 Tampere Fax: +358 (0)205 44 120
Automation Systems Finland Email: [hidden email]

John Dammeyer <[hidden email]>

Sent by: [hidden email]
22.08.2007 10:54
Please respond to canlist_NOT To: [hidden email]
cc:
Subject: RE: [CANLIST] Anybody ever run an MCP2515 at greater than
1Mbps?

Although not with an MCP2515, I have run up to 2.666Mbps for a very
short distance. It would be possible to run it further but the nature
of electrons in the wire and propagation times through buffers are the
real limiting factor.

John Dammeyer

Automation Artisans Inc.
http://www.autoartisans.com
Ph. 1 250 544 4950

--
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/CANbus
Subscribe and unsubscribe at www.vector-informatik.com/canlist/
Report any problems to <[hidden email]>

heikki.saha

RE: Anybody ever run an MCP2515 at greater than 1Mbps?

Hi John,

That was a strange but great improvement idea. I have read your paper
and can confirm that you didn't write more than exists in the paper.

BR,

-Hessu
----------------------------------------------------------------------
Heikki Saha SMC Oy Tel(dir): +358 (0)400 346 537
M.Sc. P.O. Box 100 Tel: +358 (0)205 44 121
Research Engineer FIN-33311 Tampere Fax: +358 (0)205 44 120
Automation Systems Finland Email: [hidden email]

John Dammeyer <[hidden email]>

Sent by: [hidden email]

23.08.2007 11:28
Please respond to canlist_NOT

To:	[hidden email]
cc:
Subject:	RE: [CANLIST] Anybody ever run an MCP2515 at greater than 1Mbps?

Hello Heikki,
Yes. You are right. Although I believe I'm still under NDA for that approach I can tell you that we were running MPEG4 video using 29 bit IDs concurrent with standard 29bit, 8 byte standard CAN messages all on the same bus.
John Dammeyer

Hello,
There is implementations, where arbitration and ack fields are driven in standard 1Mbps baudrate and data and crc-fields in much higher speed.
Typically those solutions use more than 8 bytes data.
BR,
-Hessu ---------------------------------------------------------------------- Heikki Saha SMC Oy Tel(dir): +358 (0)400 346 537 M.Sc. P.O. Box 100 Tel: +358 (0)205 44 121 Research Engineer FIN-33311 Tampere Fax: +358 (0)205 44 120 Automation Systems Finland Email: [hidden email]

John Dammeyer <[hidden email]>

Sent by: [hidden email] 22.08.2007 10:54 Please respond to canlist_NOT To: [hidden email] cc: Subject: RE: [CANLIST] Anybody ever run an MCP2515 at greater than 1Mbps?

Although not with an MCP2515, I have run up to 2.666Mbps for a very short distance. It would be possible to run it further but the nature of electrons in the wire and propagation times through buffers are the real limiting factor.
John Dammeyer

Automation Artisans Inc. http://www.autoartisans.com Ph. 1 250 544 4950

> -----Original Message----- > From: [hidden email] > [mailto:[hidden email]] On > Behalf Of Michael Noone > Sent: Tuesday, August 21, 2007 12:08 PM > To: [hidden email] > Subject: [CANLIST] Anybody ever run an MCP2515 at greater than 1Mbps? > > > Hi there - Does anybody here have any experience with using > an MCP2515 > on a CAN bus running faster than 1Mbps? I am interested in using a > number of them on a bus that is running at at least a couple > Mbps. They > are being powered with 5V and have a 40MHz clock, if it matters. > > Thanks! > > -Michael > > -- > 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/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/CANbus Subscribe and unsubscribe at www.vector-informatik.com/canlist/ Report any problems to <[hidden email]>

Charles Manning

RE: Anybody ever run an MCP2515 at greater than 1Mbps?

In reply to this post by Heinz-Jürgen Oertel-2

> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On
> Behalf Of Heinz-Jürgen Oertel
> Sent: Wednesday, 22 August 2007 6:03 p.m.
> To: CANLIST
> Subject: Re: [CANLIST] Anybody ever run an MCP2515 at greater
> than 1Mbps?
>
> Am Dienstag, 21. August 2007 schrieb Michael Noone:
> > Hi Vikram - you are certainly right about 1Mbps being the maximum
> > speed of the official CAN spec. However, some of us like to
> break the
> > rules :)
> >
> > I have heard various success stories of running CAN at speeds much
> > greater than 1Mbps. However, I have never heard somebody
> mention doing
> > so with the MCP2515.
> >
>
> One small problem to solve is increasing the speed of
> electrons in copper cables. I think this is solvable, and CAN
> can replace 10 Gibit Ethernet easily.

Although the CAN spec only goes to 1Mb/s it is worth reflecting that the RS232 spec only goes to 19200 baud yet most RS232 links will use it far faster than that.

The major limits in CAN are the transceivers, termination and bus capacitance.

There is a very big difference between the way ethernet and CAN buses are driven which limits the maximum lenghts and speeds.

The termination on ethernet etc has the main purpose of providing a good transmission line with minimised overshoot, reflections etc.

The so-called termination on a CAN bus does provide some of this transmission line improvement, but the main purpose is to provide a resistive load to pull CAN_H and CAN_L together when in the passive state. The major limiting factor on CAN bus speed is the RC time for the resistor overcoming the capacitance in the bus. In practice these considerations will be the limiting effect far sooner than anything else (raw propagation delay).

At very much higher speeds (if you could reach them), progagation speed could be a consideration too.

Remember that a CAN state propagaion looks like this:
1. Drive state onto bus.
2. Wait a bit.
3. Read back state to check for bus fails or arbitration.

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.

--
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]>

John Dammeyer

RE: 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/CANbus
Subscribe and unsubscribe at www.vector-informatik.com/canlist/
Report any problems to <[hidden email]>

Jason Turner-2

RE: Anybody ever run an MCP2515 at greater than 1Mbps?

In reply to this post by Michael J. Noone

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.

Charles Manning

RE: Anybody ever run an MCP2515 at greater than 1Mbps?

In reply to this post by John Dammeyer

I prefer John's description to my own because he is more thorough.

Perhaps I did not explain correctly because it was my intention to
convey a subset of what he says.

I think what we have is a conflict of terminology over the meaning of
"propagation delay" I was using the term to mean speed at which a signal
travels down a wire (approx speed of light) and John means the time for
the changed bit state to be fully presented on the bus (which would
include the time to defeat the capacitance etc - and is far, far less
than the speed of light).

Ultimately we were both trying to make the same point: the way CAN
signals bits down the bus limits speed to far lower than any
speed-of-light considerations and which is why CAN speeds cannot be
cranked up to ethernet-like levels.

A CAN bus only has a single bit-state present on the bus at a time. That
is very different to something like ethernet which can have many bits
"in flight" down the cable at the same time (that is obvious from
recognizing that a 100m cable is approx 40 times the wavelength of a
single bit at 100 Mbits per sec).

I was also simplifying the case by just looking at it from the
transmitter's perspective. John, more correctly, also considers the ACK
slot too which pushes the times out further.

> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On
> Behalf Of John Dammeyer
> Sent: Friday, 24 August 2007 1:22 p.m.
> 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

By propagation speed I mean the speed at which an electrical signal
passes down a wire (ie approx the speed of light). At 100kbps has a
wavelength of approx 3000m so clearly that is not a limiting factor. It
is the transceiver/capacitance issues that limit the bus to a more
realistic 30m or so.

>
>
> > 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.

That is exactly the point I was trying to make.

The speed of propagation of an electical signal is not a material
consideration.

>
> 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/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/CANbus
Subscribe and unsubscribe at www.vector-informatik.com/canlist/
Report any problems to <[hidden email]>

John Dammeyer

RE: Anybody ever run an MCP2515 at greater than 1Mbps?

In reply to this post by Jason Turner-2

Hi,
>
> Great explanation John.

Thanks.

John

>
> Best Regards,
>
> Jason Turner
> [hidden email]

--
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]>

John Dammeyer

RE: Anybody ever run an MCP2515 at greater than 1Mbps?

In reply to this post by Charles Manning

Hi Charles,

> I prefer John's description to my own because he is more thorough.

Thanks.

>
> Perhaps I did not explain correctly because it was my intention to
> convey a subset of what he says.

I wasn't trying to make you wrong. In fact I had to wrap my mind around
the idea of one 300m wavelength sitting on this really long wire while
doing the write-up. Novel concept. Brought a smile to my face. In no
way did I intend on negating your description.

In fact, of course 1 Mbps CAN is really at most 500Khz with an
alternating bit pattern. And, since it's a square wave (or tries to be)
the harmonics are into the 10's of MHz.

Just imagine if we did the arbitration at 10kbps (100 uS per bit) and
send a packet with one 1 byte with the value 0x55 (alternating 01010101)
Inside that byte make each 100 microsecond dominant (or recessive) bit
the equivalent of 100Mbs signalling. Potentially 10K bits of
information. With some clever filtering, the CAN device would see only
a dominant or a recessive for 100 uS. A separate FPGA, could pull an
Ethernet size packet out of that 'noise' that's sitting on top of the
CAN bits.

Then you'd have bit wise arbitration. You wouldn't be modifying the CAN
standard so no royalties. And the only thing you really need is a
signal out from the CAN engine that it's won arbitration. Alas, except
in FPGA implementations that's not easily available.

Take it one step further and you could run a standard CAN bus network,
with a few custom devices and assign the first bit of the 29 bit ID to
be a selection for the type of message. A dominant means the short 0x55
packed message. A recessive means regular CAN. Could even park it on
top of J1839 (I think that's the right number) like MilCAN does.

And all it requires is access on the outside of the device to the
arbitration won signal.

Contact me for the address to send royalties. <WINK>

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]>

Olga Fischer

Re: Anybody ever run an MCP2515 at greater than 1Mbps?

Hi, guten Morgen,

may I join your discussion?

John Dammeyer schrieb:

> [snip]
> In fact, of course 1 Mbps CAN is really at most 500Khz with an
> alternating bit pattern. And, since it's a square wave (or tries to be)
> the harmonics are into the 10's of MHz.
>
> Just imagine if we did the arbitration at 10kbps (100 uS per bit) and
> send a packet with one 1 byte with the value 0x55 (alternating 01010101)
> Inside that byte make each 100 microsecond dominant (or recessive) bit
> the equivalent of 100Mbs signalling. Potentially 10K bits of
> information. With some clever filtering, the CAN device would see only
> a dominant or a recessive for 100 uS. A separate FPGA, could pull an
> Ethernet size packet out of that 'noise' that's sitting on top of the
> CAN bits.
>
> Then you'd have bit wise arbitration. You wouldn't be modifying the CAN
> standard so no royalties. And the only thing you really need is a
> signal out from the CAN engine that it's won arbitration. Alas, except
> in FPGA implementations that's not easily available.
>
> Take it one step further and you could run a standard CAN bus network,
> with a few custom devices and assign the first bit of the 29 bit ID to
> be a selection for the type of message. A dominant means the short 0x55
> packed message. A recessive means regular CAN. Could even park it on
> top of J1839 (I think that's the right number) like MilCAN does.
>
> And all it requires is access on the outside of the device to the
> arbitration won signal.

In fact you can all do this with almost standard components. No
expansive FPGA is needed. No complicated filtering is needed. Just use
TTCAN devices and the sky is the limit ;-).

The problem of all these kind of solutions is that you will loose the
error detection capabilities that are provided by CAN. In other words
the error detection has to be shifted into the higher layers and have to
be done in software. If this is acceptable then standard TTCAN devices
can be used. With TTCAN the communication system has to be timed, which
means, every device will receive its exclusive communication slot. With
that you can use almost any bit rate.

Even this can be combined with standard CAN devices. In this situation
there have to be a communication slot where regular CAN communication
takes place. The solution is that way that the reference message is
transmitted at a regular speed, e.g. at 1 Mbps or 500 kbps. Following to
the reference message there are the TTCAN communication slots. That
means the software on the regular CAN devices has to switch off the
transmit capabilities, the Tx-pin, of the regular CAN controller. All
the TTCAN device can transmit their data at any speed you can think of,
of course this is pre-defined for the system. When its time for the
arbitration window the software on the regular devices switches the
Tx-pin back on and the TTCAN device are switching back to regular speed.
That means, now is time for the regular CAN communication until the next
reference message shows up.
The charm of this solution is, there are only off-the-shelf available
devices. Just a very little piece of software. That's it folks.

> Contact me for the address to send royalties. <WINK>
>
Contact me for the address to send the royalties. <WINK>

> John Dammeyer
>
>

Greetz

Thilo

PS: John, did you mean J1839 or was J1939 meant? Because J1839 defines
coarse water removal tests.
--
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]>

Corrigan, Steve

RE: Anybody ever run an MCP2515 at greater than 1Mbps?

In reply to this post by John Dammeyer

Guys,

I have a customer running a 10 Mbps CANbus using the SN65HVD251
transceivers. Can't talk about it, but it is indeed very real.

Cheers,
Steve

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of John
Dammeyer
Sent: Thursday, August 23, 2007 10:27 PM
To: [hidden email]
Subject: RE: [CANLIST] Anybody ever run an MCP2515 at greater than
1Mbps?

Hi,
>
> Great explanation John.

Thanks.

John

>
> Best Regards,
>
> Jason Turner
> [hidden email]

--
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/CANbus
Subscribe and unsubscribe at www.vector-informatik.com/canlist/
Report any problems to <[hidden email]>

Funny N.

RE: Anybody ever run an MCP2515 at greater than 1Mbps?

In reply to this post by heikki.saha

This is good for fun.
For mass products, I don't recommend run those chips faster than their spec.