CAN Bus vs USB differential signaling

[Warren]

Here is an academic question regarding the differences between CAN bus and USB differential _signals_. I'm not interested in the protocol differences-- just the signaling.

CAN bus was created around 1983 and uses a differential signal alternating between V+/2 and V+ for CAN H, and V+/2 and CAN L for the other end. The recessive bit returns back to V+/2.

USB, which came later, OTOH, pulls the signal D+ low, and D- high and otherwise returns to the idle state of their respective D+/D- idle levels.

My question is about the differential signal design:

Is there an advantage to the CAN bus approach with the recessive bit at V++/2, or is the USB differential signal with its wider differential voltage better for noise immunity or other reasons?

Another way to phrase the question might be:

if CAN were to be redesigned today with the lessons learned from USB (signalling), would they have still chosen the same V+/2 idle signal that they chose to use?

Just curious,
Warren

[Tim Wescott]

So, interesting question, and it goes to the heart of what makes CAN what
it is.

This may no longer be the case, but when I worked with CAN (ca 2000-ish),
the standard did NOT specify the physical layer -- it just said that the
physical layer had to support the recessive/active bit behavior. The
specific physical layer of which you speak has its own ISO or SAE
standard -- but you could use other phy layers and still call it CAN.

In short, the USB differential signal that uses the full voltage swing
does have more noise immunity -- but it doesn't support the wired-and
connection that's central to CAN.

Moreover, there's no reason you couldn't have the recessive bit be
defined as line one at 0V and line 2 at V++, with the polarity reversed
for an active bit -- folks just chose not to do that, presumably to make
termination easier.

RS-485 and RS-422 have been around since the 60's or 70's, and at their
base use signaling similar to USB. I'm sure that the originators of CAN
were fully aware of both of those. So no, I don't think CAN would have
been much different if it were conceived of today.

--
Tim Wescott
Control systems, embedded software and circuit design
I'm looking for work! See my website if you're interested
http://www.wescottdesign.com

[kevin93]

On Friday, April 28, 2017 at 1:17:00 PM UTC-7, Warren wrote:
...

>
> Another way to phrase the question might be:
>
> if CAN were to be redesigned today with the lessons learned from USB (signalling), would they have still chosen the same V+/2 idle signal that they chose to use?
>
> Just curious,
> Warren

Don't forget that USB is point to point and CAN is multi-master with arbitration exploiting the recessive/dominant capability to determine which of two colliding transmitters has the higher address.

kevin

[John Larkin]

Ethernet won the bus wars!


--

John Larkin Highland Technology, Inc
picosecond timing precision measurement

jlarkin att highlandtechnology dott com
http://www.highlandtechnology.com

[kevin93]

On Friday, April 28, 2017 at 2:28:23 PM UTC-7, John Larkin wrote:
...

>
> Ethernet won the bus wars!
>

...

And Ethernet is coming to a car near you - 100Mbps (or even 1Gbps) full duplex on a single pair!

Some cars already have it for the infotainment system, I don't think any have it for engine/body control yet.

kevin

[Jim Thompson]

Who knows? Recently had our 2005 Q45 in for service and the loaner
was a new Q50... piece-a-crap... jerky braking and strange engine
stumble while stopped at a traffic.

By happenstance, reading a car magazine in a doctor's waiting room,
it's brake-by-wire... and takes the engine out of gear when you're
almost stopped, thus the jerky stop.

Also stops fuel injection for a few rotations while waiting at a
light.

Very disconcerting.

All in the name of squeezing out Obama's fleet average fuel economy.

Piece-a-crap, don't lease/buy... and it's only 2 Liters :-(

(Our Q45 is 4.5 Liter... still can smoke a Mustang ;-)

...Jim Thompson
--
| James E.Thompson | mens |
| Analog Innovations | et |
| Analog/Mixed-Signal ASIC's and Discrete Systems | manus |
| STV, Queen Creek, AZ 85142 Skype: skypeanalog | |
| Voice:(480)460-2350 Fax: Available upon request | Brass Rat |
| E-mail Icon at http://www.analog-innovations.com | 1962 |

Thinking outside the box... producing elegant solutions.

"It is not in doing what you like, but in liking what you do that
is the secret of happiness." -James Barrie

[pcdh...@gmail.com]

>(Our Q45 is 4.5 Liter... still can smoke a Mustang ;-)
                

I gather you're feeling better, since you're back to bragging about your car. ;)

Glad to see it. Any news on the pancreas thing?

Cheers

Phil Hobbs

[Jim Thompson]

Pancreatic tumor, unknown if benign/malignant... molding for
form-fitting "bed" to hold me immobile during radiation to be done
Tuesday, then five weeks of radiation. (I also get tattoo X's for
alignment purposes >:-}

