[question] Is the 0x238 frame still STW_ACTN_RQ on newest software?

[JakNo]

Tesla model

Model 3 Highland

Year

2024

HW version

HW4

Tesla firmware version

2026.14.2

Region / market

Europe

App mode used

Auto Detect

Force FSD setting

OFF (using car's Traffic Light toggle)

Result

Worked — FSD activated and remained stable

Anything else

Hi, first of all thank you for all your work and documentation you prepared, it's very useful!

I was looking for a CAN signals descriptions related to scrolls on the steering wheel (I would love to have something like "continous autopilot" from S3XY commander) and found your documentation about those signals in FEIFAN_CAN_ANALYSIS file. However, when I sniff on vehicle CAN on my 2024 Model 3 Highland on software 2026.14.1 and look for 0x238 frame, it seems like it's rather UI_driverAssistMapData signal than STW_ACTN_RQ. Routing to some place on my navigation changes pin 29 of this frame, which could be UI_navRouteActive based on other DBC file I found.

Could anyone confirm that frame 0x238 is still STW_ACTN_RQ on newest softwares?

[hypery11]

@JakNo Good observation. On 2024 Model 3 Highland (HW4) with 2026.14.x firmware, Tesla has been remapping CAN IDs across software updates.

0x238 was historically STW_ACTN_RQ (steering wheel stalk/scroll actions) on older firmware and Model S/X. On your Highland HW4 with 2026.14.x, it does appear to have been repurposed to UI_driverAssistMapData — the navigation route data you're seeing (pin 29 = UI_navRouteActive) confirms this.

The steering wheel scroll signals on Highland HW4 may have moved to a different CAN ID or may now go through the vehicle's Ethernet backbone instead of CAN. The Highland removed physical stalks in favor of capacitive buttons, which changed the entire stalk signal path.

For the "continuous autopilot" feature (S3XY Commander style): on Highland, the relevant signals are likely on 0x293 DAS_settings (autosteer enable) or 0x39B DAS_status (AP state readback), both of which we already parse. If you can capture the CAN traffic while pressing the AP button on the steering wheel, the actual signal that initiates AP engagement will be visible.

Short answer: 0x238 is NOT STW_ACTN_RQ on your firmware/platform. The DBC files for Highland HW4 on 2026.14.x are not fully documented in public sources yet.

[JakNo]

Thanks for clarification. I'll check DAS_status and DAS_settings frames and try to test after the weekend.

[JakNo]

@hypery11 From my observations, on 2026.14.2 0x39B is still DAS_status frame - DAS_autopilotState signal change it's status from AVAILABLE to ACTIVE_NOMINAL and it matches state of the car. However, I think that DAS_settings frame has now different ID - the only bytes that were changing during my testing on frame 0x293 was D7 (that was incrementing by 1, which I assume is a counter) and D8, which I think is just a checksum.

[hypery11]

@JakNo Excellent data — especially useful in light of @dmagyar's 14.3 report that TX immediately disables autosteer. Your 14.2 capture suggests the framing layer is mostly intact and the new enforcement sits upstream of frame parsing.

On your 0x293 observation: D7 incrementing by 1 = standard Tesla counter (0–15 modulo), D8 = checksum (likely the same XOR-style used on 0x3FD / 0x39B). If only D7 and D8 change, the rest of the payload is static — which would mean DAS_settings probably isn't actually riding on 0x293 anymore. It may have moved onto 0x399, or got split across muxed slots on 0x3FD.

If you're up for it: a listen-only capture during P → D → engage AP → hold would let us identify the static-vs-changing byte pattern across all IDs and pin down where DAS_settings now lives. No TX needed (especially given dmagyar's 14.3 finding).