What's the difference between CAN-C and CAN-IHS on FCA vehicles?

Two physical CAN networks with different speeds and purposes. CAN-C runs at 500 kbps and carries safety-critical powertrain and chassis ECUs — engine, transmission, ABS, ESP, steering angle. CAN-IHS (Interior High Speed) runs at 125 kbps and carries body and comfort ECUs — HVAC, doors, locks, lighting, radio, RKE, seats. They're physically separated; the TIPM/TIPMCGW bridges them.

How do I find an unknown message ID for a specific function?

Run candump to log baseline traffic for 30 seconds while idle, then trigger the function (press brake, flip headlights, open a door) and capture another 30 seconds. Diff the two logs — the message ID whose payload toggled in the triggered capture but not the baseline is your candidate. SavvyCAN's signal hunter view does this visually. Brake pedal is the easiest first target because it's a 100ms-cadence message with a clean 0-to-1 byte toggle.

Are these message IDs valid for any FCA vehicle?

No. FCA reassigns IDs aggressively between platforms — CAN-IHS messages on a 2008 Durango and a 2010 Wrangler are completely different. CAN-C content tends to be more stable across the lineup but is not guaranteed identical. Every ID on this page was verified on a specific platform (mostly JEEP); confirm on your own vehicle with candump before automating anything that writes back to the bus.

What's the role of the TIPM / TIPMCGW in CAN routing?

The TIPM bridges CAN-C and CAN-IHS, selectively forwarding messages between them. It's also where the central gateway function lives on platforms that have it. On 2018+ FCA vehicles the Secure Gateway Module (SGW) sits in front of the OBD-II port and acts as an additional firewall, but internal CAN traffic still flows through the TIPM. Direct access via the 13-way connectors behind the glovebox bypasses both.

Why are some IDs on this page marked unverified?

The candidate IDs section lists message IDs that have been documented in community reverse-engineering work (notably the JL Wrangler RE spreadsheet) but not personally verified on the platforms covered here. They're starting points for your own discovery work — fuel level, throttle position, TPMS, ambient temp, etc. — not authoritative facts. The HIGH/MEDIUM/LOW grouping reflects how stable each candidate tends to be across platforms.

[ Bus & Message Reference ]

Q: Why does the same message ID appear on both buses?

The TIPM (Totally Integrated Power Module) or TIPMCGW with central-gateway function selectively re-broadcasts certain messages across the CAN-C / CAN-IHS boundary so the same logical event — an unlock command, an ignition state change, a security trigger — can be seen by modules on either side. Payload size is a useful heuristic for origin: 1-byte payloads tend to be CAN-IHS native, 8-byte payloads CAN-C native.

← back to Car Hacking

Reverse-engineering reference for FCA / Stellantis CAN bus: bus topology (CAN-C vs CAN-IHS), TIPM/TIPMCGW gateway behavior, and decoded message IDs lifted from the scripts on the parent page with byte-level evidence — $1C0 RKE payloads, $122 ignition state, $350 RTC layout, UDS service path used by 3rd_brakelight.sh ($2D3 / $620 / DID $D1B3), and the full JEEP live-data message map extracted from pyJeepCan.py. Includes candidate IDs for fields commonly broadcast but not yet decoded here, plus the usual model/year caveats.

NOTE — platform specificity:  Most of the message IDs,
byte layouts, and decoded payloads documented here were captured on
JEEP-platform vehicles (Wrangler / Grand Cherokee / similar).
FCA / Stellantis reuses some IDs across its lineup (Chrysler, Dodge,
Ram, Alfa Romeo) but reassigns others aggressively between platforms
and model years — CAN-IHS content in particular varies a lot.

Treat every ID and byte offset on this page as a starting point for
your own candump verification, not a universal spec. The
Caveats section at the bottom has the longer
version of this disclaimer.

[ CAN-C vs CAN-IHS — bus topology ]

In Chrysler / Stellantis (FCA) architecture, two physical CAN networks serve
different purposes and run at different speeds:

CAN-C       (500 kbps) — high-speed powertrain / chassis bus. Carries engine,
            transmission, ABS, ESP, steering angle, and other safety-critical
            ECUs.

CAN-IHS     (125 kbps) — Interior High Speed body / comfort bus. Carries HVAC,
            doors, locks, lighting, radio, RKE (remote keyless entry), seats.

