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.
-- 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
Because they're robust and cheap?
Hmm. It may have been that :)
-- Tim Wescott Wescott Design Services http://www.wescottdesign.com I'm looking for work -- see my website!
Example part:
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.
Yeah, except for USB, those are basically the same PHY receivers. :-)
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
-- Seven Transistor Labs, LLC Electrical Engineering Consultation and Contract Design Website: http://seventransistorlabs.com
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).
Tim
-- Seven Transistor Labs, LLC Electrical Engineering Consultation and Contract Design Website: http://seventransistorlabs.com
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.
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.
More likely to draw the leakage current and hence keep the common mode voltage within limits.
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.
..
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:
Yes, I can see termination being easier with the CAN approach.
Thanks Tim, and everyone else. The comments made here have pretty much confirmed my own suspicions.
Warren
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.
CAN differential signalling had four criteria:
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.
But, for what it was designed for, it works great.
-- Tim Wescott Wescott Design Services http://www.wescottdesign.com I'm looking for work -- see my website!
On Tuesday, May 2, 2017 at 3:11:38 AM UTC-7, David Brown wrote: ....
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
hence the use of drive enable as the "data", output is 0 or "tristate"
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.
-- Tim Wescott Wescott Design Services http://www.wescottdesign.com I'm looking for work -- see my website!
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.
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 !
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.
Yes, this was how it was originally done.
It works quite well, since the totem pole top transistor is never on.
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!
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.
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 :-).
Exactly
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.
It is still weird to me!
Yes. I like CAN, and have used it in a number of projects.
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.
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.)
Tim
-- Seven Transistor Labs, LLC Electrical Engineering Consultation and Contract Design Website: http://seventransistorlabs.com
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.