What is adaptation and how is it used? Received OBDEleven for Christmas and I’m still learning how to use it.
To add to my colleague's response, I'm going to attempt an amateur and unofficial response to your most excellent and very fundamental question above - and I will add a short description of how adaptation channels differ from the other major coding category that OBD11 uses - long-code.
However, my attempt to describe these basic coding principles is different to the approach in
whataboutthis link - my respnse has more of an engineering design bent. Don't get me wrong - I'm not suggesting that my engineering description is any better, it's just different!! Hopefully by understanding both responses- your question is more comprehensively answered!!
First, a short intro to control systems: control modules (let's just call them "modules") in vehicles are ostensibly mechanisms for controlling function(s)/device(s) in an environment that is constantly changing. To do this, these modules contain an internal "model" of the function/device that is being controlled and they use transducers to measure the real world environment. Software in the module, adjusts the behavior of the internal model using the measured external variables to provide a predetermined output. These arrangements are called "closed system control loops" meaning that the transducer(s) modulate the module output via a feedback loop. The simplest form of this control system has just one feedback-loop (see below)
Another form of controller uses "adaptive" control system design - which is a type of non-linear operating arrangement. Adaptive control detects changes in the operation of the function/device and it then "adapts" a bunch of controlling parameters automatically to compensate for the altering conditions in the external world (often, in a way that optimizes the loop response).
The use of variable "adaptation parameters" is separate (but obviously, related) to the module's primary purpose. The main reason for using adaptive control in these modules is that most processes in today's vehicles have complex, nonlinear responses - and the processes are often, initially uncertain. Adaptive control systems look like this in high level structure:
So-comparing the two diagrams, you can see that adaptive control modules have 2 x "control system loops": one loop is the normal, primary feedback loop as described earlier and the other loop is the parameter adjustment loop.
I suspect that the adaptation channel database in a module contains a list of the adjustable parameters for the second loop as shown above (I'm guessing).
On the other hand, it seems to me that the long-code string that is present in most modules has (or, more accurately - has had?) an entirely different purpose- related in the main to the needs of the mass production process that is used by ALL vehicle manufacturers.
Long-code appears to be a much lower level control mechanism in the module. At least for the modules with which I'm familiar (which use mostly the newer UDS/ODX protocol)- it's easiest to think about long-code as being a bank of simple software switches. I use the term "Software switches" because the code-able "Bits" in long-code can readily be thought-of as simple ON/OFF mechanical switches that can be changed by the long-code software in the module
Again, at least for newer modules- long code is normally reported as a series of numbers with occasional alpha characters like A,B,C.....F. These are in fact Hexadecimal pairs - meaning that the values use a base 16 counting system. Hexadecimal counting is more efficient in computer based devices because one number can specify up to 16 x different states (whereas one number in the more normal decimal counting sysytem can only specify up to 10 x different states). I'm not sure if older modules used different counting systems - perhaps octal, or even quaternary?
Hexadecimal numbers have an equivalence in Binary arithmetic (which is counting in base 2) and a hexadecimal pair can be represented as 8 x binary Bits. Again to use my previous analogy, each Bit can be thought-of as a single software switch that can have a status of either OFF, or ON.
In terms of how long-code is used, I suspect that long-code tells the module which of many options/features were installed on the factory production line (and equally important - which options/features were NOT installed). Further, I suspect that internal to the module, long-code Bits turn-ON/OFF certain software subroutines in the module firmware thereby aligning the module's operations with the car's physical installations.
So, if you are still following this - hopefully it's clear that adaptation channels play a role in how the module controls its primary function and it's equally clear that long-code determines which of the available features/options within the module firmware to use in controlling the pimary activity.
Now, I've absolutely no doubt that there will be numerous examples where the strict distinctions made above are violated on various module. As an example, I'm aware that the a pivotal module on late model MQB platform cars that OBD11 calls the "central electrics module" have no long-code string, at all (i.e. ALL of the software switches in previous modules have been transferred to adaptation channels).
So, the general precepts in my diatribe above are not hard-and-fast distinctions. Nevertheless, I hope my "straw-man" adds a different perspective to
whataboutthis link and maybe it will prompt further responses from others
Don
