HKG: Add hands-on detection signal for LFA2 vehicles

[devtekve]

This signal is for LFA2 vehicles that uses steering grip sensor. https://www.hyundaimotorgroup.com/innovation/CONT0000000000005027

Validation

• Dongle ID: e1107f9d04dfb1e2
• Route: e1107f9d04dfb1e2/0000025f--8df0049cd4

Note

The signal name is not 100% confirmed officially. This is because while I found found the signal on an official DBC, the message address was not the same as what I found, and neither was the structure completely. However, the values themselves mapped to what I found, so my only guess is that the signal simply got updated since the dbc I found.

Note

needed by: #1676

[jyoung8607]

This message looks to have a usable COUNTER and cyclically-repeating CHECKSUM, which I'd presume uses one of the existing HKG checksum algorithms. Can you add those fields? Will merge once that's done.

[devtekve]

This message looks to have a usable COUNTER and cyclically-repeating CHECKSUM, which I'd presume uses one of the existing HKG checksum algorithms. Can you add those fields? Will merge once that's done.

@jyoung8607 this does not have COUNTER and I wasn't confident that the first 2 bytes are in fact CHECKSUM either because there was no mention of it on the official DBC (although like I said earlier, this is not 1:1 to the official message I found). That being said, I compared it with other messages of the same frequency and the CHECKSUM seems to be a perfectly good guess.

COUNTER is definitely not. What seems like it it's the HOD_Dir_Status but that's our grip level on the steering.

Screen.Recording.2025-07-02.at.9.28.17.AM.mov

---

Edit: Doing a "quick & dirty" search on the dbcs for canfd I don't see an instance where CHECKSUM exists but COUNTER does not, so I wouldn't like to define it and it meaning something else (even though it kinda points to be checksum)

[jyoung8607]

From the very beginning of the route, with no motion and no hands-on/torque applied yet, the rest of the message beyond the counter and (assumed, unverified) checksum is invariant, so we can see the cyclic repetition on both. The counter is mod 0xF rather than mod 0x10 but I see that's done with some other HKG messages already.

I'll go ahead and merge this message as-is, so you'll have it for informational purposes, but I'd suggest adding CHECKSUM and COUNTER support before shipping a car port that makes active use of this detection.

[devtekve]

From the very beginning of the route, with no motion and no hands-on/torque applied yet, the rest of the message beyond the counter and (assumed, unverified) checksum is invariant, so we can see the cyclic repetition on both. The counter is mod 0xF rather than mod 0x10 but I see that's done with some other HKG messages already.

I'll go ahead and merge this message as-is, so you'll have it for informational purposes, but I'd suggest adding CHECKSUM and COUNTER support before shipping a car port that makes active use of this detection.

Oh! Thank you for that insight, I was under the wrong assumption that the checksum was meant to be 2 bytes but clearly not. My comment for it not having counter was solely based on the fact that the 3rd byte was already identified properly, it never crossed my mind the 2nd byte would be having the counter!