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 ?

MP3Car.com

 

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. I can't give you the CAN numbers off the top of my head, but it is much much faster.

The protocol does make a difference, the software makes a difference and the interface makes a difference.

We have tested against an ELM device, an ELM bluetooth device, various mOByDic devices and the BR-3 device, this question you posted has been needing a good answer for a long time. I promise to spend some time documenting some test results against various hardware/protocols and softwares available.

I have never tested the Mongoose, but I'd like to know the hardware limitations accross protocols for that as well.

__________________
Joel Konecny
Digimoto OBDII Diagnostics

It's A Honda

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

digimotojoel

It does not matter if you are querying a single sensor or 100, you'll get 18 queries a second. If you are querying 1 sensor the software will update the value of that sensor 18 times a second, if you are querying 100, each sensor will update once every 5 seconds or so.

__________________
Joel Konecny
Digimoto OBDII Diagnostics

michbound

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's A Honda

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.

It's A Honda

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


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 ?

michbound

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.

MP3Car.com

 

It's A Honda

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

digimotojoel

With an ELM interface you can make a request and not even get a response for 200ms. The software needs to wait for the response/translate it before it can send another request. This was my point in the other thread ~ it doesn't matter if you are running at 9600, 38k, whatever... the ELM interface is the bottleneck here. I am not going to repost everything, but I ran some tests the other night and saw Digimoto running against an ELM pulling 5 times a second, with the mOByDic based interface it was pulling at 18 times a second. On a side note the mOByDic interface does not pull any faster when using USB 2.0... the interfaces are the bottlenecks here. From what I have read I believe the Mongoose can pull at 30 times a second (not limited by the interface itself, but the vehicle) depending on the vehicle, but I am just throwing that out there, I haven't actually used it.

__________________
Joel Konecny
Digimoto OBDII Diagnostics

It's A Honda

are you referring to this post ?

wow. is ASCII conversion really that slow ?!
y'know, in the last few days after I received the OBDPro and started getting involved, I have many times wondered - what is really the need for an 'interface' (or rather a 'middle layer') like ELM ? Why not communicate straight from the serial port to the obd port ? If at all any 'interface' is needed for difference in line levels(voltage) it can be scaled up or down, that should be all there needs to be in an interface, no processing. A covered dip switch can serve as a protocol selector if automatic detection is not feasible or to keep things simple. I know I am oversimplifying it but thats how I feel it should be.

Having said that, looking forward to the "BINARY" version of OBDPro soon !!

digimotojoel

I was referring to this post: http://www.mp3car.com/vbulletin/show...2&postcount=18

When it comes down to it an interface is needed simply to keep you from frying your computer. Outside of that each interface is developed differently in how they allow the other end to communicate. ELM was an awesome product years ago when this technology was brand new, when no one understand how to use it and there were no software developers out there writing applications against it. It just hasn't kept up with evolving technologies and has slipped behind in design.

edit: On a side note god_of_cpu stated that StreetDeck pulls around 2.5 times a second against the ELM interface. You can read the post here

__________________
Joel Konecny
Digimoto OBDII Diagnostics

It's A Honda

yes I saw that post too in the same thread.
best I have been able to get from OBDPro using wOBD was ~6.5Hz using a timeout of 32ms.
that was at 38.4k. I did not play around much with it at 9.6k so dont have a comparison but I can check for you.

digimotojoel

I have been meaning to purchase one of these units for some time, so I'll probably snag one and see what it can do myself, but if you do get to run some tests anytime soon, please do post results.

__________________
Joel Konecny
Digimoto OBDII Diagnostics

michbound

Well,

If you were able to get a response at 32 ms then there is'nt a whole lot of overhead beyond that from the interface, try running a simple script and timing the responses, any software in the mix might have overheads that are unknowns so the best option is to go raw to the interface and time it, that will give you your raw response time

Paul

MP3Car.com