Gauge vs OBD-II - who to believe?

[khoney]

I recently purchased an OBD-II scanner (contains the ELM327 universal protocol converter), and am working on a custom interface to it. Today I noticed that my tach and speedo are off from the OBD-II reported values. The tach gauge is about 250RPM higher than the scanner at 4500RPM, and the speedo gauge is about 4MPH higher than the scanner at 70MPH. I have OEM tires and rims. So, which should I believe? I don't have a radar dector - so can I drive faster now? ;)

Also, are we unable to monitor O2 sensor data on the MS3? The scanner is always reporting that a full drive cycle is incomplete or the vehicle does not support O2 monitoring. This is even after I drive it 25 miles.

[meha11]

beleive the gauge, it was designed, built and installed by mazda, your scan gauge wasnt.

[numbnuts22715]

On my dashhawk I can read my air to fuel ratios and stuff like that, maybe yours just doesnt support it with the mazda?

[07speed3]

It sounds like what you have is more universal not like the dashhawk/scanguage that are vehicle specific for the MS3 so that may have something to do with why your readings are off and not working at all.

[khoney]

beleive the gauge, it was designed, built and installed by mazda, your scan gauge wasnt.

There's no question that the scanner is reporting what the ECU is seeing - that's the whole purpose of OBDII - it's a standard protocol, so the scan gauge has nothing to do with it. I guess the question I'm asking is whether the needle gauge is a more true representation of actual speed/RPM than the sensors that are reporting to the ECU.

[khoney]

It sounds like what you have is more universal not like the dashhawk/scanguage that are vehicle specific for the MS3 so that may have something to do with why your readings are off and not working at all.

"Universal" simply means it can handle different physical protocols, such as PWM, CAN, VPW, KWP2000. The data is the data, and is defined by OBD-II standard. The data is the same regardless of the protocol. "Vehicle-specific" scanners are able to read additional parameters beyond what is defined by the OBD-II standard, e.g. transmission, BCM, ABS, etc.

[Sierra117]

I can read AFR and Lambda on my Aeroforce, I currently have it set up to read AFR and Boost in PSI with the shift light set to go off above 6k rpm.

What differential are you seeing between the scangauge and your needle gauge? Because the scangauge reads directly from the ECU.

[Shaun]

Factory gauges are hardly ever exact. I would believe the scanner for actual data over the factory gauges.

[Ziggo]

I think it was 2 years ago that Yamaha was advertising that their new 600 had a redline of 17.5k, which is what the tach was showing, but if you actually measured it, it was only 16k. Forced them to issue a refund of the entire motorcycle to anyone who complained.

Lesson learned; measured (OBD) > indicated (needle gauge)


It goes for the speedo too.

[AutoXRacer]

My dashhawk and gauges are pretty up to par with themselves...

[sleeper3]

your gauges are analog, the scanner is digital.

the error is occuring when the signal is converted from 0s and 1s to making a needle point at something. it's the exact same signal going to the OBDII port and the gauges. it's just being interpreted more accurately by the scanner.

[08 SSM MS3]

Get a gps reading and compare all three.(laugh)

[sleeper3]

if you have navigation, that's easy too!

[matsuda]

There's no question that the scanner is reporting what the ECU is seeing - that's the whole purpose of OBDII - it's a standard protocol, so the scan gauge has nothing to do with it. I guess the question I'm asking is whether the needle gauge is a more true representation of actual speed/RPM than the sensors that are reporting to the ECU.

The gauges in the instrument cluster are essentially using the same data that you are reading from the diagnostic port because the instrument cluster is connected to the same CAN bus. If there is any discrepancy, it is the gauges that are wrong.

It is common for a speedometer to read high. For obvious reasons, speedometers never read low unless something is wrong.

[khoney]

Guess I can drive faster then :D

[tru-boost]

your stock gauges are off. it is very common. the scanner is the actual number. the scanner sees what the ECU sees it just displays the info. OBDII is a universal system and the scanners act like TV screens, thats all. they dont make up the numbers or do any conversions or anything like that. it displays what is going on. stock gauges are often off. my DH reads different from my tach and speedo too. the DH is correct. the DH reads directly from thee coils to measure RPM it cant be wrong. the stock set-up loses some accuracy along the way somewhere. it is a needle style gauge, there is a lot of points that can throw them off. i remember i put a shift light on my old mustang back in the day. i set it for 6k. my dash tach would read only 5700RPM when the light would flash. but it was the light that was correct.