My humor is coming back along with my appetite. This has been quite a
debilitating experience... I've dropped 18 pounds since March 15...
now holding at 152... Thompson's weight-loss diet >:-}

Haven't weighed that little since probably age 16.

For a while there I think I had mentally thrown in the towel... then I
decided I'm going to enjoy every last minute.

[Don Y]

On 4/28/2017 4:38 PM, Jim Thompson wrote:
> On Fri, 28 Apr 2017 15:38:32 -0700 (PDT), pcdh...@gmail.com wrote:
>
>>> (Our Q45 is 4.5 Liter... still can smoke a Mustang ;-)
>>
>> I gather you're feeling better, since you're back to bragging about your car. ;)
>>
>> Glad to see it. Any news on the pancreas thing?
>>
>> Cheers
>>
>> Phil Hobbs
>
> Pancreatic tumor, unknown if benign/malignant...

Presumably, they are aggressively watching your blood sugar
and insulin levels?

> molding for
> form-fitting "bed" to hold me immobile during radiation to be done
> Tuesday, then five weeks of radiation. (I also get tattoo X's for
> alignment purposes >:-}

Bummer. Hopefully they don't screw up the targeting (a friend had
heart damage when they mistargetted a cancer in her chest and
"caught" her heart, in the process). Annoying when you have to rely on
other peoples' skillsets! :<

> My humor is coming back along with my appetite. This has been quite a
> debilitating experience... I've dropped 18 pounds since March 15...
> now holding at 152... Thompson's weight-loss diet >:-}
>
> Haven't weighed that little since probably age 16.
>
> For a while there I think I had mentally thrown in the towel... then I
> decided I'm going to enjoy every last minute.

Getting old (infirm) is the pits. When you finally have the "wisdom",
"resources", "experience", etc. to *do* stuff, your BODY gets in the way!

A friend having surgery for stomach cancer, this week. Another lost
top lobe of a lung to lung cancer surgery two weeks ago. Before that,
another had a hysterectomy for ovarian cancer. Before that, another
with a mastectomy for breast cancer. Before that...

[Christ! You'd think something was out to KILL us!! :< ]

Best of luck!

[Jim Thompson]

Thanks! Much appreciated!

[rickman]

On 4/28/2017 4:52 PM, Tim Wescott wrote:
>>
>> Is there an advantage to the CAN bus approach with the recessive bit at
>> V++/2, or is the USB differential signal with its wider differential
>> voltage better for noise immunity or other reasons?
>>
>> Another way to phrase the question might be:
>>
>> if CAN were to be redesigned today with the lessons learned from USB
>> (signalling), would they have still chosen the same V+/2 idle signal
>> that they chose to use?
>

> In short, the USB differential signal that uses the full voltage swing
> does have more noise immunity -- but it doesn't support the wired-and
> connection that's central to CAN.

USB doesn't support the wired and connectivity because it is really a
point to point interface at the physical level. There are just two
devices sharing a pair of wires to send data back and forth. This
eliminates many signal integrity issues with terminations at multiple
points.

I don't know much about CAN so I can't say why it is designed at the
physical layer the way it is, but anytime you connect more than two
devices on a single channel it is much more complicated to make work at
all layers.

--

Rick C

[Tim Wescott]

CAN is designed to be real time. This is done by allowing no more than
eight bytes per message, and with prioritized addressing: each
transmitter watches its receive line as it chunks out an address; if it
sees an active bit when it's sending a recessive bit, it silently backs
off. IIRC zero is active, so the lowest-numbered address wins.

So if the highest-priority message gets queued up one bit-time too late
to make it out, it has a finite and short wait before it gets sent.
Ditto second-highest priority message (except that the maximum wait is a
bit longer), etc.

[k...@notreal.com]

tYou're not likely to ever find it in the engine/body controls but it
is highly likely to find its way into ADAS systems, though.

[upsid...@downunder.com]

On Fri, 28 Apr 2017 15:52:33 -0500, Tim Wescott <t...@seemywebsite.com>
wrote:

Before dedicated CAN bus transceiver chips become available, ordinary
RS-485 chips were used. The transmitter input was constantly connected
to the dominant state and the actual data stream connected to the
Driver Enable (DE) pin.

When the dominant state is to be transmitted, the DE is activated
driving the transmitter hard into the dominant state. When the
recessive state is to be transmitted, the transmitter is put into high
impedance tri-state. It is then up to the "fail-safe" termination to
create the recessive voltage level (those quoting marks are in the
original RS-422/RS485 standard text :-). Of course, the pull-up and
termination resistors could drive the tri-stated bus to any voltage,
such as V+/Gnd or V+/2 on both lines. Which to use,depends of the
receiver switching characteristics.

One way of looking at the CAN bus _system_ is to handle it as a
wired-OR gate. Each CAN device has an open collector NPN transistor
with a _common_ pull-up resistor to V+. Then also each CAN derive has
a PNP open collector transistor and the whole bus has a shared
collector resistor to Gnd. The wired-OR action on both (positive and
negative) lines eliminates the risk of physically damaging the
devices during a collision.

Connecting the open collector common pull up resistors to some other
voltage can be used to limit the voltage swing. Since a twisted pair
cable impedance is around 100 ohms, the termination resistor should be
the same, Limiting the signal voltage swing will also limit the signal
current through the termination resistor and hence reduce the total
power dissipation. This is the case e.g. with LVDS.

[Tim Williams]

CAN has strictly better noise rejection and robustness over the USB pair.

USB could stand to take some lessons from CAN. :)

