Gauge vs OBD-II - who to believe?

[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]

MS3 O2 sensor data

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]

Decent update rates (IMO)

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...