Hi Michael,
Sounds like you were not getting a signal because the input impedance to the device is so low it gobbled up all your current.
You need the termination resistors on each end of the main line to not only establish a differential voltage, but to complete the current path back through CANL.
I see that you mentioned a star, but is it a true star topology with all communication going through the star central controller? Or is it just a bunch of stubs connected in a star shape?
You can branch out many stubs in any direction from the main line. Care must be taken to keep the stub length under a critical length.
Since stub-lines are unterminated, signal reflections can develop in a stub that drive signal levels back and forth across a receiver's input thresholds, creating errors. Bit-sampling occurs near the end of a bit, so it is mandatory that all signal reflections in a CAN stub-line be attenuated before or during the propagation delay segment to provide an adequate margin of safety.
To minimized reflections, stub-line length should not exceed one-third (1/3) of the line's critical length. Beyond this stub-length, many variables come into play since the stub is no longer considered to be a lumped parameter, and is the maximum length that a stub remains invisible to a transmission line. The critical length occurs at the point where the down-and-back propagation delay (tprop(total)) of a signal through a line equals the transition time of a signal (the greater of the rise or fall times).
Network Critical Length = tt = tprop(total)
Therefore, a typical CAN driver may have a 50 ns transition time, and when considering a typical twisted-pair transmission line prop delay of 5 ns/m, the down-and-back delay for one meter becomes 10ns/m for the cable. Therefore, the critical length is 5 m (50 ns / 10ns/m = 5 m), and the max un-terminated stub length for the network is 5/3 m or 1.67 m.
For example, on a 40 m bus, a typical propagation delay may be approximately 200 ns for each down and back delay, 60 ns for the transceiver��s driver prop delay and another 40 ns for the receiver prop delay. This brings the total down-and-back prop delay to 500 ns. Even with a 1 Mbps signaling rate, this 500 ns tprop_seg is more than enough time for signal reflections to attenuate with the 1.67 m stub-line.
When critical length is taken into consideration, driver slew-rate control becomes a valuable design asset. The Standard recommends a maximum un-terminated stub length of 0.3 m with a 1 Mbps signaling rate, but with slew rate control, reduced signaling rate, and careful design, longer stub lengths are easily obtained.
For example, if a 10 k�� resistor is applied for slope-control at the Rs pin (pin 8) of the HVD230 CAN transceiver, a 160 ns max transition rate increases the maximum stub length to 16/3 m or 5 1/3 meters.
I hope hope this helps.
Cheers,
Steve
-----Original Message-----
From: canlist-***@vistrem1.vector-informatik.de [mailto:canlist-***@vistrem1.vector-informatik.de] On Behalf Of John Dammeyer
Sent: Friday, June 23, 2006 3:29 PM
To: ***@vector-informatik.de
Subject: RE: [CANLIST] Canalyzer report Frame Error. Any ideas why?
Hi Michael
Gosh. That's such a tough question. Perhaps someone like Cyrilla can add something or someone else involved in the motor end of things.
Post by michaelvincentsantosCurious. In the automotive world, is there a common placement where
the bus is usually terminated.
The CAN rules say at the termination at the end of the bus. That's mostly a transmission line issue which is especially important at the 1mpbs rate as we're into RF at that point.
Of course, all rules can be broken and lots of people run longer stubs and star networks. There's one really go app note out there on how to terminate a star. (Don't off hand remember where).
Since we aren't really doing RF where we want maximum power transfer to the load (the antenna for example) on a transmission line, the termination is really more to reduce reflections that may reduce or even null out the signals at certain places on the bus. And Murphy's law says that the null is where you'll always put the critical node. 8-(
Steve Corrigan can clarify electrically how it all fits together but the bus also requires the termination resistors to complete the signal path on some of the drivers. There are others that can operate with only one side active and the other shorted or open; all for fault tolerant situations.
Using the 82C250 data sheet for info, the max CANH voltage can be 4.5V and the min CANL voltage 0.5V for a difference of 4V across the 60 Ohm bus load.
You'd think that then there'd be 67ma max on the bus during a dominant which is just under the max supply current parameter of 70mA.
Again from the data sheet the minimum differential input resistance of the receiver section is 20K and max number of nodes is 110 devices. That makes for a worst case parallel combination of 182 ohms in parallel with our 60 ohm termination for a total differential load of 45 ohms. That's at maximum 88ma which may be reached near the end of a six bit dominant error flag at 1mpbs (depends on impedance) and most certainly will be reached at low bit rates.
Maximum supply current is rated at 70mA so we can see that we might exceed that value in a worst case situation. So what happens if there is one extra termination resistor?
With our two 120 ohm terminations we have 60 ohms in parallel now with another 120 ohm resistor which results in a 40 ohm load or 100ma drive requirement.
Doesn't take much to potentially take down a bus. And some nodes may have weaker drivers or 3.3V drivers.
That's the long version of why termination is important...
John
Now that I say that I guess it
Post by michaelvincentsantoswouldn't be at each node (PCM, etc.). Only reason I mention that is
because I have the PCM unit on my desk modified with power etc. So I
am thinking it does not have the proper termination, which I have
added. So I am able to see bus traffic with the PCM or diag tester
connected to CANalyzer with an added termination resistor. So maybe
tester has some added resistance or something. I'll check out those
points you mentioned.
Thankfully,
Michael
Post by John DammeyerCheck and make sure your GND, CAN_H and CAN_L are correct. Make
sure your
Post by John Dammeyertool doesn't add an extra termination resistor. When you
have your CAN
Post by John Dammeyeranalyzer and tool connected you need a 120R resistor at both ends.
When you
Post by John Dammeyerpatch into your car you probably don't need one at all since the the
CAN bus
Post by John Dammeyershould already be properly terminated.
John Dammeyer
Wireless CAN with the CANRF module now available.
http://www.autoartisans.com/products
Automation Artisans Inc.
Ph. 1 250 544 4950
-----Original Message-----
Sent: Thursday, June 22, 2006 11:25 AM
Subject: [CANLIST] Canalyzer report Frame Error. Any ideas why?
Hi Everyone,
I would be greatful to anyone that can comment on my situation.
Thanks in
Post by John Dammeyeradvanced.
So the situation is that I can transmit and recieve data when I
connect my
Post by John Dammeyerproduct(diagnostic teser) to canalyzer.
I am also able to transmit and recieve data when I connect a Ford
PCM to the
Post by John DammeyerCanalyzer.
When I connect the diag tester and PCM to Canalyzer I just get a
bunch of
Post by John Dammeyerframe errors.
Any suggestions how to resolve or why I am getting all these frame
errors?
Post by John DammeyerI have used this same setup with a different manufacturers diag
tester and
Post by John Dammeyereverything.
MCU <-> Canalyzer OK
PCM <-> Canalyzer OK
MCU <-> Canalyzer <-> PCM NOT OK
Thanks,
Michael
_____
Yahoo! Sports Fantasy Football '06 - Go with the leader. Start
<http://us.rd.yahoo.com/evt=33539/*http://football.fantasyspor
ts.yahoo.com?o
Post by michaelvincentsantosvchn=YAH&ovcpn=Integration&ovcrn=Mail+footer&ovrfd=YAH&ovtac=AD>
your league
--
Archives and useful links: http://groups.yahoo.com/group/CANbus
Subscribe and unsubscribe at www.vector-informatik.com/canlist/
Report any problems to <canlist-***@vector-informatik.de>
--
Archives and useful links: http://groups.yahoo.com/group/CANbus
Subscribe and unsubscribe at www.vector-informatik.com/canlist/
Report any problems to <canlist-***@vector-informatik.de>
--
Archives and useful links: http://groups.yahoo.com/group/CANbus
Subscribe and unsubscribe at www.vector-informatik.com/canlist/
Report any problems to <canlist-***@vector-informatik.de>