Indeed, CAN is better than RS-422/485, which is already pretty robust, while
having comparable signaling rates (and build-your-own protocol -- it's just
the physical layer; whereas, CAN takes care of a huge load of things at
once).

That said, USB (Full Speed, which is as described -- full logic level
output) is faster, and can be *much, much* faster (High Speed, etc.).

Noise is part of the reason USB is point-to-point, and all of the reason it
must be 100% shielded. USB has no input range beyond the rails, and PHYs,
and recommended ESD diodes, all have diodes to clamp to the rails.

You might think, well, can't we improve USB's CMRR at AC, by adding ferrite
beads or CMCs? Alas, no -- USB itself is unbalanced, that is, it uses
unbalanced symbols (J and K). Also, because it is source terminated, you
can hardly afford any loading on the load side, so you don't have anything
to create a voltage divider with the CMC. (And, needless to say, ferrite
beads will swallow high speed signals whole, so no good there.)

RS-485 and CAN are very easy to filter, because they normally expect to have
low impedances around. Both are fully differential, so you can always split
the termination resistor or filter capacitor, and get common mode "center
tap" that can be loaded with whatever impedance you like. (Recommended is a
+V/2 divider, and some R+C damped filtering, so the CMC + C doesn't ring.)

Tim

--
Seven Transistor Labs, LLC
Electrical Engineering Consultation and Contract Design
Website: http://seventransistorlabs.com

"Warren" <ve3...@gmail.com> wrote in message
news:301a77c9-d8bf-440a...@googlegroups.com...

[rickman]

On 4/29/2017 8:32 AM, Tim Williams wrote:
> CAN has strictly better noise rejection and robustness over the USB pair.

I believe it can work over longer distances as well. USB is limited to
5 meters. But then it runs at some pretty high rates...

> USB could stand to take some lessons from CAN. :)

As could a chicken from a duck. Two different animals. No point in
comparing them really.

> Indeed, CAN is better than RS-422/485, which is already pretty robust,
> while having comparable signaling rates (and build-your-own protocol --
> it's just the physical layer; whereas, CAN takes care of a huge load of
> things at once).
>
> That said, USB (Full Speed, which is as described -- full logic level
> output) is faster, and can be *much, much* faster (High Speed, etc.).
>
> Noise is part of the reason USB is point-to-point, and all of the reason
> it must be 100% shielded. USB has no input range beyond the rails, and
> PHYs, and recommended ESD diodes, all have diodes to clamp to the rails.
>
> You might think, well, can't we improve USB's CMRR at AC, by adding
> ferrite beads or CMCs? Alas, no -- USB itself is unbalanced, that is,
> it uses unbalanced symbols (J and K). Also, because it is source
> terminated, you can hardly afford any loading on the load side, so you
> don't have anything to create a voltage divider with the CMC. (And,
> needless to say, ferrite beads will swallow high speed signals whole, so
> no good there.)
>
> RS-485 and CAN are very easy to filter, because they normally expect to
> have low impedances around. Both are fully differential, so you can
> always split the termination resistor or filter capacitor, and get
> common mode "center tap" that can be loaded with whatever impedance you
> like. (Recommended is a +V/2 divider, and some R+C damped filtering, so
> the CMC + C doesn't ring.)

USB was designed for short cables connecting peripherals to computers.
I think it does a very good job of it. I can't remember the last time I
had a problem with noise in a USB cable.

--

Rick C

[upsid...@downunder.com]

On Sat, 29 Apr 2017 07:32:55 -0500, "Tim Williams"
<tiw...@seventransistorlabs.com> wrote:

>CAN has strictly better noise rejection and robustness over the USB pair.

Why ?

I would consider RS-422/485, USB, CANbus, Profibus DP similar in
performance across long lines, all 5 V differential devices..

.
>USB could stand to take some lessons from CAN. :)

Original USB might have learned something from Profibus DP, which
required special T-connectors with built in series inductors to run
multidrop at 12 Mbit/s at 100 m lines.

