CAN bus Problem

You don't tell, what type of optocoupler You use. Cheap optocoupler have propagation delays of

Regards

Klaus

In theory: yes. But rather much doubt that this could have any measurable effect on propagation timing unless you chose a ridiculously slow type of transistor, or aren't driving it correctly. In other words: if adding that transistor drove your propagation time beyond the acceptable, you must already have been perilously close to it before.

"Longer" meaning what? How many meters? Or, more to the point: how many nanoseconds of cable propagation time? Do you have any measurement or idea what your total propagation time (two optos, two CAN transceivers, one cable) actually is, with and without the transistor, respectively?

To me that sounds like somethings wrong with those nodes, not with your new ones that have the transistor. By design, a CAN node goes bus off because it thinks *itself* is behaving incorrectly. Can you tap into on of those and find out why they go bus-off, i.e. what types of errors they're seeing?

important

Well, the latter could be the case. Many people just 'trow in' a transistor and a base resistor that is way too low. The transistor saturates heavily and takes 10s of microseconds to get out of saturation. This can be prevented very easy by adding a schottky diode across collector and base.

Meindert

transistor

collector

Thanks I'll say it to the concern person We are trying to reduce the time, but we don't have thinking about this solution Herve Lhuguenot

Hi

Yes Klaus it's cheap optocoupler, that's one of the problem. We are searching for better OC with same package

Thanks Hervé Lhuguenot

Hi,

important

That's what I think !

Longer is 300 meters (at 83.333 Kb/s i.e. BT = 12us) instead of 100 meters

• cable I don't have any information propagation time on the cable (Corel L120)

With fastest transistor it seems to work. The older products without transistors works fine until we plug a new one.

I know but we have searching for the problem for 5 days. That's why I don't know what type of error is the problem. It's not logical !

No, I can't reproduce the problem where I am (not enough cable). The problem appears on a installation far away. We are going to buy cable to test new design, 'faster'.The element which goes off sends time each second. It's the element which transmit the frames on the bus.

Thanks Hans-Bernhard We are actually trying to reduce the time. Hervé Lhuguenot

"Hans-Bernhard Broeker" schrieb im Newsbeitrag

Yep, I agree. When using CMOS-parts the propagation delay increases only for a few ns, e.g. the analogue switch 74HC1G66 from Philips. Additional prop-delay ~ 11 ns! ...

Yep, this approach is highly recommended when debugging CAN-applications.

Regards, Taso

"MU13" schrieb

...

Can you give a few more details. What kind of transistor do you apply? What is the prop-delay of this transistor (data-sheet or measured)? What takes place on Rx and Tx? Maybe you can analyze this with a logic probe and tell us the prop-delay of a node with transistor.

I surely think it is, but you do not give us any more details nor do you try to debug the whole thing. The bit error type might be important. Maybe your new nodes exceed a certain inductance value on the bus, you don't tell.

How many nodes do you have on the bus? Far too less information for granting serious help, sorry.

Regards, Taso

transistor

The transistor is a BC857. I don't have any other references. But my question at the beginning was more software oriented. Between the tx signal and rx signal on a node with transistors, I have 4.5us (2 opto + 2 transistor + 2 drivers ) The bit Length is 12 us. With the programmation I use, the sample point is at 8.5 us. So my first idea was to put the sample point at 11 us for example. But, imho, I don't think (now) that it will resolve the problem. I think that I will have to reduce prop delay or reduce speed. We have found fastest optocoupler which not need the use of Optocouler, so i hope that will resolve the problem.

don't

I don't have access to the bus so I can't analyse exactly what happens. I only have the information of how the products reacts on the installation site by phone. I have products here, but I can't reproduce the problem, because I don't have enough cable length (actually, we'll command it).

Yes but I can't know it actually.

tell.

There's actually 12 nodes on the bus. If I put only 1 'ok node' and 1 'error node' (with long cable between): the error happens. So the problem isn't the number of nodes on the bus. I'm Software Enginneer, so excuse me, but how can the inductance value be different than the other nodes ? We use the same Driver. I don't understand exactly what you mean about the inductance value. How can I measure it .

I'll do it as soon as I can produce the error. But actually I can't.

problem

new

the

With 12 nodes without transistor, it works With 1 node without, and 1 with, it doesn't work. With 11 nodes without transistor, and 1 with it doesn't work.

Thank you, but I effectively have too less information.

Regards Hervé Lhuguenot

What was it without the transistors?

That cannot work. Due to the enormous propagation delay in your optocouplers, you've exceeded the overall timing tolerance.

Exactly

important

Yes it's a CMOS transistor !

I don't have seen it myself, so i doubt of the person who said it to me ! For me it's impossible that the good goes bus off instead of the bad !

I'll try as soon as I can.

Thanks Taso Herve Lhuguenot

I don't have made the test.

optocouplers,

If I set the sample point at 11 us, am I resolving the problem or not ?

We have found a fast optocoupler which doesn't need the use of transistor at the input. So we think that will resolve our problem.

Thanks Regards Herve Lhuguenot

On Fri, 31 Oct 2003 12:41:36 +0100, "MU13" wrote: [snip...snip]

Maybe You have only measured the upgoing edge. As transistors and optocouplers do not act symmetrically, the falling edge normally has a much higher propagation delay (look to Meinderts posting about saturation effects).

Regards

Klaus

I strongly doubt it. I don't have my reference texts at hand, so I can't give you a more precise answer right now.

You have 4.5 us transceiver dely, and at 300 meters of bus length, you have to take into account something like 1.5 us per direction of cable delay on to of that. Your problem most likely is that you can't get ACK bits sent and received in time.

You have three to four variables to play with --- transceiver delay, cable length, sampling time, and, as a last resort, the bus speed itself. It's their combination that really defines the problem. One of them will have to change to fix it, and I doubt that moving the sampling point alone is going to do it.

You _really_ should have someone at your shop with a CAN spec at hadn and enough experience to use it, so you can do this on your own without asking on the 'net, though, if you're going around deploying devices to remote users...

Thanks Hans-Bernhard

Hi

We've tried Meindert suggestion, but had another problem. Our transistors wasn't correctly polarized. We have resolved the problem.

Ok Thanks Klaus