JEEP HACKING CAN-C / CAN-IHS / UDS ! (Reverse Engineering)

[redracer]

I have not been paying attention to this site since we where chatting on the other thread. Sorry. But, oh man! You have been rocking it. Way to go on making progress!

As for the dual can adapter, I was able to get mine running on both busses at the same time. I had both can0 and can1 online, and was able to monitor either interface. ... Now that I think about it, I'm not 100% sure if I did both concurrently on two separate ssh sessions.

I wonder if you just got a can hat with a bad interface chip.

Sponsored

 

[jmccorm]

As for the dual can adapter, I was able to get mine running on both busses at the same time. I had both can0 and can1 online, and was able to monitor either interface. ... Now that I think about it, I'm not 100% sure if I did both concurrently on two separate ssh sessions.

I wonder if you just got a can hat with a bad interface chip.

If you could let me know which PI you used, and which version of Raspbian, it'd make a good starting point for me to debug further. You and I suspected the same thing, it seems. A bad chip on the CAN HAT. I went as far as purchasing a second only, but was disappointed to find that it acted the same way.

So it doesn't matter which of the two networks (CAN-C, CAN-IHS) I have plugged into CAN1 and it doesn't matter if CAN0 is in use or not. CAN1 just doesn't see any traffic. Odd, isn't it?

 

[redracer]

If you could let me know which PI you used, and which version of Raspbian, it'd make a good starting point for me to debug further. You and I suspected the same thing, it seems. A bad chip on the CAN HAT. I went as far as purchasing a second only, but was disappointed to find that it acted the same way.

So it doesn't matter which of the two networks (CAN-C, CAN-IHS) I have plugged into CAN1 and it doesn't matter if CAN0 is in use or not. CAN1 just doesn't see any traffic. Odd, isn't it?

I was using a Pi Zero W with Buster light.

 

[jmccorm]

UPDATE --

I've spent a couple of days trying to figure out the Raspberry Pi / Waveshare CAN HAT problem that prevents both the CAN-C and CAN-IHS bus connections from operating at the same time.

To simplify the problem, it looks like the first CAN device that gets defined is the one that works, and the second device gets defined but doesn't see any traffic.

I've used various commands to verify I've got the right interrupts and the right chip select lines, and that they work, and that the right CAN cables are plugged into the right terminals, and so much more. I've even upgraded to the latest Bullseye release of Raspbian. No help there, either.​

At best, I've been able to simplify it so where the CAN-IHS network is active on can0 (and can1 will be present but will not work) if /boot/config.txt contains the following:

dtparam=spi=on
dtoverlay=mcp2515,spi0-0,speed=20000000,interrupt=25
dtoverlay=mcp2515,spi0-1,speed=20000000,interrupt=23

Alternatively, I can configure it so where the CAN-C network is active on can1 (and can0 will be present but will not work) if /boot/config.txt contains the following:

dtparam=spi=on
dtoverlay=mcp2515,spi0-0,speed=20000000,interrupt=23
dtoverlay=mcp2515,spi0-1,speed=20000000,interrupt=25

The information above suggests, to me at least, that the board has a hardware problem. Both CAN devices are (contrary to published design) sharing interrupt 25. If so, it is possible for them to still individually function because they still retain their own unique Chip Select (CS) lines. Whichever one is the first to be assigned interrupt 25 is the one that actually works. The kernel rejects all subsequent attempts to claim that interrupt line.

This setback really is costing me a lot of time that's better spent on reverse engineering the JL Wrangler's CAN networks.

CHANGE OF PROJECT FOCUS --

I've decided it's unlikely for me to want to make a commercial project out of this. The final form is still uncertain, but I'm aiming for something along the lines of a public project. My aim would be to pave the path with some unique new features while at the same time providing information which helps those who want to make a similar journey of their own.

People are constantly modding the hardware of their Jeep to add more capabilities. Why not modify out Jeeps with software? Why not BOTH?

 

[jmccorm]

I recently came across a few interesting topics:

Discussion of FCA's Secure Gateway Module - It talks about the specific event that the Secure Gateway Module was a reaction to, it's intended purpose, and the ability to remove and work around it (if you can't get a real-time authorization through FCA's servers). I stumbled across an article which covers this same topic, but from a slightly different angle.

TTCAN (Time-triggered CAN) - I've tracked any number of CAN message which fire off like clockwork (like with the ambient temperature reading updates every second), and other CAN messages that only trigger on specific events (like codes from using the remote keyfob buttons). They're very well coordinated and they're using something beyond the CAN protocol to do it. I think it might be this TTCAN protocol. I see that the CANopen protocol goes several steps further, but I can't find anything that makes me think the Wrangler is using that.

CAN 2.0A / 2.0B - Us nerds would call this a CSMA/CR (Carrier Sense Multiple Access with Collision Resolution) network protocol. There are tons of documents out there on everything from a basic introduction to vendor CAN controller documentation to the specifics of modern-day vehicle wiring. I'll try to summarize the important parts:

CAN is a broadcast network. (Everyone can always see every message.). Messages have an ID and a payload (1 to 8 bytes long). Members automatically synchronize and prioritize the next message using "bit dominance" which allows the module with the lowest message ID to "win" and transmit it's message right away. If all members are following protocol, it actually prevents two senders from talking over each other.​

​

Messages are physically transmitted across a pair of two twisted wires which are always send opposite signals from each other. Us nerds call it differential signaling). When one wire transmits a signal, the other wire doesn't. When one wire stops transmitting, the other wire starts transmitting. These simple mechanisms make for a really strong signal that's immune to many common forms of interference (cut wire, grounded wire, cell phone interference, etc). A notable exception would be that which is caused by corroding terminals. (Even if you have a snorkel, try to keep your Wrangler dry behind the glovebox.)​

​

When any module uses those wires to send a message, they do not have to identify who they are. Instead, they provide an ID number which identifies what kind of information they're sending. As an example, a module might suddenly transmit ID 122 with the numbers 00 01 00 00. Your radio, your dash, your gear shifter, and all the other modules which care to do something with ID 122 will learn that they vehicle's ignition switch (that push-button switch) is in the "off" state. None of them have to ask because the steering column control module will broadcasts every second the latest status of the vehicle ignition with message ID 122. Should the position of the ignition switch change, it won't want that full second before sending it's update. Because it could be important to update that information quickly, it'll send another update right away whenever it's status has changed.​

​

Finally, there is another feature in the CAN network where any module can actively ask the "owner" of a specific message ID to send a new message with their latest update. If you're creating a electronic dash, you don't want to rely on that every half second or so to keep asking "What's the tachometer at? How fast are we going now? What's my odometer?". So far, it looks like Jeep elected not to follow that specification. It's probably a better practice that they don't.​

That's all I got for now. I'm still fighting that issue with the two-channel CAN module. I've gotten a response from Waveshare and they're taking a look at it. I might try downgrading to a Raspberry Pi 2B or 3 and seeing if that helps the issue any. Short of that, it may just be time for me to put these Waveshare modules away and try PiCAN or one of the other CAN HAT vendors.

