Page 1 of 2 12 LastLast
Results 1 to 10 of 16

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

  1. #1
    Low Bitrate
    Join Date
    Jul 2006
    Posts
    67

    What limits the refresh rate for OBD-II readers ?

    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 ?

  2. #2
    Variable Bitrate
    Join Date
    Jul 2005
    Location
    Rosemount, MN
    Posts
    228
    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.

  3. #3
    Low Bitrate
    Join Date
    Jul 2006
    Posts
    67
    Quote Originally Posted by digimotojoel View Post
    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 ?

  4. #4
    Variable Bitrate
    Join Date
    Jul 2005
    Location
    Rosemount, MN
    Posts
    228
    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.

  5. #5
    VENDOR - OBDPros
    Join Date
    Mar 2006
    Posts
    359
    Quote Originally Posted by It's A Honda View Post
    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

  6. #6
    Low Bitrate
    Join Date
    Jul 2006
    Posts
    67
    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.

  7. #7
    Low Bitrate
    Join Date
    Jul 2006
    Posts
    67
    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 ?

  8. #8
    VENDOR - OBDPros
    Join Date
    Mar 2006
    Posts
    359
    Quote Originally Posted by It's A Honda View Post
    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.

  9. #9
    Low Bitrate
    Join Date
    Jul 2006
    Posts
    67
    Quote Originally Posted by michbound View Post
    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...

  10. #10
    Variable Bitrate
    Join Date
    Jul 2005
    Location
    Rosemount, MN
    Posts
    228
    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.

Page 1 of 2 12 LastLast

Similar Threads

  1. Need software to increase refresh rate!
    By Swifty in forum Software & Software Development
    Replies: 2
    Last Post: 08-13-2006, 03:42 PM
  2. Change Refresh Rate to 75hz
    By Cheekz185 in forum LCD/Display
    Replies: 3
    Last Post: 06-21-2005, 02:23 AM
  3. Replies: 1
    Last Post: 06-18-2004, 06:49 AM
  4. Best GPS refresh rate?
    By FiSKARZ in forum GPS
    Replies: 16
    Last Post: 05-26-2004, 06:16 PM
  5. refresh rate and screen position
    By blkdragon6 in forum Software & Software Development
    Replies: 2
    Last Post: 11-16-2000, 05:27 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •