Fingerprinting

Fingerprinting is how openpilot figures out which car it's connected to. Most cars are identified by querying ECU firmware versions over UDS and matching the responses against a known table. Pre-AP Model S identification works differently.

How NAP identifies the car

The pre-AP Model S has its own platform entry in NAP's car database: TESLA_MODEL_S_PREAP. In the firmware version table (fingerprints.py), this entry has no firmware versions listed — identification does not rely on reading EPAS or other ECU firmware strings.

Instead, NAP uses the NAPForcePreAP parameter. When this param is set, the interface layer bypasses the standard firmware-matching path entirely and directly returns the pre-AP platform. The NAP settings panel keeps this param permanently on (locked, grayed out — it cannot be turned off from the UI).

The practical consequence: your car is always recognized as a pre-AP Model S as long as the NAP branch is installed. The device won't go looking for firmware version strings that pre-AP ECUs may not respond to in the expected way.

There is also a CAN fingerprint entry for TESLA_MODEL_S_PREAP containing the set of message IDs and lengths seen on the pre-AP CAN buses. This is used as a secondary check at the CAN level — if the traffic pattern doesn't match, the platform won't be accepted even with the forced param. The message set in the fingerprint was captured from real pre-AP hardware.

What "unknown car" or wrong identification means

If the device is showing an unrecognized car or a different Tesla model:

1. NAP isn't running. The NAPForcePreAP logic only exists in the NAP branch. If you accidentally reverted to stock openpilot or a different fork, the device will try standard fingerprinting and may fail to match or identify the wrong car. Check Settings → Software and confirm the branch ends in nap-release or nap-alpha.

2. The param got cleared. A full factory reset or a corrupted params store could clear NAPForcePreAP. Open the NAP settings panel — if the Force Pre-AP Mode toggle is off (which you can see even though it's grayed out), something reset the params. Tap Reset to Defaults in the Actions section, which re-applies the lock.

3. CAN fingerprint mismatch. If the CAN traffic from the car doesn't match the TESLA_MODEL_S_PREAP fingerprint — say, because a module replacement changed the message set — the override may not be enough. This is rare. If you suspect it, check the #dev channel on Discord with a drive log.

Pre-AP vs. HW1 Model S

The NAP platform (TESLA_MODEL_S_PREAP) is distinct from the HW1 Model S entry (TESLA_MODEL_S_HW1) that exists in openpilot proper. HW1 refers to the first-generation Autopilot hardware (2014–2016 cars with cameras and the original AP ECU). Pre-AP refers to 2012–2014 cars that shipped with no forward-facing cameras or driver-assistance hardware at all. These are genuinely different cars with different CAN architectures.

If you see Tesla Model S (with HW1) 2014-16 on the device screen, NAP is not running — standard openpilot is active and identified your car as the HW1 AP variant. That's the wrong code for a pre-AP car. Get back to the NAP branch.

DBC and CAN architecture

NAP uses the tesla_preap DBC for all three buses (chassis, party, and powertrain). This is a separate DBC from the HW1/HW2/HW3 DBCs. The pre-AP car speaks a different dialect on some message IDs, and the pre-AP-specific carstate and carcontroller code handles the differences. If you're debugging CAN issues, make sure you're using the right DBC — the wrong one will parse garbage even though the messages are there.