ACC speed auto-set

   #1  

Hamid

New Member
Joined
Jul 30, 2024
Messages
9
Reaction score
12
Location
Iran
I implemented an idea so that the ACC speed is automatically set to 90 km/h every time the car is started.

I have a 2018 Passat 1.8 TSI equipped with ACC.
With almost simple software on a cheap processor connected to the CAN bus, I send some data packets with specific timing that set the cruise control speed to any desired value.



Only two ACC settings have memory and do not need to be set every time the car is started. One is whether ACC is on or off and the other is the distance from the car in front. But for me, every day after starting the car I have to set the cruise speed to 90 and then use it (the speed limit in our area is 90 on the highway). For this, I have to press the speed increase key (V+) seven times on the steering wheel and make sure that not more than that by mistake. This daily repetition is a bit annoying.
Of course, I understand that memorizing ACC speed by the car is intentionally not allocated, so the risk of uncontrolled speed does not arise when using ACC for the first time. The driver has to set the ACC speed on purpose to accept the resulting responsibility.
However, since the cruise control in my car is adaptive, in my opinion, this risk is not significant. So I decided to add this feature to the vehicle.



Findings
The processor inside the steering wheel transmits information through the Convenience CAN bus. In some previously reviewed cases (see here and here) the right side keys, which are mainly used for AID settings and audio, are sent via CAN ID = 5BF. But the processor sends the status of the left side keys (cruise control keys) in a different way and with a different CAN ID. My searches to find its specifications were unsuccessful.
By monitoring the Convenience CAN bus and overcoming many difficulties, I was able to find out that the processor on the steering wheel does the sending with the following rules:
1) The CAN-ID is equal to 12B and the data length is always 8.
2) According to the CAN bus standard, the packet structure is as follows (each number is one byte and is displayed as hex):

00 00 01 2B 08 xx yy zz 2A 00 00 00 00
3) This processor sends one data packet approximately every 30 milliseconds to let the system know that it is alive and well. Thus, even if no key is pressed, approximately 32 packets are always sent per second.
4) The yy number in each packet increases by one digit compared to the previous packet. If ACC was on, it would start from 0x40 and continue until 0x4F, which means 16 different numbers. After that, it starts again from 0x40. The number xx is determined by the rule that is unknown to me but depends on the numbers yy and zz.
5) If all keys were released, the zz number in packets is 80.
6) If the speed increase key (V+) is pressed, the zz number is 82. As long as the V+ key remains pressed, other specific series of codes will be sent.
7) The rest of the ACC keys also have their zz. For example, for V- it is 84.
The table for "no key", "V+ key" and "V- key" is as follows:
Table



A real sample of packets
These are real packets sent by the steering wheel via the CAN bus when I pressed V+ key for a short time:

Code:
. . . . .
00 00 01 2B 08 0D 4F 80 2A 00 00 00 00
00 00 01 2B 08 86 40 80 2A 00 00 00 00
00 00 01 2B 08 F4 41 80 2A 00 00 00 00
00 00 01 2B 08 50 42 80 2A 00 00 00 00
00 00 01 2B 08 CF 43 82 2A 00 00 00 00 // V+ key pressed
00 00 01 2B 08 4F 44 82 2A 00 00 00 00
00 00 01 2B 08 EA 45 82 2A 00 00 00 00
00 00 01 2B 08 F3 46 82 2A 00 00 00 00
00 00 01 2B 08 D6 47 82 2A 00 00 00 00
00 00 01 2B 08 03 48 82 2A 00 00 00 00
00 00 01 2B 08 CC 49 80 2A 00 00 00 00 // V+ key released
00 00 01 2B 08 DC 4A 80 2A 00 00 00 00
00 00 01 2B 08 79 4B 80 2A 00 00 00 00
. . . . .
It can be seen that yy numbers didn't change but xx and zz numbers changed from "No-key" table to "V+" table. The V+ key code started from yy=43 just by chance.


Designing
It is possible to use a cheap simple board like Arduino and a CAN bus interface board like MCP2515. But, for some reason, I used the STM32 processor.
The main idea is to artificially simulate the pressing of the V+ key and send the desired number of appropriate packets on the CAN bus.
While working with the system, I realized that if for any reason, the yy numbers are not sent in the order that was said, an ACC error will be declared and ACC will be unusable for now. Of course, this error will be resolved by restarting the car.
Therefore, from a technical point of view, this task is as follows:
16 consecutive packets of V+ table will be sent with a time interval of 1.5 milliseconds. These packets take about 24 milliseconds and fit between the transmissions of the steering wheel processor. So that the overall sequence of yy numbers does not get mixed up and the pressing of the V+ key will be simulated.
Packets on the CAN bus in the time axis will be as follows:
Timing

