Last Online
Recent Posts
posted in Firmware read more

Oh... you're using Linux. I used Arduino 1.6.0 with Windows XP and it worked as prescribed here:
and here

posted in Firmware read more

It took some work, but I got it to flash and run OK. I am able to change program code at will now and observe changes via the LEDs, but I haven't tried CAN yet. I am able to connect CBT Bluetooth to my iPhone using the Lightblue app too, but I want to work towards an iOS app ASAP. What is your error message?

posted in General Discussion read more

If you plan to use the CBT on a candidate vehicle, you might want to check to see for sure whether your candidate vehicle actually has a CAN bus. For example, CowboyMatt might be out of luck with his 2003 Toyota Matrix, as it might be too old to have CAN. While everything 1996 and newer has OBD2, CAN didn't come in until much later on most cars sold in America. Sometimes there is a CAN bus, but it doesn't come out on the OBD2 connector.

The Internet has lots of misinformation, so beware. For example, here is a posted list, but the list is not up to date and is likely incomplete.

I use for subscription data that is vehicle specific. It is relatively inexpensive, electronically searchable, and accessible anywhere there is Internet. I do occasionally find data missing, such as certain schematics, but 98% of everything a mechanic might normally need should be there.

posted in Hardware and Wiring read more

Contrary to popular misunderstanding, CAN is a three-wire interface. The three connections are CAN-High, CAN-Low, and CAN-ground. Most people (including many Electronics Engineers) often believe that only two wires are needed... CAN-High and CAN-Low. In practice, two wires are indeed normally sufficient in a vehicle. That is because each node on the CAN bus uses the same ground, and that ground can be different from node-to-node by several volts and things will still be OK. In a test cell, or other ad hoc network situations, where CAN nodes can have different power grounds, three wires are always the best practice.

CAN is a differential bus interface, hence why two wires are needed in addition to ground, instead of just one wire and ground, as is the case with some other network physical layers. While one wire goes high the other goes low, and vice versa. This gives the bus better immunity to noise, both radiated and conducted; effectively increasing the distance CAN messages can travel without corruption.

The USB is also a differential bus, but the behavior of USB is much different than the behavior of CAN. Differential signals have a characteristic called common mode rejection. This is the ability to disregard the effective DC level the signal pair rides on. That effective DC level shifts when the ground voltage differs from node-to-node. In a vehicle, sheet metal ground can vary by up to 1V and still be considered OK. This is because the sheet metal is used as a power source causing current to flow across it. Sheet metal has resistance and that resistance causes appreciable voltage drops to occur when significant current flows. Most vehicle specs allow up to 1V between different body points and still be considered OK. If you try to measure this, you may need an Oscilloscope to see it, as the biggest voltage drops are dynamic (high frequency AC) in behavior.

CAN can usually deal with several (>7V+) Volts of ground offset between nodes because the transceiver has high common mode rejection, so even a few Volts between grounds is fine. However, USB does not have high common mode rejection. If the ground voltage between two USB nodes exceeds about .5V, bad things happen. Exceed it by a little more than .5V and data is often lost. Exceed it by more and the connection may need to be reset. Exceed it by more yet, and the smoke comes out. Without that smoke it won't work. Perhaps you’ve heard of the difficulty in putting the smoke back in once it escapes. This why USB connectors always have USB ground hardwired between nodes and CAN connectors may not (USB is always at least a four wire connection).

However, despite CAN's high common mode rejection, in certain cases the CAN ground will be needed and in most cases it won’t hurt to have it there unnecessarily. For example… According to the schematic, the CBT appears to be powerable via the USB, without any 12V connection. If the USB is connected to a laptop PC, the PC ground is the USB ground and then of course the USB ground becomes CAN ground for the CBT. If the PC is powered from an AC power source, the PC ground might be at a different potential than the actual vehicle ground. If the CBT has no connection to vehicle ground at all then the vehicle CAN ground can be at a much different voltage than the CBT CAN ground and the CAN bus connection to the vehicle can be disrupted. Any big difference in ground voltage between the PC and the vehicle can permanently damage things, or just give you headaches with intermittent issues. The bottom line is to always remember that CAN needs all three wires in order to be robust. The 3rd wire is there normally by default via the 12V power connection (and it’s ground), so as long as the CBT isn’t powered from a source other than the vehicle, two wires for CAN should be fine.

Last words of wisdom on CAN… CAN’s differential wiring is meant to be a twisted pair. The twists need to be in the same direction as, and with about the same number of twists per distance as, the CAN bus the CBT is connected to. The higher the CAN bus speed, the more important this is. 250 kbps and higher should be twisted for sure. If the vehicle is a hybrid with a high voltage battery, then twisting, split termination, common mode chokes, filter caps, and daisy chain topology rules should all be strictly followed. In some extreme cases shielding of the CAN pair may become necessary. The Brits call this shield a “screen”. That is because they don’t use screens to keep out bugs when they open their windows in the summer, or they would know better than to confuse the two concepts. Any shield wire should only be connected at one end to avoid the shield from becoming a current carrier, defeating the shield's purpose (and making the shield that was intended to minimize noise into a noise maker).

