2
\$\begingroup\$

This vehicle that I've started co-developing is designed with only a 120 termination resistor on the CAN bus. Obviously there should be two of those resistors on two ends of the bus. I will be making that change, but there were some troubles in the past and present with the CAN bus. I'm wondering if it is likely that those are/were caused by this error. And how critical it is/was that the bus was terminated at only one location, and at 120 ohm.

I will be troubleshooting those issues, but they're intermittent. So it would be of great help to know whether it is sensible to keep looking for them if this termination resistor issue is solved.

Some information:

  • J1939 communications protocol is used
  • Bus speed 250 kbit/s
  • Bus length ca. 7 m
  • Amount of nodes is 15 (I guess), combined, 60 unique messages exist.
  • Average busload 40%, at intervals the bus load peaks at 100%

There are also issues with one node intermittently not getting online at startup. Twisted pairs were used that wasn't forgotten by the designer, if you were wondering...

|improve this question
\$\endgroup\$
  • 1
    \$\begingroup\$ And how critical it is/was that the bus was terminated at only one location, and at 120 ohm. I would say: very critical. The CAN bus is designed to be a 120 ohm system and it can only do so when all terminations are in place. Omitting a termination resistor results in reflecting signals. If you can force the CAN bus to work at a very low speed (10 to 100 times slower than nominal) then maybe it could work without all terminations in place. But that would be a "hack". The CAN bus needs to be properly terminated to work properly. \$\endgroup\$ – Bimpelrekkie Jan 29 '19 at 10:42
  • 1
    \$\begingroup\$ @Bimpelrekkie I figured that whether it works or not, it is bad engineering practice and should be revised. My colleagues say that at one time, no termination resistors were used at all, and that it did work, albeit not perfectly. How errors like this can sneak through into a production vehicle is beyond me, but that's how it was. I'd like to assess the damage this was did before trying to fix errors that won't be occurring anymore. Do you think it is plausible that one node will be inactive on the CAN network in the situation described? \$\endgroup\$ – Bart Jan 29 '19 at 11:07
  • \$\begingroup\$ @Bimpelrekkie I'd like to add that there are physical duplicates (but with a unique identifier) of the erroneous node. It concerns a power distribution module, that controls actuators. I find it strange that only one(and always the same) of those nodes went offline, and not the others, even though they are very similar. Maybe the fact that it is connected in a slightly different way than others, that impedance/capacitance or something is slightly different, resulting in the same node going offline everytime. \$\endgroup\$ – Bart Jan 29 '19 at 11:10
  • 2
    \$\begingroup\$ Since the CAN bus is a shared bus there is probably no point in inactivating one node. Probably only completely disconnecting the node(s) will help. Signal reflections can lead to all kinds of weird behavior, which is what you experience. I would not waste time on trying to work around that as whatever you do the system will probably never operate reliably. Either you fix the problem or disconnect the problematic nodes. \$\endgroup\$ – Bimpelrekkie Jan 29 '19 at 11:15
  • \$\begingroup\$ Given the bus even worked, at least long ago, in FAULT mode (unterminated), I'd be suspicious of the EMI/bypassing/powerIntegrity/etc of that oddly behaving node. \$\endgroup\$ – analogsystemsrf Jan 29 '19 at 11:26
10
\$\begingroup\$

From a professional point of view, this is a critical problem. Missing termination will cause energy bouncing back at the end which isn't terminated. This could lead to strange random noise on the line, such as for example transients or random pulses that seem like ok binary pulses, but with wrong voltage levels etc. CAN Hi and Lo don't necessarily behave the same when this happens.

In practice, the CAN bus is so rugged that it might be able to "limp home" despite missing termination. You might get random error frames here and there but otherwise receive correct packages. How well this works "by accident" depends on baudrate, CAN transceivers used and wire length.

In my experience, you often get away with only using one terminating resistor at low baudrates. Errors tend to start becoming particularly noticeable around 250kbps, which is the most common baudrate. At faster baudrates it will typically not work at all.

This could match the problem you describe. Another common problem is missing signal ground, which could give very similar error symptoms: intermittent error frames, the system sometimes working perfect, other times not at all.

Either of these problems will manifest themselves with spurious error frames in your CAN listener.

100% bus load means an unhealthy, dangerous bus. Either because whoever designed the bus was a quack, or because a quack started to hook up other equipment to an existing bus without consulting engineers. Sure, if the bus is non-critical, you can design by purposely allowing 100% bus load peaks... maybe. But J1939 buses are almost exclusively performance and/or safety critical. If so, you definitely need to get to the bottom of the bus load problem.

|improve this answer
\$\endgroup\$
  • \$\begingroup\$ "Another common problem is missing signal ground" ... that's why i always refuse to say: "CAN consist of 2 wires". \$\endgroup\$ – Huisman Jan 30 '19 at 9:51
  • \$\begingroup\$ @Huisman It's not really something up for debate, since there are industry standards from ISO and CANopen both, that are specifying this. Engineers have to fall in line or call their bus something else other than CAN. In these standards, it is stated that CAN consists of 5 signals: CAN_H, CAN_L, CAN_GND, CAN_SHLD, CAN_V+. The former 3 are mandatory and the latter 2 are optional. \$\endgroup\$ – Lundin Jan 30 '19 at 10:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.