Modern USB rates at 5-7 m looks OK.

>Indeed, CAN is better than RS-422/485, which is already pretty robust, while
>having comparable signaling rates (and build-your-own protocol -- it's just
>the physical layer; whereas, CAN takes care of a huge load of things at
>once).

One should always remember that the CAN collision domain size severely
limited the network size !

In a CAN network, the two way propagation delay between any two
stations on the network must be less than a fractional bit time.
Considering any optoisolators on the line, the maximum bus length is
about 10-40 m at 1000 kbit/s.

I have had problems running a few dozen nodes on a 100-200 m bus at
125-250 kbit/s CAN bus, sometimes forcing to reduce the line speed.

I like the CANbus peer-to-peer arbitration principle, but it
_severely_ limits the bus length

[upsid...@downunder.com]

One should always remember that Modbus RTU, Profibus DP and USB are
basically master/slave protocols with arbitration at the message
_frame_ level, while in CANbus, the arbitration is done at a single
bit level.

This of course limit the collision domain size.

[Lasse Langwadt Christensen]

I believe that first CAN implementations used rs485 transceivers

[k...@notreal.com]

On Sat, 29 Apr 2017 10:37:51 -0400, rickman <gnu...@gmail.com> wrote:

- It's unlikely you'd ever know it if you did.
- If you did, you'd likely assume it's just a bad cable
- You've probably not used it at the edge of its capability

[Tim Wescott]

I considered doing so in the project where I used CAN. We ended up using
the automotive chips for some sensible reason, which I can't remember
because it was 17 years ago.

[k...@notreal.com]

On Sat, 29 Apr 2017 19:12:50 -0500, Tim Wescott <t...@seemywebsite.com>
wrote:

Because they're robust and cheap?

[Tim Wescott]

Hmm. It may have been that :)

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

I'm looking for work -- see my website!

[Tim Williams]

<upsid...@downunder.com> wrote in message
news:jj89gcpqh6vu24hqr...@4ax.com...

>>CAN has strictly better noise rejection and robustness over the USB pair.
>
> Why ?

Example part:
http://www.ti.com/lit/ds/symlink/sn65hvd233-ht.pdf
40V input range, though I think the operational V_icm is more like +12/-7V
(same as RS-422/485). Sadly, they don't specify this directly, but they do
reference relevant voltages for valid input states (input current and
differential input readings being within spec for such-and-such input
voltages).

It's not obvious if it'll give BS values outside of that range (in the 12-40
and -7 to -40V range, outside of which the ESD diodes do their business),
but anyway, having a >5V range covers a lot of noisy environments.

USB has strictly within-rails range, so, +/- 1.65V is it. Pretty poor.

That's why USB must be shielded.

> I would consider RS-422/485, USB, CANbus, Profibus DP similar in
> performance across long lines, all 5 V differential devices..

Yeah, except for USB, those are basically the same PHY receivers. :-)

> In a CAN network, the two way propagation delay between any two
> stations on the network must be less than a fractional bit time.
> Considering any optoisolators on the line, the maximum bus length is
> about 10-40 m at 1000 kbit/s.
>
> I have had problems running a few dozen nodes on a 100-200 m bus at
> 125-250 kbit/s CAN bus, sometimes forcing to reduce the line speed.
>
> I like the CANbus peer-to-peer arbitration principle, but it
> _severely_ limits the bus length

Yeah, as with most things (USB included), it was designed for its purpose,
and isn't really suitable outside that range. CAN can be forced into
facility-wide operation, but it'll generally need to be slowed down to do it
reasonably well.

Point to point links don't have to worry about that, which gets you
something like Ethernet that can go long distances, and also doesn't give a
shit about ground loop or noise or shielding, because it's friggin'
transformer isolated! :-)

[Tim Williams]

"rickman" <gnu...@gmail.com> wrote in message
news:oe289u$u27$1...@dont-email.me...

> USB was designed for short cables connecting peripherals to computers. I
> think it does a very good job of it. I can't remember the last time I
> had a problem with noise in a USB cable.

Well, if you get a shitty cable, like krw said, you'd probably not notice,
or discard it and start over again.

It's mostly connector design problems. Few people apparently realize what
shielding /actually is/, including many appnote authors. So you have
abominations like TI putting ferrite beads between shield-ground and
circuit-ground: a step that can /only/ worsen signal quality!

I inspected one MSP430 programmer dongle that's apparently built this way.
Another was an RS-422/485 adapter dongle, which even had the gaul to claim
it was isolated and noise immune -- hah! Sure, it used optos and a DC-DC
converter, but that funny little Y cap bridging across the barrier, combined
with the shitty cable connection, ensured it took a shit on more than about
2V conducted or 2V/m radiated.

