60hz interference with CANbus?

Right, I haven't come across a uC in the lower cost class that inherently supports Ethernet. But a lot of times I have to do this stuff for medical products and a DC path tyically isn't in the cards there. Unless you do a DC restore via clamping but that kind of gets old ;-)

--
Regards, Joerg

http://www.analogconsultants.com

I didn't think a high end CAN controller would be in your price range, I just wanted to provide an existance proof ;) I figured you'd build your own transciever to implement the technique for whatever controller you were using if it seemed applicable. Mind you if anyone does know of this being implemented I'd be curious.

Don't ask me to defend NXP's Web site. Every 'improvement' appears to take another step backwards. The latest being popups that hide the actual datasheet links behind some sort of annoying collective download thingy.

Robert

--
Posted via a free Usenet account from http://www.teranews.com

So would I. An AC coupled CAN bus could be quite useful in safety-critical applications.

That's when their ridiculous zip file habit seemed to have started. Instead of just starting the PDF download like everyone else they show a popup box. Oh man. It's quite sad to see so much self-destruction at work.

--
Regards, Joerg

http://www.analogconsultants.com

If you don't find one, have a look at the (National Semiconductor) DP8352C data sheet it appears the implementors of this card used the circuit basically as shown there

Bye. Jasen

The CAN standard itself doesn't require that you have a DC path, or even that you use electrons to carry your data. It just requires that you have a media that will support recessive and dominant bits, and that the delay between the farthest points in the network be short enough that a bit collision can be detected during the bit time.

Practically this means that your network can't span more than 1/2 bit time divided by your local propagation speed. This rules out high-speed CAN in a building, but doesn't restrict you much in a car or something smaller.

The commonly used CAN transceivers _do_ specify just how to push electrons around, but they are specified with a separate SAE spec -- not CAN. There's no reason you couldn't come up with your own CAN physical layer that could be AC coupled (transmitting or refraining from transmitting a tone comes to mind), but then you'd have to come up with your own hardware to make it work.

--

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

Posting from Google?  See http://cfaj.freeshell.org/google/

Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" gives you just what it says.
See details at http://www.wescottdesign.com/actfes/actfes.html

CAN is a lightweight network with send and forget philosophy. The CPU load in CAN is determined by the need to parse the inbound. Although all of CAN controllers provide some filtering of addresses, it is not enough of hardware filters as a rule. The typical requirement is somewhat about

2K RAM and 10MHz CPU.

Ethernet is much heavier then CAN both in the processing, memory and hardware requirements. By design, it is intended for the different class of applications: point - to - point transfer of the large chunks of data. I would stay away from Ethernet + TCP/IP for anything smaller then

256k/100MHz. That would be an incomplete realization with very limited throughput.

VLV

Yes. CAN 2.0 spec is not concerned with the physical layer. However why reinventing the phy?

As pointed by Robert Adsett, the SJA1000 from Phillips has a mode of operation for AC coupled CAN. Quite simple indeed: they invert the polarity after every dominant bit. In recessive state, the transmitter is in high impedance. Although I have some doubts about the error immunity of this method, it should generally work.

(transmitting or refraining from

Not a very good idea. On collision, there will be an interference. It would be difficult to extract a meaningful data from it.

Vladimir Vassilevsky

DSP and Mixed Signal Design Consultant

[%X]

I have found some, probably quite informative, websites that leave me staring at nothing more than a blank page after they have loaded what looked like good information. Some weirdly crude Javascript is usually to blame for this facet. I am not sure they read the Postmaster or Webmaster in-boxes either but I make the complaint about it anyway, sometimes including a W3C report as an attachment.

If ever you get hold of one of their reps let them know that you have problems with their web-site. It just might get them fixed.

--
********************************************************************
Paul E. Bennett ....................
Forth based HIDECS Consultancy .....
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-811095
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************

Which is all very well until a low priority device begins to be very verbose and hogs the bus continuously (it is one of the documented foreseen failure modes for CANBus).

--
********************************************************************
Paul E. Bennett ....................
Forth based HIDECS Consultancy .....
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-811095
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************

You could even implement a CAN network using a traditional 20 mA current loop with a few nodes. Put all node transmitters and receivers in series and drive the loop with a single floating power supply. When a node wants to send a dominant state, it just cuts the loop current.

Creating an isolated current loop system is easy, when the loop current passes directly through the optocouplers.

Paul

Their site doesn't find it anymore. But then again they seemed to have butchered their web site lately. The ones I found were CAT-5 only and that's AC coupled.

--
Regards, Joerg

http://www.analogconsultants.com

Oops, soory about that Paul.

Robert

--
Posted via a free Usenet account from http://www.teranews.com

No. I was describing a failure mode and really did mean a low priority device running amok on the bus continuously streaming (probably) rubbish data. This sort of thing would lock out the high priority and any other devices on the bus. Hopefully the watchdogs catch this problem.

--
********************************************************************
Paul E. Bennett ....................
Forth based HIDECS Consultancy .....
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-811095
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************

Shouldn't the higher priority messages grab the bus during the ID contention phase?

Robert

--
Posted via a free Usenet account from http://www.teranews.com

Normally it would. Except with the low priority device continuously transmitting to the bus and not behaving as it should, and shutting up, the bus was effectively locked out of use.

--
********************************************************************
Paul E. Bennett ....................
Forth based HIDECS Consultancy .....
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-811095
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************

Well, guess what, a 10 kV low-impedance DC source will also lock out the bus. Yes, devices completely violating the specification can ruin its operation.

But that's not a failure mode. That's one of those things that always remain, after all failure modes have been accounted for.

Bear with me Paul. How can a device send low piority messages(*) successively without giving up the bus to higer priority messages and stay within the protocol?

Robert

• I assume you mean message since device priority has no meaning in CAN.

--
Posted via a free Usenet account from http://www.teranews.com

While any device short circuiting the bus will kill any traffic, but assuming the device honours the specified times after the ACK slot, how would a low priority ID actually kill the bus ?

Paul

According to CAN specification 2.0 Part A in chapter "3.1.5 INTERFRAME SPACING" deals with what happens after the data frame

or

free and

is pending for

first bit following

Only a device that starts to transmit before the end of Intermission (e.g. due to a faulty receiver) could take over the bus with a low priority message. If the Intermission is honoured, the low priority message will loose the arbitration anyway.

Paul