EDIT TO ADD:

I'm still reading up on TTCAN and I strongly believe that this variant is what's used on the Wrangler. (If not, I've come up with the FlexRay and TTP as similar time-triggered networks worth investigating.) Based on TTCAN, on the CAN-C bus, the time masters would likely have IDs 400, 401, 402, 403, 407, and *maybe* 409. On the CAN-IHS bus, that would be IDs 401 and 403.

These time-triggered networks (operating on top of a CAN network) may explain even more why JScan and Tazer have so much trouble with retransmits. CAN normally lets transmitting participants determine for themselves (in a method that's based upon the IDs used by the transmitting nodes) who gets priority and transmits. On TTCAN, I think JScan and Tazer may not know that CAN negotiations only happen some of the time, potentially messing up the message of the module that was originally authorized to transmit, re-queuing their own failed messages for retransmission, and then retransmiting the message yet again (and just as likely, at the start of yet another time window that they're not permitted to transmit in).

It's against spec to be transmitting in a valid CAN window while transmitting in an invalid TTCAN window. The upside here is that 100% available windows and lesser available windows (subject to a limited number of CAN negotiation attempts), are both at pre-regular times which are pre-determined. There's no need for guessing. Both tools have the potential of significantly increasing the reliability and perhaps even the speed in which they send information to the vehicle. It'd just be time-consuming to program and test for it.

 

[jmccorm]

That's all I got for now. I'm still fighting that issue with the two-channel CAN module. I might try downgrading to a Raspberry Pi 2B or 3 and seeing if that helps the issue any.

Finally! I've tapped into my Wrangler's CAN-C & IHS networks!

  can0  2E0   [8]  00 00 00 FF FE FE FE FE
  can1  023   [8]  10 02 10 00 00 00 A4 04
  can1  02F   [8]  00 00 00 00 01 1A 7A 00
  can1  26F   [8]  00 C0 28 1A 2C 7F 7F 00
  can1  023   [8]  10 02 10 00 00 00 B4 C9
  can0  3A2   [6]  00 00 02 01 FF 00
  can0  22D   [8]  FF 06 00 00 00 00 00 00
  can1  02F   [8]  00 00 00 00 01 1A 7A 00
  can1  071   [8]  1F FF 00 00 5E 00 00 97
  can1  31A   [8]  00 00 00 00 00 00 00 00
  can1  0AD   [5]  01 00 00 40 D7
  can0  358   [4]  FF 01 FF 00
  can0  413   [8]  FD 3C 3F FF FF FF FF FF

I swapped out the Raspberry Pi 4 for a Raspberry Pi 3B. That did the trick! I'm on my way to doing a little more reverse engineering and then finally getting down to making some cool software mods for the Wrangler!

As time permits, feel free to join in with your own efforts!
Regardless, I'll still be documenting my efforts.

 

[jmccorm]

Want to try your hand at reverse engineering, but don't want to take apart your glovebox and hook your vehicle up to a Raspberry Pi? I got you covered. A dump of all CAN traffic (ASCII format) covering a 7 minute and 17 second drive.

Here's my own interpretation, based off of 10 decoded CAN IDs:

323067.322198 KEY: Run RPM: 1.7k STEER: +0.210 HEADING: N GEAR: DRIVE 1 MPH: 6 ODOMETER: 6958.8m HOOD1: 92 F LAPBELT: 00​

323067.822247 KEY: Run RPM: 1.7k STEER: +0.440 HEADING: N GEAR: DRIVE 1 MPH: 7 ODOMETER: 6958.8m HOOD1: 92 F LAPBELT: 00​

323067.843358 KEY: Run RPM: 1.7k STEER: +0.450 HEADING: N GEAR: DRIVE 1 MPH: 7 ODOMETER: 6958.8m HOOD1: 92 F LAPBELT: 00​

323068.322315 KEY: Run RPM: 2.0k STEER: +0.540 HEADING: N GEAR: DRIVE 1 MPH: 8 ODOMETER: 6958.8m HOOD1: 92 F LAPBELT: 00​

323068.823292 KEY: Run RPM: 2.2k STEER: +0.610 HEADING: N GEAR: DRIVE 1 MPH: 9 ODOMETER: 6958.8m HOOD1: 92 F LAPBELT: 00​

323068.843395 KEY: Run RPM: 2.2k STEER: +0.610 HEADING: N GEAR: DRIVE 1 MPH: 9 ODOMETER: 6958.8m HOOD1: 92 F LAPBELT: 00​

323069.191479 KEY: Run RPM: 2.4k STEER: +0.580 HEADING: N GEAR: DRIVE 2 MPH: 9 ODOMETER: 6958.8m HOOD1: 92 F LAPBELT: 00​

323069.322297 KEY: Run RPM: 2.5k STEER: +0.560 HEADING: N GEAR: DRIVE 2 MPH: 10 ODOMETER: 6958.8m HOOD1: 92 F LAPBELT: 00​

323069.822313 KEY: Run RPM: 3.0k STEER: +0.370 HEADING: N GEAR: DRIVE 2 MPH: 12 ODOMETER: 6958.8m HOOD1: 92 F LAPBELT: 00​

323069.843836 KEY: Run RPM: 3.0k STEER: +0.360 HEADING: N GEAR: DRIVE 2 MPH: 12 ODOMETER: 6958.8m HOOD1: 92 F LAPBELT: 00​

323070.322468 KEY: Run RPM: 2.3k STEER: +0.160 HEADING: NE GEAR: DRIVE 2 MPH: 14 ODOMETER: 6958.8m HOOD1: 92 F LAPBELT: 00​

323070.823330 KEY: Run RPM: 2.6k STEER: +0.050 HEADING: NE GEAR: DRIVE 2 MPH: 17 ODOMETER: 6958.8m HOOD1: 92 F LAPBELT: 00​

323070.843511 KEY: Run RPM: 2.6k STEER: +0.040 HEADING: NE GEAR: DRIVE 2 MPH: 17 ODOMETER: 6958.8m HOOD1: 92 F LAPBELT: 00​

323071.322456 KEY: Run RPM: 3.0k STEER: -0.000 HEADING: E GEAR: DRIVE 2 MPH: 21 ODOMETER: 6958.8m HOOD1: 92 F LAPBELT: 00​

323071.822479 KEY: Run RPM: 3.5k STEER: -0.010 HEADING: E GEAR: DRIVE 2 MPH: 24 ODOMETER: 6958.8m HOOD1: 92 F LAPBELT: 00​

An example from the live and complete record of CAN data during the drive:

(1638323019.362674) can1 1CE#2B00300B R​

(1638323019.362919) can1 2F2#0000000000000000 R​

(1638323019.363161) can1 407#FD09040FE1FFFF00 R​

(1638323019.363508) can1 025#0000077C07D410D5 R​

(1638323019.364220) can1 037#1FFE000010687024 R​

(1638323019.364488) can1 09D#00FFFFFF000090A1 R​

(1638323019.364598) can0 12B#06 R​

(1638323019.365239) can1 0AB#00000D0D0000B081 R​

(1638323019.365482) can1 027#89A507D4000010E3 R​

(1638323019.365593) can0 328#2001004900430020 R​

A quick description of the recorded experience:

Remotely started vehicle, opened the door, sat in the driver's seat and clicked my seatbelt by time index 323041. Music was playing on the radio. I pulled forward and then exited my driveway to the right. Almost a mile later, I turned right at an intersection. Short of a mile later, I turned right at an intersection and took an onramp to an expressway. I exited again less than a mile later and turned right. I drove a mile, turned right again at an intersection, and two blocks later I made a turn to the right, finishing the journey where I had begun. Placed the vehicle in park, turned off the vehicle, removed my seatbelt, and exited the vehicle.

File "4mi-loop.zip" contains two files:
summary-2021-11-30_194339-4mi-loop.log (104K)
candump-2021-11-30_194339-4mi-loop.log (47M)

PS:
Please let me know privately if you happen to stumble across any sensitive data, like mobile device numbers, keyfob encryption keys, etc.

 

[jmccorm]

Today I believe I have a better high-level understanding of the Secure Gateway Module, it's purpose, and it's relationship with the OBD-II port (what Jeep calls the DLC, or Data Link Link Connector) as well as it's relationship with the uConnect radio.

At the bottom of this message, I've included a diagram of the DLC connector (including pinouts) as well as both connectors to the Secure Gateway module. But the what I really want to reference is one of the Wrangler's wiring diagrams.

Below I have pasted a portion of the CAN-C bus wiring diagram. (For our purposes, we can assume that the CAN-IHS bus is wired in a similar manner, so I've not included it.)

The Secure Gateway Module (SGM) receives an ordinary connection to the vehicle's main CAN-C and CAN-IHS bus. What the SGM does is it stands between the radio and the reset of the vehicle. Separately, it also stands between the OBD-II port and the rest of the vehicle. It acts as two separate firewalls with two different sets of rules, designed to limit and protect access to the CAN network.

The Secure Gateway Module allows third-party OBD-II tools to listen in on everything that's happening on the vehicle's two major buses. But when these OBD-II tools try to write to the CAN-C and CAN-IHS bus (for example, they might send a command to bleed the brakes), it prevents it. Not unless they authenticate themselves in a special way that Jeep built into the system. Obviously, some vehicle technicians have questioned if this might be a little self-serving of Jeep, requiring some third-party tools to seek authorization from Jeep to fully function on their vehicles.

At the dealership, when your vehicle is being serviced, a tech will make a connection to the OBD-II port. Aside from being able to read parameters from your vehicle, this can also allow Jeep (corporate) to send a special message to your Secure Gateway Module, authorizing the technician's tool to have read and write access to the vehicle's CAN-C and CAN-IHS bus for a limited time.

I suspect (but have not yet validated) that something different is happening with the Secure Gateway's Module's connection to the radio module.

The uConnect radio normally IS allowed to write certain configuration changes to the CAN bus (where it is stored and relayed by a separate module). For example, when you select the setting on the uConnect touch-screen which enables a horn honk when remote-locking your vehicle, the uConnect radio broadcasts that configuration change to another CAN module where it is permanently stored and made available to other modules. But there are certain other messages that your radio should never be sending (for example, a message that contains the angle of the steering wheel, or the current engine RPMs).

Pre-approved messages on a whitelist ARE allowed. Anything that isn't pre-approved is filtered out. And this is to maintain the security of your vehicle in case the uConnect radio gets hacked (via it's own cellular conection, or via the USB ports, for example). Theoretically, it may be possible for Jeep (corporate) to use the uConnect radio to remotely flash updates individual components on your vehicle (like the transmission). I don't know for certain if the provisioned this capability in the Secure Gateway Module or not, or if they've taken advantage of this in the past or not.

Back to the Secure Gateway Module, when an owner replaces it with a bypass cable (or a Tazer), it does two things. First, it makes full access to your vehicle's CAN networks available via the OBD-II port. Any tool that plugs into the OBD-II port now has full CAN access. I imagine that Jeep wanted to prevent this, as it wouldn't be too difficult for a third party to create a small inexpensive OBD-II plugin that sends a few signals in a matter of seconds, and once it is removed, it will have silently made changes to your vehicle's configuration that completely disables it (or worse).

Second, it gives full CAN access to your uConnect radio. Not too long ago, students of cyber security at the University of Tulsa hacked the uConnect radio of an FCA vehicle, giving them remote access to the vehicle's bus (over the vehicle's own built-in cellular connection), allowing them to do things on command, such as completely preventing the brakes from working. In short, the Secure Gateway Module makes it harder for your vehicle to be hacked, and and it makes it harder for your vehicle to be monitored or operated remotely.

