More Info – OBD II
Technical Tip #1
When an external application connect to the OBD2 port of a car, it requires “attention” from the ECU (Engine Control Unit) of the car.
For each “dialogue”, it is like calling the ECU to get temperature of the coolant, it must get the ECU’s attention as well as Bandwidth in the communication channels used between the application and the ECU.
This means, bandwidth of the ECU to the OBD2 port of the car, then for the little adapter, that talks to the OBD2 port (protocols) and then to a small processor in the adapters converts that language into the Bluetooth channel, that is read from the smartphone, and then end to the application that monitor, displays and store such information.
It is good to keep in mind that for each specific piece of information (like Coolant temperature, RPM of the engine, odometer reading, speed of the car, efficiency of the catalytic converter, and etc..) the transfer of this information takes time and uses the path from the ECU to the application.
In the OBD2 “language”, each of the typical available pieces of information offered by sensors and devices located in a modern car, are called “Pids” (Parameter IDentificationS).
Note that the available Pids can be different for each brand, model and year, i.e.: not all cars offer the same information. It can even vary within a model year. Some vehicle brands, that make use of “reserved” channels (i.e.. in the OBD2 connectors) that provide proprietary information, like Pids that are “encoded” and can be read only by the brand “official testers”.
In our application, we have decided to display some basic Pids, (RPM and Speed) in what we call our “Screen 1”, then in our “Screen 2” we have again the 2 basic information, and the time plus a customizable list of Pids that any user can select based on the Pids available from their car, brand-model-year. This customized page can be edited anytime, and at the end of a session, the choice of the user is stored, so, when the same user comes back for another session, with the same car (i.e.: VIN is also stored) the previous list of customized Pids is shown. The same thing happen in our “Screen 3” where no Pids are selected by default. In our Screen 3, the user will see only the Pids that they have selected.
This been said, it will then be easy to understand that the number of Pids selected is going to have an effect in the entire chain of data transfer, from the ECU of the car, into the App that displays the information. Or : selecting Pids has a “price” ! (for example in Blutooth data transfer, in the smart phone with the data crunching (time of response, battery consumption and etc..).
While at ChkOBD, our team of veteran software engineers have used some sophisticated technology to provide applications that are the most user friendly as possible, we also realize “for an app, anything that is not instant, is not good !”
This is easy to say, ..but many times, dealing with a complex matter, it is extremely difficult to realize.
In the case of our app, to minimize the amount of information that has to be transferred and “crunched” through, for each Pids that we select and use, we have analyzed its frequency of change (some Pids are “dynamic” and some other are “static”). To easily explain this characteristic, think about the RPM : to display it correctly, you want this information to be “instant”, or being prioritized over other Pids like the coolant temperature, ..that can also change, but in a slower way than the RPM. OR, the odometer, that can change is an even slower mode, with less strategic importance than the coolant temperature, and this specifically, ..if the speed is low, ..or if the car is currently stopped !
We hope this explanation helps your understanding that even if we have integrated in the technology of our app a kind of “smart” timing to read and display every Pids with an optimized frequency, we would recommend selecting Pids carefully in screens 2 and 3 to optimize responsiveness in the app.
For sure, we would like to thank you using our app.