B2aaa ошибка ауди

На чтение 3 мин Просмотров 8.4к.

We recommend Torque Pro

Table of Contents

1. What Does Code B2AAA Mean?
2. Where is the B2AAA sensor located?
3. What are the common causes of code B2AAA?
4. Get Help with B2AAA

What Does Code B2AAA Mean?

SPECIAL NOTES: Since the subject of OBD communication protocols is highly technical, this quick guide to OBD II communication protocols can at best only cover the bare basics, and as such, the information provided here is intended for general informational purposes only. Therefore, the information provided here should NOT be used as a diagnostic aid without making proper reference to the repair manual for the affected application. END OF SPECIAL NOTES.     

In simple terms, OBD II fault code B2AAA is a code that is sometimes displayed by some scanners or code readers when that particular scanner or code reader is programmed with an OBD II communication protocol that is incompatible with the OBD communication protocol in use on the affected application. In essence, the B2AAA code is an indicator than one or more actual OBD II code have been set and stored by one or more control modules on the affected application, but since a communication incompatibility issue exists between the scanner and the vehicles’ OBD II system, the “real” code(s) cannot be displayed, and code B2AAA is displayed instead.

However, note that in some cases-

• code B2AAA can also be displayed when the original fault data gets overwritten (for reasons that are not always clear)
• code B2AAA can be displayed when some cheap, generic code readers cannot access the CAN (Controller Area Network) bus system on the affected application, even though its programmed communication protocol is largely or wholly compatible with that on the affected application
• code B2AAA can sometimes be displayed even on high-end dealer-grade diagnostic equipment that does not recognize all (or any) of the PID’s ( Fault Parameter Identifiers) that relate to the root cause(s) of the problem on the affected application. This often happens when some imported European and/or Asian- produced applications are tested or diagnosed with equipment that is programmed for use on vehicles that are produced for, and sold in, the North American market.

While the obvious solution to communication incompatibility problems is to obtain diagnostic equipment that is fully compatible with the affected application in order to be able to extract the “real” trouble code(s), the fact that there are nine (including four CAN protocol variants) in common use today greatly complicates the issue of OBD II programming compatibility. This is  especially so for non-professional mechanics, but once the basics of OBD II communication protocols are understood the issue becomes less confusing, if not entirely clear, so let us explore the problem by asking-

What is an OBD II communication protocol?

In simple terms, an OBD II communication protocol represents the set of programming rules that determines the structure of the messages that are exchanged between vehicle’s control modules, and the diagnostic equipment that interrogates the fault memory that is contained in one or more control modules.

The image below is a graphic representation of the structure of the KWP2000 protocol that is based on the ISO 9141 standard, which is commonly used on Chrysler, all European, and most Asian vehicles imported into the USA.

In this example, the message structure is made up of three parts; the header, a section containing the actual data being extracted, and a checksum, which can be thought of as a means of verifying the validity of all the data/information contained in the message. In turn, the header section of the message can be thought of as a sort of electronic “handshake” or interface between the control module and the diagnostic equipment. Briefly, the header section consists of a maximum of four bytes of information that identify the-

• Format of the message
• Target address of the message
• Source address of the message
• Total length of the message

The header section is followed by the service identification byte, which basically means that the diagnostic equipment uses this information to identify a particular diagnostic service within the OBD II system. These services include (among others), freeze frame data, oxygen sensor monitoring results, on-board activation tests, and data related to emissions.

While all of the above is very interesting, it is also a gross over simplification of a highly technical subject. In practice, this means that  from the perspective of the average non-professional mechanic that is interested in diagnosing/fixing his own vehicle, the fact that there are so many different, and incompatible OBD II protocols in use today often leaves him up the creek without a paddle, so to speak.

Although there is very limited information available in the public domain that provide technical descriptions of the various OBD II communication protocols, the following section should provide the average non-professional mechanic with sufficient information to not only be able to differentiate between the various OBD II protocols, but also to determine which communication protocol is used by the affected application.

OBD II communication protocols (briefly) explained

While the law in the USA states that all vehicles sold within the US market must be fully OBD II compliant, and especially with regard to generic codes that must have the same meaning/definition for all manufacturers, the fact is that all NOT all vehicles sold within the United States are fully compliant. There are many reasons for this, and if one adds the fact that some imported European and Asian vehicles use the EOBD II (European On-board Diagnostics) standard and specifications that differ from how the OBD II standard is applied in the USA in some respects, the situation becomes truly chaotic.

