Control unit for lighting functions of headlight systems with bus control

Hello,

I'm new here and to the world of Can.

I want to build a headlight control system for a vehicle based on the MQB platform from Volkswagen, where the headlight functions are controlled depending on CAN bus messages.
In this case, the headlights are controlled by a slave module that receives commands from the master headlight control unit (55).
I already have the gateway (19), vehicle network module (09), and headlight range control unit (55) connected, along with the wiring for the steering column switches, and the basic setup is working.

The basic plan is to install the headlight range control unit as a separate component in the other vehicle, specifically on the PQ25 platform, and I will provide the necessary CAN information using an Arduino or STM32 microcontroller. I want to use the existing outputs of the B-connectors, which currently switch headlights on and off, as input signals for my additional electronics, and then generate CAN messages based on these signals for the headlight range control unit.
The problem is that with my current headlight setup, the component protection feature is active, which constantly keeps the low beam on and prevents the high beam from activating, even though the switch positions and light functions are correctly displayed in the diagnostic system for the automatic headlight range control (LWR).
Since the 55 does not have component protection and therefore doesn't need to be initialized, I assume that somewhere on the CAN bus, a message is being sent indicating that the component protection is active, which prevents the system from feeling comfortable and proceeding. I observe the same behavior when I activate the LWR (Low Beam Headlight Range) without any other participants on the bus by sending a "power on" signal to Kl15 via the CAN bus.

Unfortunately, my RKS CAN interface hasn't arrived yet so I can't capture the bus data. When I try using an Arduino and can tool, everything crashes as soon as I connect to the vehicle, and many messages are lost at a speed of 1 Mbit/s.

So, my question is whether anyone has more information about what specific information participants in the CAN extended protocol need to function, or whether messages like "component protection active" are sent on the bus.

Best regards,
Max.

Interestingly, my RKS CAN device has now arrived, and it turns out to be a bus operating at 500 kbit/s. With the Arduino, I always had to set the speed to 1 Mbit/s in can tool, and also when transmitting with the MCP2515.

Hello.

sline wrote:

Interestingly, my RKS KCan has now arrived, and it turns out that it is indeed a bus with 500 kbit/s. With the Arduino, I always had to set the CAN Tool to 1 Mbit/s, and also when sending data with the MCP2515.

Unfortunately, I can't really help you with component protection; I haven't had much experience with it in the past.

Your bitrate discrepancy: Could the crystal oscillator for the CAN controller be incorrectly configured by chance?

I'm not familiar with the MCP2515. For the MCP2518, it operates at 4 MHz with a PLL, and at 20 MHz and 40 MHz without a PLL. I suspect that the predecessor chip might have similar characteristics. It's best to consult the datasheet. Most likely, the clock frequency is incorrectly configured or a different oscillator than expected has been soldered onto the board.

Best regards, Rainer.

CAN-Diagnose wrote:

Your bitrate discrepancy: Could the crystal oscillator for the CAN controller be incorrectly configured by chance?

That's it, I didn't set the tempo correctly.

I have now successfully installed a CAN extended trace from a T6.1 vehicle. As a result, the headlight seems to be working correctly, and I can control all of its functions.
The list of sent messages is very long, and many have checksums or changing bytes, which means I need to send a lot of data from the Arduino to simulate the rest of the bus and extract the necessary messages.

What about the Arduino? Is the ATMega 328P even suitable for it? I'm concerned that the memory space might be too limited. That's why I was thinking that an STM32 with an integrated CAN controller might be a better choice?

Max.

sline wrote:

What about the Arduino? Is the ATMega 328P actually suitable for it? I'm concerned that the memory space might be too limited. That's why I was thinking that an STM32 with an integrated CAN controller might be a better choice? Max

Hi Max, the 328p is definitely suitable for this application. I've implemented an interface that captures analog motor data, incorporates calibration data, and outputs it to the NMEA2000 marine network. Complete network management is also implemented, and there's still some processing power available.
I'm starting new projects using the MEGA128DB48 microcontroller, which offers more memory, RAM, and I/O pins, as well as a 12-bit ADC, all while maintaining the same component size (7x7mm).

Best regards, Sigi.

That sounds good. Now that I've also resolved the issue with the headlights, it seems like the entire project can be implemented with a relatively small number of IDs on the CAN bus. This means the lamp functions as intended, even without an onboard network and gateway. I'm sending data directly to the CAN Extended.

Werde daher sowieso erstmal mit dem Arduino einen Prototyp bauen und das Fahrzeug mit den neuen Leuchten ausstatten um das ganze zu testen, dann ergeben sich sowieso die nächsten Probleme.

Max.