Thread: What limits the refresh rate for OBD-II readers ?

Originally Posted by digimotojoel

Off the top of my head I know that our 5.0 software (with a mOByDic) queries a non CAN based vehicle at about 18 times a second.

that would be for one sensor, right ? i.e. I could query for example just one oxygen sensor at about 18 times per second ?

Originally Posted by It's A Honda

What does the refresh rate from a typical obd-ii reader depend upon ? Is the protocol ? Or the interface ? the software ? the ecu/pcm ? or what ?

I read somewhere that OBD-II mandates a minimum bus idle of 300ms - that's a refresh rate of about 3.3 Hz. If that’s true then its really not possible to make a scanner read faster than that.
But I have also heard claims to the effect of 35Hz! Are these proprietary interfaces that implement it completely differently ?

What are some of the "faster" types available currently ?

The answer really is all of the above.

(Hopefully I do not screw up the math, at least as far as order of magnitude is concerned I think this should be correct)

1. The OBD II protocol itself plays a large part. For example the ISO protocol used by most imports before 2006 has a throughput of 10400 BPS. Now lets just take coolant temp for example. That message has a total of 3 header bytes + 3 data bytes + 1 checksum so that is 70 bits (start stop bit overhead of 2 bits/byte). Now to get the sensor reading you need to send the ECU a command that is 3 header bytes + 2 data bytes (PID + mode) + checksum = 60 bits. So the round trip bit count is 130 bits, so in theory if you were to send back to back commands you can get roughly 80 readings in a second. (we still have not factored in the time needed for the message to make it back from the interface to your PC at whatever speed you are talking to the interface) - This is one thing that the OBDPro does better than some of the other interfaces as it allows you to talk at speeds upto 128K back to the pC

Obviously you cannot do the 80 readings since once you send the command you also need to wait for the vehicle to response. Typically the software programs specify a 100 ms timeout value per command, that is after sending a command they allow the interface to wait for 100ms before deciding that there is no additional data from the vehicle. In this scenario with a timeout of 100ms you can only get 10 readings from the sensor.

Now you could manually adjust the timeout parameter and you will get more readings. The OBDPro has a command ATST that let's you set the timeout parameter, but if you make it too small you are liable to get NO DATA since the vehicle did not respond within the timeout value, so this is a compromise.

As you can see we just looked at one potential parameter that affects timing, another issue is the speed at which the interface talks back to the PC, if the speed is set to 9600 BPS you can see that the ideal 80 readings cannot happen since we did not factor in time for the

I guess this is a long winded way of saying that there are multiple factors that affect the reading speed and in some cases such as coolant temp even if you could read faster than 80 readings per second your actual sensor probably does not have tha dynamic range so it's really useless to even ask for more speed in the case of coolant temp. (I know that's not what you were looking at higher rates for, but just wanted to raise that as a point of consideration)

Paul
www.obdpros.com

It does not matter if you are querying a single sensor or 100, you'll get 18 queries a second.....if you are querying 100, each sensor will update once every 5 seconds or so.

I understand the ‘number of queries per second’ will remain the same, but somehow I was of the impression that the ratio was proportional with multiple sensors i.e. if one sensor updates 18 times per second, then two sensors will update 9 times per second each, three sensors will update 6 times per second each and so on...

seems like the interface<->PC and Timeout values are tweakable or atleast under the control of the user.

Using Werner-Digital’s wOBD v1.51beta that has an adjustable sample rate - which I believe is nothing but the timeout - I have been able to get somewhere between 6 to 7hz rate using a timeout of 32ms(which is the lowest allowed value that can be set in that software). With two sensors I can still get about 5hz. (they call it events/sec).

I hear ya about the dynamic range of a "slow" sensor like coolant temp but something as fast as a O2 sensor (even faster wideband sensors) could certainly use some bandwidth.

Paul, while I have your attention I will ask you a question quickly –

the ISO protocol used by most imports before 2006 has a throughput of 10400 BPS

so for ISO (10.4k) does it make sense to set the baud rate of the com port (using ATSCS/ATWCS) to anything higher than 14.4k (next step up from 9.6k) ? would there be any advantage ?

Originally Posted by It's A Honda

so for ISO (10.4k) does it make sense to set the baud rate of the com port (using ATSCS/ATWCS) to anything higher than 14.4k (next step up from 9.6k) ? would there be any advantage ?

Setting the com port to a higher speed will help since that means commands from the software to the interface and back would be faster, leading to an increase in the refresh rate, but a lot of existing software only supports 9600 and 38400 BPS, so it's better to set the speed to 38400.

Originally Posted by michbound

In this scenario with a timeout of 100ms you can only get 10 readings from the sensor.

Assuming the serial port is set at 38400, it sounds like the greatest limiting factor then is the timeout.
After playing around a bit with the timeout values I found that the '01 MDX ecu responds perfectly down to 32ms and the '99 Accord likes to be at 40ms but works most of the time at 32ms as well. So theoretically you should be able to get a sample rate of about 20-25Hz including the round trip and timeout. Does that mean the interface is the bottleneck ? Unless I am missing something...