That was a fun day at the lab. I had to fix, not the EUT, but the device
being used to communicate with the EUT.

A handful of ferrite beads, capacitors and copper tape fixed that. Cut open
the USB cable's jacket, tape the shield onto a ground plane (the PCB didn't
have ground pour, either), and add ferrite beads and caps to the RS-422 pair
(thus filtering away, and shunting around, the noise away from the stupidly
designed dongle).

[upsid...@downunder.com]

On Sun, 30 Apr 2017 10:09:27 -0500, "Tim Williams"
<tiw...@seventransistorlabs.com> wrote:

><upsid...@downunder.com> wrote in message
>news:jj89gcpqh6vu24hqr...@4ax.com...
>>>CAN has strictly better noise rejection and robustness over the USB pair.
>>
>> Why ?
>
>Example part:
>http://www.ti.com/lit/ds/symlink/sn65hvd233-ht.pdf
>40V input range, though I think the operational V_icm is more like +12/-7V
>(same as RS-422/485).

The voltage ranges for the garden variety 82C250 CAN transceiver is
much smaller. The NXP version absolute maximum input range is -8 V to
+18 V and IIRC I have seen even smaller ranges down to -5 to +12 V
absolute maximum ratings on some other CAN chips.

In a big installation, that is not much common mode range, so in
practice, galvanic isolation has to be used anyway.

> Sadly, they don't specify this directly, but they do
>reference relevant voltages for valid input states (input current and
>differential input readings being within spec for such-and-such input
>voltages).
>
>It's not obvious if it'll give BS values outside of that range (in the 12-40
>and -7 to -40V range, outside of which the ESD diodes do their business),
>but anyway, having a >5V range covers a lot of noisy environments.
>
>USB has strictly within-rails range, so, +/- 1.65V is it. Pretty poor.

Not much issue for bus powered small devices, but of course, can be a
problem for independently powered devices due to power supply or
ground connection leakage.

>That's why USB must be shielded.

More likely to draw the leakage current and hence keep the common mode
voltage within limits.

>> I would consider RS-422/485, USB, CANbus, Profibus DP similar in
>> performance across long lines, all 5 V differential devices..
>
>Yeah, except for USB, those are basically the same PHY receivers. :-)
>
>
>> In a CAN network, the two way propagation delay between any two
>> stations on the network must be less than a fractional bit time.
>> Considering any optoisolators on the line, the maximum bus length is
>> about 10-40 m at 1000 kbit/s.
>>
>> I have had problems running a few dozen nodes on a 100-200 m bus at
>> 125-250 kbit/s CAN bus, sometimes forcing to reduce the line speed.
>>
>> I like the CANbus peer-to-peer arbitration principle, but it
>> _severely_ limits the bus length
>
>Yeah, as with most things (USB included), it was designed for its purpose,
>and isn't really suitable outside that range. CAN can be forced into
>facility-wide operation, but it'll generally need to be slowed down to do it
>reasonably well.
>
>Point to point links don't have to worry about that, which gets you
>something like Ethernet that can go long distances, and also doesn't give a
>shit about ground loop or noise or shielding, because it's friggin'
>transformer isolated! :-)

The collision detection is still visible in Ethernet frames, in which
requires a minimum frame length of 64 bytes for CSMA/CD. This was
required in 10base5, 10base2 coaxial buses as well as with simple
10baseT hubs. With switches, this should not be an issue, but in order
to route traffic into those old systems, that requirement must still
be maintained.

nnnBaseT can only do 100 m.

In addition the galvanic isolation is specified as 2 kV, which is
usually fully adequate within a building, but is quite useless between
two buildings with separate lightning rods. The ground potential rise
between the two buildings can be much larger than that during a
lightning strike, so I would always recommend fibre between separate
buildings.

>
>Tim

[Warren]

On Friday, 28 April 2017 16:52:41 UTC-4, Tim Wescott wrote:
> On Fri, 28 Apr 2017 13:16:56 -0700, Warren wrote:
>
> > Here is an academic question regarding the differences between CAN bus
> > and USB differential _signals_. I'm not interested in the protocol
> > differences-- just the signaling.

..

> > My question is about the differential signal design:
> >
> > Is there an advantage to the CAN bus approach with the recessive bit at
> > V++/2, or is the USB differential signal with its wider differential
> > voltage better for noise immunity or other reasons?

> So, interesting question, and it goes to the heart of what makes CAN what
> it is.

> > ...

> In short, the USB differential signal that uses the full voltage swing
> does have more noise immunity -- but it doesn't support the wired-and
> connection that's central to CAN.

If we forget USB and implemented a signal that pulled up on one hand, and the other pulled down for the other signal, we could very well have the same capability as CAN except that the voltage differential would be V rather than V/2.

