Audi A8 D3 heated seat via CANBUS

Hello everyone,
being inspired by some other users I am currently building an office chair using one of the Audi A8 D3 comfort seats.

I am using Arduino + Seeed BusCan shield and so far I've managed to wake up the control module. All adjustments work fine.

The seats is 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. Any idea ?

I have a doubt regarding the heating function. My idea was also to activate it with Arduino but I am not sure if that's possible.
According to wiring diagram both heating elements and temp sensor are connected to the ventilation control module, which indicates we could influence it with canbus.


Does anyone know if the heater can be directly activated with canbus or it will need an external switch relay, which feeds the power to the seat?

If so, would anyone know the bus command to activate the heater? Having no access to a real car and I am unable to scan the bus

thanks a lot for your help.

Hey,
ID 0x415 looks like Network management ID. Its for other ECUs to tell "Im alive", go to sleep mode and etc.

Would you know if memory function can be accessed over the management 0x415 or rather the 0x515? I am trying to figure out how to program the seat memory with arduino...

KotekBury hat folgendes geschrieben:

Would you know if memory function can be accessed over the management 0x415 or rather the 0x515? I am trying to figure out how to program the seat memory with arduino...

0x415 is for NMW - its not interesting to you. In audi/vw cars, IDs with 0x4** are usually for NWM..
Memory function should be available over CAN (i think, i dont know exactly), because in some cars (maybe in this audi as well), seat position is stored in to your key, because then different drivers with different keys still have own configuration for steering wheel, seats, mirrors..

So it should be possible over CAN (if your seat is without other buses i.e. LIN).
0x515 ID is sending passenger seat. It should be useless as well, because this ID is coming from seat, not to seat. As you wrote in this ID you see status about position, which might be interesting for feature, which i described above.

Can you post pinout of your seat connector(s)?

There are only 3 meaningful pins:

1. CAN HIGH
2. CAN LOW

3. BUS LIN (Not-Aus).
According to diagrams this one is wired directly to a door control unit. But from the description (not-aus) I'd assume it is only used for an emergency button in the door panel next to memory buttons. I could be wrong here, though.

When adjusting the seat the following messages are thrown to CAN:
0x415 14 15 x x x - as you indicated it might not be interesting for 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 height adjustment the value will be 0x80 2 1 0 0 0 irrespective of whether height is down or up. It looks like the message identifies the button pressed but no the adjustment values. Of course, I tried to send the same message back with different values to no avail.

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 values actually are.

My idea is to program a long loop and test many IDs with a combination of one or two next bytes and maybe I will get some other response.

Looping 0xFFFF is not practical, so I am going to limit myself to only IDs in a very narrow range (e.g. up to 0x7D0) . If that makes sense. I hope IDs above that are not really used

Passenger seat memory button ID is 0x615.
Byte0 is checksum.
Byte1 low nibble - counter to calc checksum;
high nibble - empty;
Byte3:
bit0 - Pos1
bit1 - Pos2
bit2 - Pos3
bit3 - Pos4
bit4 - on [??]
bit5-6 - empty;
bit7 - memory button.


Without valid checksum your message will be ignored....

This is great. I am trying but obviously I am still missing something.

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

Would you have some tips on how to calculate the checksum correctly?
Which crc-x should be used ?

Actually, I am confused why we would need to add crc in the data field.
The crc is already present in the can message by default.

Or did I misunderstand your last post ?

Thank you for your help.

First. sorry, i made a mistake. Not byte3 but byte2 is the last one (for buttons info).
Length is 3.

All important messages in audi, vw, mb, bmw and etc has checksum included in CAN message. Its important, because ECU before will start to do something, must be sure, that data is valid. Not from physical side, but from application. Maybe second ECU is working in strange status and sends only wrong data. So receiver must check validity of received data.

Its crc-8. so only one byte.

But Audi/VW engineers made it in very "nice" way. If you want to get CRC you should know not only algorithm, but also 16bytes sequence (in MQL and MLBEvo cars, about older i cant say). Thats why always you have counter from 0 to F in second byte. This counter shows, which element from the sequence need to take.

Example for 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
....

Maybe its very simple like byte1 AND byte byte2.. This one i cant say to you...
You should simple try.

About the checksum, code explains more than 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; }

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

