Originally Posted By: DriveHard
Before this year, I was all for things like this. I even went out and bought my own tool just for monitoring my vehicle while I was driving. I used it quite a bit, and still use it to pull codes, and check on general vehicle health. I used to have it plugged in ALL the time in my truck. Here is what I had.
http://www.scangauge.com/
Now…I no longer drive with it plugged in unless I am actively trying to solve a problem. I was at a week long training course at the SAE headquarters in Detroit. I was asking some questions about vehicle networks and communication, and earned myself the opportunity to meet a very high up engineer at a foreign car company. He was specifically at the SAE headquarters to meet with the heads of several insurance companies in regards to the “passive” scanning devices that you plug into your OBDII port to get a discount. The short story is…anything plugged into that port disrupts vehicle communication. The OBDII port is just an interface into the vehicle network (it’s a node on the internal vehicle bus) – think of it like a gateway. Well, different nodes on a bus have different priority. That makes sure that important messages like vehicle speed, throttle position, AIRBAGS going off, etc. has a HIGH priority, and their messages can actually kick messages of lesser important off the bus. Well, the OBDII node is the HIGHEST priority on the bus because it is supposed to be used for diagnostic purposes (ie. just in the lab or garage setting). When you plug anything into the OBDII port, that device just became more important that the computer that controls vehicle stability, your airbags, your ABS, etc. ***** was meeting with the heads of these insurance companies to urge them to NOT offer those devices to the public because it has the chance to make their cars LESS safe and cause performance issues. In talking with him, the summary was “don’t leave things plugged into your OBDII port, or you risk messing up your car.”
So…now I no longer drive around with my scanner plugged in.
Bus congestion, as you implied, concerns me so I looked into the CAN protocol a bit. First of all the bus is physically just a 2-wire 120 ohm twisted pair. ISO 11898-2 is a linear bus terminated at each end. The transmitters only transmit on the bus when the bus is free. The questions I have are what is the bandwidth of the bus and how much bandwidth are we generating by poling the ECU with whatever scanner we're using?
Maybe this doesn't matter so much... From the Wikipedia en.wikipedia.org/wiki/CAN_bus#Architectureen.wikipedia.org/wiki/CAN_bus#Architecture
"The CAN specifications use the terms "dominant" bits and "recessive" bits where dominant is a logical 0 (actively driven to a voltage by the transmitter) and recessive is a logical 1 (passively returned to a voltage by a resistor). The idle state is represented by the recessive level (Logical 1). If one node transmits a dominant bit and another node transmits a recessive bit then there is a collision and the dominant bit "wins". This means there is no delay to the higher-priority message, and the node transmitting the lower priority message automatically attempts to re-transmit six bit clocks after the end of the dominant message. This makes CAN very suitable as a real time prioritized communications system."
Good information! So the new questions are, what number node is our scanner and what number node is the ECU? My skeptic wants to say that no way have the auto manufacturers allowed safety equipment to have a higher node number and therefore lower priority than other nodes, but maybe, as your wrote, that's exactly the problem and that our scanner may have a lower node number and potentially preempt other messages.
I'm having some trouble with your description of the OBDII port. "Well, the OBDII node is the HIGHEST priority on the bus because it is supposed to be used for diagnostic purposes (ie. just in the lab or garage setting)." The OBDII port for our purposes is just a physical access point to the CAN bus. It is the node number of the connected device which determines message priority and only if 2 nodes transmit at the same time does message priority come into play.
It seems to me we've come back to the bus bandwidth (1 Mbit/s) and bus loading questions. If something like Wireshark were available for CAN ISO 11898-2:2003 (and it probably does exist in someone's lab) it would be child's play to see the bus utilization and how that utilization changes with the use of a ScanGauge or UltraGauge.
So who's got the goods to do some tests? The UltraGauge people naturally don't seem concerned, but the poling rate is adjustable. I have an open ticket with them and will ask about the bandwidth of the UltraGauge.