Ah, I guess that is what you said below:

> Moreover, there's no reason you couldn't have the recessive bit be
> defined as line one at 0V and line 2 at V++, with the polarity reversed
> for an active bit -- folks just chose not to do that, presumably to make
> termination easier.

Yes, I can see termination being easier with the CAN approach.

> RS-485 and RS-422 have been around since the 60's or 70's, and at their
> base use signaling similar to USB. I'm sure that the originators of CAN
> were fully aware of both of those. So no, I don't think CAN would have
> been much different if it were conceived of today.

Thanks Tim, and everyone else. The comments made here have pretty much confirmed my own suspicions.

Warren

[David Brown]

On 29/04/17 02:38, rickman wrote:
> On 4/28/2017 4:52 PM, Tim Wescott wrote:
>>>
>>> Is there an advantage to the CAN bus approach with the recessive bit at
>>> V++/2, or is the USB differential signal with its wider differential
>>> voltage better for noise immunity or other reasons?
>>>
>>> Another way to phrase the question might be:
>>>
>>> if CAN were to be redesigned today with the lessons learned from USB
>>> (signalling), would they have still chosen the same V+/2 idle signal
>>> that they chose to use?
>>
>> In short, the USB differential signal that uses the full voltage swing
>> does have more noise immunity -- but it doesn't support the wired-and
>> connection that's central to CAN.
>
> USB doesn't support the wired and connectivity because it is really a
> point to point interface at the physical level. There are just two
> devices sharing a pair of wires to send data back and forth. This
> eliminates many signal integrity issues with terminations at multiple
> points.

Exactly. USB is complicated by using the same pair for transmission and
reception (I think USB 3 uses separate pairs?), but there is never any
question about which side is transmitting at a given time.

>
> I don't know much about CAN so I can't say why it is designed at the
> physical layer the way it is, but anytime you connect more than two
> devices on a single channel it is much more complicated to make work at
> all layers.
>

CAN differential signalling had four criteria:

1. It should work with multiple nodes (32, IIRC) on the bus.

2. It should support collision detection and resolution without needing
re-transmission. That's why it has wired-and - each node trying to
transmit sends its telegram identifier, checking each bit as it goes
along and giving up if a higher priority identifier "wins" that bit.

3. It should be cheap and simple to terminate, while supporting a few
volts common mode difference from ground. Having the "recessive" state
defined by a V+/2 signal means termination is just a 110 Ω resistor at
each end of the bus.

4. It should be cheap and simple to implement the drivers. Originally,
CAN drivers were RS-485 drivers with the TX input tied to 0, the receive
enable always active, and using the drive enable input for the data input.

[David Brown]

On 29/04/17 14:32, Tim Williams wrote:
> CAN has strictly better noise rejection and robustness over the USB pair.
>
> USB could stand to take some lessons from CAN. :)
>
> Indeed, CAN is better than RS-422/485, which is already pretty robust,
> while having comparable signaling rates (and build-your-own protocol --
> it's just the physical layer; whereas, CAN takes care of a huge load of
> things at once).
>

CAN is limited to 1 MB/s, and even that is for shorter distances (still
longer than USB, of course). For longer buses the maximum rate drops.
The collision detection system costs - when you have sent a dominant bit
(driving the lines) and then a recessive bit, you need a bit time that
is long enough for the terminating resistors to pull the line, with the
bus's capacitance and the capacitance of all the nodes, back to a
recessive state in good time before the next bit is sent. This severely
limits the speed - RS-485 (and especially RS-422) can run /much/ faster,
over /much/ longer distances.

[Tim Wescott]

Yup. With perfect termination you're still limited by the speed of
light, and I doubt that real systems come close to that.

But, for what it was designed for, it works great.

[kevin93]

On Tuesday, May 2, 2017 at 3:11:38 AM UTC-7, David Brown wrote:
....

> 4. It should be cheap and simple to implement the drivers. Originally,
> CAN drivers were RS-485 drivers with the TX input tied to 0, the receive
> enable always active, and using the drive enable input for the data input.

That doesn't sound like it would work properly - RS485 drivers have totem pole outputs and if two drivers were on simultaneously you couldn't guarantee who would win.

It may work with a diode in series with the output so either of the drivers could pull the output lines to the dominant state.

kevin

[Lasse Langwadt Christensen]

Den tirsdag den 2. maj 2017 kl. 23.06.39 UTC+2 skrev kevin93:
> On Tuesday, May 2, 2017 at 3:11:38 AM UTC-7, David Brown wrote:
> ....
> > 4. It should be cheap and simple to implement the drivers. Originally,
> > CAN drivers were RS-485 drivers with the TX input tied to 0, the receive
> > enable always active, and using the drive enable input for the data input.
>
> That doesn't sound like it would work properly - RS485 drivers have totem pole outputs and if two drivers were on simultaneously you couldn't guarantee who would win.
>

