-
-
Notifications
You must be signed in to change notification settings - Fork 312
Data item update time
Per default AndrOBD cyclically requests all data items, which are supported by your vehicle. The overall data update cycle time is directly dependent on the number of data items to be read.
This list of requested items to be updated can be limited by selecting (a set of) individual data items and display in a filtered list-, gauge-, head up-, dashboard- or graph display.
AndrOBD attempts to read the signals at the highest possible rate considering the communication delay factors below. It does not use any additional delays or fixed update rates.
These communication delay factors are:
- ELM adapter response time / timeout
- There is quite a big variance in response time between different ELM adapters / clones.
- Communication supported by vehicle
- Method (CAN / K-Line)
- Protocol (ISO / KWP / J1939)
- Baud rate (10.4 - 500 kBaud)
- Protocol response time of the vehicle
The adaptive timing function tries to optimize the adapter response time on protocol requests. Details of the ELM internal functionality are described in ELM327 manual.
Options for this function can be selected in AndrOBD settings.
Following options are available for selection:
- OFF - NO adaptive timing used
- ELM_AT1 - ELM adapter method 1 (adapter default setting)
- ELM_AT2 - ELM adapter method 2 (more aggressive optimization)
- SOFTWARE - AndrOBD software method
- Minimum timeout limit [ms]
Since some older ELM models do not support the adapter methods, the AndrOBD software method provides a software adaption of the ELM read timeout to the smallest possible value during communication. So communication starts rather slow and speeds up as long as the car reports valid data. The algorithm learns the fastest possible response rate when it starts to receive NODATA responses.
Depending on the combination of your adapter, vehicle and OBD protocol it might be worth to play with these settings to receive best data response times.
AndrOBD used to request all selected PID's cyclically in a "round robin" style.
Since V2.6.0 AndrOBD allows to prioritize PID's within selected data items.
This mechanism supports an update of some data items less frequent than others, because it is very unlikely for it to change rapidly. A good example for this is the engine coolant temperature: In order to check the warmup of an engine it is enough to check the coolant temperature approx. every 15 seconds.
OBD even provides some data which does not change at all during a drive cycle like for example "Available O2 sensors" or "OBD conformity". If these data items are requested once there is no need to refresh these for this running test cycle.
The feature of PID prioritization does hold back requests of lower priority to allow more frequent requests of higher prioritized PID's
In detail, AndrOBD allows to set a desired data refresh time for each data item. Many of these data items are already pre-set with some (hopefully sensible) values, but can be customized individually using the dialog Data item customization.
The algorithm for this priorisation is very simple:
- Every PID has an attached timestamp of next desired request
- Timestamp is initially zero to ensure data is requested at least once
- On data reception of a PID it's timestamp of next desired request is set to
<current time> + MAX(<desired data refresh time>)
- Whenever AndrOBD can request new OBD data, it will
- The next PID to be requested is the first item of a sorted list of selected PIDs
- The list is sorted by timestamp value for next desired request
- The next PID to be requested is the first item of a sorted list of selected PIDs
In consequence this means
- AndrOBD does prioritize PID's by their desired time of next request
- AndrOBD can NOT guarantee a fixed update time on the configured value
- The update may occur faster than desired update time
- If no more PID's of higher priority are selected
- The update time may occur slower than desired update time
- If more PID's are selected than the OBD protocol can process in desired timeframe
- The update may occur faster than desired update time