Audi A8 D3 heated seat control via CANBUS

Hello everyone,
Inspired by other users, I'm currently building an office chair using a comfort seat from an Audi A8 D3.

"I'm using an Arduino with a Seeed BusCan shield, and so far I've been able to successfully power on the control module. All settings are working correctly."

The seats are sending messages with ID 0x415 and ID 0x515.

The ID=0x515 seem to be related to seat's adjustments and the values change according to buttons pressed. Not sure what ID=0x415 is for. Sure, here's the translation:

"Do you have any ideas?"

I have a question about the heating function. My initial thought was to control it using an Arduino, but I'm not sure if that's feasible.
According to the wiring diagram, both the heating elements and the temperature sensor are connected to the ventilation control module, which suggests that we might be able to influence it via CAN bus.


"Does anyone know if the heater can be directly controlled via CAN bus, or does it require an external switch relay that provides power to the seat?"

If so, does anyone know the CAN bus command to activate the heater? Since I don't have access to a real car, I'm unable to scan the CAN bus.

thank you very much for your assistance.

Hey,
ID 0x415 appears to be a network management ID. It's used by other ECUs to indicate their status, such as "I am active," or to enter sleep mode, among other functions.

I'm not sure if the memory function can be accessed via management address 0x415, or whether it's actually accessible through address 0x515. I'm trying to figure out how to program the seat memory using an Arduino.

KotekBury wrote:

Do you know if the memory function can be accessed via management address 0x415, or rather 0x515? I'm trying to figure out how to program the seat memory using Arduino.