The blue packets are sent by the processor on the steering wheel, and the red packets are sent by our processor.
The final algorithm can be expressed as follows:

Code:
Start-up and initialize  //immediately after ignition-on
delay for 6 seconds
N = 7;  /* 1=30 km/h , 2=40 km/h , ... , 7=90 km/h, … */
For N times
{
   Wait and Read-CAN packets to find: xx,yy,zz = 0D,4F,80
   delay for 3 mili-sec
   Every 1.5 mili-sec: Send-CAN packets of V+, start from 41,40,82 up to CA,4F,82
   delay for 300 mili-sec
}
Set MCP2515 to sleep mode
Set the CPU to sleep mode
It is possible to develop the above algorithm in any software language on various processors.


Final result
I implemented the above algorithm in STM32 processor in C language. The MCP2515 function library was very useful. The board power should be connected to Terminal-30.
Please see this video:
go.screenpal.com/watch/cZiv6zVPHpy

The system works well, without any errors.
When the car is started, the ACC speed is set to 90 km/h automatically within 10 seconds.

It has brought me a kind of comfort. Besides, it was fun to face this challenge.
 
   #2  

AINils

VCDS Distributor
VCDS Distributor
Joined
Apr 3, 2020
Messages
1,275
Reaction score
1,158
Location
Germany (AIB)
VCDS Serial number
C?ID=56975
Nice feature for old ACC sensor in MQB cars. But in cars with pACC this feature is available in stock (not 90, but actual speed from TSR/NAvigation)

Great job, thanks for sharing.
 
   #3  

NEtech

VCDS Distributor
VCDS Distributor
Joined
Feb 7, 2014
Messages
3,844
Reaction score
6,119
Location
Denmark
VCDS Serial number
C?ID=56995
Is it not possible to drive to 90 km/h and press SET ?
Also look what the CAN data is used for that.
 
  • Agree
Reactions: TTT
   #4  

Hamid

New Member
Joined
Jul 30, 2024
Messages
9
Reaction score
12
Location
Iran
Is it not possible to drive to 90 km/h and press SET ?
Also look what the CAN data is used for that.
That is the usual method.
But consider how convenient it would be if it was automatically set to exact 90 every time.
 
   #5  

PetrolDave

Verified VCDS User
Verified
Joined
Dec 16, 2014
Messages
8,997
Reaction score
8,614
Location
Westbury, UK
VCDS Serial number
C?ID=1423
But consider how convenient it would be if it was automatically set to exact 90 every time.
Given that the early part of my drives is always in town it would be annoying to get the message telling me to use the brake the first time I join a traffic queue on every drive from home. Not for me...
 
  • Like
Reactions: Uwe
   #6  

Hamid

New Member
Joined
Jul 30, 2024
Messages
9
Reaction score
12
Location
Iran
Nice feature for old ACC sensor in MQB cars. But in cars with pACC this feature is available in stock (not 90, but actual speed from TSR/NAvigation)