hence the use of drive enable as the "data", output is 0 or "tristate"

[Tim Wescott]

That's why the actual data line is tied to 0 -- with more than one driver
turned on, everyone is trying to force the lines to 0, so everyone wins.

[upsid...@downunder.com]

I have several systems running for more than a decade with 60-75 nodes
on the bus. The practical issue is the individual node stub cable
lengths, not the node DC loading.

>2. It should support collision detection and resolution without needing
>re-transmission. That's why it has wired-and - each node trying to
>transmit sends its telegram identifier, checking each bit as it goes
>along and giving up if a higher priority identifier "wins" that bit.

The CAN style (dominant/recessive) arbitration can be implemented with
real CAN transceivers (like 82C250) or with any RS485 hardware.

It could also be implemented with a 20 mA current loop by putting all
nodes in series as well as the Rx and Tx sides in series. Define 20 mA
as the recessive state and 0 mA as the dominant state. The number of
nodes is limited by the constant current source compliance range. A 24
V current loop limits the number of nodes quite rapidly, but with a
120 V source (still within the IEC ELV Directive), a usable number of
nodes can be used.

With optical devices, define NO_LIGHT as the recessive state and
LIGHT as the dominant state and off you go !

>3. It should be cheap and simple to terminate, while supporting a few
>volts common mode difference from ground. Having the "recessive" state

>defined by a V+/2 signal means termination is just a 110 ? resistor at

>each end of the bus.

As long as you work within a car body, things are easy, but already in
the lorruy/traller case, things can get ugly with ground potential
issues.

>4. It should be cheap and simple to implement the drivers. Originally,
>CAN drivers were RS-485 drivers with the TX input tied to 0, the receive
>enable always active, and using the drive enable input for the data input.

Yes, this was how it was originally done.

[upsid...@downunder.com]

On Tue, 2 May 2017 14:06:36 -0700 (PDT), kevin93 <ke...@whitedigs.com>
wrote:

>On Tuesday, May 2, 2017 at 3:11:38 AM UTC-7, David Brown wrote:
>....
>> 4. It should be cheap and simple to implement the drivers. Originally,
>> CAN drivers were RS-485 drivers with the TX input tied to 0, the receive
>> enable always active, and using the drive enable input for the data input.
>
>That doesn't sound like it would work properly - RS485 drivers have totem pole outputs and if two drivers were on simultaneously you couldn't guarantee who would win.

It works quite well, since the totem pole top transistor is never on.

[David Brown]

On 02/05/17 20:38, Tim Wescott wrote:
> On Tue, 02 May 2017 12:23:37 +0200, David Brown wrote:
>
>> On 29/04/17 14:32, Tim Williams wrote:
>>> CAN has strictly better noise rejection and robustness over the USB
>>> pair.
>>>
>>> USB could stand to take some lessons from CAN. :)
>>>
>>> Indeed, CAN is better than RS-422/485, which is already pretty robust,
>>> while having comparable signaling rates (and build-your-own protocol --
>>> it's just the physical layer; whereas, CAN takes care of a huge load of
>>> things at once).
>>>
>>>
>> CAN is limited to 1 MB/s, and even that is for shorter distances (still
>> longer than USB, of course). For longer buses the maximum rate drops.
>> The collision detection system costs - when you have sent a dominant bit
>> (driving the lines) and then a recessive bit, you need a bit time that
>> is long enough for the terminating resistors to pull the line, with the
>> bus's capacitance and the capacitance of all the nodes, back to a
>> recessive state in good time before the next bit is sent. This severely
>> limits the speed - RS-485 (and especially RS-422) can run /much/ faster,
>> over /much/ longer distances.
>
> Yup. With perfect termination you're still limited by the speed of
> light, and I doubt that real systems come close to that.
>

CAN speeds are much more limited than just speed of light issues - the
requirement to wait for the whole bus to be pulled to the recessive
state is the key limiting factor. (It is possible to cheat a little if
you have particular bus topologies and usage patterns.)

For RS-485 and RS-422, the slow speed of light can be a factor. I have
always thought it a bit weird that you can be putting multiple
characters of your telegram onto the bus at one end before the first
bits have arrived at the other end!

[upsid...@downunder.com]

It _is_ a speed of light issue, the bit time T at 1 Mbit/s is 1 us. In
vacuum, that is 300 m at speed of light. At least with PE coaxial
cables the velocity factor Vf is typically 0.66 and considering the
back and forth delay, we are talking about 100 m maximum distance. Of
course, each node needs some time within T to determine, if it has
acquired the bus or not, this still reduces the maximum distance.