posted in Hardware and Wiring read more

I noticed that the schematic shows that the CBT offers an easy way to terminate the CAN bus when necessary, by shorting what looks like a solder pad to place a 120 Ohm resistor between CAN Hi and CAN Lo. While this method should suffice for most applications, everyone should be aware that there are other termination methods and some good reasons to use them that I will try to describe here.

The higher the bus speed the more important proper termination is to bus integrity. The entire bus topology needs to be considered before some of the more obscure termination methods are deployed. Remember that some buses you may want to tap into send safety critical information from one ECU to another that can affect the safe and reliable operation of the vehicle.

Termination is probably needed at the CBT when the CBT is the end node on a CAN bus, which will be normal when bridging (severing a CAN bus) and probably not very normal when just monitoring. The normal topology is that the bus is a daisy chain, meaning that it goes from ECU to ECU to ECU to ECU, with the ECUs that are serving as endpoints on the daisy chain requiring termination and all the ECUs in the middle generally requiring no termination. Of course like all rules, these rules are often broken to save cost or for practical convenience, especially for test tools that don't remain on the bus for long periods of time. By "daisy chain", it means that the 2 CAN wires are continuous from one end to the other, with no splices, tributaries, "T" connections or stubs. Chain.jpg

This is why many ECUs have the same CAN bus on two different sets of pins, to avoid having more than one wire per pin (weather proof connectors don't allow more than one wire per terminal) and to allow the ECU to make the daisy chain connection internally with as short of an internal "stub" as possible. However, sometimes a short stub is impossible to avoid, like when connecting the CBT to an existing bus for bus monitoring. Even if you connect the CBT to an existing bus to monitor it by tapping into the bus wires, a "T" connection is made where you splice in and the stub is the length between your splice point and the bus transceiver internal to the CBT. I would keep that distance less than 6 inches at 500 kbps and higher as a general rule of thumb.

If the bus speed is 500kbps or higher, you'll also want to pay good attention to termination requirements. At 1Mbps this becomes critical. Thankfully, most CAN buses are 500 kbps or slower. When a stub can't be avoided it can be acceptable to use what is known as weak termination. This is a value of resistance much higher than 120 Ohms, but I'll not get into why that is here unless someone asks. You can read about it at the following link though if you'd like.

What is important for all of us to know is that a more common termination method these days in automotive is called "split termination". This is when the 120 Ohm terminator is split into two 60 Ohm resistors placed in series and a capacitor goes from the resistor-to-resistor junction to CAN ground. This will minimize the noise that the CBT can inflict on the CAN bus, and can make the connection more reliable for the CBT when a lot of noise is present. This is an EMC concern.

To address other EMC concerns, it is also common to add additional capacitors as filters and a common mode choke. I have seen split termination and common mode chokes solve huge problems in certain cases, such as in a hybrid or electric vehicle where high voltage is present.

Here is a depiction of split termination, the common mode choke, filter capacitance, and ESD protection. I can envision making an add-on board that does this for the current CBT, and any future iteration of the CBT having some or all of those components built-in and the split termination similarly selectable as the single terminator is now. These parts need to be as close to the CAN transceiver as possible, hence why making them part of the main PCB design is preferred.

posted in General Discussion read more

Hello All,

I am in the Detroit area. I look forward to becoming proficient with the CANbus Triple. I see this tool as a low cost alternative to some of the other CAN tools I have worked with, but with the ultimate in capabilities since the firmware will be under my own control.

I have a GM vehicle that uses the CAN bus for powertrain and I plan to start out by monitoring that bus and extracting useful data. I haven't yet decided what to do with that data, but that isn't the point. The point is that variables sent from one module to another across CAN often limit what you might want to do with the vehicle. This tool is a way to intercept that variable, modify it, then send it along to the device(s) that use that variable.

For example... you've modified the transmission so it can handle the added performance of your target engine mods, but the transmission controller keeps requesting a huge torque reduction from the engine during each shift. The right thing to do is recalibrate the transmission controller so it sends a more appropriate torque reduction command. Depending on the powertrain, this might be very expensive or even impossible to do without insider information.

The CANbus Triple can be installed as a bridge, severing the connection between the transmission control and the engine control. The CANbus triple can be easily programmed to pass along every message it captures, making the bridge connection completely undetectable and benign. Then the CANbus Triple can be programmed to capture the errant torque reduction command from the trans controller, reduce it to a less annoying level, then send the modified torque reduction command on to the engine. Such a change might yield a .1 or .2 second improvement in 0-60 MPH or 1/4 mile time.

The possibilities are endless...

Looks like your connection to CANBus Triple was lost, please wait while we try to reconnect.