LIN communication with VW multifunction steering wheel (22-03-2017, 12:04)

Hello,

I would like to establish communication between a Volkswagen multifunction steering wheel and a microcontroller.
I've already done some reading about the structure and communication related to the LIN bus.
I already have an MFL steering wheel, and I just received a "LIN Serial Analyzer" from Microchip to test the communication.

The question is only how?
Does anyone know which IDs and parameters my master device needs to send in order to receive a response from the steering wheel?

Has anyone successfully tested this before and could possibly help me with it?

I would be very grateful!

Regards,
Martin.

First, you need to determine the speed at which the LIN bus is operating. Then it's relatively straightforward because the LIN bus has a predefined "schedule table" and a maximum of 64 possible frames.

So, you just send all the frames and see how the slave responds.

Hello mailman,

Thank you for reaching out!

Somewhere I read that baud rates of 2,400, 9,600, or 19,200 are used in the LIN bus.
Then I started the transmission and sent out the unconditional frame IDs from 0x00 to 0x3b.
...and lo and behold, with 19K2, I then received responses for 3 IDs .
I haven't made much progress yet. One of the three IDs is constantly sending the same byte content, while the other two IDs have responses that change with each query, and this happens exactly 16 times before it starts again with the first string.
I haven't been able to quickly determine if there are any changes in the byte data when a button is pressed on the steering wheel; it was also quite late last night...
I will post a snippet of the communication here later.

Okay, I've now run HTerm.
As I mentioned, I'm currently only receiving resumes for 3 specific ID numbers.


ID - 0x3A
Please provide the German text you would like me to translate into English. I will then give you only the translation, without any explanations.
On ID 0x3A, I'm receiving a resume signal from 0xBA.
After the wake-up signal, the first byte sent is 0xFE.
Subsequently, for each query within approximately 4 seconds, it sends 0xFF. Otherwise, the slave goes back to sleep and then restarts, behaving as if the first request from the master received no response, followed by 0xFE on the second query, and then continuously sending 0xFF.
The second byte always contains 0xFE, which I cannot currently assign a meaning to.


ID - 0x0E
Please provide the German text you would like me to translate into English. I will then give you only the translation, without any explanations.
On ID 0x0E, I'm receiving a resume signal from 0x8E.
The first byte increments from 0x80 to 0x8F with each query, and then restarts from the beginning.
The fifth byte always contains 0x40, and the rest are set to 0x00.

ID - 0x0F
Please provide the German text you would like me to translate into English. I will then give you only the translation, without any explanations.
On ID 0x0F, I'm receiving a resume signal with value 0xCF.
The first byte changes with each query.
The second byte increments from 0x40 to 0x4F with each query, and then restarts from the beginning.
In the third byte, there is always 0x80, in the fourth byte, there is 0x2A, and the rest are 0x00.


Please provide the German text you would like me to translate into English.
Current status:
A button press on the steering wheel has no effect on any byte; what have I missed?
The lighting on the steering wheel buttons isn't working either; it probably needs to be activated with a command.
I'm not yet sure how I can move forward at this point.
I might also get a steering column control unit, which would then be the master device, and I'll see what data it sends out.

Does anyone have any other suggestions?

Regards,
Martin[/img].

Here's the part that we're talking about .

Well, I'm kind of stuck right now; either I don't understand something, or I'm doing something fundamentally wrong...?

When I send requests using header IDs in the range of 0x00 to 0x3B, I only receive responses for the three specific IDs mentioned.
Initially, I didn't understand how values like 0x0F could change to 0xCF or 0x3A to 0xBA. However, I then realized that even when sending with PID 0xCF, the slave still returned the same response.
Looking at the PID byte in binary format, I believe I understand that these are the two most significant bits used for parity checking.
Starting with LIN 2.0, these 2 bits are added and essentially form an "enhanced checksum," which is not present in the classic version.
I probably overlooked that.

What's more puzzling to me is that I receive response data of 8 bytes for both IDs 0xCF and 0x8E, and this data appears in 16 consecutive, distinct response frames. However, these frames are identical and do not change at all when a button is pressed on the steering wheel.

Why isn't anything happening? Do I need any special commands to activate the MFL, because the key illumination doesn't turn on even when it's powered?

Something is still missing, but what ?

You probably haven't "enabled" the MFL yet. Usually, bus nodes receive a trigger signal (e.g., connected to terminal 15) via the network and then activate the application.

Therefore, if the buttons in the vehicle only function when connected to terminal 15, you will need to send the signal from the LIN master to the LIN slave.

Hello, I'm sorry for writing in English.
Attempt to send a 4-byte message to the MFSW at address 0x0D.
The message could be, for example:

50 F9 FF FF

The first byte controls the keyboard backlight, the second likely indicates the clamp status, and the remaining bytes (FF FF) are unknown to me.

Listen for button inputs at memory address 0x0E.
Good luck!

It is working!!!
You're welcome! / Thank you for your help!

Greetings.
Martin.

@postman

You were right, the MFL was still running in standby mode .

While the MFL indicates its presence and provides some information in response, it only gets to the point after being activated.
I spent quite some time figuring out how to assign the bits and bytes.
What can I say, I actually found all the keys now, and now I need to make some notes that are a little more understandable for myself, it works .
Certainly, there are still some hidden functions, but they won't be easily discoverable.
One would need to tap into a working system and monitor its activity.
But for now, that's enough, and I can now focus on establishing communication with a controller and then distributing the functions to the periphery, etc.
It looks like it will probably take some more time before everything is fully operational.

Regards,
Martin.

I'm moving on now; I've acquired an Arduino board and have primarily been focusing on learning how to program it.
A CAN data logger has been a great help to me. It allowed me to verify whether the communication was working correctly. It was invaluable in getting everything up and running.
However, we have now managed to read out all 21 button functions, and they are already triggering test functions on the Arduino board.
Now there's still a lot of work to be done, but I think I've probably managed the trickiest part .

Snooky wrote:

@postman You were right, the MFL was still running in standby mode . While the MFL indicates its presence and provides some information in response, it only gets to the point after being activated. [...Bitte gib mir den deutschen Text, den du übersetzt haben möchtest. Regards, Martin

What exactly did you do to activate it?

marvin wrote:

Snooky wrote: @postman You were right, the MFL was still running in standby mode . While the MFL indicates its presence and provides some information in response, it only gets to the point after being activated. [...Bitte gib mir den deutschen Text, den du übersetzt haben möchtest. Regards, Martin What exactly did you do to activate it?

Have you tried sending a "start engine" command yet? That would be my first suggestion...