Fortunately, though, it is relatively easy to distinguish between the various primary communication protocols based on which pins/terminals in the data link connector are wired. So, before we look at the details of the various protocols, let us look at a typical data link connector (shown below) that complies with the SEA J1962 standard.

Note though that the above example is for a Type-A data link connector. The SAE J1962 standard also makes provision for a type-B connector, which is shown below.

In practice however, the outward appearance of the data link connector makes no difference to the pins/terminals it must have wired to comply with the requirements of a particular communication protocol.

Note that one of the defining characteristics of a communication protocol is its “baud rate”. The term “baud” refers to the speed at which information can be transferred by a particular protocol. For instance, if the “baud rate” of a communication channel is say, 10 000 baud, the rate of communication in that channel is 10 000 bytes of data per second. That said, below are some details of the OBD II communication protocols in use today-

 – ISO15765-4 (CAN-BUS)

This is the most modern communication protocol, and it is mandatory on all post-2008 vehicles sold in the United States. Note however that four variants of this protocol exist, these being-

• ISO 15765-4 CAN (11 bit ID, running at 500 kilo baud)
• ISO 15765-4 CAN (29 bit ID, running at 500 kilo baud)
• ISO 15765-4 CAN (11 bit ID, running at 250 kilo baud)
• ISO 15765-4 CAN (29 bit ID, running at 250 kilo baud)

The above variants differ only in the number of bytes contained in the identifier and the speed at which they communicate. All variants require pins #6 and #14 (referenced to signal ground) in the data link connector to be wired to allow for differential communication. Note also that some European imports from around the production year 2003 may use one of the above CAN variants.

NOTE: While some European imports such as various Fiat/Lancia/Alfa Romeo models also use a CAN-based protocol, this particular protocol runs at a rate only 50 kilo baud, which means that it is not OBD II compliant.

ISO9141/14230 (KWP2000)

These asynchronous serial communication protocols are used mainly on Chrysler, European, and Asian vehicles made after 2003, and must have pin #7 wired, and optionally pin #15. Note however that two variants of the ISO ISO14230-4 protocol exist, these being-

• ISO 14230-4 KWP (5 baud initialization, and running at 10.4 kilo baud)
• ISO 14230-4 KWP (fast initialization, and running at 10.4 kilo baud)

– SAE J1850 VPW

This protocol is used on most General Motors applications, and it must have pin #1 in the date link connector wired. This protocol is based on Variable Pulse Width, and it runs at 10.4 kilobytes per second.

– SAE J1850 PWM

This protocol is based on Pulse Width Modulation, and is typically used on Ford applications. The communication signal is differential, it runs at 41.6 kilobytes per second, and it must have pins #1 & #2 wired.

To summarize…

In addition to the pins mentioned above that must be wired in the data link connector, all OBD II compliant connectors must also have the following pins wired-

• Chassis ground at pin #4
• Signal ground at pin #5
• Battery positive at pin #16
• Note that on applications that use protocols ISO9141-2 or ISO14230-4, pin #15 may or may not be wired.

Moreover, on an application that is OBD II compliant the data link connector must have the following pins in the data link connector wired-

• Pin #2 – J1850 Bus+
• Pin #4 – Framework/Chassis Ground
• Pin #5 – Signal ground
• Pin #6 – CAN High (J-2284)
• Pin #7 – ISO 9141-2 K Line
• Pin #10 – J1850 Bus
• Pin #14 – CAN Lower (J-2284)
• Pin #15 – ISO 9141-2 L Line (Optional)
• Pin #16 – Battery Positive

Based on the above-wired pins, it is often possible to determine the particular OBD II communication protocol that is used on a particular post-1996 application if the following is taken into account-

• CAN (Controller Area Network) based protocols will have pins 4, 5, 6, 14, and 16 wired
• ISO 9141-2/KWP2000 protocols will havepins 4, 5, 7, 15, and 16 wired
• Protocol J1850 VPW will have pins 2, 4, 5, and 16 wired, but NOT pin #10
• Protocol J1850 PWM will have pins 2, 4, 5, 10, and 16 wired

