01-17-2022, 10:33 PM
The slow PID refresh rate of OpenAuto has been previously discussed by myself and others on this forum, and after digging into the ELM327 datasheet, I appear to have found the potential reason as to why we notice such a stark performance difference between OpenAuto, and other apps like Car Scanner or Torque.
It appears to be, down to CAN based protocols support "Multiple PID Requests", whereby up to 6 params can be aggregated and sent/received with a single message. This is described on page 45 of the ELM327 DataSheet (https://www.elmelectronics.com/wp-conten...M327DS.pdf)
I am asking, if this (frankly game changing) feature can be implemented, either alongside the current receive/send requests, or at least allow us to make these more complex requests, and access the individual responses in an array like manner from the obd_gauges config. The previous reasons discussed by the support team were due to apps using interpolation etc, but I believe the reason such a difference exists is in fact because of them implementing this standard response/message.
I believe that this, alongside potentially AT2 (as opposed to the less aggressive, default AT1 variable timing command) may be the reason so many of us experience such poor PID refresh rates, and would completely change how useful the dashboard section can be.
These CAN protocols (ISO 15765-4) are found in most modern vehicles, and fully support the SAE J1979 standard which is what allows the implementation of multiple PID requests within a single message.
I hope this can be seriously discussed and considered.
Pedro
It appears to be, down to CAN based protocols support "Multiple PID Requests", whereby up to 6 params can be aggregated and sent/received with a single message. This is described on page 45 of the ELM327 DataSheet (https://www.elmelectronics.com/wp-conten...M327DS.pdf)
I am asking, if this (frankly game changing) feature can be implemented, either alongside the current receive/send requests, or at least allow us to make these more complex requests, and access the individual responses in an array like manner from the obd_gauges config. The previous reasons discussed by the support team were due to apps using interpolation etc, but I believe the reason such a difference exists is in fact because of them implementing this standard response/message.
I believe that this, alongside potentially AT2 (as opposed to the less aggressive, default AT1 variable timing command) may be the reason so many of us experience such poor PID refresh rates, and would completely change how useful the dashboard section can be.
These CAN protocols (ISO 15765-4) are found in most modern vehicles, and fully support the SAE J1979 standard which is what allows the implementation of multiple PID requests within a single message.
I hope this can be seriously discussed and considered.
Pedro