So this explains why a Secure Gateway bypass cable is needed for a tool like JScan (which connects to the OBD-II port) to be able to make configuration changes and to perform some of it's adaptation functions. The cable gives it direct access to both CAN networks, and not the filtered read-only access that comes from the factory.

In the case of the Tazer (which replaces the Secure Gateway entirely), this gives it Tazer itself direct access to both CAN networks. Although that position makes it possible for it to maintain separate connections to the uConnect radio and the OBD-II ports, most likely it simply bridges all three connections together, giving itself and everything else full access to the vehicle's CAN networks.

Originally, I had a theory that the Tazer performs some operations by intercepting the signals and modifying them in-flight. When I can, I try to support or refute any theories I've developed (and shared) along the way. While that's possible, that's not what's going on here. That theory is wrong.

I now know that the Tazer performs makes many of it's configuration changes by writing them to specific BUS IDs where the vehicle ordinarily stores them. I have yet to see how certain operations like the Light Show are done, but during that time, I happened to see CAN messages with IDs in the 4Cx, 5xx, and 7xx ranges, which typically aren't seen.

The part of the vehicle I've chosen to focus on is behind the glovebox, which offers direct access to two of the vehicle's 13-way CAN bus connectors. There's still plenty of space for my components, and anything too large can still be placed in the glovebox itself.

Numerous items already plugged into some of the ports, but there are still a number of open ports available, any one of which can provide the access necessary for my own tools. An advantage worth noting is that any one of these open ports can be used without disrupting any of the other existing third-party tools like JScan and the Tazer.

This final benefit of this area is that it also gives us the potential to isolate any of the the major components which plug into the 13-way bus connector. Once isolated, any of those modules can be listened to (or have their signals intercepted and modified) on an individual basis. While those opportunities aren't my immediate area of interest, it's clear to me that they have the potential to create new possibilities that we haven't seen before.