0x415 is related to the Network Management Window (NMW) – it's probably not of interest to you. In Audi/VW cars, IDs starting with 0x4** are typically used for NWM functions.
The memory function should ideally be available via CAN bus (I think, I'm not entirely sure). In some cars (possibly this Audi as well), the seat position is stored in the car key. This allows different drivers with their own keys to have personalized settings for the steering wheel, seats, and mirrors.

It should be possible to achieve this via the CAN bus (provided your seat doesn't use other communication protocols like LIN).
0x515 ID is transmitting data related to the passenger seat. This information should also be irrelevant, as this ID originates from the seat itself, not *to* the seat. As you mentioned, this ID contains status information about the position, which could be useful for the feature I described earlier.

Could you please provide the pinout diagrams for your seat connectors?

There are only 3 meaningful pins:

1. CAN HIGH.
2. CAN LOW.

3. BUS LIN (Emergency Stop).
"According to the diagrams, this one appears to be wired directly to a door control unit. However, based on the description (emergency stop), I would assume it's only used for an emergency button in the door panel, next to the memory buttons. I could be wrong about that, though."

When adjusting the seat, the following messages are transmitted via CAN:
0x415 14 15 x x x - as you indicated, it might not be of interest to me.

0x515 080 x x x x - depending on the button pressed, the values change. However, the values are constant regardless of the direction in which the button is pressed. In other words, if I press the height adjustment button, the value will be 0x80 2 1 0 0 0, irrespective of whether the height is being adjusted up or down. It appears that the message identifies the button that was pressed, but not the adjustment values. Of course, I tried sending the same message back with different values, but it didn't work.

Maybe the seat is not broadcasting the position values at all as there are no other devices that would need them. Maybe I only need a trigger to the seat's control unit to store the current values and then another trigger to restore them. I am sure this is what the door control unit actually does. The memory buttons in door panel are directly connect to the door control unit. The door control unit possibly only sends one message to CAN: store seat position values or restore values. Without even knowing what the actual values are.

My idea is to program a long loop and test many IDs using combinations of one or two subsequent bytes, and perhaps I'll receive a different response.

"Looping through 0xFFFF is not practical, so I'm going to restrict myself to only IDs within a very small range (e.g., up to 0x7D0). Hopefully, IDs above that value aren't actually being used."

The passenger seat memory button ID is 0x615.
Byte 0 is a checksum.
Byte 1: Lower nibble - counter for calculating the checksum.
high nibble - empty;
Byte3:
bit0 - Position 1.
bit1 - Pos2
bit2 - Pos3
bit3 - Pos4
bit4 - on [??Bitte gib mir den deutschen Text, den du übersetzt haben möchtest.
bit5-6 - empty;
bit7 - memory button.


"Without a valid checksum, your message will be ignored."

This is excellent. I'm trying, but clearly I'm still missing something.

Is the message length 8 bytes, or is it limited to only 4 bytes?

I would appreciate it if you could provide me with some guidance on how to accurately calculate a checksum.
Which CRC-X algorithm should be used?

"Actually, I'm confused as to why we would need to include a CRC (Cyclic Redundancy Check) within the data field."
The CRC is already included in the CAN message by default.

Did I misunderstand your previous message?

Thank you for your help.

First, I'm sorry, I made a mistake. It's not byte3, but byte2 that is the last one (for button information).
Length is 3.

All important messages in Audi, VW, Mercedes-Benz, BMW, and other vehicles include a checksum within the CAN message. This is crucial because an Electronic Control Unit (ECU) must first verify that the data is valid before taking any action. This validation isn't just about the physical integrity of the data, but also its application context. For example, another ECU might be in an unusual state and sending incorrect data. Therefore, the receiving ECU must check the validity of the received data.

It's a CRC-8 checksum, so it's just one byte in size.

"But Audi/VW engineers implemented it in a very clever way. To obtain the CRC value, you need to know not only the algorithm but also a 16-byte sequence (in MQL and MLBEvo cars; I can't say for sure about older models). That's why there's always a counter from 0 to F in the second byte. This counter indicates which element from the sequence should be used."

Here's an example of this ID from my log files:
0x01 0x01 0x00
0x12 0x02 0x10
0x13 0x03 0x10
0x14 0x04 0x10
0x15 0x05 0x10
0x16 0x06 0x10
0x17 0x07 0x10
0x18 0x08 0x10
...

Perhaps it's something very simple, like "byte1 AND byte2". I can't tell you more about that.
You should simply try.

Regarding the checksum, the code itself speaks volumes.

Code:

uint8_t counter; void send_msg(void) {       can_t msg_tosend;       msg_tosend.id = 0x123;       msg_tosend.length = 8;       msg_tosend.data[0]=0;       msg_tosend.data[1]=0;       msg_tosend.data[2]=0;       msg_tosend.data[3]=0;       msg_tosend.data[4]=0;       msg_tosend.data[5]=0;       msg_tosend.data[6]=counter&0xF0;       msg_tosend.data[7]=msg_tosend.data[0]^msg_tosend.data[1]^msg_tosend.data[2]^msg_tosend.data[3]^msg_tosend.data[4]^msg_tosend.data[5]^msg_tosend.data[6];       can_send_message(&msg_tosend);              counter+=0x10; }

OK. That's clear now. Thank you very much.

Now, what would be the sequence of messages I need to send in order to program the memory?

I tried using a `byte[2]` array, but nothing happened.
0x91 = 10010001, which should store the value 1 in memory.
0x10 = 00010001, which should reset memory location 1.

I sent a sequence of 16 messages one after another.

The checksum and counter were calculated according to your suggestions, using both `counter += 0x10 & 0xF0` and `counter += 0x1 & 0xF`.

91 0 91
81 10 91
B1 20 91
A1 30 91
D1 40 91

majonez wrote:

Regarding the checksum, code explains more than a thousand words: Code: uint8_t counter; void send_msg(void) {       can_t msg_tosend;       msg_tosend.id = 0x123;       msg_tosend.length = 8;       msg_tosend.data[0]=0;       msg_tosend.data[1]=0;       msg_tosend.data[2]=0;       msg_tosend.data[3]=0;       msg_tosend.data[4]=0;       msg_tosend.data[5]=0;       msg_tosend.data[6]=counter&0xF0;       msg_tosend.data[7]=msg_tosend.data[0]^msg_tosend.data[1]^msg_tosend.data[2]^msg_tosend.data[3]^msg_tosend.data[4]^msg_tosend.data[5]^msg_tosend.data[6];       can_send_message(&msg_tosend);              counter+=0x10; }

"For which car is this checksum valid? Audi or Volkswagen? If we're talking about older cars (those before the MQL and MLB Evo platforms), Audi and Volkswagen use different checksums."

In your example, the counter is located at byte 6, whereas typically, for Audi vehicles (such as those using the MQB and MLBEvo platforms), the checksum is found in byte 0. The counter, specifically the low nibble, is usually in byte 1; in your example, it appears to be in byte 6, representing the high nibble.
"Your checksum appears to be the one used for older Volkswagen and Škoda vehicles..."

Paulius wrote:

"For which car is this checksum valid? Audi or Volkswagen? If we're talking about older cars (those before the MQL and MLB Evo platforms), Audi and Volkswagen use different checksums." In your example, the counter is located at byte 6, whereas typically, for Audi vehicles (such as those using the MQB and MLBEvo platforms), the checksum is found in byte 0. The counter, usually represented by the lower nibble, is in your example at byte 6, which corresponds to the upper nibble. Your checksum looks like the one used for older VW and Skoda cars...

Yes, my code is valid for the PQ platform.
I didn't even notice that the MQB checksum is different . Sorry for the confusion.
BTW, this is very interesting. Below is the data dump from the Skoda Octavia III infotainment bus, ID 0x3C0 (ignition). It includes a checksum:

Code:

000014,773   3C0   4   18 0A 00 00                .... 000014,773   3C0   4   27 0F 00 00                '... 000014,773   3C0   4   66 00 00 00                f... 000014,773   3C0   4   D3 01 00 00                Ë... 000014,773   3C0   4   23 02 00 00                #... 000014,773   3C0   4   59 05 00 00                Y... 000014,773   3C0   4   E8 09 00 00                Ŕ... 000014,773   3C0   4   AD 0B 00 00                ş...

It's not easy to calculate a CRC (Cyclic Redundancy Check).

majonez wrote:

Paulius wrote: "For which car is this checksum valid? Audi or Volkswagen? If we're talking about older cars (those before the MQL and MLB Evo platforms), Audi and Volkswagen use different checksums." In your example, the counter is located at byte 6, whereas typically, for Audi vehicles (such as those using the MQB and MLBEvo platforms), the checksum is found in byte 0. The counter, usually represented by the lower nibble, is in your example at byte 6, which corresponds to the upper nibble. Your checksum looks like the one used for older VW and Skoda cars... Yes, my code is valid for the PQ platform. I didn't even notice that the MQB checksum is different . Sorry for the confusion. BTW, this is very interesting. Below is the data dump from the Skoda Octavia III infotainment bus, ID 0x3C0 (ignition). It includes a checksum: Code: 000014,773   3C0   4   18 0A 00 00                .... 000014,773   3C0   4   27 0F 00 00                '... 000014,773   3C0   4   66 00 00 00                f... 000014,773   3C0   4   D3 01 00 00                Ë... 000014,773   3C0   4   23 02 00 00                #... 000014,773   3C0   4   59 05 00 00                Y... 000014,773   3C0   4   E8 09 00 00                Ŕ... 000014,773   3C0   4   AD 0B 00 00                ş... Es ist nicht einfach, eine CRC zu berechnen.

The Skoda Octavia III is built on the MQB platform, which is also used for models like the Volkswagen Passat B8, Golf VII, and Arteon. It shares some similarities with the MLBEvo platform found in Audi vehicles such as the A5 and A6. Furthermore, due to the MQB platform, certain components and systems share commonalities across various brands, including Audi (as evidenced by shared CAN IDs, for example, like in the ignition system).

"Your example uses a Cyclic Redundancy Check (CRC), as I mentioned earlier. To understand it, you need to know the algorithm used and a 16-number sequence. The counter indicates which element from that sequence should be used."

"Yes, I can control the seat without using the CAN bus. I only had to send it one command to activate it, and since then the seat has been working. It doesn't even need to be powered on constantly. I can unplug it for a day or two without losing its responsiveness."

"I also activated the heater using a MOSFET controlled by an Arduino. I'm using the seat belt height adjustment mechanism to turn it on and off. The button didn't have any other functions, anyway."
Since each button sends a unique CAN message, it was easy to program.

Now all I need is the memory foam to have a fully functional seat.

"Could you please provide more log entries with the ID 0x615? This might help me identify some patterns."