When the same message ID appears on both buses, payload size is a reliable
discriminator on JEEP platforms:

    1-byte payload  ⇒  CAN-IHS
    8-byte payload  ⇒  CAN-C

[ TIPM / TIPMCGW — the bus gateway ]

The TIPM (Totally Integrated Power Module), or TIPMCGW on platforms that include
the Central Gateway, sits between CAN-C and CAN-IHS. It processes and selectively
re-broadcasts messages across the boundary, so the same logical event — an
unlock command, an ignition state change, a security-system trigger — can be
observed on both buses even though it originated on only one of them.

This is why payload size is a useful heuristic for "where did this actually come
from" when the same ID shows up on both buses (see topology note above).

[ Message ID $1C0 — Remote Lock / Unlock (RKE) ]

$1C0  (0x1C0 / 448 decimal)

On the FCA CAN bus, $1C0 appears in the "Remote Lock / Unlock" message group
alongside $1C8 and $291. It is part of the Remote Keyless Entry (RKE) / body
control group — typically broadcast when a key fob lock/unlock command is
processed, originating from the Body Control Module (BCM) or the RF Hub /
Wireless Control Module.

Natural home is CAN-IHS, since locks and RKE are interior body functions. If
you observe $1C0 on CAN-C as well, that is almost certainly the TIPM/TIPMCGW
gateway re-broadcasting it for modules on that bus that need to react — e.g.
unlock-on-approach interactions with powertrain or security state.

New messages are sent every ~100 ms while the vehicle is awake; the payload
contains an ID byte representing the last fob command (or an idle-state ID
when no command was received). When the vehicle enters sleep mode, $1C0 stops
broadcasting until the vehicle wakes.

This is the same ID consumed by the Remote_WiFi.sh
script on the parent page — it sniffs $1C0 for fob-driven lock/unlock events
and uses the double-unlock sequence as a covert trigger for the Pi's WiFi radio.

Observed 6-byte payloads on the JEEP platform Remote_WiFi.sh was developed
against (byte 0 = command code, byte 3 = active/idle flag):

    1C0#21 00 00 90 00 00      Lock
    1C0#23 00 00 90 00 00      1st Unlock
    1C0#24 00 00 90 00 00      2nd Unlock     (double-tap)
    1C0#00 00 00 80 00 00      Idle           (no recent command)

Other bytes appear to carry fob ID / button-hold metadata but have not been
positively identified on this platform — see caveats below before assuming
this byte map holds for your year/model.

[ Message ID $122 — Ignition / virtual key state (CAN-IHS) ]

$122  (0x122 / 290 decimal)  —  CAN-IHS only

Broadcast every ~100 ms while the vehicle is awake; carries the virtual
ignition switch state (OFF / ACCESSORY / RUN / START). The vehicle stops
sending $122 entirely when it enters sleep mode — absence of $122 is the
sleep-state signal.

The Blackbox_monitor.sh script
treats the payload as a single big-endian integer and uses bit 26
(0x04000000) as the run-state flag:

    payload >= 0x04000000   ⇒  RUN / START   (engine running, ACC + RUN)
    payload <  0x04000000   ⇒  OFF / ACCESSORY

That bit-26 threshold is sufficient to drive on/off automation (start log
on RUN, terminate log on OFF). Finer-grained discrimination between OFF
vs ACCESSORY vs RUN vs START would require decoding the lower bytes —
not done in the script.

[ Message ID $350 — Vehicle clock / RTC ]

$350  (0x350 / 848 decimal)

Broadcast once per second on both CAN-C and CAN-IHS while the vehicle is
awake. Carries the dashboard clock as raw hex (NOT BCD), one field per byte:

    byte 0   seconds              (0x00..0x3B)
    byte 1   minutes              (0x00..0x3B)
    byte 2   hours                (0x00..0x17)
    bytes 3-4  year               (big-endian, e.g. 0x07E7 = 2023)
    byte 5   month                (0x01..0x0C)
    byte 6   day                  (0x01..0x1F)

A payload of all 0xFF means the clock has never been initialized (vehicle
disconnected from battery, or set-from-radio has not run). The
getVehicleTime.sh script uses this
as an error sentinel.

Because the message ID and payload format are stable across platforms (the
dashboard clock has to render somewhere), $350 is one of the more reliable
"is this bus even alive" probes during initial reverse-engineering.

[ UDS over CAN-C — service path used by 3rd_brakelight.sh ]