>For RS-485 and RS-422, the slow speed of light can be a factor. I have
>always thought it a bit weird that you can be putting multiple
>characters of your telegram onto the bus at one end before the first
>bits have arrived at the other end!

This is only really an issue for half-duplex protocols. In
full-duplex protocols (such as TCP/IP with a big window size) there
might be several pictures propagating under the Atlantic all the time
:-).

>> But, for what it was designed for, it works great.

Exactly

[David Brown]

I can certainly agree that the speed of light limits the bus length to
100m for 1 Mbps (with "perfect" termination), as your calculations show.
But with CAN, you have the additional RC delay for recessive bits, and
that will increase with longer buses. IIRC the maximum bus length of
CAN at 1 Mbps is 30m, rather than 100m. I guess it is better to say
that the speed of light is /one/ of the limiting factors in CAN bus length.

>> For RS-485 and RS-422, the slow speed of light can be a factor. I have
>> always thought it a bit weird that you can be putting multiple
>> characters of your telegram onto the bus at one end before the first
>> bits have arrived at the other end!
>
> This is only really an issue for half-duplex protocols. In
> full-duplex protocols (such as TCP/IP with a big window size) there
> might be several pictures propagating under the Atlantic all the time
> :-).

It is still weird to me!

>
>>> But, for what it was designed for, it works great.
>
> Exactly
>

Yes. I like CAN, and have used it in a number of projects.

[upsid...@downunder.com]

On Wed, 03 May 2017 15:19:49 +0200, David Brown

You are making the same mistake as the builders of the first
transatlantic cable in 1858. They also assumed that was simple RC
case and increased the voltage to get more speed and finally punched
trough the cable.

In reality, both that telegraph cable as well as a twisted pair
RS-422/485 or CAN cables are transmission lines with a constant L/C
ratio and hence a constant characteristic impedance. The signal
propagates as a _wave_, and only attenuated by the dielectric losses.
With air core coaxials and twin leads, the losses are very small.

[Tim Williams]

"David Brown" <david...@hesbynett.no> wrote in message
news:oecl7i$vcc$1...@dont-email.me...

> I can certainly agree that the speed of light limits the bus length to
> 100m for 1 Mbps (with "perfect" termination), as your calculations show.

> But with CAN, you have the additional RC delay for recessive bits...

No, the line is terminated. It looks like a Zo/2 = 60 ohm resistor at all
points on the bus. The fall time is limited only by the transmitters'
turn-off speed. (This is true for the best case design: a single linear
transmission line with end terminations, no HF losses, and no additional
filtering components.)

[k...@notreal.com]

On Wed, 03 May 2017 12:21:31 +0200, David Brown
<david...@hesbynett.no> wrote:

Why is that weird? Intercontenental communication would be rather
difficult otherwise. Radio wouldn't work very well, either.

[David Brown]

On 03/05/17 18:43, k...@notreal.com wrote:
> On Wed, 03 May 2017 12:21:31 +0200, David Brown

>> For RS-485 and RS-422, the slow speed of light can be a factor. I have
>> always thought it a bit weird that you can be putting multiple
>> characters of your telegram onto the bus at one end before the first
>> bits have arrived at the other end!
>
> Why is that weird? Intercontenental communication would be rather
> difficult otherwise. Radio wouldn't work very well, either.

I know /how/ it works, and I am happy to make systems that rely on it.
That does not stop it seeming strange to me. Lots of things in life can
be strange, or weird, or amazing, or counter-intuitive - even when you
understand how they work and use them every day.

[Jan Panteltje]

On a sunny day (Thu, 04 May 2017 09:56:23 +0200) it happened David Brown
<david...@hesbynett.no> wrote in <oeeml5$v61$1...@dont-email.me>:

na, it is just like the postal service, only faster.
Now all ye need is a FTL tracking code ;-)

[Tim Williams]

"Jan Panteltje" <pNaOnSt...@yahoo.com> wrote in message
news:oeeq9m$khh$1...@news.datemas.de...

>>I know /how/ it works, and I am happy to make systems that rely on it.
>>That does not stop it seeming strange to me. Lots of things in life can
>>be strange, or weird, or amazing, or counter-intuitive - even when you
>>understand how they work and use them every day.
>
> na, it is just like the postal service, only faster.
> Now all ye need is a FTL tracking code ;-)

That's why they send it first, instead :-) (TCP)

[k...@notreal.com]

We see lots of counterexamples of such things every day. Oscillations
on a rope are visible example. It's not as visible but think about
thunder. The frequency content is likely on the order of a few
hundred Hz but the delay can be many seconds. We see many
counterexamples so another shouldn't be too weird.

[k...@notreal.com]

That's another one. The information packed in a letter is much higher
than 1/postal_delay. ;-)