Sub'd for info. Will be undertaking similar project soon!

 

One easy alternative to tap into the CAN bus would be an obd port splitter/breakout (a plug that has both genders that fits over the obd port, allowing you to both tap into the CAN wires, and still retain use of the port). Although, that would move the electronics into the cabin.

I've used CAN a bit for laboratory experiments at work with labview, and with an arduino in the elise. I ignored the rules for node termination (with respect to daisy chaining and parallel devices) and mostly worked with short wire lengths. It still worked fine. My recommendation would be to try it out, and if you lose packets or communication fails, refine the termination resistance (120 ohm). I expect that's only critical for fast data rates, long wires and high bus loads.

 

I need to double check but it will depend on how many modules are in the can-bus. I want to say it’s limited to roughly 26 modules and expanding beyond whatever the limit is would be very difficult. Also regarding wire length, the wires are twisted in a very specific intervals so that may be why the poster above only found it to work with short wires.

 

I've done a fair amount with CANBus for work as we use it on our robots. The wiring is overall quite simple and surprisingly robust, which I think makes it harder to understand when you're first learning because you expect something more sophisticated. There are two wires: CAN-H and CAN-L (High and Low), and you connect all devices on the bus in parallel. At each physical end of the bus, you connect CAN-H and CAN-L together with a 120 Ohm resistor, this is called the "Terminating Resistor". Nothing special, just a resistor. If you don't happen to have 120 ohm, you can do something close, and it will almost certainly work, but in this case, the CANBus in the car should already be terminated properly. You're right on track by adding new devices in the middle. Where exactly you add them is not particularly important for communications purposes, just physical layout. It is likely that the devices at either end of the bus have their terminating resistors more deeply embedded in the device, so it would not be trivial to extend in those directions anyway.

There's a great picture here: CAN Bus Wiring Diagram, a Basics Tutorial | Tek Eye

 

CAN bus has a described method that it is "suppose" to be wired but I have seen all the rules broken and it still works. The ECU will definitely have a termination resistor. Most modern devices that are configurable will allow you to enable or disable the termination resistor. Less sophisticated devices require an external termination resistor. Since I know that CAN bus wiring is very forgiving, just tap in the the CAN bus wiring before the ECU and run it to the devices that you want in the engine bay. If you wire in a CAN bus hub, it will make it easier to expand the bus but you can just keep daisy chaining to the new devices that you add and make sure the last one has the termination resistor. Having more than two termination resistors on the bus will not keep it from working. Use twisted pair when running your CAN bus and you will be fine.

An example of how forgiving the CAN bus is, I once found a CAN bus wired as a star burst with each device having a termination resistor. There were 4 - 5 devices on the bus and the bus was running at 1M baud. The bus worked just fine and completely surprised me that it worked at all.

The other rule of thumb is that at least one termination resistor must exist on the bus. If the bus is short, less than 1 meter, than this works. Once the bus length becomes longer than 1 meter, use termination resistors at both ends. The actual length allowed is actually dependent on the baud rate of the bus. The slower the baud, the longer the length is allowed. Also be aware that there is a maximum length the bus can be for each baud rate.

Later,
Eldon

 

@eldonz, and others, thanks for the great answers! I suspected that a CAN bus would tolerate a bit of poor configuration but I didn't want to find out the hard way. Knowing that you've seen real world examples of less than ideal setups actually work is helpful.

 

I'll add some more confirmation that CAN buses are surprisingly robust if not perfectly configured and (usually) hard to damaged if anything isn't connected properly. I'd also recommend just adding more nodes and only adding in an expansion board if you experience issues, because it's very possible you won't.

How many other devices are you adding exactly? Is it just a few things needed for your new ECU, plus the logger listening on the bus? There is an upper limit on bandwidth for CAN. That shouldn't pose an issue unless you are adding a bunch of devices at high update rates, but it's worth mentioning. Also, what year is this for? There is different amounts of data already present on the bus for different years.

 

He is going to an aftermarket ECU.

Later,
Eldon

 

@steven_d at this this moment it's only the ECUmaster ECU, the dash, the OBDII port, EGT to CAN, and perhaps a data logger. I have visions of 4 more tire temperature sensors, a CAN switchboard, a multifunction display, and possibly more. If in the future I switch out the dash for something aftermarket, I should be able to adjust the CAN speed. The car is pretty torn apart right now and I'm already opening up the ECU connectors to add additional pins, thus it seems logical to me to make future expansion as easy as plugging in a Deutsch connector.

The car is a 2006 with a REV400 kit, and 9:1 pistons.

 

Okay, so the only extra traffic will be the EGT's. At least for now.

As for the baud rate, isn't it already at 1 Mbit/s? I have a 2007 and that is the bus bitrate, I'd assume other years would be the same.

 

I believe that the baud rate is the same but I haven't verified.

 

I've effectively done this and made it all reversible by extending the dash wiring in a small sub harness.



I also fitted the ADU ECUmaster dash so I needed an adapter harness anyway, and I used that adapter harness to splice a new CAN branch which goes into a daisy chain of GPS2CAN, TPMS and a CAN expansion module which I use to give myself a bunch of extra inputs.



End result is that I have TPMS, GPS, WheelSpeed from ABS which is used for a TC strategy and various buttons/inputs.