[matsuda]

your stock gauges are off. it is very common. the scanner is the actual number. the scanner sees what the ECU sees it just displays the info. OBDII is a universal system and the scanners act like TV screens, thats all. they dont make up the numbers or do any conversions or anything like that.

If a scan tool is reading speed in MPH, a conversion from km/h to MPH is being done.

[tru-boost]

true but it still based off what the cars sensors are telling it. it isnt just making up numbers. the MPH/kilometer conversion is just a display option. the scanner isnt decoding signals from the cars sensors.

[sleeper3]

If a scan tool is reading speed in MPH, a conversion from km/h to MPH is being done.

an explicit conversion like this is far more accurate than a conversion of a digital signal to an analog display.

[Rotus8]

I can tell you that the OBDII RPM display is not perfect. If you do an acceleration run and log the RPM, then graph it, you can see that it has regular flat spots. I believe this is some kind of arithmetic artifact that allows round-off errors to effect the data. It drives the inertial "dyno" calculation of packages like Auterra Dyno-scan banannas.

[sleeper3]

I can tell you that the OBDII RPM display is not perfect. If you do an acceleration run and log the RPM, then graph it, you can see that it has regular flat spots. I believe this is some kind of arithmetic artifact that allows round-off errors to effect the data. It drives the inertial "dyno" calculation of packages like Auterra Dyno-scan banannas.

kind of weird that they occurred at regular time intervals... almost like that's how often it sampled the reading from the ecu?

[tru-boost]

I can tell you that the OBDII RPM display is not perfect. If you do an acceleration run and log the RPM, then graph it, you can see that it has regular flat spots. I believe this is some kind of arithmetic artifact that allows round-off errors to effect the data. It drives the inertial "dyno" calculation of packages like Auterra Dyno-scan banannas.

actually what causes that is the scan tool itself. it depends on the sample rate of the unit. if it can take lets say 10 samples per second, the tool basically places dots on the graph for each sample. it then goes back and plays connect the dots to make a graph. the flat spots are odd though, my DH doesnt leave flat spots like that.

[khoney]

Can anyone tell me if they are able to get OBDII data from both Bank1 Sensor1 and Bank1 Sensor2? According to my OBDII 'Oxygen Sensors Present' PID code, I have both sensors. However, I am only able to read data from Bank1 Sensor 2.

Note: My reference for OBDII data is http://en.wikipedia.org/wiki/OBD-II_PIDs

[khoney]

actually what causes that is the scan tool itself. it depends on the sample rate of the unit. if it can take lets say 10 samples per second, the tool basically places dots on the graph for each sample. it then goes back and plays connect the dots to make a graph. the flat spots are odd though, my DH doesnt leave flat spots like that.

Can you tell me the approximate updates/sec rate for the Dashhawk if you monitor six parameters simultaneously? How about 10? In messing around with the ELM327 chip, I think I'm being limited by its translation method and communications protocol. I think I'll be able to do better by using a CAN microcontroller and making my own protocol. I have some ideas, and I'm curious about the Dashhawk's performance for comparison. With only three parameters, the best I can do is about 7Hz with the ELM chip, and that's at a baud rate of 500K. The problem is that the ELM does not let you request multiple PIDS in one command, and then return all data in one response. All PIDS are requested sequentially. It's OK for a general-purpose scan tool, but less than optimal for a data logger.

[khoney]

Anyone? I know at least one person on this forum is awfully proud of his DashHawk ;)

How about some real numbers - I can't find any reference to update rates on the MSD web site.

[khoney]

After some fine-tuning, I'm getting 7 PIDs at 2Hz update rate, and 27 PIDs at ~.7Hz update rate, while graphing all of the parameters. However, since many of these parameters are rather slow to change, I'm thinking a priority-based system could significantly improve the throughput.

I guess the ELM327 isn't such a bad chip after all...