I'm writing a software to make a telemetry application for my 2001 VW Golf mk4 reading parameters from OBD2 using an ELM327 compatible cable.

I succeeded so far. The problem that I have now, is that the software is too slow (3 - 4 values per seconds). Some of the problems might be in my software, some may be limitation of the OBD2 protocol in my car, but let's presume that it's all from my software and I'm going to improve it to the point I'll be able to read as fast as possible.

I read in the documentation for the cable that is forbidden, for a car using OBD2 standars prior of 2002, to read values faster than 100 milliseconds appart. It sais that problems may occur, but they don't go into details.

My question is: does anybody have any idea what sorts of problem may occure by reading information to fast from the OBD2, and if those problems, if occurring, may be fixed by just removing & re-connecting the battery terminals to the car ?


ELM documentation indicates that this is not a query-only problem. I see on page 31 of that document that the issue was that of the rate at which J1850 requests arrive at the OBD system (this is a consequence of the April 2002 update of the J1979 standard). Specifically, they warn you against querying at rates higher than 100 milliseconds (also known as 10 per second) but don't provide any specifics.

It's important to understand that you aren't just passively reading data. There's a query-response asynchronous loop going on. As near as I can tell, too many queries too fast could overflow the outgoing message queue on the OBD system. Since that situation sounds an awful lot like a buffer overflow problem, it's not impossible that you could do fatal damage to your OBD system, if not your entire engine computer.

That's me being skittish: it's your vehicle, of course.

Now, that all said: it looks like OBD monitoring tools are freely available for Ubuntu. The manual page for obdgpslogger shows two options of interest:

   -a|--samplerate <samples-per-second>
          Sample at most this many times a second. The software will sleep
          temporarily at the end of each loop if appropriate. Keep in mind
          there is an upper limit to samplerate, typically capped  by  I/O
          on  your  serial  port.  Set  this  to zero to sample as fast as
          possible.  BE WARNED. Values greater than ten here are forbidden
          for  cars  predating April 2002. If you think your car postdates
          early 2002, and you'd like to sample as fast as possible, the -o
          option may help

          Enable  certain  elm327  optimisations. This will [usually] make
          sampling faster [not a noticeable amount if you're only sampling
          once a second], but makes it much easier to accidentally disobey
          the standard if you're sampling as fast as possible.

From that page, it seems that the best actual rate that you're likely to achieve will result from:

obdgpslogger --samplerate 10 --enable-optimisations
| improve this answer | |
  • I got the same from the documentation as you are, but I'm surprised that in the auto standards there would be such sloppy problems, like buffer overflow. Usually they have very tight testing regimes. Anyway; I've tested on my car and apparently it doesn't let me poll faster, even if I want to. Thank you very much for your input! – Nicu Surdu Jun 26 '13 at 19:55
  • "but don't provide any specifics." That pissed me of and that is what I am looking for: specifics :( – Nicu Surdu Jun 26 '13 at 19:59
  • 1
    @NicolaeSurdu, in fairness, it appears that the behavior is undefined for cars prior to April 2002. It's not clear that a 3rd party could give you useful information about all vehicles since they don't have it. Regardless, you can still produce useful monitoring systems from limited data: e.g., Kalman Filter for an adaptive interpolation / extrapolation filter: cs.unc.edu/~welch/kalman – Bob Cross Jun 27 '13 at 12:44

You will note that most OBD software tools rarely display more than 4 or five outputs per view. I've also run into problems when trying to read too many values at once.

Speaking from experience, I would suggest working out a strategy for polling different values. For instance you really only need to poll

  1. Vehicle's speed every 2 seconds.
  2. RPM every 1 seconds.
  3. Fuel level every 30 seconds.
  4. Battery Voltage every 5 seconds.
  5. Intake manifold pressure, aka Boost Pressure every 1 second.
  6. Coolant temperature every 10 seconds.
  7. Engine load every 1-2 seconds.

The trick is to poll things that change more often, more often.

Next time you're in a car with an on-board computer, switch to instant consumption view and see how often the value changes. For my car, it's every second. I would say that one second is a great baseline because it actually allows you to read 9 PID's at 100ms each second without hassle.

| improve this answer | |
  • "The trick is to poll things that change more often, more often" Now that's again something obscenely obvious that I didn't consider. Thanks for the input, much appreciated! – Nicu Surdu Jun 26 '13 at 19:49
  • Experience is the greatest teacher ;) – Captain Kenpachi Jun 27 '13 at 7:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.