The major downside? While it is a little less convenient to access than the OBD-II connector., it's major problem appears to be that there's no direct source of power in the immediate area. (If I'm overlooking something, please, add what you know!) Power might be routed over through the center console or through the engine bay, but there doesn't seem to be major 12v feeds to tap into.

So, I hope this information helps someone along the way when they go to look at the OBD-II port, Secure Gateway Module, or one of the CAN bus connections as their source for vehicle connectivity. I've typed quite a bit here, so I might have made a mistake or two along the way. If so, let me know.

For completeness, here are diagrams of the OBD-II and Secure Gateway Module connectors, with labels for each pin. Where you see a "DIAGNOSTIC CAN C" or "DIAGNOSTIC CAN IHS" bus, those are the the filtered bus lines for the OBD-II connector. Where you see "CAN C AT" and "CAN IHS AT", those are filtered bus lines for the radio module. (Maybe someone else knows what AT stands for?)

If you've read this far, wow, you must be interested! Thanks, and any comments are welcome.

 

[jmccorm]

PROVEN CONFIG.TXT PARAMETERS FOR THE RASPBERRY PI WITH THE INEXPENSIVE 2-CHANNEL WAVESHARE CAN HAT:

dtparam=spi=on​

# CAN0 - CAN-IHS 125kbps passenger network​

dtoverlay=mcp2515,spi0-0,spimaxfrequency=2000000,interrupt=23​

# CAN1 - CAN-C 500kbps critical automotive network​

dtoverlay=mcp2515,spi0-1,spimaxfrequency=2000000,interrupt=25​

dtoverlay=spi0-2cs​

DEVICE INITIALIZATION COMMANDS:

ip link set can0 type can \​

bitrate 125000 listen-only on triple-sampling on​

ifconfig can0 up​

ip link set can1 type can \​

bitrate 500000 listen-only on triple-sampling on​

ifconfig can1 up​

ifconfig can0 txqueuelen 65536​

ifconfig can1 txqueuelen 65536​

NOTES FOR FIRST-TIME USERS:

can0 vs can1: When using the Waveshare adapter, you may have physically wired the CAN-IHS network into the can0 terminal, but inside of Raspbian, it may be given a can0 or a can1 identifier. For this reason, you may find it useful to successfully configure just the CAN-IHS adapters before moving on to using both adapters. (If you want to standardize with my configuration, wire it up so that CAN-IHS is given the can0 identifier inside the OS, and CAN-C is given the can1 identifier. In some circumstances, yes, the labels printed on the card itself will end up backwards. As long as the device labels in the OS are correctly ordered, that's okay.)

terminating resistors: When connecting to the Wrangler, you do not need to add a terminating resistor (the Waveshare CAN HAT has a pair of jumpers which performs this function). Behind the glovebox, both of the 13-way CAN bus connectors are self-terminating. That is, built into the bottom of every slot in the 13-way connector is it's own terminating resistor. You do not need to add your own.

broadcast protocol: CAN is a broadcast protocol where every message is sent to all other participants, all of which may be free to ignore or use that information as they see fit. Instead of your dash asking the vehicle's various components for the information it needs (how fast are we going? is my turn signal on?), it waits for those devices to send a regular status update with that information. Anything it receives that it isn't programmed to use is ignored.

sleeping CAN bus: While the vehicle is off, you shouldn't expect to see any activity on either CAN bus. To wake it up, put the vehicle into accessory or run mode, or start the engine. As an alternative, you can partially wake up the CAN-C and CAN-IHS bus by hitting the lock/unlock buttons on your keyfob. Some (but by no means all) CAN IDs will report in for a short time before the vehicle goes back to sleep once again. UPDATE (DEC 2021): You can also wake up a CAN bus by sending *any* message. I use one of the console button IDs but with an empty bitmap that shows no buttons pressed.

SIDE NOTE: If you vehicle is not going to sleep, something is wrong and you need to investigate why. Modules remaining active while the vehicle is off will continuously drain your battery, eventually causing it not to start. You'll end up with a dead battery.​

message IDs: A message ID is accompanied by one to eight bytes of data. The message ID is the key which tells you what it's accompanying data contains, and how that data is encoded. (This is exactly what we're trying to reverse engineer!) Although it is technically possible for any module on the bus to transmit any message using any ID it wants, in practice, a single module will only transmit messages using a handful of pre-determined IDs, and it will be the exclusive source for those messages. While one ID may have only one sender, every other module will be a receiver. Of those, only a few modules might put that information to use.

Example: Only the Transmission Control Module (TCM) will send messages with an ID of 340, which provides the current speed of the vehicle. But when that message is received by the dash, radio, brakes, collision avoidance system, occupant restraint controller (airbags), and all the other modules, they each can make use of the message (or discard it) as they see fit.​

missing and ignored messages: Some CAN IDs will not be broadcast unless the vehicle's engine is running. This is particularly true for many IDs on the CAN-C bus. You should also be aware that while the CAN protocol supports a "request message" (where you ask the owner of a message ID to immediately report back with its status), to the best of my knowledge, no module responds to the CAN request function. It is not used on the Wrangler.

CAN-C vs CAN-IHS: In general, the CAN-C bus is used to transmit messages that are critical to the operation of the vehicle, and CAN-IHS is used to transmit messages for human comfort or interaction. As with anything, there are exceptions. You will also find that some messages will be broadcast on both the CAN-C and CAN-IHS bus. Finally, you may discover that both the CAN-C and CAN-IHS contain messages with an ID of 12B, but that the content of the messages are completely different. This is something you can use to verify which network adapter is on which CAN network. If the message is one byte long, it's on CAN-IHS. If the message is eight bytes long, it's on CAN-C.

time driven vs event driven messages: Some messages are automatically broadcast on a regular basis (time driven). Every second, every half second, tenth of a second, all the way down to messages which repeat every hundredth of a second. There are other messages that are transmitted when a module has something interesting to share (event driven).

bitmaps, binary, hexadecimal, nibbles, bytes, and words: Knowledge of binary and hexadecimal numerical formats is helpful, although not absolutely required. It can be helpful to have a conversion tool handy at times (Windows calculator will do if you go into the upper-left and set into "programmer" mode). Understanding hexadecimal can help you to quickly understand if you're looking at a bitmap (a series of binary switches), a numerical representation (a number that floats up and down, like a temperature), or a counter (a number which never decreases, like an odometer).

Using bindechexascii to convert numbers: In Raspbian, there is a utility called bindechexascii which can be installed using the command "apt-get install bindechexascii". Once installed, you can consult it's man page for information on how to use it's many functions. As an example, if you want to convert a string of bytes from hexadecimal to ordinary decimal numbers:​

​

# bindechexascii --h2d 0A 43 21 fe 11​

Hexadecimal to Decimal: 10 67 33 254 17​

​

UPDATE (DECEMBER 2021): printf may be a better way of converting numbers. For example:​

value="0F"​

value=$( printf "%d" 0x$value )​

echo $value​

reports from partially offline sensors: Many sensors will report one number while the vehicle is off (FF or FFFF is common, otherwise 00 and 0000), and then report their actual value when the vehicle's ignition is in run mode. Keep this in mind as you are working with the data.

units of measure: An open mind is helpful when considering what units the vehicle may be reporting with. Messages with IDs 300-3FF are typically believed to report using the units you (the driver) have selected in the Settings, and application found in the uConnect radio. There will be exceptions, such as ID 3D2 (Odometer), which reports mileage in tenths of a kilometer. Outside the $3xx range, resist making assumptions, but looking for metric units may be helpful.

interface statistics and error rates: In Raspbian, if you want to check an interface to see if it is successfully receiving traffic, you'll want to use the "ifconfig" command and look for the can0 and can1 sections. Keep an eye on the number of "RX packets" and compare those with the "RX errors". Your error rate should be well under 1%. If not, something may be wrong and you'll want to address this issue before you unlock your ability to send messages. Why? A CAN module which is allowed to transmit is also allowed to send error reports. If your module is seeing excessive errors, those errors will be shared across the entire network, so you'll want to keep your error rate low. Even more detailed information can be found by running "ip -details -statistics link show".

exiting listen-only mode: You can unlock your ability to send messages by removing the string "listen-only on" in your initialization commands. As mentioned earlier, make sure you've addressed any significant error rate before doing so. If you are familiar with the practice of futzing (sending semi-random messages with random IDs), you're strongly advised to avoid that practice as it can have unpredictable and damaging effects to your vehicle.

automating your CAN bus configuration: Once your configuration is stable, you can automate the configuration commands by placing them in the /etc/network/interfaces.d directory with a filename of "can0" or "can1" Sample content for can0 (CAN-IHS bus) might be:

auto can0​

iface can0 can static​

bitrate 125000 listen-only off triple-sampling on​

post-up /sbin/ifconfig can0 txqueuelen 65536​

CAN vs TTCAN: While the Wrangler's CAN-C and CAN-IHS buses are CAN compliant, they appear to be using a more complex variant known as TTCAN (Time Triggered Controller Area Network). In TTCAN, the majority of time units are reserved a specific individual message ID (and only that ID) to be sent. There are a few time-slots (limited in length) where event-driven IDs can compete using normal CAN arbitration. Because the devices we are using are not TTCAN compliant (and even if they were, they do not contain the Wrangler's TTCAN's scheduling matrix), any message that we transmit may potentially collide with another device's exclusive time slot. The other device does not expect to be interrupted and makes no provisions for re-transmission. See illustration.

BULK TRANSMISSIONS WITH CAN DEVICES: Where possible, bulk transmissions should be avoided. More so on the CAN-C bus than the CAN-IHS bus (which is more event driven). Where bulk transmissions cannot be avoided, the timing of each message should be irregularly staggered. For the more advanced user who has configured an automatic re-transmission interval for failed messages, they should avoid using common intervals (.01 seconds, .1 seconds, .2 seconds, .5 seconds, 1 second, etc) as they are more likely to collide with the same message, over and over.​

​

TTCAN Controller: The TTCAN Controller is responsible for coordinating activity on the CAN bus. As part of it's duties, it sends the reference message (shown above) from which all other modules coordinate their timing. Although the Wrangler appears to have multiple TTCAN controllers (for redundancy), as of this writing, I believe that the primary TTCAN Controller is represented by ID 400.​

​

Getting started: If you're just getting started, you can behave as if the Wrangler has an ordinary CAN network. Just be aware of TTCAN, and know that it's importance may grow as your knowledge and skill advances.​

some changes don't last: If you transmit a message, sometimes you may find its effects to be permanent, while at other times they may only last for less than a second. This is because most modules transmit regular updates every fraction of a second, so the effects of any changed values you transmit may be undone when the real module you're impersonating sends its next regularly timed update. If this is the case, you may need to find a better way of achieving the same goal (such as writing into an ID which stores the headlight relay status rather then writing a message ID that is used to report the current headlight switch position).

data protection: The CAN protocol includes some level of basic protection for all messages, but you'll find that some important IDs on the Wrangler (CAN-C IDs below $0100) may contain a constantly incrementing counter and/or a special byte at the end which sums up all seven digits before them (a checksum). Both of these fields are used to prevent tampering and to ensure the integrity of those messages. This technique is most often used on critical automotive data such as brakes, steering, acceleration, etc. Transmitting your own messages with these protected IDs may result in detection by the ECU, and an engine code will be generated which documents your transgression. (It can be cleared like any other engine code.)

deploying the airbag / bricking your vehicle: Someone might tell you that working on your vehicle's CAN bus is dangerous because you could accidentally deploy the airbag. Sure enough, the Occupant Restraint Controller (the module responsible for the airbag) is connected via the CAN-C network. And it's exact command set is unknown. Given what we know about airbags in general, and given what we know about the Wrangler's use of additional data protection for it's more critical functions, it seems unlikely that you'd trigger the airbag by accident. But no, the chances are not mathematically zero. If you are concerned, there are a number of ways you can make this outcome even more unlikely. You could simply not send any messages and instead only read existing data from the CAN bus. Alternatively, you could restrict yourself to only sending messages with IDs that are well-understood. Or you could limit yourself to avoiding any program which constantly crafts random messages (in an attempt to provoke a new response from your vehicle). Actually, it's a best practice to avoid randomly probing your vehicle like that. Sure, you may not deploy an airbag, but you're far more likely to brick a component, or brick your entire vehicle all together. Don't do that.

shorting the CAN bus: What happens in the unlikely event that you might short the CAN bus (or pull off one of the two bus wires, or short the CAN bus to ground, or brush a +12VDC line across it... those sorts of things)? While none of those conditions are desirable, the Wrangler's CAN bus is designed to continue operating through those very conditions, but not without a slap on the wrist. It's likely that you'll throw an engine code which documents exactly what you did. Unless you've actually cut one of the wires, no permanent damage should have been done. While working on the CAN bus, if you ever do see any strange messages on your dash about a loss of communication with any module, that may be a good time to turn off your engine and figure out what you're doing wrong. If you can't turn off your engine, then unplug the power from your Raspberry Pi.

starting out: Your initial efforts should be focused on reading and understanding the various messages being sent on your CAN bus. But if you want to try your hand at sending a simple message, this will darken the interior dash and door lights and engage the clicking sound of your turn signal for a very brief period of time:

cansend can1 291#000000F000000000​

questions / personal discoveries / participation: If you have any questions, you're in the right place! We're all just building upon the shoulders of those before us. If you make an interesting new discovery, please share! Looking for some idea of what does what? Be sure to visit the very first message in this thread. It contains an Excel spreadsheet which documents many recently discovered CAN IDs for the JL Wrangler.

Ready to start communicating with your vehicle on a more basic level? Join us! We'd love to see more people using this knowledge and sharing their own experiences!

 

[jmccorm]

RASPBERRY PI SHELL SCRIPT:
EXTRACT DATE AND TIME FROM THE CAN-IHS BUS

Ideally, any computer you choose to connect to your CAN bus should be heavily firewalled and/or disconnected from the Internet. This means that your device may not have the ability to read the latest time and keep it's clock in sync. Even more so because your vehicle is in motion and any network-based source for that information may not take your current location (timezone) into consideration.

As it turns out, your vehicle broadcasts the current time and date (presumably from the uConnect radio) on both the CAN-C and CAN-IHS bus once per second using message ID 350. This script reads the value from the CAN-IHS bus and returns the current value in a human-readable format. This can be used as part of an initialization routine, or to regularly check for time zone updates.

Example usage:

# gettime​

12/5/2021 13:11:44​

​

Bash shell script follows:

#!/bin/bash

# This script reads the current date and time from the CAN-IHS bus
# and returns the output.

# The method we use to read any CAN-IHS message with an ID of 350 is stored in $COMMAND.
# The "timeout" command limits how long we're willing to wait to only one second.
COMMAND="timeout -s 9 1 /usr/bin/candump -L can0,0350:0fff"

# If we run into an error, this fuction displays a generic error message and exits.
error() {
  echo "ERROR: Is the vehicle off? Current time and date not found."
  echo "DEBUG: A valid ID 350 message was not seen on CAN-IHS within 3 seconds."
  echo " "
  # Exit with a failure result code
  exit 1
}

# We begin by grabbing out message.
# If we got lucky and received two, we only keep the last one.
can350=$( $COMMAND | tail -1 )

# Display an error and exit if no messages were received.
if [ "$can350" == "" ] ; then error; fi

# Display an error and exit if the clock has not been initialized.
if [ "$( echo "$can350" | cut -c30-43 )" == "FFFFFFFFFFFFFF" ] ; then error; fi

# Extract the hexadecimal numbers from the message.
rawtime="$( echo "$can350" | cut -d# -f2 )"

# Reformat the numbers as hexadecimal bytes with spaces in between them.
rawtime="$( echo "$rawtime" | fold -w2 | paste -sd' ' )"

# Change year so that it is represented as one word instead of two bytes.
rawtime="$( echo "$rawtime" | cut -c1-11,13-20 )"

# Read the six hexadecimal fields as: seconds minutes hours year month day
# Convert to decimal, Reformat as: day/month/year hours:minutes:seconds
time="$( echo $rawtime | { read seconds minutes hours year month day ; \
  printf "%d/%d/%d %02d:%02d:%02d\n" \
    0x$month 0x$day 0x$year 0x$hours 0x$minutes 0x$seconds ; } )"

# Print the result to the screen
echo "$time"

# Exit with a successful result code
exit 0

 

[donmontalvo]

Not for nothing, but the back ticks `` on your command substitutions are a bit obsolete, might want to replace with $(). #justsayin #nicework

 

[jmccorm]

Not for nothing, but the back ticks `` on your command substitutions are a bit obsolete, might want to replace with $(). #justsayin #nicework

I think this is the first time I've been called out for not making POSIX compliant shell scripts. And you know what? That's something I probably should be striving for. (I just hope that I'm not opening up a can of worms here... I seem to recall quite a number of style changes when going POSIX.)

I've tested the changes and updated the post with the modifications.
I appreciate the tip, thanks!

 

[Mx5red]

Looking at this thread reminds me of when I walked into an Honors Classic Literature class in college. That stuff was Greek, too.

 

[donmontalvo]

I think this is the first time I've been called out for not making POSIX compliant shell scripts. And you know what? That's something I probably should be striving for. (I just hope that I'm not opening up a can of worms here... I seem to recall quite a number of style changes when going POSIX.)

I've tested the changes and updated the post with the modifications.
I appreciate the tip, thanks!

Thanks for not taking the feedback the wrong way. I've managed a fair number of RHEL/macOS servers and workstations at the command line, its one of the things that usually gets flagged at my peer review sessions. #thatAndAbsolutePaths #LOL

 

[wolf]

Here's a big gift for someone just starting to get their feet wet. (If visiting this a year later, hopefully we're well past this point.) This contains my findings AND GUESSES so far. PLEASE CONSIDER THIS INFORMATION UNRELIABLE AND NEEDING TO BE VERIFIED, AND REFINED.

Some text (below) may be too wide, requiring you to scroll left-and-right or to enlarge your window.

Refinements and additions are totally welcome!

# Modules ON THE CAN-C BUS (PER SYSTEMS DIAGRAM)
================================================
Secure Gateway, Radio, Emergency Assistance, Occupant Restraint Controller,
Power Steering Pump, Instrument Cluster, Powertrain Control,
Steering Column Control, Anti-lock Brakes, Transmission Control,
Body Control, Tire Pressure Monitoring System, Radio Frequency Hub,
Automatic Sway Bar, Electronic Shift, Steering Column Lock,
Exhaust Temperature, Occupant Classification System, Drivetrain Control,
Driver Detection, Star CAN-C Body Hub, Star CAN-C IP Hub, Diagnostic OBD2 Port

Optional Safety System: Park Assist
Optional Export:        Headlamp Leveling System
Optional Diesel:        Diesel Powertrain Control Unit
Optional eTorque:       Battery Pack Control, Motor Generator Unit,
                        eTorque Powertrain Control Unit

#MODULES ON THE IHS BUS (PER SYSTEMS DIAGRAM)
=============================================
Secure Gateway, Body Control Module, HVAC Module,
Integrated Center Stack Switch Bank Module, Lamp Assembly Tail (Left),
Lamp Assembly Tail (Right), Radio Module, Emergency Assistance Module,
Radio Amplifier, Comfort Seat Steering Wheel, Star CAN-IHS IP Hub,
Star CAN-IHS Body Hub, Data Link Connector 1

Optional Sky One Touch: Power Top Module
Optional Export:        Intrusion Transciever Module


#ITEMS ON A PRIVATE BUS (PER SYSTEMS DIAGRAM)
=============================================
Electronic Shift Module to:
    Tranmission Control Module

Powertrain Control Module to:
    Sensor NOX (1 of 2)
    Sensor NOX (2 of 2)
    Sensor Particulate Matter

#JSCAN uses these IDs for some interior control bitmasks
504? 620?

#TURN SIGNAL
318 TURN SIGNAL STALK
291 TURN SIGNAL SWITCH / FOG SWITCH / headlight knob in off position
    (LIGHTS CAN ACTIVATE WITHOUT THESE VALUES, NOT RELAYS)

#COMMAND: TURN PARKING LIGHT OFF (unverified)
291#00.46.2B.00.00.28.00.00
   SOURCE: https://www.jlwranglerforums.com/forum/threads/canbus-codes.36782/

#DRIVER DOOR STATUS?
09B

#SWAY BAR DISCONNECT?
4CA

#TAZER LIGHTSHOW IN PROGRESS
4C2 FIRST 5 BYTES
504
620
742 - NOT SEEN ELSEWHERE

# CLEARING DTCs - POSSIBLY ENUMERATES EACH CONTROL MODULE
# Might use Tazer, JScan or another tool to see which ID is what module.
4C0, 4C7, 4C9, 4CB, 504, 620, 740, 743, 747, 749, 74B, 762,
7DF, 7E0, 7E1 and possibly with a different use: 7E8, 7E9

#STEERING WHEEL POSITION
023 Starting with 10 00 is dead center
    Additional bytes for... force applied? Resistance? Motor strain?

#GAS PEDAL
081 and 09D -- contained in a byte
               its inverse value is mirrored in several different locations.

#POWER USED? BITS CHANGE UPON PRESSING AUX BUTTONS OR USING HEADLIGHTS
                                       OR WIPERS
13F

#BRAKE
087 then 028, 079, 09B 093 083 127 12B Various bits
407 ACTIVATION IN THE BITMAP? 3rd light?

#EVIC DISPLAY OF SONG NAME
328 LINE CODES:              +-> 2=Artist, 3=Song Title,
                             |   1=Radio Input Name
      4=Start of new line---+|
Lines remaining----------+  ||
                         |  ||
can0  RX - -  328   [8]  30 42 00 42 00 6C 00 75   '0B.B.l.u' <--Artist
can0  RX - -  328   [8]  20 02 00 65 00 46 00 6F   ' ..e.F.o'
can0  RX - -  328   [8]  10 02 00 78 00 4D 00 75   '...x.M.u'
can0  RX - -  328   [8]  00 02 00 73 00 69 00 63   '...s.i.c'
can0  RX - -  328   [8]  00 00 00 00 00 00 00 00   '........' <--END OF MESSAGE

can0  RX - -  328   [8]  50 43 00 45 00 6C 00 65   'PC.E.l.e' <--Song Title
can0  RX - -  328   [8]  40 03 00 63 00 74 00 72   '@..c.t.r'
can0  RX - -  328   [8]  30 03 00 6F 00 20 00 50   '0..o. .P'
can0  RX - -  328   [8]  20 03 00 65 00 72 00 66   ' ..e.r.f'
can0  RX - -  328   [8]  10 03 00 65 00 63 00 74   '...e.c.t' <--TOO MANY CHARS
can0  RX - -  328   [8]  00 03 00 6F 00 00 00 00   '...o....' <--WILL NOT SHOW
can0  RX - -  328   [8]  00 00 00 00 00 00 00 00   '........' <--END OF MESSAGE

    Always transmit 8 bytes. Use "00" for any unused characters.

#MUTE AUDIO ACTIVE (but does not track MUTE BUTTON)?
25D

#STEERING WHEEL BUTTONS -- LEFT/RIGHT/UP/DOWN/OK (ON LEFT):
22D

#STEERING WHEEL BUTTONS -- CRUISE CONTROL:
0B1 - Highest byte (next two are counters)

#FOUR WHEEL TRAVEL (UNSIGNED)
#All four wheels get their own byte which increments with any wheel movement.
#Will increment regardless of if the movement is forward or backwards.
#After about five feet of movement, an FF flag is created in another byte.
07F

#ACCELEROMETER? PITCH/ROLL? (SEAT PRESSURE?)
02B 089

#VEHICLE VIN (MULTIPART) -- NULL TERMINATED
#My own VIN has been replaced with the valid ID for a 2020 Rubicon.
#These three messages constantly repeat themselves over and over.
#Each line is almost exactly 0.1 seconds apart every time.
 (1636391583.192313)  can0  RX - -  3E0   [8]  00 31 43 34 48 4A 58 46   '.1C4HJXF'
 (1636391583.292118)  can0  RX - -  3E0   [8]  01 4E 36 4D 57 37 35 36   '.N9LW246'
 (1636391583.392040)  can0  RX - -  3E0   [8]  02 35 33 30 00 00 00 00   '.350....'

#HVAC FAN SPEED AND TEMPERATURE (source for some: redracer):
332 - SENSING OF _ACTUAL CURRENT FAN SPEED_ IN 6th BYTE
2B1 - FAN KNOB/AUTO in first byte, others SWITCHING A/C BAFFLES FOR HOT/COLD
2b1#01 - 07 hvac fan speed status
2b1#00.00.?? Temperature status

#BUTTONS (source: redracer):
230#?? 01 ac off 03 ac on 07 defrost 00 all off status
22d#00.00.00.??.?? 10 00 left arrow, 00 01 right arrow, 40 00 down, 00 04 up
318 ?? : 01 left blinker stalk, 02 right, 08 moment high beam, 04 hold high beam, 10 wipers moment,


#REMOTE LOCK / UNLOCK:
1C8 1C0 291... unclear if 02B and 07B involved.

#SHUTDOWN INVOLVED:
401 402

#COUNTERS (NOTE: Some counters also seem to store important
#                information. Perhaps as a timestamp for those events?)
023
02F
071
079   [8]  80 00 00 00 00 00 60 3F   '......`?' Lowest two bytes incrementing
079   [8]  80 00 0F FF 00 00 70 28   '......p(' Unknown meaning of 0F FF
083   [8]  80 04 00 00 00 00 10 63   '.......c' COUNTER
083   [8]  80 04 00 00 00 00 20 29   '...... )'
087   [8]  00 02 00 00 00 6E 40 E5   '.....n@.' COUNTER
087   [8]  00 02 00 00 00 6E 50 28   '.....nP('
087   [8]  07 FF 00 00 00 6E 60 69   '.....n`i'
089   [8]  FF FF FF 6D FF FF E0 FF   '...m....' COUNTER
089   [8]  FF FF FF 6D FF FF F0 FF   '...m....'
089   [8]  FF FF FF 6D FF FF 00 FF   '...m....'
089   [8]  FF FF FF 6D FF FF 10 FF   '...m....'
0A7
0AD
0B1


#General OBD-II PIDs:
#SOURCE: http://obdcon.sourceforge.net/2010/06/obd-ii-pids/
===========================================================
$01 = Show current data

                Bytes                                   Min     Max
Mode    PID     returnd Description                     value   value   Units   Formula (in decimal)
01      00      4       PIDs supported [01 - 20]                                Bit encoded [A7..D0] == [PID 0x01..PID 0x20]

01      01      4       Monitor status since DTCs cleared.                      (Includes malfunction indicator lamp (MIL) status
                                                                                and number of DTCs.) Bit encoded. See below.
01      02      8       Freeze DTC
01      03      2       Fuel system status                                      Bit encoded. See below.
01      04      1       Calculated engine load value    0       100     %       A*100/255
01      05      1       Engine coolant temperature      -40     215     °C      A-40

                                                        (RICH)  (LEAN)
01      06      1       Short term fuel % trim—Bank 1   -100    99.22   %       (A-128) * 100/128
01      07      1       Long term fuel % trim—Bank 1    -100    99.22   %       (A-128) * 100/128
01      08      1       Short term fuel % trim—Bank 2   -100    99.22   %       (A-128) * 100/128
01      09      1       Long term fuel % trim—Bank 2    -100    99.22   %       (A-128) * 100/128

                                                                        kPa
01      0A      1       Fuel pressure                   0       765     (gauge) A*3
                                                                        kPa
01      0B      1       Intake manifold abslt pressure  0       255     (abslt) A

01      0C      2       Engine RPM                      0       16383.75 rpm    ((A*256)+B)/4
01      0D      1       Vehicle speed                   0       255     km/h    A

                                                                        ° relative
01      0E      1       Timing advance                  -64     63.5    to #1
                                                                        cylindr A/2 – 64

01      0F      1       Intake air temperature          -40     215     °C      A-40
01      10      2       MAF air flow rate               0       655.35  g/s     ((A*256)+B) / 100
01      11      1       Throttle position               0       100     %       A*100/255
01      0D      1       Vehicle speed                   0       255     km/h    A

                                                                        ° relative
01      0E      1       Timing advance                  -64     63.5    to #1
                                                                        cylindr A/2 – 64

01      0F      1       Intake air temperature          -40     215     °C      A-40
01      10      2       MAF air flow rate               0       655.35  g/s     ((A*256)+B) / 100
01      11      1       Throttle position               0       100     %       A*100/255

    [More data continues, see original document.]

CODE FRAGMENTS FOUND IN OTHER PROJECTS:
=======================================

# Some general Chrysler values found in another project.
#https://github.com/karlyamashita/common_libraries/blob/master/CHRYSLER_CAN_ID.h
#-------------------------------------------------------------------------------

#ifdef CHRYSLER_V5
// MSCAN (IHS)
// Dodge Durango 2017 // // hands free on BOTH front speaker outputs
// Dodge Charger 2016 // hands free only on front RIGHT speaker output
// Jeep Grand Cherokee 2017 // hands free only on front RIGHT speaker output
// Dodge Ram 2017 // hands free only on front RIGHT speaker output

#define POWER_MODE_ID 0x122
#define RADIO_AUDIO_STATUS_ID 0x30F
#define RADIO_PHONE_AUDIO_STATUS_ID 0x30D // Hands free uses seperate volume
#define SWC_TURN_SIGNAL_ID 0x318// SWC BT Command VR and Answer in Dodge Ram Diesle Truck
#define SWC_ID 0x22D // basic audio controls. Dodge Ram SWC ID is 0x318
#define LIGHTING_STATUS_ID 0x3B2
#define DIMMER_DOOR_PARKING_BRAKE_ID 0x2FA
#define BRAKE_GEAR_INFO_ID 0x332
#define RAP_ID 0x12B
#define DASH_BUTTONS_ID 0x2D3
#define AMP_STATUS_ID 0x354
#define VEHICLE_SPEED_ID 0x340 // or 0x322?
#define VIN_ID 0x3E0
#define DASH_BUTTONS_ID 0x2D3
#define VOLUME_TUNE_KNOB_ID 0x273
#define RPM_SPEED_ID 0x322
#define TURN_SIGNALS_SWITCH_ACTIVE_ID 0x2A8

// below for Jeep Cherokee 2015-2017, 52 pin connector
#define POWER_MODE_JEEP_CHEROKEE_ID 0x20B
#define HYDRALIC_BRAKE_JEEP_CHEROKEE_ID 0x5DC
#define GEAR_INFORMATION_JEEP_CHEROKEE_ID 0x190
#define TURN_SIGNAL_JEEP_CHEROKEE_ID 0x4A1
#define DIMMER_JEEP_CHEROKEE_ID 0x5CA
#define LIGHTING_STATUS_JEEP_CHEROKEE_ID 0x337
#define DOOR_STATUS_JEEP_CHEROKEE_ID 0x339
#define RAP_JEEP_CHEROKEE_ID 0x192
#define VIN_JEEP_CHEROKEE_ID 0x3D3
#define VOICE_ANSWER_HANGUP_ID 0x4A3
#define HYDRAULIC_BRAKES_ID 0x5DC
#define DIMMER_ID 0x5CA // 34-200

// Steering Wheel Controls
#define SWC_BUTTON_RELEASE 0x00
#define SWC_LEFT_UP 0x10
#define SWC_LEFT_DOWN 0x20
#define SWC_LEFT_MIDDLE 0x40
#define SWC_RIGHT_UP 0x04
#define SWC_RIGHT_DOWN 0x08
#define SWC_RIGHT_MIDDLE 0x01

//Power Mode
#if defined CHRYSLER_V5 // need to check if this is for CRYSLER_V4 or V3
#define POWER_MODE_OFF 0x00
#define POWER_MODE_ACCESSORY 0x03
#define POWER_MODE_IGNITION 0x04
#define POWER_MODE_CRANK 0x15
#define POWER_MODE_MASK 0x1F

// Gear Information
#define GEAR_PARK 0x0D
#define GEAR_REVERSE 0x0B
#define GEAR_NUETRAL 0x00
#define GEAR_DRIVE 0x01

// 74HCT4052 or FSAV331 switches
#GUESS: Video switchers only for those who have built-in trail camera?
#define NO_VIDEO 0xFF
#define REAR_VIDEO 0
#define FRONT_VIDEO 1
#define LEFT_VIDEO 2
#define RIGHT_VIDEO 3

#JK SCAN DOCUMENT
#These values are completely wrong for us, and it is in OpenDocument
#format. But I think he sets the bar for how we should be documenting these.
https://github.com/BiggRanger/CANBUS-Vehicle-Reverse-Engineering


PERSONAL NOTES FOR USING CAN-BASED COMMANDS ON RASPBIAN:
========================================================
# initialize to 500kbps for CAN-C network listen-only mode
ip link set can0 up type can bitrate 500000 listen-only on
ifconfig can0 txqueuelen 65536
ifconfig can1 txqueuelen 65536
#ip link set can1 up type can bitrate 1000000 dbitrate 8000000 restart-ms 1000 berr-reporting on fd on

#check status of CAN network
ifconfig | more

#listen to any CAN message:
candump any
candump can0
candump -ta -c -a -d -e -x any
candump -ta -c -a -d -e -x can0,087:fff   # ID FILTER:MATCHING BITMASK
candump -ta -c -a -d -e -x can0,ffff:0400 # IDs 400-4FF

#sniffer
cansniffer -B -c -v 0x3ff -m 0xf00 can0
cansniffer -B -c -v 0x2ff -m 0xf00 can0
cansniffer -B -c -v 0x03ff -m0xf00 -v 0x04ff -t 100 -h 20 -l 4 can0

#send something
cansend can0 111#FF
cansend can1 000##11.22.33.44

#get module status
dmesg | grep -i can

[    6.082632] CAN device driver interface
[    6.109042] mcp251x spi0.0 can0: MCP2515 successfully initialized.
[    6.122284] mcp251x spi0.1 can1: MCP2515 successfully initialized.
[  104.418340] IPv6: ADDRCONF(NETDEV_CHANGE): can0: link becomes ready
[  108.789716] IPv6: ADDRCONF(NETDEV_CHANGE): can1: link becomes ready
[  123.985383] can: controller area network core
[  124.000906] can: raw protocol

#shutting down
ifconfig can0 down

#automatically enable can0 interface at boot time
#(example only, values need to be changed)
/etc/network/interfaces -----
auto can0
iface can0 inet manual
    pre-up /sbin/ip link set can0 type can bitrate 500000 listen-only on
    up /sbin/ifconfig can0 up
    down /sbin/ifconfig can0 down

I have no idea or knowledge about any of this but it leads to me asking, why? What’s the purpose of what your doing. It’s evident that you guys are Einstein’s off spring some how. I’m sure I missed something at the start of this. I do admire you guys though. I’m sure there’s a purpose and we will all benefit in the future. Thanks.

Sponsored