When you click on links to various merchants on this site and make a purchase, this can result in this site earning a commission. Affiliate programs and affiliations include, but are not limited to, the eBay Partner Network.
Just ran two days Thunderhill (with GGR PCA); first time out since installing a Cobb Access Port on my 2012 Cayman R. While my engine is currently stock, I plan to add headers soon and install the Cobb AP was the first step in that project. The Cobb AP has the added bonus of displaying a number of useful data point from the ECU such as oil temp, coolant temp, oil pressure, etc. The AIM Solo provides the similar functionality, but with a slightly less friendly interface.
While running at Thunderhill this weekend, I had both the AIM solo and Cobb AP reporting oil temp, coolant temp, and oil pressure. I was rather surprised to see a huge discrepancy in the data being reported by the two devices, with the Cobb AP reporting oil temps far below what the AIM reports. At one point, the AIM reported 235 on oil temp, the Cobb 207; oil pressure is also wildly different, 33 on the AIM and 10 on the Cobb while idling. Coolant temps were always within 1-2 degrees.
The AIM is wired directly to the CAN bus, the COBB uses the ODB2 port to access ECU data.
In short, CAN will be more accurate than OBD II because both the protocol and intended use of the architecture are different. Trust the CAN data.
In long, the structure of a CAN bus and CAN data is different from OBD II. On a CAN bus the messages / signals are always there, always being updated by whichever ECU creates that data. They transmit on a fixed, regular time step. You'll see a new updated value every 1 second, 0.1 second, 0.01 second, or even as fast as 0.001 second. This is because the actual CAN bus is how the various ECU's communicate with each other. The engine controller might send out an ambient temperature signal because the brake controller needs to know if it's cold and the temp impacts fluid viscosity and how they need to run the ABS pump for effective pressure and brake events. The steering system needs to send out the steering wheel angle so the brake controller knows what the driver is doing and can calculate a theoretical yaw rate to compare to a measured yaw rate and know when to intervene with ESC. In my line of work I need to know how much torque the engine is generating so we can actuate the AWD coupling and transfer torque to a secondary drive axle.
OBD II is a diagnostic interface which operates on a request / answer protocol. There is zero data being transmitted until it is requested. You can't get data any faster than the Cobb AP is asking for it, and even then you can only get it as fast as the gateway module is able to package it and supply it. The more you ask for at any one time the longer it takes to receive it. Asking for one piece of data every 0.1 seconds is better than asking for 20 pieces of data every 0.01 seconds. This is still not necessarily live data. You are asking for the ECU to send you a value stored in a memory location (DID's and PID's). OBD II has no control over how often that value gets updated by whichever ECU supplies it. You might ask for it 10 times per second, but the value in memory might get updated once per minute by the actual ECU generating the value. The only way around this would be a DPID, but those take up more bandwidth and only certain things are pre-defined as available through a DPID. Most frequently you'll see wheel speeds available on a DPID to help a service technician diagnose issues with wheel speed sensors.
In short, CAN will be more accurate than OBD II because both the protocol and intended use of the architecture are different. Trust the CAN data.
In long, the structure of a CAN bus and CAN data is different from OBD II. On a CAN bus the messages / signals are always there, always being updated by whichever ECU creates that data. They transmit on a fixed, regular time step. You'll see a new updated value every 1 second, 0.1 second, 0.01 second, or even as fast as 0.001 second. This is because the actual CAN bus is how the various ECU's communicate with each other. The engine controller might send out an ambient temperature signal because the brake controller needs to know if it's cold and the temp impacts fluid viscosity and how they need to run the ABS pump for effective pressure and brake events. The steering system needs to send out the steering wheel angle so the brake controller knows what the driver is doing and can calculate a theoretical yaw rate to compare to a measured yaw rate and know when to intervene with ESC. In my line of work I need to know how much torque the engine is generating so we can actuate the AWD coupling and transfer torque to a secondary drive axle.
OBD II is a diagnostic interface which operates on a request / answer protocol. There is zero data being transmitted until it is requested. You can't get data any faster than the Cobb AP is asking for it, and even then you can only get it as fast as the gateway module is able to package it and supply it. The more you ask for at any one time the longer it takes to receive it. Asking for one piece of data every 0.1 seconds is better than asking for 20 pieces of data every 0.01 seconds. This is still not necessarily live data. You are asking for the ECU to send you a value stored in a memory location (DID's and PID's). OBD II has no control over how often that value gets updated by whichever ECU supplies it. You might ask for it 10 times per second, but the value in memory might get updated once per minute by the actual ECU generating the value. The only way around this would be a DPID, but those take up more bandwidth and only certain things are pre-defined as available through a DPID. Most frequently you'll see wheel speeds available on a DPID to help a service technician diagnose issues with wheel speed sensors.
Thanks for the wealth of information and thorough explanation, Scooby -- very helpful. Disappointed to hear that I can not use the Cobb to accurately display oil temp/pressure.
The labels OBD II and CAN can get a bit confusing too. I had to email AiM tech support to fully understand the difference between their own CAN vs. OBD II cables and options for the data loggers. What Porsche does with a gateway module and very specific and limited data at the OBD II port is different from a lot of other manufacturers. In the OEM programs I've worked on for Ford, FCA, GM, and Land Rover in the last few years they wire the CAN bus straight into the OBD II port. You don't need a special cable / harness to tap into the CAN network like you do with a Porsche. Thus I was confused as to why they offered different cables and why one version provided better data than the other. Porsche's gateway module is a bit of a middle-man data bank where everyone else lets the OBD II protocol talk directly to specific modules and get the data directly from the source. While still at the mercy of the request / answer protocol data transfer rates you do seem to get more up-to-date data with that structure.
Unfortunately we're fast approaching the "enjoy it while you have it" phase of automobiles. As OEM's want to do more with the cars and add more ECU's and software they need faster communication networks. When they do this the protocol changes and it will become harder for the aftermarket to find that data. We are also rapidly growing in "connected" features in the cars which open up the potential for hacking and attacks. Cyber Security is now a huge item in the auto industry and OEM's are locking down both the ECU's and the communication networks. I know of one OEM who is now using one data message to carry the actual data and a second data message with a key to unlock and decode the first one. You can't just monitor the data and reverse engineer it. You have to find two separate messages and learn the relationship. It's a lot harder than it sounds when we're talking about matching up a pair of messages out of the near thousand flying around the network. This OEM also uses two separate networks and might toss the second "unlock" message onto the second network making for a million possible combinations to test and decode.
The labels OBD II and CAN can get a bit confusing too. I had to email AiM tech support to fully understand the difference between their own CAN vs. OBD II cables and options for the data loggers. What Porsche does with a gateway module and very specific and limited data at the OBD II port is different from a lot of other manufacturers. In the OEM programs I've worked on for Ford, FCA, GM, and Land Rover in the last few years they wire the CAN bus straight into the OBD II port. You don't need a special cable / harness to tap into the CAN network like you do with a Porsche. Thus I was confused as to why they offered different cables and why one version provided better data than the other. Porsche's gateway module is a bit of a middle-man data bank where everyone else lets the OBD II protocol talk directly to specific modules and get the data directly from the source. While still at the mercy of the request / answer protocol data transfer rates you do seem to get more up-to-date data with that structure.
Unfortunately we're fast approaching the "enjoy it while you have it" phase of automobiles. As OEM's want to do more with the cars and add more ECU's and software they need faster communication networks. When they do this the protocol changes and it will become harder for the aftermarket to find that data. We are also rapidly growing in "connected" features in the cars which open up the potential for hacking and attacks. Cyber Security is now a huge item in the auto industry and OEM's are locking down both the ECU's and the communication networks. I know of one OEM who is now using one data message to carry the actual data and a second data message with a key to unlock and decode the first one. You can't just monitor the data and reverse engineer it. You have to find two separate messages and learn the relationship. It's a lot harder than it sounds when we're talking about matching up a pair of messages out of the near thousand flying around the network. This OEM also uses two separate networks and might toss the second "unlock" message onto the second network making for a million possible combinations to test and decode.
When I first got my AIM Solo, I had the ODB cable and was not able to see oil temp at all. I got the cable swapped for the direct wired CAN option and there was all the data I was looking for. Banks makes a series of gauges that can work with ODB2 or CAN for certain ECUs. I am going to give them a call and see about getting one for direct CAN connection. https://www.bankspower.com/series-2-...per-gauge.html
WRT the march of technology in cars: I am actually quite happy to have a 987.2 which is a bit less 'techy' than new Porsches.
9 Vehicles Porsche Helped Engineer that Aren't Porsches
Slideshow: Long before engineering consulting became trendy, Porsche was quietly helping other automakers build everything from supercars to economy hatchbacks.
9 Features and Characteristics That Only Porsche People Understand
Slideshow: Some brands build cars. Porsche builds traditions, obsessions, and a few habits that stopped making sense decades ago but somehow became part of the charm.
This Builder Is Turning Heads With Its Slantnose 911 Creation
Slideshow: A small Polish tuner has reimagined the Porsche 911 Slantnose for the modern era, blending 1980s nostalgia with widebody tuning culture and serious performance upgrades.
Porsche 911 GT3 Artisan Edition Pays Homage to Japanese Culture
Slideshow: Porsche has created a Japan-only 911 GT3 Artisan Edition that blends track-ready hardware with design cues inspired by traditional Japanese craftsmanship.
Porsche Reveals Coupe Variant of the Electric Cayenne With a Fresh Look
Slideshow: Porsche's latest electric Cayenne Coupe blends dramatic styling with supercar acceleration, turning the brand's midsize SUV into a 1,139-horsepower flagship.
Data discrepancy: AIM Solo vs. Cobb AP