UDS (Unified Diagnostic Services, ISO 14229) rides on CAN-C with a
request/response framing completely different from the broadcast-style
messages above. Every request gets a positive or negative response from
the target ECU.

The 3rd_brakelight.sh script uses
the following sequence to toggle the cargo-area / 3rd brake light:

    1.  Wake the bus.                cansend can0 2D3#0700000000000000

    2.  Enter Extended Diagnostic    cansend can1 620#0210030000000000
        Session (Service 0x10,                     |  |  +- subfn 0x03
        sub-function 0x03).                        |  +---- service 0x10
                                                   +------- PCI len = 2

    3.  IOControlByIdentifier        cansend can1 620#052FD1B303010000
        (Service 0x2F), DID                        |  |    |  |  +-- state
        $D1B3 (3rd brake light),                   |  |    |  +----- control byte
        control 0x03 (short-term                   |  |    +-------- DID lo
        adjustment), state 0x01 (ON):              |  +------------- DID hi / svc
                                                   +---------------- PCI len = 5

    4.  Turn it OFF with state 0x00: cansend can1 620#052FD1B303000000

Notable:

  - $2D3 on the wake bus is a generic "wake" frame; not part of UDS itself.
  - $620 is the UDS REQUEST arbitration ID for this target ECU; the ECU's
    RESPONSE arrives on a different ID (typically request_id + 0x08, so $628).
  - Service 0x2F (IOControlByIdentifier) is your knob for forcing actuators
    via diagnostics. DID $D1B3 is the 3rd brake light DID on this platform —
    not portable.