I then sent a "can trunk" back to the engine bay in case I want to add something there later such as EGT2CAN but also with +5v and GND from the dash, which I then used to add loads of engine sensors without any factory harness splices.



Whole thing is completely reversible, but could have been done with a lot less complexity if I was willing to just splice factory harness !

Branch length limitations can be worked around by simply changing which of your can devices are terminating the bus.

 

I'll tack on a few more points to this thread for the benefit of future readers.

A CAN network is quite robust, a decent design back when Bosch did good work (don't get me started on their integrated circuit divisions these days). There are definitely rules about total bus length vs. data rate, etc. but in general the system is very tolerant. Automatic error detection and retransmission is handled automatically by the hardware interface chips (called PHY's for the PHYsical layer of the OSI model) so you normally don't have to worry about error correction... if the packet arrives you can accept that it's accurate.

CAN is a backbone-and-stub physical topology. You can liken this to a busy "arterial" street with a bunch of short dead end streets turning left and right going to individual houses. There is a pair of signals (CANH and CANL) which are differential but not balanced. This last point is crucial because it means there MUST be a shared ground reference to every node, you cannot just run CANH and CANL to the node and expect it to work. Look at the signals with a scope sometime and it will become immediately obvious why this is true.

PHY chips are quite robust. Most of them will tolerate shorts on their CANH and CANL to +12V, Ground, and each other without damage. I wouldn't do it on purpose but it's nice to know there's some protection circuitry in there. There are quite a few manufacturers of CAN PHY's, some of which work very well and others which I intentionally avoid. Unless you're designing and building CAN products you will not need to worry about the specific components involved.

The backbone has terminators at each end. Their standard value is 120R. Having two of them means the total seen across the pair is 60R. This does mean it is a higher current system, but it's also relatively low impedance which makes it more noise resistant (and an automotive environment is very electrically noisy). These terminators are NOT OPTIONAL. You can sometimes get away with only one (though only in a test situation, never production) but you cannot operate with zero terminators. This is because the collision backoff algorithm depends upon the bus assuming its passive state when no transmitter is operating, and by definition if no one is transmitting no one is discharging the network - so you need a passive resistance to make that happen.

To connect a node (the "houses" above) to the backbone (the "arterial" above) we use a short segment called a "stub" (the "dead end streets" above) . Stubs are not electrically terminated. Routing the backbone through the vehicle takes some planning because there can only be two ends, each with a terminator. The stubs are NOT additional ends of the backbone and their individual and cumulative length must be kept to a minimum. As a rule of thumb a few inches is fine, more than a foot and you should be rerouting the backbone to shorten the stubs. If a stub gets too long its impedance discontinuity can cause reflections on the backbone which corrupts the data. To answer the inevitable next question, No, you cannot just presume that error detection and retransmission will "hide" your improper layout for you. Retransmissions consume bandwidth on the backbone; the system only works if you don't overload it. If poor layout due to excessive stubs, or excessive stub length, causes too many retransmissions you will eventually have ZERO throughput and you'll experience weird, intermittent, difficult to diagnose errors.

CAN is forgiving about its cable. The data rates, network lengths, and impedances do not require formal transmission line analysis. Twisted pair works well, even one pair out of a CAT5/6 cable will work for a stub. Be thankful CAN doesn't run on coax!

I mention all of this to emphasize that you can't just go hanging a bunch of new wire on a CAN network. Want to connect a new node? Great! But do it intelligently. Find a place on the backbone centered between two existing stubs, or at least 6-12 inches away from an existing stub, to tie into the backbone. Don't hang several nodes on a single stub, that's not how it's designed to work. Note this means you shouldn't find an existing stub and just jumper your new one next to it - create its own stub off the backbone. It might work fine for testing, it might "work fine" on the track today, but someday it will bite you by causing problems out of nowhere. Don't splice a node onto the end of the backbone past the terminator either... if you must be at the end, relocate the terminator past your new node and/or extend the backbone to reach it.

 

I appreciate all the replies and insight. I'm likely going to do one of two things. Either is probably overkill but I don't want to end up doing rework. Since I'm most interested in adding items to the bus in the engine bay, I've resigned myself to the fact that there's no way I can avoid cutting the factory wiring short of running a whole bunch of new wiring from the cabin back to the dash, and likely getting a new dash with a configurable termination resistor. And who am I kidding, my car isn't going back to stock! That being said, I want the install to be clean and facilitate future expansion.

Option A:
Pull the factory pins from the ECU connector. Trim them off and repin the leads for a DTM connector. Pull that connector out of the harness, so that it sits next to the ECU connector. Run a jumper from that connector to the CAN distribution block. Run another jumper from the other end of the CAN block back to the ECU connector. The ends of that jumper would be pinned for the factory ECU connector, completing the CAN bus with the dash and ECU still being the ends of the bus. All new items are simply plugged into the CAN block, and act as a node.

Option B:
Pull the factory pins from the ECU connector. About 2 inches from the end of the pin, cut each wire in half. Splice in a third wire using a heat shrinked, open barrel splice. Run the third wire to the CAN block via a DTM connector. The CAN block can be configured to serve as the bus end by moving a jumper to enable a termination resistor. Likewise, the ECU's termination resistor can be disabled. This would result in the end of the CAN block and the dash being the two ends of the bus and the ECU is a node.

A or B?

EDIT: If this isn't clear, I can try to create some drawings tonight.