Announcement

Collapse
No announcement yet.

Spec question from the bowels of OBDII

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Spec question from the bowels of OBDII

    Say I have two ECUs, ECU#1 and ECU#2.

    ECU#1's address is lower than ECU#2's
    ECU#2 always takes 5ms to respond to a query, ECU#1 always takes 20ms.

    If I were to call 0100 [assuming the delay is the same no matter the PID being queried, which is presumably not accurate but a good enough approximation], would I see:
    A) ECU#2 respond after 5ms, and then ECU#1 respond 15ms later
    B) ECU#1 responds after 20ms, and is immediately followed by the responds from ECU#2
    C) Something else
    D) Protocol-dependant

    [I'm guessing the answer is (A)]


    If I then set the timeout using ATST to be 15ms. Do I see:
    A) ECU#2 responds at 5ms [correlates with option (A) above]
    B) ECU#2 responds at 15ms [correlates with option (B) above]
    C) Something else
    D) Protocol-dependant

    [I'm guessing (A)]

    Do I then see any data from ECU#1 the next time I do a query? Does the delayed-past-the-timeout response get buffered up, or does the scantool drop the response?

    Gary (-;
    OBDGPSLogger, for logging OBDII and/or GPS data
    OBDSim, an OBDII/ELM327 software simulator
    mp3car forums: obdgpslogger, obdsim

  • #2
    And since I'm on the topic, what happens in modes other than 1? Does an ecu take a similar amount of time to process a request in mode 2, 3 or 4 as it does in mode1?

    Gary (-;
    OBDGPSLogger, for logging OBDII and/or GPS data
    OBDSim, an OBDII/ELM327 software simulator
    mp3car forums: obdgpslogger, obdsim

    Comment


    • #3
      In semi-related news, I went ahead and implemented my best guesses on this, (A) and (A). OBDSim now supports a varialbe timeout for each ecu.

      Gary (-;
      OBDGPSLogger, for logging OBDII and/or GPS data
      OBDSim, an OBDII/ELM327 software simulator
      mp3car forums: obdgpslogger, obdsim

      Comment


      • #4
        Originally posted by chunkyks View Post
        Do I then see any data from ECU#1 the next time I do a query? Does the delayed-past-the-timeout response get buffered up, or does the scantool drop the response?
        That depends entirely on the tool, so if you're using an elm chip you need to know how it is implemented. J1979 tells you to issue requests like this:
        • Wait for a certain amount of time (P2, 100ms in most cases) for a response
        • Restart that timer each time an ECU responds and wait another P2 until all ECUs have responded.
        • If you see certain frame that indicates an ECU will take a while, reload the timer with a large value (P2*, 5000ms in most cases) and wait for the response
        So sure you have some observations that your vehicle always takes X ms, but anything different than above may be outside the bounds of any OBD2 specification. My short answer is that if the scantool issues things too quickly, without waiting for the specified timings, bad things may happen to the network or to the ECUs.

        Comment


        • #5
          That makes sense. I think I'm satisfied with my implementation; delays vary and the ECUs can reply out of order. Any ECU taking longer than ATST gets dropped

          Saliently, that's the hardest possible case for an OBDII software developer to code for; if you support that, you support all the simpler cases.

          Gary (-;
          OBDGPSLogger, for logging OBDII and/or GPS data
          OBDSim, an OBDII/ELM327 software simulator
          mp3car forums: obdgpslogger, obdsim

          Comment

          Working...
          X