Python alternative for UDS work: udsoncan
(referenced in 3rd_brakelight.sh's notes).

UDS over the OBD-II port specifically on 2018+ FCA vehicles is gated by the
Secure Gateway Module — see the
SGW / SGM reference for what gets
through unauthenticated and what doesn't. Direct CAN access via the
13-way connectors behind the glovebox is NOT gated by the SGW, which is
one of the main reasons that access point is useful for research work.

[ JEEP live-data message map (from pyJeepCan.py) ]

The pyJeepCan.py dashboard monitor
hard-codes the IDs, buses, and byte offsets below. Treat as a starting
catalog — verified against the script's target platform; YMMV elsewhere.

    ID       Bus       Field           Bytes   Decode
    -----    -------   -------------   -----   ----------------------------
    $02B     CAN-C     Roll            0-1     (hi<<8|lo) - 2048, /10
                       Tilt            2-3     same
                       Yaw             4-5     same
    $023     CAN-C     Steer Angle     0-1     (hi<<8|lo) - 0x1000
                       Steer Rate      2-3     same
    $093     CAN-C     Gear (PRNDL)    2       0x50=P 0x52=R 0x4E=N 0x44=D
                                               0x31..0x38 = "1".."8" (mt)
    $127     CAN-C     IAT             0       (byte - 40), °C→°F
                       Coolant temp    1       same
    $128     CAN-C     PS Temp         1       (byte * 9/5) + 32 → °F
                       PS PSI          2       byte * 4 * 0.145038
    $13D     CAN-C     Oil Pressure    2       byte * 4 * 0.145038
                       Oil Temp        3       (byte - 40), °C→°F
    $277     CAN-C     Transfer case   0       0x00=4x2H 0x10=4x4H 0x40=4x4L
                                               0x02/0x20=N 0x80=Shifting
    $2C2     CAN-IHS   Battery V       2       byte / 10  (volts)
    $322     CAN-IHS   RPM             0-1     hi<<8 | lo  (0xFFFF = engine off)
                       Speed (MPH)     2-3     ((hi<<8|lo) / 200), 1 decimal

Offsets and constants in the table are the script's; bytes are 0-indexed
from the start of the 8-byte CAN payload. Bus assignments are the script's
hard-coded canIHS / canC labels (vcan0 / vcan1 in the test harness).

[ Candidate IDs — useful next-additions (UNVERIFIED) ]

Common fields broadcast on FCA / Stellantis CAN that pyJeepCan.py does
NOT yet decode, with candidate message IDs from community RE work
(notably the JL Wrangler reverse-engineering spreadsheet). Treat the
specific IDs as starting points — they vary by model year and
platform, sometimes drastically. Confirm with candump on your own
vehicle before wiring any of these into automation.

    Confidence: HIGH (commonly broadcast on every modern FCA platform,
                      IDs vary)
    -----------------------------------------------------------------
    Field              Likely Bus   Typical decode
    ---------------    ----------   --------------------------
    Fuel level %       CAN-IHS      byte / 2.55  (0..100%)
    Outside temp       CAN-IHS      (byte / 2) - 40  (deg C)
    Throttle position  CAN-C        byte / 2.55  (0..100%)
    Brake switch       CAN-IHS      single bit flag
    Cruise set speed   CAN-IHS      raw byte = MPH
    TPMS (4 tires)     CAN-IHS      byte / 4 per tire = PSI
    Odometer           CAN-IHS      32-bit big-endian, units 0.1 mi


    Confidence: MEDIUM (well-documented on JL Wrangler, may apply to
                        Grand Cherokee / Ram / Durango / similar)
    -----------------------------------------------------------------
    ID       Likely bus   Field                Notes
    $308     CAN-IHS      Fuel level           1 byte payload
    $3DA     CAN-IHS      Fuel level (alt)     alternate on some years
    $29C     CAN-IHS      Outside ambient      byte 0 or 1, deg C + offset
    $129     CAN-C        Throttle position    byte 2 or 3, near IAT msg
    $14A     CAN-C        Throttle (alt)       alternate on some years
    $371     CAN-IHS      TPMS pressures       4 bytes: FL FR RL RR
    $2D0     CAN-IHS      Cruise control       byte 0 = set spd, b3 flags
    $2A8     CAN-IHS      Door states          bit-packed, 1 = open
    $2FA     CAN-IHS      Window position      byte per window 0..255
    $214     CAN-IHS      Headlight / turn     bit flags in lighting msg
    $2FB     CAN-IHS      Wiper state          bit flag in lighting msg
    $3F1     CAN-IHS      HVAC fan speed       byte 0..7
    $3F4     CAN-IHS      HVAC mode (alt)      alternate on some years
    $1F1     CAN-IHS      Seatbelts            bit flag per seat
    $3E0     CAN-IHS      Odometer             4 bytes BE, units 0.1 mi
    $416     CAN-IHS      Odometer (alt)       alternate on some years


    Confidence: LOW (observed in some captures, very platform/year
                     dependent — treat as research leads, not facts)
    -----------------------------------------------------------------
    - Charging voltage / alternator output (separate from battery V
      on some platforms, often in ID adjacent to $2C2)
    - Fuel injector pulse width / fuel rail pressure (diesel mostly)
    - MAF / MAP sensor (sometimes broadcast for dashboard gauges)
    - Wideband lambda / O2 (usually UDS-only, not broadcast)
    - Compass heading (derived from steering+accel+GPS, CAN-IHS)
    - GPS coordinates (Uconnect-equipped only, often encrypted)


How to discover unknown signals on YOUR vehicle:

    1.  candump -L can0,can1 any > baseline.log     # 30s idle
    2.  trigger the thing  (press brake, flip lights, open door)
    3.  candump -L can0,can1 any > triggered.log    # 30s during

    Diff the message IDs whose byte patterns changed in step 3 but
    not in step 1. The ID with newly-toggled bytes is your candidate.
    SavvyCAN's "signal hunter" view does this visually if you prefer
    a GUI over diff.

Brake pedal is the easiest first target — flip the pedal on/off
and watch which byte in a 100 ms-cadence message toggles 0/1.

[ Caveats — before you trust any of these IDs ]

A few things to keep in mind before committing to an interpretation of any
FCA message ID, $1C0 included:

1.  Model / year variance is huge.  FCA has reassigned IDs between platforms.
    CAN-IHS messages on a 2008 Durango and a 2010 Wrangler are completely
    different, even when CAN-C content is mostly consistent. So $1C0 on a
    2014 Grand Cherokee may not mean what it means on a 2020 Wrangler JL.
    Always confirm on your own vehicle before automating anything destructive.

2.  Payload structure is not fully documented.  Which byte represents
    lock vs unlock vs trunk vs panic, which carries the key fob ID, which
    holds the button-hold flag — most of that is community reverse-engineering
    work (notably the JL Wrangler RE spreadsheet maintained by the forum
    community), not a published spec.

3.  None of this is an official FCA / Stellantis specification.  Stellantis
    does not publish their DBC files. Everything here is community RE.
    The authoritative reference for any given vehicle would be FCA wiTECH
    service information or a purchased / leaked DBC for that exact platform.

When in doubt: log first, act later. candump on a stationary vehicle, replay
fob actions one at a time, and confirm the ID and payload behavior on YOUR
platform before wiring any of it into automation.