ford: add 2025 F-150 Lightning fingerprint (ABS TL38, radar RB5T)#130
Merged
alan-polk merged 2 commits intoMay 25, 2026
Merged
Conversation
New FW strings found on 2025 Lightning Flash (131 kWh, built April 2025): - ABS 0x760: TL38-2D053-AD (was PL38/RL38 on 2022-23) - fwdRadar 0x764: RB5T-14D049-AB (was ML3T on 2022-23) - EPS and fwdCamera unchanged from existing MK1 entries Updates CarDocs year range to 2022-25. Co-Authored-By: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com>
The 2025 F-150 Lightning Flash's EPS ECU at 0x730 responds to Mazda's UDS
query (which targets the same OBD-II address) but does NOT respond to
Ford's own auxiliary=True (bus 0) query in FW_QUERY_CONFIG. openpilot's
brand-tagging logic records the Mazda response with brand='mazda' and the
Ford logging-only response with logging=True. build_fw_dict(filter_brand='ford')
keeps only Ford-tagged entries with logging=False, so it never sees an
EPS FW string for matching. Without an EPS entry, MK1's exact-match check
fails on the eps line, and openpilot falls back to MOCK / dashcam mode
on first fingerprint attempt — even though the patched fingerprints.py
correctly contains TL38-2D053-AD and RB5T-14D049-AB.
Adding MK1 to non_essential_ecus[Ecu.eps] tells the matcher to skip the
EPS check for MK1 when no Ford-tagged matching-eligible EPS FW is present.
The 3 ECUs that DO respond cleanly to Ford's auxiliary query (abs at 0x760,
fwdCamera at 0x706, fwdRadar at 0x764) are sufficient to uniquely identify
MK1:
- TL38-2D053-AD (ABS): unique to MK1
- RB5T-14D049-AB (radar): unique to MK1
- RJ6T-14H102-BBC (cam): also in F-150 MK14, but MK14's ABS list is
disjoint from MK1's so no false-match risk
Verified: with this patch applied, match_fw_to_car on the actual 31-FW
set returned by a 2025 Lightning Flash returns
{CAR.FORD_F_150_LIGHTNING_MK1} exact=True. Without the patch, it returns
the empty set.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
FORD_F_150_LIGHTNING_MK1for the 2025 model year2022-23to2022-25Ecu.epsnon-essential for MK1 so the 2025 Lightning auto-detects despite an EPS query quirkNew firmware versions (VIN
1FT6W3L78SWG0XXXX, built April 2025)PL38-2D053-AA/RL38-2D053-BDTL38-2D053-AD← newML3T-14D049-ALRB5T-14D049-AB← newRL38-14D003-AARJ6T-14H102-BBCWhy
non_essential_ecus={Ecu.eps: [MK1]}is requiredThe first commit (FW strings + year docs) was sufficient on devices that already had a cached
CarParamsPersistentfrom a previously successful fingerprint. On a freshCarParamsCachewipe — or on any other 2025 Lightning Flash being fingerprinted for the first time — the result iscarFingerprint='MOCK'/dashcamOnly=Truedespite the patched fingerprints.py containing both new FW strings.The 2025 Lightning's EPS ECU at
0x730responds to Mazda's UDS query but not to Ford'sauxiliary=True(bus 0) query. openpilot's brand-tagging logic records the Mazda response withbrand='mazda'and the Ford logging-only response withlogging=True.build_fw_dict(filter_brand='ford')keeps only Ford-tagged entries withlogging=False, so the Ford matcher never sees an EPS FW string for matching. MK1's exact-match check fails on the EPS line and openpilot falls back to MOCK.Verified on the actual 31-FW set captured from a 2025 Lightning Flash:
With this patch:
Without this patch (just the FW strings):
set(), falls back to MOCK.False-match safety
With EPS marked non-essential, the matcher uses
abs + fwdCamera + fwdRadarfor MK1. Verified unique:TL38-2D053-AD(ABS): only in MK1 (added by this PR)RB5T-14D049-AB(radar): only in MK1 (added by this PR)RJ6T-14H102-BBC(camera): also in F-150 MK14, but MK14's ABS list (ML34/NL34/PL34/PL3V) is disjoint from MK1's so no false-match riskSo
non_essential_ecus={Ecu.eps: [MK1]}does NOT create cross-platform ambiguity. Other Ford platforms (MK14 / Mustang / Edge / etc.) keep EPS as essential and are unaffected.Test plan
match_fw_to_caron the actual 2025 Lightning Flash's 31-FW dump returns{FORD_F_150_LIGHTNING_MK1}withexact=Trueset()(i.e. fingerprinting fails → MOCK) without thenon_essential_ecusline