Be aware however that the connections listed above represents a general rule of thumb at best, and does therefore NOT guarantee that a particular application is fully compliant with current OBD II standards. In some cases, the data link connector may have wired pins other than the ones mentioned here; in these cases, the additional pins usually connect to specialized systems that may be unique to the affected application.

One more thing…

While it is sometimes possible to resolve the problem with codes like B2AAA that make no sense and do not appear even in the most comprehensive resources simply by determining which OBD II communication protocol is used on the affected application, this often also solves only half of the problem.

The other half of the problem involves the fact that not all PID’s ([Fault] Parameter Identifiers) are supported by all OBD II protocols on all applications, or on all code readers. While most PID’s that relate to generic codes are supported by most protocols on most code readers, manufacturer specific PID’s for systems that do not involve engine/transmission/fuel management or emission control, are often only supported by code readers that are designed for use with a particular make and model of vehicle.

In practice, a PID refers to a system in the vehicle many of which, such as climate control, anti-theft/security, navigation, and others whose technical details/specifications are unique to each manufacturer. In fact, of the thousands of known PID’s that are in use today, the vast majority are non-standard in the sense that they apply to a particular make and/or model only, which usually makes it impossible for cheap, generic code readers to access these PID’s.

According to current OBD II requirements, vehicle manufacturers are obliged to make only ten modes, or fault data on ten systems that relate to generic trouble codes available, these modes being-

• 01 – Show current data
• 02 – Show freeze frame data
• 03 – Show stored diagnostic trouble codes
• 04 – Clear diagnostic codes and previously stored values
• 05 – Test results on oxygen sensor monitoring on non-CAN systems
• 06 – Test results on oxygen sensor/other component testing on CAN based systems
• 07 – Show pending codes set during the last or current drive cycle
• 08 – Control operation of on-board components/systems
• 09 – Request/show vehicle information
• 0A – Show permanent trouble codes as well as information on previously cleared codes

Vehicle manufacturers are therefore free to develop PID’s for any number of systems that do not have to comply with federally mandated regulations on lighting, or ABS/TC/ESC systems. Moreover, vehicle manufacturers are not obliged to make proprietary information on ‘their” PID’s available to anyone.

However, the US-based Equipment and Tool Institute is the only body that maintains a comprehensive database on proprietary PID’s, which requires a membership (available at a hefty fee) to gain access to. However, membership does not necessarily guarantee access, with the result that most car manufacturers have chosen to enter into agreements with individual scan tool manufacturers, instead.

Thus, the amount (and accuracy) of fault data that can be extracted from a given application with any given generic scan tool or code reader depends entirely on the amount (and accuracy) of the information supplied to the manufacturer of the scan tool by the manufacturer of the vehicle.

In practice, vehicle manufacturers will generally only supply high-level diagnostic data to manufacturers of high-end diagnostic equipment manufacturers, which is the primary reasons why most cheap, generic code readers cannot access some systems such as the CAN (Controller Area Network) bus system on most vehicles, and why strange codes such as B2AAA are sometimes displayed on cheap, generic code readers.

Where is the B2AAA sensor located?

The location of the part or system in which a fault/malfunction/defect is present that is causing code B2AAA to be displayed depends entirely on the application, and the actual code(s) that may be present.

Note however, that it is possible for code B2AAA to be displayed due to faults/defects/malfunctions in systems/parts/components/circuits, subsystems, and/or control modules that are not in any way related to body control functions. Therefore, and at the risk of over stating the case, the surest way to find the location of the defective part or system is to extract the actual code(s) with diagnostic equipment that is fully compatible with the OBD II protocol in use on the affected application.

What are the common causes of code B2AAA?

The “B2” part of the code most commonly indicates that the root cause of the issue is a manufacturer specific problem that relates to the body, or the BCM (Body Control Module). Since some applications can have dozens, or even hundreds of possible body control functions, the diagnostic procedure MUST begin by determining the communication protocol in use on the effected application.

If this is not possible, the better option is to refer the vehicle to the dealer or other competent repair facility for professional assistance in obtaining the actual codes. Failure to obtain the real codes that are stored will definitely result in a misdiagnosis, and very likely in additional damage to the application’s electrical system that may be very costly to repair.

Help Us Help You

Please comment below describing your issue as well as the specifics of your vehicle (make, model, year, miles, and engine),
and one of our mechanics will respond as soon as possible. We appreciate a $9.99 donation via the payment button below.