Now, what would be sequence of messages I would have to send to program the memory?

I tried the following byte[2] but nothing happened:
0x91 = 10010001, which should store in memory 1
0x10 = 00010001, which should restore memory 1

For reach I sent a sequence of 16 messages in a row.

The checksum and counter were calculated as per your suggestions both with counter+=0x10&0xF0 and counter+=0x1&0xF

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

majonez hat folgendes geschrieben:

About the checksum, code explains more than 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 is valid? Audi or VW? If we are talking about old (before MQL and MLB Evo platform) cars, Audi and VW have different checksums.

In your example I see counter on byte 6, usualy Audi (as MQB and MLBEvo cars) checksum has it in byte0. Counter in byte1, low nibble, in your example its byte6, high nibble.
Your checksum looks like for old VW, Skoda cars...

Paulius hat folgendes geschrieben:

For which car is this checksum is valid? Audi or VW? If we are talking about old (before MQL and MLB Evo platform) cars, Audi and VW have different checksums. In your example I see counter on byte 6, usualy Audi (as MQB and MLBEvo cars) checksum has it in byte0. Counter in byte1, low nibble, in your example its byte6, high nibble. Your checksum looks like for old VW, Skoda cars...

Yes, my code is valid for PQ platform.
I didn't even notice, that MQB Checksum is different Sorry for the confusion.
BTW, this is very interesting. Below is the dump from Skoda Octavia III infotainment bus, id 0x3C0 (ignition). It has 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 CRC.

majonez hat folgendes geschrieben:

Paulius hat folgendes geschrieben: For which car is this checksum is valid? Audi or VW? If we are talking about old (before MQL and MLB Evo platform) cars, Audi and VW have different checksums. In your example I see counter on byte 6, usualy Audi (as MQB and MLBEvo cars) checksum has it in byte0. Counter in byte1, low nibble, in your example its byte6, high nibble. Your checksum looks like for old VW, Skoda cars... Yes, my code is valid for PQ platform. I didn't even notice, that MQB Checksum is different Sorry for the confusion. BTW, this is very interesting. Below is the dump from Skoda Octavia III infotainment bus, id 0x3C0 (ignition). It has 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 CRC.

Skoda Octavia III is MQB platform car (Passat B8, Golf VII, Arteon) and also like MLBEvo (audi a5, a6). And with MQB platform, all cars they made like Audi (some CAN IDs are the same like in old Audi cars, i.e. your ignition example)

Your example has CRC which i mentioned above: need to know algorithm and 16 numbers sequence. Counter shows which element from sequence need to use.

[quote="Paulius"][quote="majonez"]

Paulius hat folgendes geschrieben:

Counter shows which element from sequence need to use.

I am confused about the sequence. What is the importance of it apart from including it in the calculation the CRC?

What if I send same data twice with the same sequence number ?
What if I send different data twice with the same sequence number ?

[quote="KotekBury"][quote="Paulius"]

majonez hat folgendes geschrieben:

Paulius hat folgendes geschrieben: Counter shows which element from sequence need to use. I am confused about the sequence. What is the importance of it apart from including it in the calculation the CRC? What if I send same data twice with the same sequence number ? What if I send different data twice with the same sequence number ?

Some ECUs are checking counter, some - not. Because counter in this case has two "features":
1. ECU knows if any messages are missing;
2. Can calculate own CRC and compare with CRC in received message to check validity.
Some ECUs are simply ignoring wrong CRC, some are completely off for some delay.

In VW, by example, radio is ignoring counter and CRC in ignition message. It checks only data byte(s).
So I guess seats are not that critical so it should work with any counter and CRC values (maybe I'm wrong!).

By the way: In Mercedes seats are awaiting voltage over CAN, without this they are not moving, but I guess its not a problem to you, because you can control them, only memory function is not working.

Yes, I can control the seat without CAN. I only had to wake it up with one message and since then the seat is active. It does not even have to be powered on all the time. I can unplug it for a day or two without loosing the responsiveness.

I also activated the heater using MOSFET controlled by Arduino. I am using the seat belt height adjustment to switch it on/off. Button had no other function, anyway.
Since each button trows an unique CAN message it was easy to program it.

Now I only need the memory to have a fully functional seat.

Would you have more messages in your logs for ID 0x615, so that I could maybe figure out some patterns?