Great job, thanks for sharing.
Not just old ACC. My car has pACC feature, but it cannot be used in our region.
Even no MIB2 Map in this area :(. I use Android Auto.
 
   #7  

Hamid

New Member
Joined
Jul 30, 2024
Messages
9
Reaction score
12
Location
Iran
Given that the early part of my drives is always in town it would be annoying to get the message telling me to use the brake the first time I join a traffic queue on every drive from home. Not for me...
Maybe I didn't understand your comment correctly, but setting the ACC speed does not mean it starts working, and you must press the RES button by yourself to start the ACC.
Meanwhile, ACC means you don't have to worry about the traffic in front and the car will slow down.
Of course, in my car ACC works until it comes to a complete stop.
 
   #8  

jyoung8607

FoRT
Verified
Joined
Feb 25, 2014
Messages
2,826
Reaction score
4,563
Location
Garrettsville, OH
VCDS Serial number
C?ID=25607
Nice project! I know you've gotten it working already, but I thought you might find this info useful:

The CAN arb ID 0x12B that you're working with is called GRA_ACC_01 and it has documentation in opendbc.

The byte you refer to as XX contains a payload-level CRC. That's why it varies together with the other values. It's documented in the AUTOSAR End-to-End Protocol Specification as E2E Profile 2. To summarize, it's CRC-8H2F over the remaining payload bytes PLUS a pseudo-secret magic padding byte. The magic byte varies by CAN arb ID and (for some arb IDs) the message counter as well. openpilot (specifically opendbc) has code to implement E2E Profile 2 including the magic padding bytes you'll need.

The byte you refer to as YY contains, as you saw, a 4-bit rolling counter in the low nibble.

The byte you refer to as ZZ contains, as you saw, the signal you're using to change the setpoint. That can be Accel or Resume depending on how your car is equipped.

openpilot also sometimes sends GRA_ACC_01 to simulate cancel/resume presses on top of what the car sends, much like you're doing here. Timing and counter sync are indeed critical. We've had reasonably good success with watching when the gateway sends GRA_ACC_01, waiting 10ms (instead of the car's 30ms send rate) and sending with the next counter value. That seems to get the recipients to accept our message as legit and discard the gateway's message as a duplicate. Obviously you're welcome to do whatever works in your application.
 
Last edited:
   #9  

Hamid

New Member
Joined
Jul 30, 2024
Messages
9
Reaction score
12
Location
Iran
Nice project! I know you've gotten it working already, but I thought you might find this info useful:

The CAN arb ID 0x12B that you're working with is called GRA_ACC_01 and it has documentation in opendbc.

The byte you refer to as XX contains a payload-level CRC. That's why it varies together with the other values. It's documented in the AUTOSAR End-to-End Protocol Specification as E2E Profile 2. To summarize, it's CRC-8H2F over the remaining payload bytes PLUS a pseudo-secret magic padding byte. The magic byte varies by CAN arb ID and (for some arb IDs) the message counter as well. openpilot (specifically opendbc) has code to implement E2E Profile 2 including the magic padding bytes you'll need.

The byte you refer to as YY contains, as you saw, a 4-bit rolling counter in the low nibble.

The byte you refer to as ZZ contains, as you saw, the signal you're using to change the setpoint. That can be Set or Resume depending on how your car is equipped.

openpilot also sometimes sends GRA_ACC_01 to simulate cancel/resume presses on top of what the car sends, much like you're doing here. Timing and counter sync are indeed critical. We've had reasonably good success with watching when the gateway sends GRA_ACC_01, waiting 10ms (instead of the car's 30ms send rate) and sending with the next counter value. That seems to get the recipients to accept our message as legit and discard the gateway's message as a duplicate. Obviously you're welcome to do whatever works in your application.
Very interesting information and great links.
Thank you very much.
 
   #10  

Dr Sheldon

Verified VCDS User
Verified
Joined
Dec 5, 2014
Messages
2,533
Reaction score
800
Location
Windsor UK
VCDS Serial number
C?ID=334979
I implemented an idea so that the ACC speed is automatically set to 90 km/h every time the car is started.
Great solution !! Clearly got a good head for technology there - But your solution is to a problem that no one that I know has !!


We have Adas systems now - Distronic etc was in MB cars in 2002 ish !!


Come up with a solution that where Adblue & Nox systems can out live a set of brake pads and I would say your cooking with an air fryer !!
 
   #11  

Hamid

New Member
Joined
Jul 30, 2024
Messages
9
Reaction score
12
Location
Iran
Great solution !! Clearly got a good head for technology there - But your solution is to a problem that no one that I know has !!


We have Adas systems now - Distronic etc was in MB cars in 2002 ish !!


Come up with a solution that where Adblue & Nox systems can out live a set of brake pads and I would say your cooking with an air fryer !!
Thanks for the compliment :D:cry:

I agree that there was no problem; it was just for the sake of being easy.

It'd be so nice if my car's settings would stay the same whenever I turn it on, just like they were when I turned it off!
The settings were generally like that, except for the speed in ACC.
 
   #12  

Hamid

New Member
Joined
Jul 30, 2024
Messages
9
Reaction score
12
Location
Iran
Nice project! I know you've gotten it working already, but I thought you might find this info useful:

The CAN arb ID 0x12B that you're working with is called GRA_ACC_01 and it has documentation in opendbc.

The byte you refer to as XX contains a payload-level CRC. That's why it varies together with the other values. It's documented in the AUTOSAR End-to-End Protocol Specification as E2E Profile 2. To summarize, it's CRC-8H2F over the remaining payload bytes PLUS a pseudo-secret magic padding byte. The magic byte varies by CAN arb ID and (for some arb IDs) the message counter as well. openpilot (specifically opendbc) has code to implement E2E Profile 2 including the magic padding bytes you'll need.

The byte you refer to as YY contains, as you saw, a 4-bit rolling counter in the low nibble.

The byte you refer to as ZZ contains, as you saw, the signal you're using to change the setpoint. That can be Accel or Resume depending on how your car is equipped.

openpilot also sometimes sends GRA_ACC_01 to simulate cancel/resume presses on top of what the car sends, much like you're doing here. Timing and counter sync are indeed critical. We've had reasonably good success with watching when the gateway sends GRA_ACC_01, waiting 10ms (instead of the car's 30ms send rate) and sending with the next counter value. That seems to get the recipients to accept our message as legit and discard the gateway's message as a duplicate. Obviously you're welcome to do whatever works in your application.
Once again I appreciate you sharing the information.

I usually make an effort to consider devices from the perspective of their designers to gain useful insights.

Here are some questions that I have, and I would appreciate it if there are explanations for them:
1- The CAN protocol incorporates a robust CRC mechanism ensuring 'error-free' for each packet. Why did VW designers add an extra CRC inside the package?
2- Why does the extra CRC formula have to be so complicated? A simple formula involving all the bytes of the packet is not enough?
3- It is reasonable to send a data packet with a neutral command from time to time to declare that the processor on the steering wheel is healthy. But why every 30 milliseconds? Isn't for example every 1000 milliseconds enough? What is the risk?
4- As you have experienced, why is the error not reported when the rolling counter gets messed up (of course only once)? So what problem does the counter in the package solve?

The above points are relevant because the designers of the communication protocol should not impose an additional load on the CAN bus, and they should not force the hardware designers to use higher speed and more expensive processors.
 
   #13  

downtime

Verified VCDS User
Verified
Joined
May 27, 2017
Messages
3,491
Reaction score
2,177
Location
Finland
VCDS Serial number
C?ID=280813
Maybe I can give some insights. There are regulations behind why the update interval is so fast. Road safety regulations, which means the modules need to be able to communicate in real time. 30ms is as closer to real time but there are even faster messaging happening in CAN bus. 1000ms is not, it's already 1 second.

Also what comes to the encryption of the packages. I would imagine it is only as an extra "security" measure to prevent unauthorized tampering of the CAN messages.

The need for faster and more cyclic communication is not coming from designers, it's coming from road safety and automotive regulations.
 
   #14  

Spacewalker

Verified VCDS User
Verified
Joined
Jun 10, 2014
Messages
1,304
Reaction score
894
Location
Poland
VCDS Serial number
C?ID=159607
how is pACC working ? if you are in 40km zone , and after that zone motorway with 140 - they jump from 40 to 140 stright away, or it jump every 10 ?
 
   #15  

downtime

Verified VCDS User
Verified
Joined
May 27, 2017
Messages
3,491
Reaction score
2,177
Location
Finland
VCDS Serial number
C?ID=280813
From 40 to 140 directly. Neck breaking experience😀
 
   #17  

Hamid

New Member
Joined
Jul 30, 2024
Messages
9
Reaction score
12
Location
Iran
Maybe I can give some insights. There are regulations behind why the update interval is so fast. Road safety regulations, which means the modules need to be able to communicate in real time. 30ms is as closer to real time but there are even faster messaging happening in CAN bus. 1000ms is not, it's already 1 second.

Also what comes to the encryption of the packages. I would imagine it is only as an extra "security" measure to prevent unauthorized tampering of the CAN messages.

The need for faster and more cyclic communication is not coming from designers, it's coming from road safety and automotive regulations.
I do not doubt that this is right regarding most CAN communications. I believe the front ACC sensor (radar), main ECU, and brake control system communicate at intervals shorter than 30ms, possibly under 3ms.

But, the questions above focus on the processor located in the steering wheel, which has just one job: sending the state of the keys.
I think those questions are still valid.

As a comparison, pressing the Start/Stop switch sends a specific packet to change the engine's Start/Stop state. There is no additional CRC, no counter in the packet, and no repetition. This is quite logical!
Here is the packet:
Code:
00 00 06 5A 08 00 00 00 01 00 00 3C 00
 
   #18  

downtime

Verified VCDS User
Verified
Joined
May 27, 2017
Messages
3,491
Reaction score
2,177
Location
Finland
VCDS Serial number
C?ID=280813
The steering wheel buttons are part of the drivertrain scheme so they need to operate within the automotive safety regulations.
 
   #19  

AINils

VCDS Distributor
VCDS Distributor
Joined
Apr 3, 2020
Messages
1,275
Reaction score
1,158
Location
Germany (AIB)
VCDS Serial number
C?ID=56975
From 40 to 140 directly. Neck breaking experience😀
Only if you have an engine with such power ;-)
But it's working fine it engine isn't boosted by a chiptuner.....
It depend on engine and his power map in ecu
 
   #20  

downtime

Verified VCDS User
Verified
Joined
May 27, 2017
Messages
3,491
Reaction score
2,177
Location
Finland
VCDS Serial number
C?ID=280813
Only if you have an engine with such power ;-)
But it's working fine it engine isn't boosted by a chiptuner.....
It depend on engine and his power map in ecu
Agreed. If you have a smaller engine then it's fine. Electric car, it's chiropratic time afterwards :)
 
Back
Top